Software · Practical guide
Custom software or SaaS? Test the awkward cases first
Choose between a ready-made product and a custom build by testing the work your team actually needs to finish.
The demo is not your working day
A polished software demonstration usually shows the straightforward case. Your team also deals with cancelled orders, absent approvers, duplicate records and last-minute changes. Those cases are often where the difference between a ready-made tool and custom software becomes visible.
Before comparing products, collect five difficult but common tasks from the people doing the work. Use non-sensitive sample records. Ask every vendor to demonstrate the same tasks, including what happens when a person makes a mistake and needs to correct it.
Buy the standard parts when they fit
A subscription product can be a sensible choice when its built-in rules match your operation and your team can adopt it without excessive workarounds. The benefit is not simply a smaller initial invoice; it may also be a clearer product support model and less custom code to maintain.
Check the fit in detail. Which subscription level includes the required permissions, integrations and exports? Can the team complete an important task without repeatedly moving data into spreadsheets? Treat extra manual work as part of the decision, even when it does not appear on the software invoice.
Build around a genuinely different requirement
Custom development deserves consideration when an important business rule cannot be represented safely in the available tools. Examples might include a specialised approval chain or a customer experience tightly connected to your internal operation. The requirement should be concrete enough to test.
“We want our own dashboard” is not, by itself, a strong reason to build an entire system. Describe the decision that the dashboard enables and the data it needs. You may discover that a smaller integration or reporting layer solves the problem without replacing everything.
Compare a complete operating scenario
For each option, record setup, migration, training, integrations, support and expected usage. For a custom build, include ongoing maintenance and the people who will own it. For a subscription, include the relevant plan, seats and usage-based charges. Use current written quotes rather than assumed market prices.
Create three scenarios: the team as it is now, a larger team and a period with unusually high activity. The purpose is to expose assumptions, not to predict exact future costs. Review what can change in each agreement and how the business will respond.
Try leaving before you join
Request a sample export and inspect whether another system could use it. Check attachments, relationships between records and the meaning of status fields. An export button is not enough if the exported data loses information your operation depends on.
For custom work, discuss source-code access, service-account ownership, documentation and third-party licences. For either approach, decide who can administer the system when your main contact is unavailable. Write these responsibilities into the scope or agreement rather than relying on an informal understanding.
Make a small, reversible decision first
Run a time-bounded trial or a focused technical proof with one team. Define the tasks, success criteria and stop conditions before it begins. Ask participants to record workarounds, not just whether they liked the interface.
Then choose: adopt the product, adapt a small part of it, build a focused extension or commission a custom system. The best decision is the one that supports your real work with responsibilities your business can sustain—not necessarily the option with the most features.