The custom enterprise software development process: six steps, six decisions, and when to build
You have a vendor's phase list, a licence quote and a board that wants a date. As the CTO or the business owner, you need to know what you sign at each step, and whether to build at all.
What is the custom enterprise software development process?#
Enterprise software development runs in six steps, discovery, design, build, QA, launch and run, and at each step the client owns one decision no vendor can make for it. The steps follow ISO/IEC/IEEE 12207, the international standard for software life cycle processes. Its catalogue page lists a 2026 edition in place of the withdrawn 2017 one. However, most guides describe the custom software development process as the vendor's activity. Here they are the client's decisions instead, so you know what to sign and what to ask for. And the custom software development process steps are the same for a small product. The enterprise version just adds integrations and people who must sign.
| Step | What you decide | The artefact that closes it |
|---|---|---|
| 1. Discovery | The problem, the scope boundary and the success measure | A signed problem statement with the measure in it |
| 2. Design | The architecture, the integrations and who owns the data | An architecture document with an integration list and acceptance criteria |
| 3. Build | The release cadence, the definition of done and the security practices | Working releases that meet the definition of done |
| 4. QA and acceptance | Whether the software passes the agreed test plan | A signed acceptance, with open defects ranked |
| 5. Launch | The cutover plan and the rollback trigger | A cutover plan with a named rollback condition |
| 6. Run | The delivery metrics the team is held to | A monthly report on five delivery metrics |
Think of this customised development journey as six handovers. At each one, work then stops until a named person on your side says yes in writing. By contrast, a software customization process starts from a packaged product and adapts it. That is the buy branch, which comes later. For a definition, see what custom software development is.
Why does discovery decide most of the cost risk?#
Across 4,677 IT projects, the median finished at its estimate but the mean ran 1.8 times over, because a few projects overran by orders of magnitude. Flyvbjerg and five co-authors reported those figures in 2022, from a sample of 5,392 IT projects. Their paper also found that "overruns and underruns are about equally frequent", so the typical project is not the problem.
The risk sits in the tail, and in the same 2022 study the worst project cost 280.4 times its estimate.
Show data table
| Item | Value |
|---|---|
| Median project | 1 x |
| Mean project | 1.8 x |
| Largest overrun in the sample | 280.4 x |
The median project finished on its estimate, but the worst one cost 280.4 times its estimate.
The authors trace the tail to parts that depend on each other. When one component has a problem, it can set off chain reactions in others. Their summary is blunt: "extreme IT project cost overruns will occur". They also add that managers who assume a normal spread of overruns will badly underestimate how often it happens.
Discovery is where you cut that tail, and its job is not a sharper average estimate. Instead, it finds the links between systems, teams and data before anyone prices the work. In practice, that means listing every system the new one touches, every data owner and every rule that differs by region. Since each unknown link is a place where one change can spread, a good discovery ends with few unknowns. It also ends with a scope boundary that says what is out. That boundary matters because each vague item comes back later as a change request, and change requests carry cost.
What does the client decide in discovery and design?#
In discovery the client decides the problem, the scope boundary and the success measure; in design it signs off the architecture, the integrations and who owns the data. Each step ends with a written artefact, and nothing is built until both exist. So these two documents are the cheapest place to cut the tail the overrun data describes.
- End of discovery: you sign
The problem, in one paragraph, with the people who feel it named by role.
- End of discovery: you sign
The scope boundary, with a list of what the system will not do.
- End of discovery: you sign
The success measure, one number you can read before launch and after it.
- End of discovery: you sign
The systems and data owners the new software touches.
- End of design: you sign
The architecture, at the level of components and where each one runs.
- End of design: you sign
Each integration, with its owner on the other side and the data that crosses it.
- End of design: you sign
Who owns each kind of data, and where it lives.
- End of design: you sign
The acceptance criteria that QA will test against later.
Also, ask for both in plain language, because you cannot sign a document only the vendor can read.
The discovery output also feeds the request for proposal you send to vendors. For that, the software development RFP template shows how to turn it into one. In practice, the design sign-off is the last cheap moment to say no. Once code exists, though, every change to an integration or a data owner means rework. Also, if a vendor wants to start building before the acceptance criteria exist, ask what it plans to test against. But how long each of these steps takes is a separate question, and the custom software development timeline covers it.
What does the client decide while the software is being built?#
NIST's secure development framework lists 19 practices in four groups, and 8 sit in producing the software, so security is decided during the build, not added at QA. NIST is the US National Institute of Standards and Technology. Its Secure Software Development Framework (SSDF) dates from February 2022. It describes itself as "a core set of high-level secure software" development practices. Those practices still fit into any development life cycle.
Since most practices sit in the group for producing software, the build contract is where security is won.
Show data table
| Segment | Value (practices) | Share |
|---|---|---|
| Prepare the Organization (PO) | 5 | 26.3% |
| Protect the Software (PS) | 3 | 15.8% |
| Produce Well-Secured Software (PW) | 8 | 42.1% |
| Respond to Vulnerabilities (RV) | 3 | 15.8% |
Eight of the 19 practices sit in producing the software, so the build contract is where security is won.
During the build, you make three decisions:
- Release cadence: how often you see working software, and who on your side reviews it.
- Definition of done: what every change must pass before it counts: tests, code review, security checks and updated documents.
- Mandatory practices: which SSDF practices the contract requires, named by their NIST identifiers.
Write the third decision into the contract itself, because a practice that lives only in a slide deck is easy to drop.
In 2026, part of the code will come from AI tools, so the definition of done matters more. For example, in Stack Overflow's 2025 Developer Survey, 84% of respondents use or plan to use AI tools. And in the same survey, 66% named "AI solutions that are almost right, but not quite" as their biggest frustration. Therefore, ask how AI-written code is reviewed, and make that review part of done.
What does the client decide in QA and acceptance?#
QA ends with the client's acceptance decision: the software passes the test plan agreed in design, with defects ranked, and the client, not the vendor, signs it off. The BLS describes the people who do this work. Quality assurance analysts and testers "Create test plans, scenarios, and procedures for new software", and they report defects. So their test plan should trace back to the acceptance criteria you signed in design.
Before you sign acceptance, ask for four things:
- the test plan, with each test tied to an acceptance criterion;
- the open defects, ranked, with the ones that block launch marked;
- a test run on real data volumes, not a sample;
- the results of the security checks the build contract required.
Then sign only when every blocking defect is closed, or accepted in writing with a fix date.
A build and test team draws on six roles. Overall, their BLS May 2025 medians run from $104,300 for QA analysts to $175,140 for computer and information systems managers.
Show data table
| Item | Value |
|---|---|
| Software developers | 135,980 USD |
| Software quality assurance analysts and testers | 104,300 USD |
| Computer systems analysts | 105,850 USD |
| Information security analysts | 129,180 USD |
| Database administrators and architects | 126,760 USD |
| Computer and information systems managers | 175,140 USD |
Their BLS May 2025 medians run from $104,300 for QA analysts to $175,140 for computer and information systems managers.
Those wages matter later in this guide. They are the build side of the five-year comparison. After all, a custom system needs people like these for as long as it runs.
What does the client decide at launch and once the software runs?#
At launch the client decides the cutover plan and the rollback trigger; in the run step it owns five DORA delivery metrics, from change lead time to deployment rework rate. First, the cutover plan says how users move to the new system. They can move all at once, by region, or with the old system running alongside. Then the rollback trigger names, in advance, the condition under which you go back. Then decide both before launch day, while the room is calm.
After launch, the process keeps going, and the team is measured on how it delivers. DORA is the DevOps Research and Assessment programme. Its guide, last updated on 5 January 2026, sets out five delivery metrics. Before that, it used its original four keys.
| Metric | What it measures, in DORA's words | Group |
|---|---|---|
| Change lead time | The time for a change to go from committed to version control to deployed in production | Throughput |
| Deployment frequency | The number of deployments over a given period, or the time between deployments | Throughput |
| Failed deployment recovery time | The time it takes to recover from a deployment that fails and requires immediate intervention | Throughput |
| Change fail rate | The ratio of deployments that require immediate intervention, such as a rollback or a hotfix | Instability |
| Deployment rework rate | The ratio of deployments that are unplanned but happen as a result of an incident in production | Instability |
Source: DORA metrics guide, last updated 5 January 2026.
So put these five in the run contract, with a monthly report. Also, ask for the trend across months, since a single good month can flatter any team. In short, launch is not the finish line, because the run step shows whether the first five steps worked.
What are the advantages of custom enterprise software?#
The advantages of custom enterprise software are fit to your own workflow, integrations you control, ownership of code and data, and no per-seat licence, each paid for with a running cost. Each advantage is therefore a trade-off, not a free gain.
| Advantage | What it gives you | What it costs to keep |
|---|---|---|
| Fit to your workflow | The system follows how your teams already work | Every change to the workflow is a change you fund |
| Integrations you control | You decide how data moves between systems | You maintain each one when the other side changes |
| Ownership of code and data | The vendor cannot change the terms or retire the product | You carry the hosting and the security patches |
| No per-seat licence | Cost does not grow with every new user | A standing team, paid whether or not features ship |
| An edge competitors cannot buy | A process your rivals cannot copy off the shelf | The design knowledge has to stay in house |
Read the right-hand column first, because it shows what you still pay for in year three and beyond.
A 2026 paper by Klotz re-examined the "seven canonical decision determinants" of make or buy. They are cost, strategic differentiation, asset specificity, vendor lock-in, time to market, quality and compliance, and organizational capability. With AI in the picture, it found "Make is most compelling for commodity utilities and differentiating custom applications in the AI era". In other words, the 2026 study sees building pay off where the system is your edge. It also pays for simple commodity utilities.
In short, custom enterprise software pays where the workflow is your advantage. Elsewhere, its benefits are still real, but you pay for each one every year.
Should you build, buy or modernize your enterprise system?#
A five-person build team at US median wages costs $618,090 a year before overhead, so building wins only when seats and integrations make the licence dearer over five years. That total uses BLS medians for May 2025. It is three software developers at $135,980, one QA analyst at $104,300 and one systems analyst at $105,850. Because it leaves out benefits, tools, hosting and office costs, the true figure is higher. Still, it is one clean line of the total cost of ownership (TCO), and the easiest one to compare.
Overall, you have three options, not two:
- Buy: rent a packaged product and configure it. That is the software customization path, and it fits when your process looks like everyone else's.
- Build: fund a team and own the result. It fits when the workflow is your edge and the seat count is large.
- Modernize: keep the core system that holds your business rules, and replace or wrap the parts that block change.
Say a 400-seat organisation weighs a workflow system, with six integrations to build whichever way it goes. In this worked example, five years of the team's BLS-median wages come to $3,090,450. Divided by 400 seats and 60 months, the worked example's break-even licence is $128.77 per seat per month. Indeed, if the quote is below that, buying is cheaper on wages alone. Then raise the seat count to 1,000 in the same worked example, and the break-even falls to $51.51 per seat per month. As a result, building gets cheaper per seat as the user count grows.
Your break-even licence per seat
Put in your seat count, the months you compare and your team mix; the wages start at the BLS May 2025 medians.
Break-even licence per seat per month
$128.77
- Team wages per year
- $618,090
- Team wages over the months compared
- $3,090,450
Arithmetic from BLS Occupational Outlook Handbook medians, May 2025. Modelled, not measured.
Show data table
| Segment | Value (USD) | Share |
|---|---|---|
| 3 software developers | 407940 | 66% |
| 1 QA analyst | 104300 | 16.9% |
| 1 systems analyst | 105850 | 17.1% |
Three software developers make up $407,940 of the $618,090 yearly wage bill.
So compare that break-even with the per-seat quote you hold. However, keep two corrections in mind: first, the wage line leaves out overhead, which favours buying. Meanwhile, a licence quote often also leaves out integration and admin work, which favours building. For the line items behind a build estimate, see what custom software development costs. And for the general case outside enterprise software development, see custom software vs off-the-shelf software. If modernizing is your branch, choosing a legacy modernization partner covers it.
When not to build custom enterprise software?#
Do not build when the process is standard, a regulated system already has certified products, or nobody on your side can own the software after launch; buy or configure instead. And the 2026 Klotz paper reaches a similar line. Even with AI tools, "regulated and mission-critical systems remain predominantly" in the buy domain.
Run this check before step one. Answer each question honestly:
Is this function an edge for you, or does every competitor run the same thing?
Do you have people who build and run software today, or would you staff from zero?
Is the data this system needs clean, governed and reachable?
Does a packaged product already cover most of the need?
Will you run this system for five years or more?
Still, answer them with the people who will run the system, not only the ones who will fund it.
If you answer no to any of the first three, stop. Here is what to do instead in each case:
- The process is standard: buy a product and configure it. Since your edge is elsewhere, spend your build budget there.
- The category is regulated: buy a certified product. Certification is slow and costly to earn on your own, after all.
- Your team cannot own it: buy a managed product, or modernize with a partner while you hire.
A no to the fourth or fifth question is a caution rather than a stop. After all, building a system you plan to replace soon rarely pays.
What do CTOs consider when evaluating application development partners?#
CTOs weigh four groups of factors, strategic fit, application characteristics, cost and budget, and risk, and should ask a partner for the exit artefact of every step before signing. Specifically, the four groups come from a 2026 decision-support paper by Misra, Kaulgud, Burden and Podder. That paper builds "an ontology of decision factors" spanning strategic considerations, application characteristics, cost and budget constraints, and risk.
| Factor group | What to ask a partner | Artefact to request from past work |
|---|---|---|
| Strategic fit | Do they understand why this system matters to the business? | A discovery problem statement, with names removed |
| Application characteristics | Have they built at this scale, with these integrations? | An architecture document with its integration list |
| Cost and budget | How did past estimates hold against actual cost? | An estimate and the final cost from one project |
| Risk | How do they handle security, cutover and rollback? | A secure development checklist, a cutover plan and a run report |
Then weigh the groups by your own priorities. A regulated system puts risk first, while a new product may put fit first.
So what do CTOs consider when evaluating application development software for digital transformation projects? In fact, the same four groups apply to a platform or a tool as to a partner. Then add one more question: can your own team run it after launch? And for a software architecture partner, ask for the design artefact from step two of a past project. Then check that the integrations and data owners are written down, not implied. For the rest of the shortlist, see how to choose a custom software development company.
Where should you go from here?#
Pick the step you are at today, take its decision and its artefact from this guide, and use the linked guides for the timeline, the cost and the vendor shortlist. Each picks up where enterprise software development meets a question this guide leaves to them:
- The custom software development timeline covers how long each step takes.
- What custom software development costs breaks down the estimate.
- How to choose a custom software development company covers the shortlist.
- The software development RFP template turns discovery into a request for proposal.
If you want a team to run the steps with you, see Atyantik's custom software development work. A standalone product discovery engagement covers step one alone. For an enterprise system you already run, see enterprise software services. However, the six decisions above work with any capable team, including your own.