When the same information appears in spreadsheets, messages and forms, building a system can seem like the obvious next step. But the work starts before the screens: which record wins when those places disagree?
Test ready-made software against a real workflow before commissioning development. If it handles the work without important manual copies or parallel controls, you have an option. Custom software makes sense when there’s a clear requirement the alternatives you tested don’t meet.
Follow one request all the way
Pick a recent request and trace its path: arrival, review, approval, execution and closure. Record who participates, what information they need and where the process gets stuck.
Don’t choose only a case that went well. Include cancellation, a corrected amount, missing paperwork and a change of owner. These cases reveal rules that a list of screens won’t show.
With this map, a supplier demonstration becomes more useful. Ask them to run your case, including an exception, rather than following only their sales script.
Compare the work left over
A product may have records, reports and finance features yet still require someone to copy each approval into another tool. Record that remaining work and how often it happens.
Also compare the effort needed to maintain your own alternative: fixing faults, updating dependencies, monitoring integrations and supporting users. A development quote should explain who handles those tasks after delivery and what support excludes.
An integration with your current software may remove the bottleneck without replacing everything. Consider that route before planning a complete migration.
Define access for each operation
Define permissions in a short table: who may view a request, change its amount, approve, export or delete it? Signing in with a password doesn’t answer those questions.
OWASP recommends checking permissions on every request and denying access by default. Ask for acceptance tests where a user tries to access someone else’s data or perform a forbidden action. Hiding a button doesn’t replace this check.
If you plan to sell the product to several businesses as SaaS, add tenant isolation to the brief. AWS treats tenant isolation as a core requirement: one business mustn’t reach another’s resources. Include it from the start.
Plan how data leaves
Ask for a sample export before deciding. It should contain what the company needs to keep working elsewhere, with understandable fields and relationships.
Treat exports and backups separately. An export helps you use the data; a backup needs to support service recovery. Agree who tests restoration and how the business will be supported during an outage.
Start with a complete workflow
For the first version, choose a process that can run from start to finish. Records without approval, reporting or error handling can look like a substantial delivery while replacing no actual routine.
Bring the chosen workflow, exception examples, access roles and required integrations to the quote. After real use begins, review what remains manual. Use that record to define the next stage, rather than relying only on features imagined before anyone used the product.
Sources
- Authorization Cheat Sheet. OWASP. accessed October 2026.
- SaaS Tenant Isolation Strategies. Amazon Web Services. accessed October 2026.