Build versus buy is rarely answered honestly by either side of the market: SaaS vendors insist nobody should ever build, and development agencies insist every workflow is special. The truth sits in a question neither asks — how unusual is your workflow, really? Most dispatch-and-report operations fit known patterns and should buy. A meaningful minority run on job rules, evidence requirements, or customer commitments unusual enough that off-the-shelf tools mean permanent daily workarounds — and for them, building or a hybrid path wins over any three-year horizon. This guide lays out costs, risks, the underestimated parts of building, and a framework for deciding without either sales pitch.
Typical UK ranges in 2026. Per-user SaaS pricing compounds with team growth; build costs amortise. Cross the lines at your own team size.
The real question: how unusual is your workflow?
Strip away the sales narratives and the decision reduces to workflow distance — the gap between how your operation actually runs and the pattern the best off-the-shelf tool assumes. Measure it concretely: demo two or three leading tools against your mapped workflow and count the workarounds. Every 'we'd handle that in a spreadsheet on the side', every 'the technicians would just have to remember', every field that means something different to your team than to the tool is distance. A handful of workarounds is normal and buying is right. When the workaround list is long enough that the tool would define your operation rather than serve it, you are in build or hybrid territory.
Map your workflow first, then demo against it
Count workarounds explicitly — they are the metric
Few workarounds: buy. A defining list: build or hybrid
Ignore both vendor and agency sales framing
Buy when the workflow is standard
Off-the-shelf software is the right answer more often than development agencies admit. If your dispatch, forms, customer updates, and reporting match a known industry pattern, a mature SaaS product delivers in weeks what a build delivers in months — with mobile apps already hardened, integrations already written, and a support team already staffed. The honest costs are the subscription that scales with headcount forever, the roadmap you do not control, and the pricing reviews you cannot veto. For a five-person team on £40 per user, that is £2,400 a year — excellent value against a £20,000 build. For a forty-person team, the same maths reads £19,200 every year, and the comparison starts to invert.
Weeks to live, hardened mobile apps, staffed support
Right answer for standard dispatch-and-report patterns
Costs scale with headcount forever
Roadmap and pricing sit with the vendor
Build when the workflow is the advantage
Custom software earns its cost when the workflow itself is part of how you win and keep contracts: evidence chains competitors cannot match, customer portals shaped to a major client's exact needs, compliance reporting that turns audits from risk into sales material, or job logic that encodes years of operational judgement. In those cases generic tools do not merely inconvenience — they flatten the very thing that differentiates you. A build gives you a bespoke data model, a technician experience shaped to your jobs, reporting that mirrors your contracts, and total control of roadmap and cost structure. The price is real: meaningful upfront investment, a 6–12 week path to first value, and permanent ownership of maintenance.
Right when workflow, evidence, or reporting is the moat
Bespoke data model and technician experience
Roadmap and per-user economics fully yours
Own the maintenance — forever, and budget for it
The hybrid path: build the edge, buy the core
Most real decisions land here. Hybrid means running proven components for the standard parts — auth, database, file storage, maybe an off-the-shelf scheduling core — and building only the layer where your operation is genuinely unusual: the forms, the evidence rules, the report generation, the customer portal. Modern stacks make this dramatically cheaper than it was five years ago; platforms like Supabase and Next.js let a focused team ship a tailored operational layer in weeks, not quarters. Hybrid also de-risks sequencing: replace the most painful part of the workflow first, integrate with the tools that already work, prove value, then expand — no big-bang migration, no betting the operation on a rewrite.
Buy the commodity core, build the differentiated edge
Modern stacks (Supabase + Next.js) cut hybrid costs sharply
Replace the most painful workflow first, then expand
No big-bang migration risk
What gets underestimated when building
Build estimates fail in predictable places, and they are worth naming before signing anything. Offline sync looks like a feature and is actually an architecture — conflict handling, retry logic, and partial-sync behaviour consume a large share of real engineering effort. Evidence integrity (photos always attached to the right job, nothing silently lost) is harder than any demo suggests. Report generation swallows time because customers want documents pixel-perfect against old templates. Role-based access sounds simple until auditors define it. And the quiet one: the second year, when the person who championed the build has changed roles and someone must own updates, hosting, and small fixes. A build quote that does not address these five is not yet a real quote.
Offline sync is architecture, not a feature
Evidence integrity and report generation eat estimates
Role-based access balloons under audit requirements
Year two ownership: name the maintainer before starting
A decision framework you can run in a week
Day one: map the workflow from job request to signed report and list every current workaround. Days two and three: demo the two strongest off-the-shelf candidates against the map, counting new workarounds each would introduce. Day four: get an indicative hybrid or build quote against the same map from a development partner — a serious one will scope the smallest useful first version, not the cathedral. Day five: run the three-year maths for each path at your realistic team size, including subscriptions, build amortisation, maintenance, and the cost of the workarounds themselves in admin hours. The spreadsheet usually makes the decision obvious; when it is genuinely close, buy first and keep the build option for when the workaround list grows.
One week: map, demo, quote, three-year maths
Cost workarounds in admin hours — they are not free
Scope builds as the smallest useful first version
When close, buy first; revisit as workarounds accumulate
Common questions
Frequently asked questions
Should we build or buy operations workflow software?
Buy when an off-the-shelf product matches your workflow closely — count the workarounds in a demo against your mapped process to test it. Build or go hybrid when your dispatch, evidence, compliance, or customer-reporting path is unusual enough that daily work would be defined by workarounds.
How much does custom operations workflow software cost in the UK?
A focused first version typically runs £8,000–£50,000 depending on offline needs, integrations, and reporting complexity, with hybrid builds on modern stacks often landing £3,000–£15,000. Compare against SaaS at £25–£80 per user per month over three years at your real team size.
What gets underestimated most when building operations workflow software?
Offline sync, evidence integrity, report generation, and role-based access. They look like edge cases during scoping but represent most of the engineering effort in production systems — plus year-two maintenance ownership, which should be named before the build starts.
Is there a middle ground between building and buying?
Yes, and it is where most good decisions land: buy or reuse proven components for the standard core — auth, storage, scheduling — and build only the layer where your operation is genuinely unusual, such as forms, evidence rules, and report generation. Modern platforms make this path materially cheaper than full builds.
How long does a custom operations software build take?
A well-scoped first version typically reaches real users in 6–12 weeks, with hybrid approaches at 4–8. The reliable predictor is scope discipline: builds framed as the smallest useful workflow ship; builds framed as everything-at-once slip.
When does SaaS per-user pricing stop making sense?
Run the maths at your growth headcount, not today's: £40–£80 per user per month across a growing team, compounded over three years, frequently exceeds a build that amortises. Teams crossing roughly 20–30 field users are usually in the zone where the comparison deserves a serious look.