Building an MVP without a technical co-founder

Building an MVP without a technical co-founder usually means one of two bad trades: an agency that builds exactly what you specify and owns none of the judgment about whether it is right, or a no-code tool that cannot survive contact with real users. There is a third option. Hire the judgment a technical co-founder provides, on a fractional basis, from someone who also writes the code. That is what I do.

This page assumes you have already decided to build. If you are still weighing whether to build, buy, or outsource, that decision belongs on a different page: should you build or buy it. What follows here is how I build, once building is the answer.

The technical co-founder problem

Pre-seed and seed founders without a technical co-founder usually pick from three flawed options. A development agency builds what you ask for and has no incentive to tell you the spec is wrong; you still need someone senior on your side to direct it and check its work. A no-code tool gets you a demo fast, then hits a wall the moment real usage, real data, or a real integration shows up. A full technical co-founder is the right answer at the right stage, but the equity is given away once and is hard to take back, and good ones are in thin supply, especially in Hong Kong specifically.

The fourth option is a fractional technical co-founder: the same architecture and hiring judgment, the same hands-on building, without a permanent equity stake or a full-time salary. I work this way because it is the version of the fractional CTO model built for founders who do not have a product yet, not just teams who already do. If the fractional model itself is new to you, here is what it actually is.

How I build: proof of concept, MVP, product

The build runs in three stages, and each one ends with something real, not a deck:

• Proof of concept. The riskiest assumption in the idea, proven or killed cheaply, before real money goes into the rest.
• MVP. Scoped to what real users need to prove the product works, not the full wishlist. Architecture decided to support what comes after, not just what ships first.
• Product. Iteration on what users actually do, in AI-agent augmented build cycles, toward a product that can carry a growing team.

I write the architecture and the code myself, with AI agents multiplying the output, the same way I would work as a technical co-founder with equity on the table. That includes the governance a hands-on build still needs. CodeRabbit's State of AI vs Human Code Generation Report found AI-authored pull requests had about 1.7x more issues than human-only ones (470 pull requests, December 2025), so review discipline applies to my own commits, not just a team's.

What I've built this way

At FanForce, a pre-seed social rewards startup, I have been the hands-on product and technology lead since 2024: product vision, architecture, and most of the code across three major iterations, including an AI evaluation pipeline that scores roughly a million tweets across 2.5 million accounts for quality and community loyalty. The platform went from zero to 20,000 users on a two-person team.

Earlier, at Zwoop, I was the first technical hire: built the e-commerce platform's microservices architecture and the data pipelines behind its machine-learning core, reaching 98% accuracy in product matching, while the company raised multiple multi-million dollar rounds. Two different products, the same way of working: architect it, build it, hand it to a team that can run with it.

What "done" means, and who owns the code

You own the codebase from the first commit, not just the finished product. It is documented and tested well enough for your own team to inherit it, or for me to keep building with you, whichever you decide once you are there. There is no vendor lock-in, no proprietary platform, and no rewrite tax waiting for you six months in.

"Done" for an MVP is not every feature you can imagine. It is the smallest real product that lets you learn whether the idea works, built on architecture that will not need to be thrown away when it does.

Who this is for

This is built for a non-technical founder, pre-seed to seed, who has the idea and the budget but not the product or the technical leadership to build it. If you already have engineers and the problem is that they ship slowly, the fit is different: start with an engineering team audit instead. And if what you need is someone to make the build-versus-buy call before any code gets written, that is the question build vs buy answers.