Custom software development, scoped before it is priced

Enough that the honest answer is a range only after scoping, because the two line items that decide the total are the two nobody quotes upfront: data quality and the integration boundary. Migration estimates assume the old data is clean, and it never is. Integration is where a fixed quote quietly becomes an open one, because every system that stays has its own owner, its own format, and its own failure modes.

Before you compare totals, ask every vendor to price integration separately, in writing. A quote that leaves it as an allowance is not a quote, it is an opening position. We scope that boundary before we price the build.

Ask for the systems still in production, not the launches. Four questions separate suppliers quickly: what have you built that is still running after five years, who exactly will write our code and will we speak to them, how is the integration boundary priced, and what happens when scope changes mid-build. The last one matters most, because the answer reveals whether change requests are an exception or the commercial model.

Custom software development is building an application around one organisation’s process instead of adapting the organisation to a product someone else designed. In practice it covers the workflow no packaged product serves, the integration nobody sells, and the reporting layer assembled from systems that were never meant to talk to each other.

When the process is genuinely yours and configuring a product would cost more than building the thing. If a mature platform covers your workflow, buy it. Custom earns its cost where the process is a competitive advantage, where the integration surface is unusual, or where licence costs per user have outgrown the price of owning the software.

Most builds we run reach production in stages rather than one release, so the useful question is when the first stage goes live rather than when everything is finished. Discovery and scoping take weeks, not months. From there, each stage is planned to ship in months rather than years, which is what keeps a programme cancellable without leaving you with a half-built system.

You do. Ownership of the source code, the documentation, and the architecture decisions transfers to you, and the handover is part of the engagement rather than a separate negotiation at the end.

That is usually the whole job. Most of what we build sits between systems that already exist and are not going anywhere: the ERP that stays, the payroll platform, the warehouse system, the bank feed. We scope every boundary, name its owner, and reconcile the data flows daily during cutover so drift surfaces in hours rather than at month end.

The team that built the system stays on it. Monitoring, support, and the next set of improvements run on one roadmap rather than being handed to a separate maintenance group who have to learn the system first.