How I Helped Build a Product From Scratch — As a Test Engineer
A story of vision, wireframes in Excel, and stepping up beyond the job title.
“Hey Deepak, I have a favor to ask. I want to build an app… but I don’t have a tech team. No developers. Nothing. Can you help?”
It was early 2017. I had just ~3 years of experience working as a Test Engineer. I wasn’t a programmer. I wasn’t a designer. I hadn’t led a team before.
But this wasn’t about titles.
This was about trust.
About vision.
About building something real.
So I leaned in:
“Alright, tell me more.”
My friend was running a small image editing business. His team was manually handling client projects using Google Drive (and other file transfer tools) to transfer files and Excel sheets for image-specific instructions. The system worked, but it was painful—slow, confusing, and prone to mistakes.
“It’s getting out of hand,” he said. “Each image has different instructions. We scroll through huge Excel sheets, match filenames, miss steps… It’s messy.”
“We need a platform,” he said. “Clients should be able to upload images and write instructions for each. Our editors should log in, work on the images, and upload edited versions. Clients can compare them, approve or request changes, and make payments if they’re satisfied.”
It was a brilliant idea. But he had no technical team, and he didn’t want to outsource.
“We want to own this,” he said. “Build our own product, keep improving it, add more features over time.”
I didn’t know how to build the whole thing alone. But I knew how to think clearly, ask the right questions, and break down complexity. So I jumped in.
How I Approached It – From a Test Engineer’s Lens
I told him clearly:
“I’m a Test Engineer. I don’t write production code. But I can help you build this — from scratch.”
1. Understanding the Vision, Not Just Requirements
Before anything else, I focused on understanding the problem from all sides — not just features, but the why behind them.
I kept talking to stakeholders:
Why does the current process fail?
What does the ideal flow look like?
What will make this easier for the client, the editor, and the admin?
I regularly followed up with stakeholders to verify my understanding.
When I documented requirements, I explained not just what we needed, but why we needed it.
I also created a culture of open discussion in our development team:
I encouraged devs to ask questions.
I never let us assume anything without validation.
Every proposed solution was discussed from the user’s perspective.
2. Mockup Design… with Excel
We didn’t have access to fancy mockup tools at the time.
So I used what I had: Excel.
I created the entire UI — client view, admin view, editor view — using Excel.
I laid out buttons, tables, form fields using cell borders. It looked basic, but it worked.
I showed these to the designer and developers and walked them through screen by screen.
We categorized the system into three user roles:
Client – Uploads images, writes instructions, downloads results
Admin – Manages users, jobs, pricing, status tracking
Worker (Editor) – Views assigned tasks, downloads/uploads images, marks jobs complete
These Excel designs became our wireframes. They guided the front-end implementation exactly as we intended.
3. Building the Team
I helped my friend form the core team:
A freelance designer for branding and UI colors
A backend developer I trusted from past experience
A front-end developer to implement the interfaces
I stayed at the center of it — as the glue.
Writing requirements, verifying flows, sharing feedback, managing timelines, and most of all — testing, continuously.
4. Working in Agile Style
We didn’t follow a strict Scrum process, but we applied agile principles throughout.
And for our setup, we used simple tools that worked:
Trello for task and project tracking
Excel for UI mockups, requirements, and prioritization
Our process looked like this:
We broke down features screen by screen in Trello
Tracked progress visually with cards and lists
Updated requirements and visual notes in Excel
Reviewed changes frequently, refined based on feedback, and kept cycles tight
Our MVP goals:
Build the client-facing platform
Build admin functionalities
Handle the worker side manually until the next release
It wasn’t fancy, but it was focused.
We didn’t aim for perfection. We aimed for clarity, usability, and momentum.
Launch Day — and Real-World Lessons
Exactly three months later, we launched.
Within 24 hours, clients started signing up, uploading raw files, and interacting with the product.
But real users brought real-world problems:
Huge image files slowed the system
Unexpected formats like CR2, NEF, and TIFF caused upload failures
Some clients uploaded hundreds of images at once
We even faced a DDoS attack (within a week)
But our team adapted fast:
The backend was optimized for performance
We expanded file support
We added better feedback for failed uploads
We monitored activity in real time and patched issues quickly
It wasn’t smooth. But it was real.
And it was ours.
What This Experience Taught Me
This journey changed how I viewed my role as a Test Engineer.
I realized:
Testers can drive clarity across the entire product team
You don’t need design tools to design — you need empathy and structure
Good testing starts with asking the right questions
A Test Engineer can be the bridge between business, design, and engineering
More importantly, I saw how testing is deeply connected to building.
Testing isn’t something that happens after.
It’s something that happens throughout.
Final Words
This wasn’t just a project.
It was a transformation.
It taught me that:
You don’t need permission to lead.
You just need purpose, clarity, and the courage to start.
If you're a Test Engineer, don’t wait for the product to be "ready" before you step in.
You belong at the table from day one.
If you found this helpful, stay connected with Life of QA for more real-world testing experiences, tips, and lessons from the journey!