1. Home
  2. Founder Academy
  3. Product & MVP
  4. Build, buy, or do not do it at all

Build, buy, or do not do it at all

The most valuable engineering decision is usually not writing the code. Three questions that settle it.

10 min read · Level 2

The point

The most valuable engineering decision is usually not to write the code. Technical founders default to building because building is what they are good at and enjoy, and because a vendor's price looks expensive next to code that feels free — which ignores that their own time is the most expensive input in the company and that maintenance is forever. Build the thing that is the reason people pay you. Buy the rest, and fake whatever is left.

What is it?

For any capability the product needs, there are three options: build it, buy it (a service or library), or do it manually until it genuinely matters.

Technical founders default to building, because building is what they are good at and what they enjoy.

Why does a founder care?

Because engineering time is the scarcest resource you have, and every hour spent rebuilding authentication is an hour not spent on the thing only you can build.

The test is simple: is this part of why customers choose you? If not, buy it or fake it.

Example

The scheduling product's decisions:

Capability — Decision — Reasoning

Rota generation algorithm — Build — This is the product. Nobody else's is right for this workflow.

Authentication — Buy — Nobody chose you for your login. Weeks of work, zero differentiation, and worse security than a specialist.

Email delivery — Buy — Deliverability is a whole discipline.

Billing — Buy — Tax, dunning, invoices, compliance. Enormous and invisible to the customer.

Holiday requests — Manual — Do it by hand for ten customers and learn how it should work.

Reporting — Do not do it — Nobody asked.

The pattern: build the thing that is the reason people pay you. Buy the infrastructure. Do the rest by hand until a pattern emerges.

A founder who builds their own auth and billing has spent two months producing something worse than a $50/month service, while the actual product stood still.

The common mistake

First-time founders often build infrastructure because it feels like real engineering and because a vendor's price looks expensive compared to 'free' code they write themselves. Their own time is the most expensive input in the company, and the vendor's price is almost always lower than two weeks of it — before counting maintenance for ever.

The second mistake: buying something that IS your differentiation. If the algorithm is why customers choose you, do not outsource it to an API.

How it works

Step 1: Ask whether it is why customers choose you

If yes, build. If no, it is a candidate for buying or faking.

Step 2: Price your own time honestly

Two weeks of founder time is worth far more than a year of most subscriptions — and the subscription has no maintenance cost.

Step 3: Consider doing it manually first

For ten customers, almost anything can be done by hand. It also produces the best specification you will ever have.

Step 4: Check the exit cost before buying

How hard is it to move later? Deep coupling to a vendor's data model is the expensive part, not the monthly fee.

Step 5: Revisit as you scale

A sensible buy at ten customers can become an expensive one at ten thousand. Set a threshold to reconsider.

When to use this

Every time a new capability is needed, and especially whenever someone says 'we could just build that'.

When not to use it

Do not buy something that is genuinely your core differentiation, and do not manually fake something that is safety- or money-critical.

How founders actually did it

Nobody chose you for your login screen

The recurring pattern is a founder spending two to three weeks on authentication and billing — producing something less secure and less complete than a service costing a few tens per month — while the product that differentiates them stands still. The cost never appears on an invoice, which is exactly why it goes unnoticed.

Price two weeks of your own time honestly before comparing it to a subscription. The comparison is rarely close.

Check the exit cost, not the price

The monthly fee is rarely what makes a vendor expensive. What makes leaving hard is coupling to their data model, and teams discover this when they try to move years later. The question to ask before adopting is how the data comes out, not what it costs to go in.

Buy freely where the data is portable. Be far more careful where the vendor would end up owning the shape of your information.

Do this now

  • List everything currently being built
  • Mark each as build, buy or manual
  • Cancel anything that is not why customers choose you

Create a free account to read the rest and apply it to your own startup.

Previous: What product-market fit actually is