Buy anything your competitor can also buy. Build only the thing they choose you for. That is the entire rule. Build or buy arguments run long because applying it honestly means admitting that your favourite internal project is a worse version of something you could rent this afternoon.
We build custom software for a living, so weigh the next part accordingly: most of what a company runs should not be custom, and a good share of what gets built in-house is a CRM that could have been rented for the price of a fortnight of engineering time.
Commodity and edge
A commodity is anything your competitor can buy on the same terms you can. A customer relationship manager is a commodity. So is payroll, email, error tracking, payments, and the database under all of it. Nobody has ever chosen a supplier because that supplier had written its own CRM.
Your edge is the part of the product a customer would notice if it disappeared. It is usually narrower than people expect, and it is almost never the part that was fun to build.
So when the question is whether to build something that already exists as a product, start by asking which of those two things it is. If a competitor can sign up for the same tool tomorrow, building it buys you nothing they cannot match in a day.
One product, and every call we made on it
We built a ticketing platform where event organisers onboard, create events, sell passes and scan them at the door. Here is what we bought, and the reason in each case was the same: a competitor could buy it too.
- Payments. Razorpay. Payments is a commodity to us and a compliance department to them. Building it means holding card data and inheriting an audit.
- Push notifications. Firebase. There is no version of this we could write that is better than the free one.
- OTP over SMS and WhatsApp. Bought. Delivery to a phone network is somebody else’s relationship with carriers.
- The database and cache. Postgres on Aurora Serverless, and Valkey. Managed, because the alternative is becoming a database administrator by accident.
- Scaling. AWS auto-scaling. A scheduler is not a differentiator.
And here is the one thing we built: pass scanning that survives a venue with bad internet. Scans queue on the device and reconcile when the connection returns, without letting the same pass through twice. No product sells that for this use case, and it is the difference between a queue moving and a queue stopping at the one moment the client cannot afford it.
That is the shape of a healthy decision list. Five bought, one built, and the built one is the reason the product works at a real venue on a bad day.
The same rule inside an AI feature
On another system we built image similarity search over a library of roughly five million photographs, answering in under 200 milliseconds for about a million monthly active users.
We did not write a vector database. We used Qdrant, because a vector store is a commodity and a very good one is free. What we built was the part that is not: the embedding pipeline, the index strategy, the reindexing and the backfill. A vector database is something you install. Making five million images answer in under 200 milliseconds is something you design, and it is where every hour of that project paid for itself.
The same split holds for most AI work: the model and the store are bought, and the retrieval, the evaluation and the failure cases are built.
The two costs people get wrong
Buying: the sticker price is not the cost. The cost is per-seat creep as you hire, and the exit. Before you adopt anything your workflows will live inside, ask what leaving costs. Your data will be exportable, because every vendor says so. Your integrations, automations and the habits of the people using it will not be.
Building: the build is the cheap part. A thing you build is maintained for as long as the company exists. Somebody is on call for it. Somebody upgrades the dependency with the advisory against it. The person who wrote it leaves, and the next person spends a month learning what it does before they can change it safely.
A build is not a project. It is a hire you have not made yet.
That is the number missing from most build-or-buy spreadsheets. People compare a one-off build estimate against a recurring subscription, which is comparing the wrong two things. Compare the subscription against the build plus a decade of somebody owning it.
The hard case: when a bought thing becomes your edge
The rule is easy at the extremes and difficult in the middle, and the difficult middle is real. You buy something at twenty people because it is obviously a commodity. At a hundred people the workflow built around it has quietly become how the company makes money.
One marketplace we built for had the problem every marketplace has: vendors will not write their own listings, and an empty listing sells nothing. The answer was automation that turns a short prompt into the description, the FAQs and the imagery.
We did not build a workflow engine. We used n8n and built the prompt pipeline and the data mapping on top of it. The orchestration is a commodity. What the prompts do with that marketplace’s own data is not, and it is the part a competitor cannot copy by buying the same tool.
That is usually the answer in the difficult middle. Not build or buy, but buy the engine and build the part that is yours.
We applied this to ourselves this week
Our own contact address needed a real mailbox, somewhere we could reply from rather than just forward to. Three options: stitch something together free, pay a small amount for one provider, or pay a bit more for another.
The rule settled it in about a minute. Is email deliverability our edge? No. Can a competitor buy exactly the same thing? Yes, in four minutes, with a credit card. So we buy it, and we spend the saved time on something a client is paying for.
The useful part is the temptation we had to turn down. We are engineers. We could run a mail server, and some of us would enjoy it. That is exactly the trap: being capable of building something is not a reason to build it. The question is never whether you can.
It helps that the downside is lopsided. Getting email wrong means an enquiry lands in a spam folder, and one lost enquiry costs more than several years of the subscription. When the failure is that asymmetric, buy the thing with the best track record and stop thinking about it.
Three questions that settle it on a call
- If we buy this, does any customer ever notice? If the honest answer is no, buy it. Internal tooling is not where you earn a reputation.
- If this breaks at 3am in two years, who fixes it? Name the person. If they are not on the payroll yet, you are costing a hire, not a project.
- What does leaving cost? Not exporting the data. Rebuilding every workflow, integration and habit that grew around it.
If a thing is a commodity, cheap to leave and invisible to customers, buy it today and stop discussing it. If it is the reason somebody picks you, build it properly and own it. Almost everything is the first kind.
This rule costs us work, and we apply it anyway
We turn down work that amounts to rebuilding something a client could rent. That is not generosity. An engineering budget spent on an internal CRM is a budget not spent on the thing that wins the next customer, and a client who runs out of money reconstructing commodity software does not come back for the project that mattered.
If you are weighing one of these, tell us what you are building and you will get an honest read on which side of the line it falls, including the times the answer is to buy it and not call us.
Originally published on the Lotus Tech Labs blog.
Top comments (0)