Seven decisions to make before commissioning custom software
Custom software is justified when the way your organisation works creates an advantage or when generic tools impose a recurring operational cost. Before selecting a framework or asking for screens, make seven decisions that define whether the product will be useful after launch.
1. Name the operational change
‘Build a portal’ is an output. ‘Cut the time between a customer request and an approved quotation’ is an operational change. The second statement gives the team something to test and gives the budget holder a reason to continue.
Write one sentence describing what should become faster, safer, less expensive or easier to understand. If the sentence contains several unrelated outcomes, split the project before estimating it.
2. Identify the daily users
The buyer, administrator and end user often need different things. Speak with the people who perform the work now. Watch where they leave an existing system, create a spreadsheet or send a message to finish the task.
Those workarounds are product requirements in disguise. They also reveal which screens need speed, which actions need explanation and where permissions must be strict.
3. Decide where the trusted data lives
Choose the source of truth for customers, products, staff, transactions and documents. If two systems can edit the same field, define which one wins and how conflicts are reviewed.
Data migration deserves its own scope. Count records, inspect missing values and agree retention rules before promising a launch date. Migration uncertainty is one of the most common reasons a sensible software estimate grows later.
4. Draw the permission boundaries
List roles and the information each role can view, change, approve or export. Include former staff, contractors and support personnel. Sensitive actions should create an audit record that a named owner can review.
Permissions added after development affect database design, interface behaviour and testing. Treat them as product architecture, not an administrative setting.
5. Define the smallest credible release
An MVP is not a collection of unfinished features. It is the smallest complete route through one valuable task. Choose a single user group and one end-to-end workflow that can operate safely in production.
Everything else belongs in a later decision log. This protects the launch and creates evidence for the next investment rather than spreading the budget across half-built modules.
6. Agree how success will be observed
Choose a baseline before development: handling time, completion rate, support volume, error frequency or revenue affected. Add product analytics only where they answer an agreed question and obtain the required consent.
Operational measures are usually more useful than page views. A dashboard should help someone decide what to do next, not decorate a meeting.
7. Plan ownership after launch
Confirm who controls the source code, hosting accounts, domains, data exports and third-party subscriptions. Ask what documentation, monitoring, backups and knowledge transfer are included.
The final test is simple: could another competent team operate and extend the product using the access and documentation you receive? If not, the build has created dependency rather than capability.
Have a process, product or campaign to examine?
Send us the current situation. We will reply within one business day with the first questions we would ask.
Discuss your situation