Custom business software becomes relevant when a specific recurring process is expensive because it lives across spreadsheets, email, shared folders and disconnected tools, while off-the-shelf software requires too many workarounds. Start with roles, data and decisions, then build an MVP around one complete workflow that creates measurable value.
Volume and repeatable rules create automation value.
Version 1 solves a real end-to-end problem.
Time, errors and cycle time should change measurably.
Recognise the signals
Duplicate entry, unclear versions, email approvals and manual reports indicate structural friction.
What this changes in practice
In practice, this step should connect to Process and Roles. Map actors, steps, exceptions and current manual work. Define who can view, create, approve and administer. This turns a preference into a testable project decision.
Bring Data into the same review. Identify entities, history, ownership and quality. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Standard, low-code or custom
Standard tools suit common needs, low-code suits lighter workflows and custom software suits distinctive rules and integrations.
What this changes in practice
In practice, this step should connect to Roles and Data. Define who can view, create, approve and administer. Identify entities, history, ownership and quality. This turns a preference into a testable project decision.
Bring Integrations into the same review. Inventory CRM, Microsoft 365, ERP, accounting and APIs. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
| Dimension | Question to ask | Good signal |
|---|---|---|
| Process | Map actors, steps, exceptions and current manual work. | The workflow is clear before screens are designed. |
| Roles | Define who can view, create, approve and administer. | Permissions are explicit. |
| Data | Identify entities, history, ownership and quality. | A source of truth is defined. |
| Integrations | Inventory CRM, Microsoft 365, ERP, accounting and APIs. | Each integration removes a concrete friction point. |
| Security | Plan authentication, logging, backup and sensitive-data controls. | Protection matches business criticality. |
| Product ownership | Assign an owner, backlog and roadmap process. | Requests are prioritised after launch. |
Build a business case
Measure volume, time, errors and delays against development and maintenance.
What this changes in practice
In practice, this step should connect to Data and Integrations. Identify entities, history, ownership and quality. Inventory CRM, Microsoft 365, ERP, accounting and APIs. This turns a preference into a testable project decision.
Bring Security into the same review. Plan authentication, logging, backup and sensitive-data controls. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Define the first version
Deliver one complete user journey rather than unrelated features.
What this changes in practice
In practice, this step should connect to Integrations and Security. Inventory CRM, Microsoft 365, ERP, accounting and APIs. Plan authentication, logging, backup and sensitive-data controls. This turns a preference into a testable project decision.
Bring Product ownership into the same review. Assign an owner, backlog and roadmap process. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Security and adoption
Plan roles, MFA, logging, backups, testing, onboarding and an internal product owner.
What this changes in practice
In practice, this step should connect to Security and Product ownership. Plan authentication, logging, backup and sensitive-data controls. Assign an owner, backlog and roadmap process. This turns a preference into a testable project decision.
Bring Process into the same review. Map actors, steps, exceptions and current manual work. For an SME, this reduces late rework, makes supplier scope easier to compare and connects the project to a commercial or operational outcome.
Portal, HR application and Licence Hub.
The value comes from coherent workflow, permissions and data management rather than simply recreating existing forms on screen.
Explore web applications ↗Questions to settle before you start
Make the main unknowns visible before committing budget. An unanswered question is not a problem when it is explicit; it becomes a risk when it is hidden inside a supplier assumption and discovered during development.
Answer these questions with the people who will use, sell or operate the solution. Discovery then becomes an internal decision tool, not just a document sent to a supplier.
- How is process handled today, and what should measurably improve after the change?
- How is roles handled today, and what should measurably improve after the change?
- How is data handled today, and what should measurably improve after the change?
- How is integrations handled today, and what should measurably improve after the change?
- How is security handled today, and what should measurably improve after the change?
- How is product ownership handled today, and what should measurably improve after the change?
Common failure patterns and warning signs
The failure patterns below all push important decisions towards the end of the project, where change is more expensive. A strong process makes these risks visible early.
Use the warning signs as review criteria. If several appear at once, reduce scope, add discovery or validate a prototype before investing further.
- Leaving process until the solution has already been built
- Leaving roles until the solution has already been built
- Leaving data until the solution has already been built
- Leaving integrations until the solution has already been built
- Leaving security until the solution has already been built
- Leaving product ownership until the solution has already been built
Recommended action plan
A good decision should be measurable after launch. Establish a baseline, an owner and a review cadence, then compare the same indicators after launch.
A useful roadmap separates launch from evolution. Prioritise later work from usage data, leads, support tickets and operational gains instead of an old pre-project wish list.
- 1. Discovery — Goals, users and the current process.
- 2. Scope — Must-haves, assumptions and risks.
- 3. Prototype — Critical journey and key decisions.
- 4. Build — Content, data, technology and integrations.
- 5. Launch — Testing, analytics and ownership.
- 6. Improve — Usage, feedback and KPIs drive the roadmap.
Build the business case before comparing proposals
A project involving When should you build a custom business application? is easier to govern when it is framed as an investment rather than a feature list. Start with one measurable outcome: more qualified enquiries, less manual re-entry, a shorter sales cycle, greater user self-service or lower operational risk. Use that outcome to judge every scope decision that follows.
The first layer of the business case connects Process with Roles. Map actors, steps, exceptions and current manual work. Define who can view, create, approve and administer. Quantify the current state where possible: enquiries per month, minutes per task, drop-off, licence cost, error volume or average cycle time. A reasonable baseline is more useful than a vague objective such as ‘modernisation’.
The second layer includes costs that appear after launch. Security and Product ownership therefore belong in the same decision as design and development. Plan authentication, logging, backup and sensitive-data controls. Assign an owner, backlog and roadmap process. A cheaper initial proposal can become more expensive if it leaves heavy manual work, unexpected licences or an architecture that is difficult to evolve.
Finally, assign value to risk reduction. Data and Integrations often affect total cost more than expected. Identify entities, history, ownership and quality. Inventory CRM, Microsoft 365, ERP, accounting and APIs. The right question is not only ‘how much does it cost?’, but ‘what level of investment is proportionate to the outcome, the risk and the expected useful life?’.
Three scope scenarios to make the decision concrete
These scenarios are not price packages. They separate the essential need from medium-term ambition. A good proposal makes the layers visible so functions can be postponed without breaking the logic of the product.
Compare proposals without comparing apples and oranges
Two proposals with the same headline deliverable can cover very different realities. Ask suppliers to respond to the same scope, assumptions and definition of ‘done’. Price then becomes a consequence of visible choices instead of a number that is impossible to interpret.
Make responsibilities explicit as well: who provides content, who approves, who configures access, who migrates data, who tests, who hosts and who responds after launch? Grey areas are often the first source of budget and timeline overruns.
| Criterion | What to review | Evidence to expect |
|---|---|---|
| Process | Map actors, steps, exceptions and current manual work. | The workflow is clear before screens are designed. |
| Roles | Define who can view, create, approve and administer. | Permissions are explicit. |
| Data | Identify entities, history, ownership and quality. | A source of truth is defined. |
| Integrations | Inventory CRM, Microsoft 365, ERP, accounting and APIs. | Each integration removes a concrete friction point. |
| Security | Plan authentication, logging, backup and sensitive-data controls. | Protection matches business criticality. |
| Product ownership | Assign an owner, backlog and roadmap process. | Requests are prioritised after launch. |
Measure value after launch
Measurement starts before launch. Choose two to four KPIs that come directly from the business case, record the current baseline and assign someone to review them after 30, 60 and 90 days. For Process and Roles, favour indicators that show changed behaviour or business outcomes rather than traffic alone.
Add quality indicators around Data and Integrations. A product can convert more while creating more errors or support demand; an automation can save time without improving the experience. Use several dimensions of value rather than a single vanity metric.
Finally, connect Security and Product ownership to operating cost: licences, administration time, tickets, maintenance and required enhancements. After a few months you will have enough evidence to decide whether to invest further, simplify or expand the solution.
- Conversion or adoption
- Time saved
- Quality / error rate
- Cycle time
- Operating cost
- User satisfaction
Before final approval, schedule a short decision review with the business owner, a representative user and the technical owner. Ask everyone the same question: which assumption would have the greatest impact on budget, adoption or continuity if it proved wrong? Give that assumption a concrete validation step before or during the first release. This makes risk management part of delivery instead of something discussed only after a problem appears.
How ready are you?
Are you ready to move forward?
Frequently asked questions
What budget?+
Usually higher than a website because of data, security and testing.
How long for an MVP?+
Weeks to months depending on scope and integrations.
Who owns data and code?+
This must be explicit contractually and technically.
How large should the first release be?+
Large enough to support one valuable journey end to end, small enough to test and improve quickly.
What needs to happen after launch?+
Monitoring, support, ownership and a roadmap are part of the solution, not just the delivery project.