Key facts
- Off-the-shelf: lower upfront cost, faster start, shared roadmap you do not control
- Bespoke: higher upfront cost, exact fit, you own the code and data
- Hybrid is common: a package for standard functions, bespoke for the parts that differ
- Per-user subscription costs grow with headcount; bespoke running costs mostly do not
- Integration quality often decides the outcome more than features do
- dijitul quotes bespoke work at a fixed price after a free chat
The short answer
Buy off-the-shelf when a product does nearly everything you need, your process is similar to other businesses in your sector, and the vendor has a healthy track record. Accounting, payroll, email and HR are classic examples: there is no advantage in having your own payroll engine.
Build bespoke when the software is how you compete, when you are working around a package more than with it, when several systems need to act as one, or when subscription costs keep rising with every new starter. Many of our clients do both: they keep Xero, Microsoft 365 and a standard CRM, and build a bespoke system for the operational core that makes them different.
Side-by-side comparison
| Factor | Off-the-shelf (SaaS or package) | Bespoke software |
|---|---|---|
| Upfront cost | Low: setup and configuration | Higher: discovery, design and build |
| Ongoing cost | Subscription, usually per user or per transaction | Hosting and support, usually flat |
| Time to start | Days to weeks | Depends on scope; often phased |
| Fit to your process | You adapt to the software | Software adapts to you |
| Integrations | Whatever the vendor's API and marketplace allow | Built for exactly the systems you use |
| Ownership | Vendor owns the code; you rent access | You own the code and the data |
| Roadmap | Vendor decides, shared with all customers | You decide |
| Vendor risk | Price rises, feature removal, acquisition | Dependence on the developer, reduced by documentation and code ownership |
| Best for | Standard functions and early-stage businesses | Core processes, complex integrations, scale |
When off-the-shelf is the better choice
Off-the-shelf wins more often than developers like to admit. If your requirement is common, the vendor has already solved edge cases you have not thought of yet. You get a mobile app, security updates and support without commissioning them. And you can start next week.
It is also the right first step for a new business that does not yet know its process. Run a package for a year, learn where it hurts, then decide. We regularly tell people in a first chat that a well-chosen SaaS product will do the job, and point them at it. That is better for everyone than building something they did not need.
When bespoke is the better choice
Signs that bespoke will pay back:
- Staff retype data between systems every day, or run the business from spreadsheets that sit alongside the package.
- The package covers most of the job, but the missing part is the part customers pay you for.
- Licences are charged per user, and you are adding users faster than revenue.
- You need a customer or supplier portal the package cannot provide.
- The vendor has raised prices, removed a feature or been acquired, and you want control back.
A bespoke system from dijitul developments is usually a secure web application in PHP 8 and Laravel or Node.js and TypeScript, integrated with the tools you keep. See bespoke software development for what that involves.
A worked way to compare total cost
Comparing a subscription with a one-off build is awkward, so here is the method we use in scoping. Use your own figures; we do not publish ours.
- Package cost over five years. Take the current per-user or per-transaction price, multiply by expected users or volume each year, and add a realistic allowance for price rises. Add paid add-ons and integration tools such as Zapier.
- Workaround cost. Estimate the hours staff spend each week retyping, reconciling or building reports outside the package. Multiply by a loaded hourly cost and 52 weeks. This is often the largest number on the page and the one most people leave out.
- Bespoke cost over five years. The fixed-price build, plus hosting, support and a sensible allowance for improvements each year.
- Risk and value. Note what each option cannot do, and what it would be worth if it could: faster quotes, fewer errors, a customer portal that wins work.
Laid side by side, the answer is usually obvious. Sometimes it is to buy, sometimes to build, and often to buy most things and build one core system.
The hybrid route, and how to decide
The most common answer is neither extreme. Keep the commodity tools, build the differentiating core, and connect them through their APIs. For example, a wholesaler might keep Xero for accounting and build a bespoke trade portal and pricing engine that posts invoices into it. See systems integration.
To decide, list your processes and mark each as standard or differentiating. Price the package over five years, including per-user growth and the cost of the workarounds staff do today. Then compare that with a fixed-price bespoke quote plus running costs. Our discovery and scoping stage does exactly this, and sometimes the honest conclusion is to buy. Related comparison: low-code vs custom development.
Frequently asked questions
Is bespoke software always more expensive?
Upfront, usually yes. Over five years it can be cheaper, because bespoke running costs rarely rise per user, and it removes the hidden cost of workarounds. dijitul helps you compare total cost honestly during scoping, and gives a fixed-price quote for the build.
Can we start with off-the-shelf and move to bespoke later?
Yes, and it is often sensible. A year on a package shows you where it fits and where it hurts. When you move, dijitul migrates your data and can keep parts of the package that still work well, integrating them with the new system.
Who owns bespoke software?
With dijitul, you do. You get the source code in a Git repository you control, the database and the hosting accounts, so you can take the system to another developer if you ever want to.
What if our bespoke developer disappears?
That risk is real and manageable. Insist on owning the code, use mainstream frameworks such as Laravel or Node.js rather than obscure ones, and require documentation and automated tests. Those steps mean another competent developer can take over.
Can bespoke software integrate with our existing packages?
Yes, if those packages have APIs, and most modern ones do. dijitul regularly integrates bespoke systems with Xero, QuickBooks, Sage, Shopify, Stripe and Microsoft 365, so you keep the tools that work and replace only the ones that do not.
Will dijitul tell us if we do not need bespoke?
Yes. If a well-priced package fits your process, we will say so in the free chat and point you towards it. Building something you do not need is bad for you and for our reputation, and it is not how dijitul has worked since 2006.
Related
Tell us what you need to build
Free chat, clear scope, fixed-price quote. You own everything we build.