What belongs in an MVP
Cutting scope is the highest-return activity in an early build, and almost nobody does enough of it. Here is a test that settles most arguments.
Build vs buy: when writing it yourself is the wrong call
The build-versus-buy argument is usually had as a comparison between a licence fee and a development estimate. Both numbers are wrong: the licence fee is the smaller part of buying, and the development estimate is a small fraction of building.
We are a company that gets paid to build software, so take the position accordingly: there are several things you should not pay us or anyone else to build.
The test
Is this thing the reason a customer chooses you over a competitor?
If yes, build it. That is your product, and outsourcing it to a vendor means your differentiation is available to anyone else with a credit card. If no, buy it — and be honest, because almost everyone believes their version of a commodity is special.
| Build | Buy | |
|---|---|---|
| It is your differentiator | Yes | No |
| It is a regulatory or commodity function | No | Yes |
| A vendor exists that does 80% of it | Rarely | Usually |
| It needs deep integration with your data model | Often | Check the API first |
| Getting it wrong is a security incident | Only with the expertise | Yes |
What the build side actually costs
The estimate covers writing it. It does not cover owning it, and ownership is where the money goes:
- Maintenance, indefinitely. Dependencies, security patches, breaking changes upstream. This never stops while the product lives.
- The edge cases you have not met yet. Vendors have met them, across thousands of customers. Your version meets them one at a time, in production.
- Compliance drift. Tax rates, regulations and standards change. Somebody now owns tracking that.
- The opportunity cost. Every week spent on a commodity is a week not spent on the thing customers choose you for. This is the largest cost and the one that never appears in a spreadsheet.
- Bus factor. The person who built it becomes the only person who understands it. Inheriting a codebase nobody documented describes where that ends.
Four things to buy, essentially always
- Authentication. There is no upside to building it and a catastrophic downside to getting it wrong. Sessions, password storage, multi-factor, account recovery — this is a solved problem and a large attack surface. Use a provider.
- Payments. Beyond the engineering, card data brings PCI DSS scope you do not want. Use a processor and keep card details out of your systems entirely.
- Email delivery. Deliverability is a specialism involving reputation, authentication records and relationships with inbox providers. Your own mail server will land in spam.
- Error tracking and monitoring. Cheap, mature, and you will build a worse one.
What to build even when a vendor exists
The inverse case matters too, because "buy" can be the lazy answer:
- The core workflow your customers pay for. If your product is scheduling, buy a calendar library, not a scheduling engine.
- Anything requiring joins against your own data. Where a vendor needs a copy of your database to work, integration cost and data risk frequently exceed building.
- Where the vendor's pricing scales with your success. Per-seat or per-transaction pricing on a core function becomes a tax on growth. Model it at ten times current volume before signing.
- Where switching later would be impossible. If a vendor holds data you could never extract, you have sold them part of your company.
The AI version of this question
It arrives now as "should we train our own model". For nearly everyone the answer is no: use a vendor API, and build the part that is actually yours — the retrieval, the evaluation, the workflow around it.
That is the same test as everywhere else. The model is a commodity; several vendors sell one and they get cheaper every year. What your customers choose you for is what you do with it. RAG versus fine-tuning covers where that line sits, and adding AI to an existing SaaS covers choosing the job worth giving a model.
The middle option people forget
Buy now, build later, and design for it. Put the vendor behind an interface of your own so the dependency is one implementation rather than a decision spread through your codebase.
That costs a little more up front and converts an irreversible choice into a reversible one, which is usually worth more than the saving. It is the same argument as starting on Postgres rather than a separate vector database — pgvector versus Pinecone makes it in detail.
What we do
On every MVP build we tell you which parts we think you should buy, and the list is usually longer than clients expect. Building your own authentication is not a project we will take, and we will say so on the first call.
Where something genuinely is your differentiator, that is what the engagement should be spent on — which is also the part where what belongs in an MVP matters most.
Frequently asked questions
How do I decide whether to build or buy software?
Ask whether the thing is the reason a customer chooses you over a competitor. If yes, build it — outsourcing your differentiator makes it available to anyone with a credit card. If no, buy it. Then multiply any build estimate by roughly three to account for maintenance, unmet edge cases, compliance drift and opportunity cost. If buying still looks expensive after that, build.
What should you never build yourself?
Authentication, payments, email delivery, and error tracking. Authentication has no upside and a catastrophic downside when wrong. Handling card data brings PCI DSS scope you do not want. Email deliverability depends on reputation and relationships with inbox providers. Monitoring tools are cheap, mature, and you will build a worse one.
When is building the right call even if a vendor exists?
When it is the core workflow customers pay for, when it needs joins against your own data and the vendor would need a copy of your database, when the vendor's pricing scales with your success and becomes a tax on growth, or when switching later would be impossible because they hold data you could not extract.
Should we train our own AI model or use an API?
Use an API for almost all cases. The model is a commodity — several vendors sell one and prices fall every year. What customers choose you for is the retrieval, the evaluation and the workflow you build around it, and that is where the engineering effort belongs. Training your own is justified by a specific constraint, not by a preference for owning it.
References
- PCI Security Standards — PCI Security Standards Council
Keep reading
What it costs to run a SaaS
Everyone asks what the build costs. The number that decides whether the business works is the one that arrives every month afterwards, forever.
Adding AI to an Existing SaaS Product
The hard part is not the model. It is choosing which job to give it, and building the parts around it that decide whether anyone trusts the output.