Build vs buy software
Most teams argue about cost. The decision actually turns on whether the process is one you compete on.
The verdict
Buy software for any process your industry runs the same way, and build it when the process is how you win or when no product will fit the systems you already run.
Payroll, email and accounting are solved. Somebody else pays to keep them working, and their answer is better than yours will be. Buy those and stop thinking about them.
The interesting case is the third option nobody puts on the slide. You buy the boring parts and build the thin layer that makes them yours.
The costs each side forgets
Every row here is a real bill that lands after the decision, not a feature comparison. The bottom two are where the argument usually gets lost.
| What you are weighing | Buying | Building |
|---|---|---|
| Time to first use | Days. Someone else already built it. | Months. Nothing exists on day one. |
| Fit to your process | Close, then never closer. You bend to it. | Exact, and it stays exact as you change. |
| Who maintains it | The vendor, whether you like their choices or not. | You, or whoever you pay to. This is the cost people miss. |
| Integration with what you run | Whatever their API allows. Their roadmap decides. | Whatever the systems expose. Your roadmap decides. |
| Price direction | Per seat, and it goes up as you grow. | Front-loaded, then flat. Support is the ongoing part. |
| What happens on a bad day | You open a ticket and wait in a queue with everyone else. | Someone who knows the code looks at it, if you kept that person. |
| The exit | Their export format, and a migration you did not scope. | Your database and your code, which is only an exit if it is documented. |
| Compliance evidence | Their certifications, which auditors accept quickly. | Yours to produce. Slower, and you control exactly what it says. |
| The failure nobody plans for | The vendor is acquired and the roadmap you depended on is cancelled. | The one engineer who understood the data model leaves. |
Which one is your situation?
Four questions about your business rather than your preferences. Answer honestly and the result is usually obvious.
Would a competitor run this process the same way you do?
How many systems must this agree with?
Who will own it in two years?
Has anyone tried a product for this already?
Every outcome
- Buy it
- The process is standard and a product already handles it. Buying means somebody else pays for the maintenance, the security patches and the compliance paperwork. Spend your engineering somewhere it changes the outcome.
- Build it
- The process is how you compete, or no product will agree with the systems you already run. Custom software development is where we do this work, and the decision that matters most is who maintains it afterwards.
- Buy the base, build the layer
- Buy the parts that are solved and build the thin layer that makes them yours. Shift Link buys identity and storage from Supabase, then builds the compliance rules that decide who may work a shift.
Buying
Where it wins
- It works the day you pay for it.
- Maintenance, security patching and uptime are somebody else's payroll.
- Auditors accept a vendor's certifications faster than they accept your documentation.
- You find out quickly whether the process was worth automating at all.
Where it hurts
- You bend your process to the product, and every year the gap between them widens.
- Per-seat pricing grows with headcount whether or not the value does.
- Integration stops where their API stops, and their roadmap is not yours to move.
- A vendor acquisition can cancel the feature your operation depends on, with no appeal.
Building
Where it wins
- It fits the process exactly, and keeps fitting when the process changes.
- It can agree with every system you already run, including the old one nobody wants to touch.
- You own the data model, so reporting is a query rather than a support ticket.
- The advantage is yours instead of being available to every competitor for the same monthly fee.
Where it hurts
- Nothing exists on day one, and the useful version takes longer than the demo.
- Maintenance is now your bill. This is the cost that sinks build decisions, not the build itself.
- You produce your own compliance evidence, which is slower than pointing at a vendor's certificate.
- Undocumented code is not an asset. It is a hostage situation with extra steps.
- Name itWrite the process down first.
- ShopTry two products properly.
- MeasureWhat percent of the job did they do?
- SplitBuy the base. Build the gap.
- AssignName who owns it in year two.
Teams skip the shopping step and build something that already existed. Others skip the last step and buy a system nobody owns.
Rules that settle most of these
The question is not which option costs less. It is which cost you would rather carry for the next five years: a subscription that grows, or a system that needs an owner.
- 01Buy it if a competitor could run the same process on the same product and nothing would change.
- 02Custom is the answer when the process is the reason customers pick you.
- 03Split it when a product does most of the job and fights you on the rest.
- 04Do neither if nobody has written the process down yet. Software cannot fix a rule nobody agrees on.
- 05Buy it, whatever the analysis says, if you cannot name the person who owns the custom version in year two.
What we tell people who ask us to build
We sell custom software, so treat this with the suspicion it deserves. We still talk people out of building, and the reason is always the same. Nobody could name who owns it in year two.
The split answer is what we actually ship most. Shift Link buys identity, storage and realtime from Supabase. On top of that it builds one rule: nobody gets scheduled until a UK Government API confirms their right to work. No product sells that rule, because it belongs to one staffing firm in one country. Manual compliance checking dropped 70%.
Field teams push this further. Buying gets you an app that assumes a signal, and an app that works with no signal is usually something you build.
Where the custom answer was right
Common questions
01Can you do both?
Yes, and it is usually the right answer. Buy the parts that are solved, such as identity, payments and storage, then build the layer that encodes how your business actually works. This keeps the maintenance bill small because you only own the part nobody else could sell you.
02Is building always more expensive than buying?
No, and the comparison people run is the wrong one. A build is front-loaded and then mostly flat, while a subscription is small and grows with headcount every year. The cost that decides it is neither of those. It is maintenance, and only the build side pays it directly.
03How do we know if an off-the-shelf product is close enough?
Run the real process through a trial, not a demo, and count what you had to work around. Under about a fifth of the job left over, buy it and live with the workarounds. Much more than that and the workarounds become a second unmanaged system made of spreadsheets.
04What if we already bought something and it does not fit?
Keep it for what it does well and build only the gap. Ripping out a working system to replace it wholesale is the most expensive version of this decision. We have built the missing layer on top of tools clients already paid for more often than we have replaced them.
05Does buying protect us from vendor risk?
It moves the risk rather than removing it. A vendor can be acquired, raise prices or retire the feature you built an operation around, and you have no vote. Building moves that risk onto your own ability to keep an owner assigned, which is at least a risk you can see.
