Describe the operational problem before the features
Start with a real sequence of work. A new customer arrives, a team checks information, a task is assigned, a document is prepared and someone approves the result. Record the delays, duplicate entry and decisions that make that sequence difficult. Then identify the smallest improvement worth funding.
A request for “a dashboard with AI” leaves the most important questions unanswered. A request to give staff one view of a customer’s messages, requirements and pending actions is easier to scope and test. Agree which users need access and the evidence that will show whether the new system helps.
What can a bespoke system include?
Common projects include customer portals, internal operations tools, custom CRMs, reporting applications and integrations between existing products. Some are complete platforms; others are a small layer connecting systems that already work well.
For example, Walthams combines public website development with staff and customer access. Socialroom brings brand context, content, media and approval stages into a dedicated workspace. The relevant lesson is to make the product follow the work, with a clear boundary around the first release.
What drives the price?
| Cost driver | Question to settle |
|---|---|
| Users and permissions | Who can view, change, approve or export each type of record? |
| Data migration | How complete, consistent and accessible is the existing information? |
| Integrations | Are documented APIs and suitable account permissions available? |
| Business rules | How many exceptions need specific handling? |
| Reliability and support | What recovery, monitoring and response arrangements are needed? |
A meaningful estimate follows discovery. Compare proposals against the same scope, including hosting, third-party subscriptions, maintenance and expected changes. A lower build quote can leave significant costs outside the agreement.
Deliver in stages that can be reviewed
Discovery should produce an agreed scope, user journeys, data model and acceptance criteria. Design should make important screens and interactions reviewable. Development should create working increments, followed by tests of normal use, exceptions and permissions.
Before launch, reconcile migrated records, check integrations and test how the system recovers from failure. Train the people who will use and administer it. A phased launch can reduce disruption where a team needs time to compare the new process with the old one.
Timescales depend on scope and dependencies. Content, access to third-party accounts, data quality and the speed of review can matter as much as coding. Ask for milestones and the assumptions behind them rather than an unsupported universal delivery promise.
Agree ownership before the handover
The agreement should explain ownership and access to source code, designs, data, infrastructure and documentation. Third-party components can have their own licences. Specify how records can be exported, who controls production accounts and how another team could maintain the application.
Maintenance covers more than fixing visible errors. Dependencies, provider APIs and business needs change. Agree monitoring, backups, updates and a process for requesting improvements. Our platform and hosting page explains the difference between self-hosted and managed delivery.
Still deciding whether to build? Use the bespoke versus off-the-shelf comparison and the custom software FAQs before commissioning a detailed brief.
Written for Orwell Lab’s practical guide collection. Examples and calculations are illustrative unless a project is specifically identified.
Discuss your own requirements ↗