Introduction
Founders often assume that building something themselves will be cheaper. In reality, custom software is usually the most expensive option, once maintenance, hiring, opportunity cost and operational responsibility are added in.
The question is not "can we build it?" The question is "should we build it?" Building creates flexibility. Buying creates speed. The mistake is assuming flexibility is always more valuable than speed at the stage you are in.
This framework helps you decide where building actually pays off, and where it merely satisfies an engineering instinct.
What it solves
What building is good at
-
Differentiation that customers feel
When the thing you build is the reason customers pick you, off-the-shelf will not get you there. Custom is the only path to a feature that competitors cannot copy in a checkbox.
-
Workflows nobody else has standardised
When your category is new or your process is unusual, no vendor has built for it yet. Building is the only option that fits the shape of the work.
-
Data you cannot let leave the building
Regulated industries, sensitive customer data or competitive intelligence sometimes force a build because the alternative is unacceptable, not because it is cheaper.
-
Cost curves at scale
At very high volume, per-seat or per-call pricing can outgrow the cost of a custom system. This rarely applies to early startups, but when it does, building stops being optional.
-
Direct control over change cadence
When a workflow must change weekly with the business, depending on a vendor's release schedule slows the team. Building puts the change speed inside the company.
What it does not solve
What building will not fix
-
A lack of customers
Building a feature does not produce demand. If the product is not selling, custom software will not change that, it will only add maintenance to the same situation.
-
Slow internal decisions
Build velocity is bounded by decision velocity. If product decisions take weeks, custom software will not be faster than the SaaS your competitors are already using.
-
An unclear roadmap
Custom software amplifies whatever roadmap the team has. A clear roadmap with off-the-shelf tools beats an unclear roadmap with a custom platform every time.
-
Vendor management discipline
Bought systems still need owners, contracts, renewals and exits. Building does not free you from that work; it changes who owns the dependency.
-
A weak product team
Custom software shifts the problem from 'we cannot configure this vendor' to 'we cannot build this ourselves'. If the team is the bottleneck, the build is not the answer.
Decision tree
Six questions before you build
Run every build proposal through these questions. The 'no's are where buying or assembling almost always wins.
- Question 01
Does this create competitive advantage?
No → Buy. Anything that does not differentiate you is a cost centre dressed up as a project.Yes → Confirm the advantage with a customer in a real situation, not in a workshop. - Question 02
Would customers choose us because of this?
No → Buy. If customers do not care, the build is for internal reasons, which is a weaker case than it feels.Yes → Confirm at least three customers can articulate the advantage in their own words. - Question 03
Can existing software solve 80% of the problem?
No → Building may be justified. Start with the smallest custom piece around the bought core.Yes → Buy the 80%, configure where possible, build the differentiated 20% only. - Question 04
Can we switch vendors later?
No → Treat lock-in as a real cost. Sometimes a temporary custom solution buys optionality you would otherwise lose.Yes → Buy with confidence. Reversible decisions are cheaper than irreversible ones almost every time. - Question 05
How much maintenance will custom software create?
No → Estimate the recurring engineering cost honestly. Most teams underestimate maintenance by 2-3x.Yes → Treat the maintenance cost as a permanent line item, not a one-time investment. - Question 06
What happens if the developer disappears?
No → Increase the bus factor before building. A custom system maintained by one person is a liability waiting to be discovered.Yes → Document, version, and add at least one more capable owner before the system goes live.
Common mistakes
Five common mistakes founders make
- 01
Building everything from scratch
Auth, billing, email, analytics, support, dashboards, every commodity layer built in-house adds months to the timeline and decades of maintenance. Build the differentiated 10%; buy or assemble the rest.
- 02
Underestimating maintenance
Custom software has a build cost and a maintenance cost. The maintenance cost is usually larger, recurring and easier to ignore. Budget for both before deciding.
- 03
Ignoring existing tools
Many 'we need to build this' problems are actually 'we did not search hard enough' problems. A 30-minute review of existing SaaS often turns a quarter-long project into a Tuesday-afternoon configuration.
- 04
Building because it feels safer
Custom feels controllable, but control is not the same as advantage. Most startups confuse the comfort of building with the value of the build.
- 05
Building before validating demand
Building a differentiated feature for a product that has not yet found fit is the most expensive form of guessing. Validate the demand first, then build the difference.
Alternatives
Practical alternatives to a full build
Four patterns that get most of the value of a build without the cost of building everything.
-
Buy the commodity, build the difference
Use off-the-shelf software for the 80% that is not differentiated, and build only the part where you actually win. Most startup products fit this pattern naturally.
-
Assemble with low-code or no-code
Tools like Airtable, Retool, Zapier, Make, n8n and Supabase let you ship internal tools and customer-facing experiences in days. Often this is enough to validate before building the bespoke version.
-
Open source + thin custom layer
Use a mature open-source platform and add the thin layer that makes it yours. Cheaper than building, more flexible than buying, and the community handles most of the maintenance.
-
Partner instead of buy or build
Sometimes the right answer is not a tool but a service partner. They solve the problem; you focus on the product. Easier to start, easier to stop, and often cheaper than both build and buy.
Ronald's rule of thumb
Build what makes you different. Buy everything else.
Custom software has a place, when the result is something competitors cannot replicate, customers can feel, and the business can defend. Outside of that narrow window, buying is faster, cheaper and lower risk. The hard part is being honest about how narrow the window actually is.
, Ronald · YourStartup.Expert
Summary
Summary
Building creates flexibility. Buying creates speed. Most early-stage startups need speed more than flexibility. The six questions above eliminate the wrong reasons first: no advantage, no customer interest, an 80% off-the-shelf fit, easy switching, manageable maintenance, and a bus factor above one.
When a build does make sense, scope it to the differentiated 20%, buy or assemble the commodity 80%, and budget for the maintenance line that will outlive the build itself. That is the discipline that keeps build decisions from quietly turning into the next rewrite.
Common questions
Build or buy, answered.
The questions founders ask before they commit to a software path.
- Is building software cheaper than buying?
- Almost never, once the full cost is included. Build cost is one line; maintenance, hiring, on-call, security patches, dependency upgrades, infrastructure and opportunity cost are five more lines that recur every year. For most early startups, buying the commodity layers and building only the differentiated 10-20% is dramatically cheaper than custom-building everything from scratch.
- When should we build instead of buy?
- When the thing you build creates customer-visible differentiation, when off-the-shelf cannot cover the workflow, when data sensitivity forces it, or when the cost curve at scale flips against per-seat pricing. If none of these is true, buying is almost always faster and cheaper. Build the differentiator; buy everything that is not.
- What is the biggest hidden cost of building?
- Maintenance. Custom software needs continuous updates, security patches, dependency upgrades, monitoring, on-call coverage and feature work as the business evolves. Most teams underestimate maintenance by a factor of two or three. Budget the recurring cost as carefully as the build cost; the recurring cost is usually larger over the lifetime of the system.
- Can we start by buying and build later?
- Yes, and this is often the smartest path. Buying gets you to revenue faster; the data you collect by running the bought system tells you what to build. Many startups discover after a year that the custom version they planned to build is not what customers actually need. Buy first to learn; build later to differentiate.
- What about low-code or no-code as a middle path?
- Often the best of both worlds for early stages. Low-code tools (Retool, Airtable, Zapier, Make, Supabase, n8n) let you assemble custom-feeling experiences in days. They are easier to change than custom code and faster to ship than bought software. They run into ceilings at scale, but for most startups the ceiling is comfortably above their first 1,000 customers.