From"WeWantSomethingLikeThat"toaDeveloper-ReadyProductin8Weeks

A travel client came to us with a reference point and no differentiator. Here's how we got from a vague idea to a fully coded prototype their developer could build from.

A client came to us recently with a familiar version of a brief: "we want to build something like this other company."

It's one of the most common ways a project starts, and one of the hardest... because there was no differentiator. The incumbents in their space were enormous and well-funded. When we asked what their moat would be, they weren't sure. They knew they wanted to build something, but they didn't yet know what made it worth building.

This is travel, a category where the big players have been consolidating for two decades with budgets that make direct competition unrealistic. Building a slightly different version of an existing product would have been a fast way to spend a lot of money on something nobody needed.

So we didn't start with design. We started with the harder question.

Discovery and strategy over a few weeks

A lot of agencies treat discovery as a single workshop. Two hours, some sticky notes, a summary document, move on to wireframes. That format works when a client already knows what they're building and needs help articulating it. It doesn't work when the strategic question is still wide open.

What we did instead was run several sessions over a couple of weeks, with digestion time in between. We'd surface ideas together, pressure test them, and then they'd go away and sit with it. Come back with reactions, objections, new information about their business we hadn't known. Repeat, until we were comfortable moving forward on some ideas.

An important part of running any workshop is being flexible, leaning into what the other party is saying. It's not just a canned sequence, but a directed one, with an intention to learn and uncover. We let that happen, in order to help set a starting direction.

The differentiator was already there

The thing that unlocked this project wasn't a clever new concept we invented. It was realizing the client already ran other businesses, and those businesses had assets and capabilities the incumbents couldn't quite replicate.

They hadn't connected those dots themselves. That happens a lot. When you're inside a business, the things that make you unusual feel ordinary. You've been doing them for years. It takes someone from outside asking naive questions to notice that what you consider routine is actually a structural advantage.

Once we found the angle, everything downstream got easier. The product had a reason to exist. The positioning wrote itself. The feature set stopped being "what does the competitor have" and became "what does our specific advantage make possible."

That's the part of the process that's hard to sell and hard to skip. If we'd started designing in week one, we would have built a competent product with no reason for anyone to choose it.

What we actually handed over

This is where most agency projects fall apart, and it's the part we care most about.

The typical handover is a set of Figma files. Beautiful, detailed, and static. The developer receiving them now has to interpret every spacing decision, guess at every interaction, and rebuild the whole thing from scratch in code. Design intent gets lost in that translation, and the client pays for the same work twice.

What we delivered instead:

  • A fully coded clickable prototype in HTML, CSS, and JavaScript, exported as a zip their developer could open and run immediately. Responsive web with proper desktop and mobile treatments, plus native app designs, including motion graphics and UX interactions, all coded rather than static.
  • A complete design system, documented and structured so it could be fed directly into AI tools to accelerate building the real platform.
  • Documentation explaining how the pieces fit together, so nobody had to reverse engineer our thinking.

Their developer didn't receive a specification to interpret. They received a working thing to build from.

Eight weeks, because they didn't know what they wanted yet

The whole project took about eight weeks. That included the extended discovery, multiple rounds of iteration on the deliverables, and feedback time for the client to review and respond without being rushed.

Our Zero to MVP process runs in four weeks when a client walks in knowing what they're building. This one took twice that, and the extra four weeks went largely into discovery. It was the work of figuring out the USPs.

We realize this is only possible now because of how the tools have changed. Building (three!) fully coded prototypes used to be multiple projects. Now it's something we can do inside the design process, which means the client gets something real to react to instead of a picture of something real.

The design is done and they're moving forward with development on their MVP, so they can test with real users.

What this means if you're in the same position

If you're sitting on a vague idea and a reference company you admire, that's a normal place to start. The mistake is treating it as a finished brief and hiring someone to execute it.

The questions worth answering first: what is your USP? what do you already have that your competitors don't? What becomes possible because of your specific situation that wouldn't be possible for someone else?

Those answers are often already in the room; they just need someone to ask.

See how Zero to MVP works →

Hitomi Abiko

Author

Hitomi Abiko

Hitomi Abiko is the co-founder and CEO of Skydea, a web and app design agency based in Tokyo. A UX designer turned founder, she writes about the places where design, technology, and business collide — and what that means for the companies building in that space.

ReadMore