Why Agencies Can't Build Your MVP

Most founders say "MVP" when they mean prototype.

A prototype is the expression of your preconceptions made into a product, a way to showcase what you think you will build. It's a deliverable you can specify.

An MVP is more a process than a deliverable. It is the minimum viable solution to a problem you've identified people may pay for. A loop of building, measuring, and learning until you find something that works.

Handing off your prototype to an agency, a freelancer, or an engineer friend who couldn't care less about your product is fine. They build to spec, you get your deliverable, everyone's happy. But expecting the same to work for your MVP can lead you to slow iterations, uncapped costs, and ultimately may cost you your business.

Building a prototype is like building a boat in a boatyard. You have blueprints, shipwrights put things expertly into place, you inspect the finished product and a few months later toast with mimosas on some paradise cove.

Building an MVP is more like fixing your boat in the middle of a storm. You're onboard. You know what's leaking and what's making a weird sound. Imagine having to update the ship's blueprints every time you need to plug a hole or clear a fuel line.

Pre-PMF development requires judgment about what to build and how. This judgement requires a deep understanding of your product, business and customers that can only be achieved by an embedded partner. Anyone beyond the "spec wall" will need you to make those judgement calls for them.

The Spec Wall

Having external developers (Agencies, Freelancers, your genius engineer friend with 3 O'Reilly publications who treats your business as a side project) means every iteration of the product requires you to define concise specs you will throw over a metaphorical wall and come out with a product built to those specs after.

The problem isn't competence. It's that pre-PMF, you're not only changing specs every Tuesday, you are also learning what to specify. A lot of your knowledge is implicit. It lives in the conversation you had with a frustrated customer last Tuesday. It's in the pause before they said "I guess that works." You can't write that into a spec document. You can't throw it over a wall.

It is widely known that tacit knowledge is difficult to capture without extensive personal contact, regular interaction, and trust.

Even if you could write down everything—all the implicit and explicit knowledge about your customer and domain—the communication overhead of each iteration makes it untenable. Every cycle requires writing specs, negotiating scope, negotiating cost, waiting for delivery, reviewing, and repeating. In a stage where your single mission is to reduce uncertainty as fast as possible, this overhead is an unacceptable hindrance.

The wall works when specs are known and stable. Internal tools with a controlled user base. Steady-state systems in established companies. Your bakery's website. But if you're testing hypotheses, you're not in that world. And I'm yet to meet anyone who can help you in this stage without riding the storm with you.

The Cost is Iteration Velocity

Pre-PMF means hypotheses to test and a business model still forming. User feedback arrives faster than you can negotiate the scope and cost of the next release.

Good agencies may significantly reduce initial build time vs. your rag-tag tech team. But in-house development consistently outperforms on iteration cycles. The first build is the easy part. It's everything after—when users tell you what's actually wrong, when you need to pivot the core flow, when you discover the feature you thought was secondary is actually the whole product—that determines survival.

The cost isn't bad code. Early code is throwaway anyway. The cost is lost velocity and explosive iteration costs during the window when velocity determines survival and your company runway is your savings.

I've worked with great agency partners. Talented people with extremely professional delivery and code that read like poetry. But the specs overhead and hours negotiations mean you cannot possibly iterate at the speed you need. By the time you've documented the change, negotiated the scope, and scheduled the work, your prospect forgot about you, your user churned, your bank balance lost a digit.

The storm keeps changing. You can't keep throwing new blueprints over the wall fast enough.

What Embedding Actually Means

Embedding isn't about office location or hours logged. It's about the questions someone asks, what problem they come to solve. "What size should this button be?" versus "What should patients achieve on this screen?". Deliver on the scope vs. make your customer happy.

The first question comes from someone executing against a spec. One is an employee and the other is a business partner. The first person needs you to make every decision. The second person makes decisions that move the business forward.

An embedded technical partner has deep, transversal understanding of your business and customer problem. They build complexity where it matters and take shortcuts where it doesn't. They intuit the unspoken domain requirements—the stuff so obvious to you that you'd never think to write it down. Like what kinds of "under construction" errors are tolerable in your domain and which ones erode customer / user / patient trust.

Contractors optimize for delivery against spec. Your pre-PMF technical partner must deliver business outcomes.

The Mission

Pre-PMF, your single mission in product development is to turn hypotheses about imaginary users into certainty about paying customers. Anything that slows this down is an unacceptable trade-off.

In choosing who to partner with, you need to look for someone willing to jump on your ship and survive the storm, not someone who needs a blueprint to build it onshore.