How I Helped Build a Product From Scratch as a Test Engineer
In early 2017, a friend called me and said:
“I want to build an app. I don’t have a tech team. No developers. Nothing. Can you help?”
At the time, I had around three years of experience as a Test Engineer.
I wasn’t a programmer. I wasn’t a designer. I hadn’t led a product before.
But I understood systems, risks, and how things break when assumptions go unchecked.
So I said yes.
The Problem Wasn’t Technical. It Was Operational Chaos.
My friend ran a small image-editing business. Clients sent raw images and instructions using Google Drive, email, and massive Excel sheets.
Every image had different instructions.
Editors scrolled endlessly.
File names didn’t match rows.
Steps were missed.
Rework was common.
The system technically worked. Operationally, it was fragile.
He explained the vision clearly:
Clients upload images and provide instructions per image
Editors log in, process images, and upload results
Clients review, approve, request changes, and pay
He didn’t want to outsource.
He wanted to own the product and evolve it over time.
What he needed wasn’t just developers.
He needed clarity before code.
That’s where I stepped in.
I Didn’t Start With Requirements. I Started With Risk.
I made one thing clear upfront:
“I don’t write production code. But I can help you build this product.”
Instead of jumping into feature lists, I focused on understanding failure.
I kept asking questions like:
Where do instructions get lost today?
What happens when filenames don’t match?
What if clients upload hundreds of files?
What breaks first when usage increases?
What does ‘done’ actually mean for each role?
These weren’t abstract discussions.
They shaped decisions early, before anything was built.
Most importantly, I refused to let assumptions slide.
If something sounded obvious, we slowed down and validated it.
That habit alone saved us from rework later.
Modeling the Product Using Excel (Yes, Excel)
We didn’t have mockup tools.
So I modeled the system in Excel.
Not to “design screens,” but to expose thinking.
I laid out:
Client workflows
Admin controls
Editor task views
Using cell borders, tables, and notes, I mapped:
What users see
What actions are possible
What states an image or job can be in
As we walked through these sheets with developers and the designer, gaps surfaced fast:
Missing error states
Unclear ownership of files
Confusion around partial uploads
Edge cases no one had considered
Excel wasn’t the point.
The conversations it triggered were.
Those sheets became shared mental models for the team.
Building the Team Around the Work, Not Roles
We assembled a small team:
A freelance designer
A backend developer
A front-end developer
I sat in the middle, but not as a manager.
My role was to:
Translate business intent into testable behavior
Challenge solutions that optimized for speed but increased risk
Continuously test ideas before they became code
I tested flows, not features.
I questioned “happy paths.”
I asked what happens when users behave badly or unexpectedly.
That shaped the product more than any checklist ever could.
Our Version of Agile Was About Learning Fast
We didn’t follow Scrum by the book.
We followed feedback.
We used:
Trello to visualize work and priorities
Excel to track flows, decisions, and open questions
We broke work down by user behavior, not components.
We reviewed changes frequently.
We cut scope aggressively.
For example:
Worker workflows were partially manual in the first release
Automation came later, once we understood real usage
Testing influenced those decisions.
Not as a gatekeeper, but as a reality check.
Launch Exposed Everything We Didn’t Know
We launched after three months.
Within a day, real users broke our assumptions.
Large image files killed performance
RAW formats like CR2 and NEF failed uploads
Some clients uploaded hundreds of images in one go
A DDoS attack hit us within the first week
None of this showed up in internal testing.
And that’s the point.
Testing isn’t about predicting everything.
It’s about being ready to learn fast when reality disagrees.
We responded by:
Optimizing backend performance
Expanding file format support
Improving error feedback
Monitoring usage patterns closely
The product survived because we treated failures as signals, not surprises.
What This Experience Changed for Me
This project reshaped how I see testing.
I learned that:
Testing is how teams reduce uncertainty early
Testers don’t need perfect requirements to add value
Modeling and questioning are more powerful than tools
The earlier testing starts, the cheaper honesty becomes
I didn’t “become” a developer or a product manager.
I stayed a tester.
I just practiced testing where it mattered most: before and during building.
Closing Thought
If you’re a Test Engineer waiting for the product to be “ready” before stepping in, you’re already late.
Products don’t fail because of missing test cases.
They fail because of unchallenged assumptions.
Testing is how we surface those assumptions early.
And that’s how testers help build products, not just verify them.
If you found this helpful, stay connected with Life of QA for more real-world testing experiences, tips, and lessons from the journey!