Every few months a team looks at an invoice and says: we could build that in a sprint. Sometimes they are right about the sprint. They are almost never right about the three years that follow it, because the sprint is the cheapest part of building anything.
The decision comes up for the same handful of pieces: authentication, billing, search, chat, notifications, feature flags, analytics. Each has a mature vendor with public pricing, and each looks tantalisingly simple from the outside. Authentication is a form and a token, until you are implementing session revocation, SAML for one enterprise customer, and a password reset flow that survives someone's mail server marking you as spam.
This post does two things. First the test that comes before any arithmetic, because most build-or-buy decisions are settled by what the thing is rather than what it costs. Then the arithmetic itself, with a calculator that counts the maintenance nobody puts in the estimate.
The test that comes before the arithmetic
Martin Fowler's distinction between utility and strategic software is the clearest framing I know. Utility software is the plumbing: he writes that for a business "software is like sewage pipes, I want it to work reliably and I don't want to know about the details". Strategic software is the part where moving faster than a competitor is the point.
The practical version for a founder is one question: can customers tell the difference, and is it why they chose you?
If your product is a marketplace, your matching and ranking are strategic; your login page is not. If you sell a search product, search is the company; if you sell a recipe site, search is a feature you should rent. The same component sits in different quadrants at different companies, which is why blanket advice about never building auth is nearly as unhelpful as building it by default.
There is a second question worth asking beside it: what happens if this thing is mediocre? A mediocre ranking algorithm in a marketplace loses customers. A mediocre notification service sends emails a few seconds late. Build where mediocre is expensive.
What building actually costs
Three lines, and only the first one ever makes it into the plan.
The build. Hours times a rate. A working authentication system with social logins, sessions, password reset and an admin view is perhaps 300 to 400 hours if you have done it before. At a senior freelance rate in the $61–80 band that Arc.dev publishes, call it $22,400 at 320 hours and $70 an hour.
The maintenance. This is the line that decides the whole argument. Dependencies age, providers change their APIs, a library gets a CVE, browsers change cookie behaviour, and one enterprise customer asks for SAML. My default is 20% of the original build cost per year, which for this example is $4,480, and I have never seen a long-lived component come in under that. It is not a one-off: it repeats every year the product exists.
Running it. Servers, storage, backups and monitoring for this piece specifically. Call it $150 a month.
There is a fourth cost that never appears in any table: the roadmap you did not ship. The engineer maintaining your homegrown billing system is not building the thing customers asked for. When I run PostEngage alone, that trade is brutally visible, because every hour spent on infrastructure is an hour the product does not move. A ten-person team feels the same thing, more slowly and less honestly.
What buying actually costs
Vendors publish their prices, which makes this side easy to check and easy to misread. Three examples, all current:
| What | Published price | Source |
|---|---|---|
| Authentication | $25/month, 50,000 monthly retained users included, then $0.02 each | Clerk |
| Billing | 0.7% of billing volume, on top of payment processing | Stripe Billing |
| Search | free to 10,000 searches, then $0.50 per 1,000 searches and $0.40 per 1,000 records | Algolia |
Two things to notice. First, the entry price is close to nothing, which is the point: vendors price to remove the reason to build. Second, each price is tied to a unit that grows with your success. Users, billing volume, searches. A percentage of billing volume is the clearest case: at $200,000 of monthly billings, Stripe Billing's 0.7% is $1,400 a month for software whose cost to run does not change with your volume at all.
That is not an accusation. Usage pricing is how the free tier gets paid for, and it is usually a bargain early. But it does mean the build-or-buy answer has an expiry date attached, and the expiry arrives with growth.
Three years, side by side
The defaults below are that authentication example against Clerk's published pricing: 320 hours at $70, maintained at 20% a year with $150 a month of infrastructure, against $25 a month with 50,000 users included and $0.02 for each one after, starting at 50,000 users and growing 60% a year.
calculator · cumulative cost, maintenance included
Build it or buy it, over three years
building it yourself
buying it
cumulative cost, year by year
what building takes on
- Every hour of maintenance is an hour not spent on the product.
- The person who wrote it becomes the only person who can fix it.
- Security and compliance work never appears in the original estimate.
- The build competes with your roadmap for the same engineers.
what buying takes on
- Their price rises when your usage does, and repricing is their decision.
- Their outage is your outage, and their SLA is a refund, not a fix.
- Migrating away later costs more than building would have cost today.
- Your data lives in their account, which matters at a sale.
Build cost is hours times rate in year zero, plus maintenance as a share of that build each year, plus the monthly running cost. Buying is the platform fee plus per-unit pricing on whatever exceeds the included allowance, with units growing at the rate above. Neither side counts your own time managing it, which is real in both cases and larger when you build.
Over three years, building costs about $41,200 and buying costs about $26,800. The first year is not close: $28,700 against $300, because you pay the whole build up front while the vendor's fee is inside their free allowance. By year three, growth has pushed the bought option to $19,000 a year on its own, and the curves are converging.
They cross in year four, at about $47,500 built against $64,300 bought. By year five, the bought option has cost $131,200 because usage has grown to 328,000 units, and the built one has cost $53,800.
So: does that mean build? Usually not, and the reasons are worth being precise about.
Why the crossover year is a trap
Your growth assumption is doing all the work. At 60% a year, usage multiplies more than six times in five years. Set growth to zero and buying wins for as long as the product exists. The crossover is a forecast about your business, not a fact about the software, and most forecasts of 60% compound growth are wrong in the optimistic direction.
The requirements change before the crossover arrives. In year four you will not be maintaining the system you built in year one. You will be adding enterprise single sign-on, or an audit log, or a compliance regime nobody mentioned at the start. Vendors price those as add-ons too, and Clerk lists enterprise SSO connections at $75 a month each, but their version arrives finished.
The vendor's problems become yours. Their outage is your outage, and their SLA is a refund policy rather than a fix, which is the same trap as any dependency on the request path. A repricing announcement is a project you did not plan. Both are real costs of buying, and neither shows up in the per-unit price.
The build gets a bus factor. The person who wrote your billing engine becomes the only person who understands it, and that is a risk that grows quietly until they resign.
The honest summary is that buying is right far more often than engineers want it to be, and building is right far more often than the "never build undifferentiated software" slogan allows. The tipping factors are usually not cost at all: an unusual requirement the vendors do not serve, a margin structure that cannot absorb a percentage fee, or a piece of the product customers actually notice.
quick check
Your usage is flat and a vendor charges $400 a month for something you estimate at 300 hours to build. What does the arithmetic say?
300 hours at a senior rate is roughly $21,000, and maintenance at 20% adds about $4,200 every year. The vendor costs $4,800 a year and does not grow. The build starts $21,000 behind and only closes the gap at about $600 a year, which takes decades.
Keep the seam either way
The most useful habit is to make the decision reversible. Whichever side you pick, put your own interface in front of it: your code calls identity.verify() or search.query(), and the vendor's SDK lives behind that boundary, in one place.
That costs a few hours and buys three things. You can swap vendors without touching the rest of the product. You can build the replacement incrementally later, running both sides in parallel. And you can test your code without the vendor's sandbox being up.
It also changes the conversation with the vendor. A customer who can leave in a month negotiates differently from one whose product has the vendor's SDK scattered across two hundred files. This is the same discipline as defining service boundaries before you need them, which is why splitting a system too early hurts while defining the seams early does not.
The ones almost nobody should build
| Buy, in nearly every case | Worth building when it is your core |
|---|---|
| Payment processing and billing | Pricing, packaging and metering logic unique to you |
| Email and SMS delivery | The ranking or matching that customers chose you for |
| Authentication and session management | Domain workflows your competitors do not have |
| Error tracking and log aggregation | The data model everything else depends on |
| Feature flags and A/B assignment | An integration with a system only you talk to |
The left column has something in common: it is regulated, commoditised, or judged by reliability rather than cleverness. Nobody has ever chosen a product because its error tracking was homegrown. The right column is the opposite; if you outsource it, you are outsourcing the reason to pick you.
One more nuance on the left column. Buying does not mean not understanding. When I built EMPRO alone, I bought almost everything that was not the product, and still had to know how each piece failed, because being the only engineer means the vendor's edge case is your 2am problem regardless of who wrote the code.
questions people ask
How do you calculate build versus buy?
Compare cumulative costs over at least three years. Building is hours times rate, plus maintenance every year, plus infrastructure. Buying is the subscription plus per-unit charges as usage grows. Then check the answer against whether the component is core to what customers pay for.
What is a realistic maintenance cost for software you build?
A reasonable planning default is 20% of the original build cost every year, covering dependency upgrades, security fixes, provider changes and small feature requests. It repeats for as long as the product exists, and it is the line most estimates leave out.
When does building your own become cheaper than a SaaS?
Only when usage grows past the vendor's pricing tiers, or when the price is a percentage of something that scales, such as billing volume. With flat usage, a bought component is usually cheaper for the life of the product.
Should a startup build its own authentication?
Usually not. Published pricing starts near zero, and the hard parts, such as session revocation, enterprise SSO and account recovery, arrive finished. Build it only if your identity model is genuinely unusual or it is the product itself.
What are the risks of buying instead of building?
Price rises you do not control, outages you cannot fix, a migration that gets more expensive every month, and your customer data living in someone else's account, which is a question at any acquisition. Wrapping the vendor behind your own interface limits all four.
Does build versus buy change as a company grows?
Yes, in both directions. Usage pricing gets more expensive with scale, while a larger team can absorb maintenance more easily. The decision is worth revisiting when a vendor's bill becomes a visible share of infrastructure spend.
The short version
Ask what the thing is before you ask what it costs. If customers can tell the difference and it is why they chose you, build it. If it is plumbing, rent it, and spend the hours on the part of the product nobody else can supply.
When cost does decide, compare three years rather than the first invoice, and put maintenance in at about a fifth of the build cost every year. That single line is what turns a sprint into a mortgage. Then make the decision reversible by keeping the vendor behind your own interface, because the thing most likely to change is not the price: it is what you need the component to do.