Two failure modes account for most wasted software budget in specialist businesses. The first is buying a generic platform and spending three years bending the business to fit it. The second is building everything, including the parts a hundred vendors have already solved better than you will.
The rule that avoids both is simple to state and uncomfortable to apply: build the thing that wins you work, buy everything else.
Applying the rule honestly
Take each capability in your process and ask one question: if we did this noticeably better than our competitors, would we win more work or make more margin? If yes, it is a candidate to build. If no, it is a candidate to buy.
- Payments, email delivery, e-signature, accounting, calendars, file storage, authentication — buy. Nobody has ever chosen a contractor because of their invoicing software.
- Pricing logic, qualification rules, the shape of your pipeline, the way a job moves through your operation — build. This is where your advantage lives, and it is exactly what generic tools flatten.
- Reporting sits in the middle. Buy the storage and the charts; build the definitions, because how you define margin is a business decision, not a software one.
Custom software is not a status symbol. It is a decision about where your process is genuinely different.
The integration tax nobody budgets for
The obvious objection to “buy the boring parts” is that you end up with six tools that do not talk. That is a real cost, and it is the cost most projects underestimate. The answer is not to build everything; it is to treat integration as a first-class part of the system rather than as a series of one-off scripts.
Practically, that means one event model, retries with a ceiling, readable field mapping, and an audit log. It means nothing fails silently — a webhook that quietly stops firing costs far more than one that fails loudly at three in the morning. Build that layer once, properly, and every subsequent integration is configuration rather than a project.
How this looks in a first build
A typical first system for a specialist business is smaller than people expect. Custom: the enquiry record, the qualification rules, the pricing engine, the pipeline, and the internal screens the team lives in. Bought: authentication, payments, e-signature, email and SMS delivery, accounting, and hosting. Integration: an event layer joining them.
That split usually delivers in six to ten weeks rather than nine months, and it leaves you with something you can extend. The tell that you got the split wrong is the second project: if extending the system means rebuilding it, the boundary was drawn in the wrong place.
A note on lock-in
Buying the boring parts creates dependency, and that is acceptable as long as the dependency is on a commodity with alternatives. Payment providers are interchangeable; a vendor that holds your pricing logic in a proprietary format is not. Keep your own data model, keep the logic that is yours, and the boring parts remain replaceable.