Custom software development services are the work of designing, building and maintaining software that matches one organisation's own process - not a product licence you install and adapt to. You are buying a working system plus the ability to keep changing it: the source, the infrastructure, and the knowledge of how it fits together. That is the whole difference from a subscription tool, and it is also why the fee is structured the way it is.
This page breaks the engagement into the phases you are actually paying for, so a proposal can be judged on what it produces rather than on its hourly rate. If you are still deciding whether to build at all, read custom software vs. off-the-shelf first.
What does a custom software development engagement produce?
It produces four things: a working application in production, the source code and deployment pipeline that keep it running, the integrations that connect it to the systems you already use, and documentation plus a handover session so your team is not dependent on the vendor for routine changes. A proposal that mentions only "development hours" is describing effort, not deliverables. Ask what exists on the last day that did not exist on the first, and you will separate a service from a staffing agency.
The four phases, and what each one is for
- Discovery and specification. The vendor maps your current process, decides what the first release will and will not do, and writes the data model. Output: scope document, wireframes, and a build estimate that both sides sign. Skipping this is the single most common reason a custom project overruns - scope decisions get made in code reviews instead of on paper.
- Design and build. Interface design, then implementation in iterations. Output: a deployable system in a staging environment from early on, with a demo you can click at the end of each iteration. You should be able to see progress without reading a status report.
- Integration and data migration. The unglamorous half of most custom work: connecting payments, accounting, CRM, or the legacy system, and moving historical records across. Output: imported data with a reconciliation count, plus error handling for anything the import rejects.
- Handover and support. Deployment, monitoring, access documentation, and a defined support arrangement. Output: credentials, runbook, and either a support agreement or a clean exit with everything your team needs.
Which service model are you buying?
Three shapes are common, and they suit different kinds of projects. Fixed price plus a defined scope fits a project you can specify up front, usually an internal tool or a replacement for a system you already understand. A dedicated team billed monthly fits a product you expect to keep evolving, because the vendor supplies capacity rather than a finish line. A small discovery or prototype engagement fits the case where you need evidence before you commit a budget - a two or three week build that tests the riskiest assumption is far cheaper than a wrong full system.
- Fixed price, fixed scope: predictable cost, weak against change requests, and the specification has to be unusually good.
- Dedicated team: flexible and fast to steer, but the cost is the same in a slow month as in a fast one, so it needs its own management attention.
- Discovery first, then fixed price: usually the best of both - a short paid phase that produces the specification the fixed-price build is priced against.
How to judge a proposal in ten minutes
- Does it name the deliverables per phase, or just a total and a duration?
- Is the estimate broken down by feature, so you can remove something and see the price move?
- Who writes the specification - their analyst with your input, or you alone? A vendor who will not do discovery for a fee is usually guessing at the price.
- What happens to the code if you leave: which account owns the repository, the hosting and the domain?
- What is the support commitment after launch, in hours per month and response time?
- Which parts are third-party and recurring - cloud hosting, email, SMS, payment processing - and are those costs quoted separately?
You can see how we structure this on our custom software development services page, and compare it with a narrower application development engagement if your scope is closer to an app than to a platform.
What the fee is really made of
Most budgets land in four buckets: people (design, engineering, project management), the third-party services the system needs, the time spent on integration and data rather than features, and the reserve for the risks discovered mid-build. Two of those are invisible on a rate card. Integration work tracks the number of systems you connect, not the size of the app; and every custom build discovers something in the data that nobody anticipated. A proposal with no contingency line is either very small or is planning to ask you for more money later.
Frequently asked questions
How long does a custom software project take?
Plan a first usable release in two to four months for a focused internal tool, and six months or more for a system that replaces an existing process across several teams. The variable that moves the date most is how quickly decisions get made on your side, especially about data and permissions, so a partner who forces those decisions early in discovery is worth more than one who promises a faster date.
Can we start small and expand later?
Yes, and it is usually the right way to buy. A first release that handles one workflow end to end proves the approach and produces a real number for the rest. The one condition is that the architecture supports the later additions - which is a conversation to have in discovery, not after the first release ships.
What should we own at the end of the engagement?
The source code in a repository your organisation controls, the deployment configuration, the database, the domain and any vendor accounts, plus written documentation of how the system is put together. Ask for it in the contract rather than at handover, because a vendor who expects to hand it over will structure the code and deployment so that handover actually works.
How do we keep costs from growing mid-project?
Fix the first scope in writing, agree a change process where every new request is priced before it is built, and review the demo at the end of each iteration rather than at the end of the project. Change is normal in custom software; unpriced change is what turns a budget into a dispute.
When is custom the wrong answer?
When an existing product covers about 80% of what you need and the missing 20% is not strategically important. Adapting your process to good off-the-shelf software is faster and cheaper than rebuilding it, and the money is better spent on the part of your business that no product covers.
If you want a scoped estimate rather than a rate, send us the workflow you are trying to fix and we will tell you which phase to start with - and say so plainly if the honest answer is that you do not need custom software yet.