At a glance. Build only after the workflow, owner and first useful release are clear. Compare integration and ready-made software before committing to a custom system.
Define the process before choosing software
Custom software becomes worth considering when an important process cannot be handled well by the tools you already use. Frequent workarounds, duplicated spreadsheets and disconnected records are useful symptoms to investigate.
They do not automatically mean that you need a new application. Sometimes a clearer process or an integration between existing systems resolves the problem with less work.
Compare the practical options
| Option | Strength | Questions to ask |
|---|---|---|
| Ready-made software | Existing features and a defined support model. | Does it cover the important workflow? Can the team use and export the data? |
| Integration between tools | Keeps established systems while reducing manual transfer. | Are the APIs dependable? What happens when an execution fails? |
| Custom application | Can fit a specialised workflow and interface. | Who owns the code, maintains it and decides what to build next? |
Compare total cost over the intended life of the system. Include licences, implementation, migration, hosting, support, changes and the time the team spends operating it. A custom build is not automatically cheaper after a fixed number of years.
Start with the smallest useful release
- Map the people, records and decisions in one important workflow.
- Define what the first release must do and what remains manual.
- Set acceptance criteria for normal and exceptional cases.
- Choose a representative group of users to test it.
- Review the outcome before expanding to more modules or teams.
What AI-assisted development changes
Tools such as Claude Code can support implementation, refactoring and testing. They do not replace product decisions, security design, review or validation with real users. A focused internal tool and a multi-module ERP have different requirements and delivery times.
Use milestones linked to a working result. Ask to see the actual interface and workflow during development, rather than relying on a single final handover. Estimate scope and dependencies before committing to a date.
Ownership and an exit path
- Specify ownership and access to the source repository.
- Keep data export formats and migration procedures documented.
- Document deployment, environment configuration and dependencies.
- Give the client appropriate administrative access.
- Agree who handles maintenance, security updates and incidents.
- Define handover support if the implementation partner changes.
Code ownership helps, but it does not eliminate every dependency. Hosting, third-party services, specialist knowledge and undocumented operational tasks can also create switching costs.
When to wait
Wait if the underlying process changes constantly, there is no internal owner or a standard tool already handles the important need adequately. Building around an unresolved disagreement about how work should happen usually produces expensive revisions.
A scoped proposal should identify assumptions, exclusions, integration requirements, maintenance and the first measurable benefit. Compare that with the actual cost of continuing as you are.
Frequently asked questions
How much does custom software cost?
It depends on the workflow, integrations, permissions, migration and operational requirements. Ask for a scoped estimate and recurring-cost plan rather than a generic market range.
Can a full system be delivered in two weeks?
A small, well-defined tool may be delivered quickly. A complete system with multiple modules and integrations requires its own plan and validation; the development method does not remove that complexity.
Who should own the project internally?
A person who understands the process, can decide priorities and can coordinate user feedback and acceptance.