For founders with a working prototype

Your prototype works in the demo. Here’s what breaks when real users arrive.

Logins, permissions, real data, failures nobody can see and a deploy that lives on one laptop. Here’s how Prodmake reviews what you’ve built, keeps what’s sound, and ships one production release in 50 days or less once the scope is agreed.

Kuan, founder of Prodmake · 3 min read

The demo goes well. Someone clicks through the main path and it does exactly what it should. Then a real customer signs up, gets halfway through and loses their work. Or two people edit the same record. Or you need to fix one bad entry and realize there’s no way to do it without a developer.

None of that shows up in a demo. All of it shows up in week one.

Where prototypes actually break

It’s rarely the main feature. It’s everything around it:

  • Access becomes real. Logins, permissions and private data can’t be placeholders anymore.
  • Failures need a path. Integrations fail and edge cases happen, and someone has to see what went wrong and correct it.
  • The product needs an operator. Without admin tools and visibility, every routine correction becomes another engineering request.
  • The deploy depends on one person’s machine.

Why we don’t start with a rewrite

Code generated with AI, or written fast, isn’t rejected on principle. What matters is what it has to do reliably in production. So we inspect first, then decide what stays, what gets repaired and what gets replaced. If it truly needs a rebuild, we’ll explain why and keep whatever product knowledge it already holds.

From there:

  1. We review the product and the code: what the prototype proves, what can be kept, and what blocks a credible release.
  2. We agree one bounded outcome in writing: the user path, the risks, the tradeoffs and the acceptance criteria, before your backlog turns into a promise.
  3. We close the gap and ship it: the UX, architecture, data, access, admin, integrations, deployment and monitoring that path needs.

Once the scope is agreed and the code and accounts are accessible, accepted scopes deploy in 50 days or less. If review shows the work is bigger, we define a narrower first release instead of stretching the promise.

Show me the prototype

Bring the demo and the codebase context. A person reads every brief.

Production is the part that matters

At Lane Technologies I built the mobile release infrastructure: automated CI/CD for web and mobile releases and the developer tooling the whole product team used, as their tenant-experience platform scaled across portfolios including Colliers and Tishman Speyer.

Illustration: twelve app tiles converge into one release pipeline of build, staging check, and launch, ending on a phone.

“Kuan was able to quickly and effectively respond to the requests of our customers as well as identify their potential needs even before they were apparent.”

Andy MacDonald, Director of Engineering, VTS (formerly Lane)

Our own Reader AI took the same path, from an AI reading demo to accounts, sync and cross-platform mobile releases shipped together. And at AuditBoard I worked on application, service and infrastructure changes where correctness wasn’t optional.

Is this right for you?

It works best when:

  • You have a working prototype or inherited codebase, and we can access it.
  • You know who the user is and what the release has to achieve.
  • Someone can make product tradeoffs and give it 1 to 2 hours a week.
  • You’re open to the review deciding what can be reused.

It isn’t the right fit if you want an unlimited backlog finished in one stage, a fixed quote before anyone has seen the code, or if the prototype is standing in for evidence that anyone wants it.

What happens next

Show us the prototype: what it does, who it’s for, and the production outcome that matters first. It starts with two quick questions, and then you can book a fit call or keep writing.