In this guide 6 sections
Test ready-made software against your busiest day, your exceptions, your data and your exit. If it handles all four with settings, buy it. If it needs workarounds for the work that makes your business different, price a custom build. Many firms combine a packaged core with small custom parts.
Start from the work, not the product list
Most comparisons start with products. Start with your own work instead. Write down the five or six flows that run the business, such as quoting, ordering, dispatch and collection.
Mark each flow as standard or yours. A standard flow looks the same in most firms in your trade. A flow that is yours depends on a rule that customers pay you for.
Four tests for a ready-made product
Run a ready-made product through four tests before you buy. Use your own data in the demonstration, not the vendor’s sample.
A product that passes by setting alone is a good sign. A product that passes only through a developer’s workaround is a different cost, and it should be priced as one.
- Busiest day: can it handle your peak volume and your usual rush?
- Exceptions: can it handle part shipments, returns and special rates?
- Data: can your current records move in, and can you take them out?
- Exit: what happens to your records if you stop paying?
When custom software earns its cost
Custom software earns its cost where the process is the business. A firm with its own pricing rules, field visits or approval chains may spend more time bending a package than using it.
It also suits cases where several systems must act as one. A custom layer can join billing, stock and a customer portal that no single package covers.
The price is ownership. Someone must maintain it, and the contract should say who owns the code.
Where the hybrid option fits
Between the two sits a middle path. Use a packaged product for accounts, stock or payroll. Build only the parts that carry your edge, and connect them through an integration.
A trading firm might keep its accounting package and build a custom order screen for its field staff. The package stays standard and upgrades cleanly. The custom part stays small.
Keep the custom part small on purpose. Every extra feature adds a maintenance duty.
Compare running cost over several years
A ready-made product charges for users, modules or both, usually every year. A custom build charges up front, then for support. Compare both across the same number of years.
Add the costs people forget. These include training, data migration, the time your staff spend on workarounds and the cost of leaving. Ask each vendor to put these in writing.
- Licence or subscription, per user or per module
- Set-up, configuration and data migration
- Training and staff time
- Support, upgrades and hosting
- Cost and effort of leaving
Custom or ready-made scoring sheet
A one-page sheet listing your main flows down the side and the options across the top. For each flow, mark whether the option handles it by setting, by workaround or not at all. A final row records the multi-year running cost. Review it with the people who use each flow.
Open a blank worksheet to printQuestions owners ask
Is custom software always more expensive?
Not always. Over several years, a package with many paid add-ons and workarounds can cost as much as a focused custom build.
Can we start ready-made and go custom later?
Yes, if your data can be exported. Ask for the export format before you sign.
Who owns custom software after delivery?
That is set by the contract. Ask in writing who holds the source code and what you receive on handover.
What if the vendor says everything is possible?
Ask for a demonstration with your own data. Anything shown only in slides has not been tested against your work.