Custom software development: the process from idea to operation and how to control cost

Custom software is often decided on a single quote, but the real cost sits in scope, contract wording and what must be paid after handover.

This article is for owners and managers weighing custom software. Sources include the 2020 Scrum Guide, DORA, McKinsey and Oxford (2012), the CHAOS report critique, ISO/IEC 25010, OWASP ASVS and Vietnamese law, checked on October 21, 2026.

It covers when not to build custom, the process, cost control and a 3-year total cost. Click Star sells custom software development, so the article has a related interest and keeps its opinions separate.

Key points

• Custom is worth it only when existing software, configuration or no-code cannot follow a specific process.
• The process has 6 stages: discovery and specification, prototype, MVP with iterations, testing and acceptance, deployment, and operation and maintenance, each ending in an approval.
• Per McKinsey and Oxford (2012), large IT projects (over USD 15 million) ran 45% over budget on average. Large projects and old data do not transfer directly to small ones.
• The Standish CHAOS report has been criticized: per Eveleens and Verhoef (2010), its definition of "success" only measures estimation accuracy.
• Control cost with prioritized scope, range estimates with assumptions, payments tied to acceptance, and a change process.
• Calculate the 3-year total cost of ownership (TCO) with a formula, and ask a lawyer about source code ownership.

When not to build custom software

Do not build custom if an existing tool, once configured, covers most of the process and the rest can be handled by adjusting the process. The ladder below is Click Star's framework, from cheap to tailored.

• Existing software as is: the cost is a subscription, and you follow the vendor's process.
• Configured software: fits when differences lie in data fields, approval rules and reports.
• No-code or low-code: fits simple internal apps; ask about permission limits and data export.
• Tools integrated through APIs: fits when data is scattered but features are not missing.
• Custom: fits when the process is a competitive edge, needs fine-grained permissions and audit trails, or workaround effort is already large.

Signs not to build custom yet: the current process is not written down, or the goal is merely "having software" rather than a business metric.

Click Star has articles on Next.js versus WordPress, vibe coding and APIs.

The 6-stage process from idea to operation

Each stage should leave something approvable. The framework is Click Star's synthesis of the 2020 Scrum Guide and DORA, not a standard, and still holds when AI writes code.

1. Discovery and requirements specification

The output is a scope document: measurable goals, users, the current process, prioritized features and exclusions. Per the 2020 Scrum Guide, the Product Backlog is an ordered, ever-changing list.

Add non-functional requirements. ISO/IEC 25010:2023 (11/2023) is a product quality model with 9 characteristics; the ISO page says it can define acceptance criteria. OWASP ASVS 5.0.0 (May 30, 2025) names a procurement use: writing security verification requirements into contracts.

2. Prototype

A prototype is a clickable version without real logic, so users see the workflow before coding. Click Star's inference, not a measurement: fixing a flow here is cheaper than after coding.

3. Minimum viable product (MVP) and iterations

Per DORA (Working in small batches, updated December 8, 2025), an MVP has just enough features to learn from users, and small batches shorten feedback time. Finish the one most important process end to end instead of building wide and shallow.

The 2020 Scrum Guide caps a Sprint at 1 month; the Sprint Review is a working session where the team and stakeholders decide the next step.

4. Testing and acceptance

Acceptance compares the product with criteria written in stage 1. The Scrum Guide says an item failing the Definition of Done cannot be released and returns to the backlog. Test function, performance, permissions, security and data, with real users.

5. Deployment

Deployment covers migrating old data with count reconciliation, training, a rollback plan and small releases. DORA (updated January 5, 2026) lists 5 delivery metrics; ask the vendor for the share of releases needing urgent fixes and recovery time after a failed release.

6. Operation and maintenance

This covers monitoring, security patches, library updates, backups with restore tests, and support. Click Star has an article on backup and recovery.

Evidence on budget overruns and its limits

According to McKinsey with the University of Oxford (10/2012), more than 5,400 large IT projects (initial price above USD 15 million) ran 45% over budget on average, 7% over time and delivered 56% less value than predicted.

The original page could not be opened, so figures come from search results and a CIO.de article (secondary). Large projects, 2012 data, none for Vietnam.

Flyvbjerg and Budzier (Harvard Business Review, 9/2011) analyzed 1,471 IT projects: the average overrun was 27%, but 1 in 6 overran by 200% on average and ran almost 70% late. The risk sits in the tail, so stage-by-stage acceptance catches drift early.

The Standish CHAOS report (1994) reported 16% of projects successful, 53% "challenged", 31% failed. Eveleens and Verhoef (IEEE Software, 1-2/2010) used 5,457 forecasts from 1,211 real projects and concluded the definition only measures accuracy of cost, time and feature estimates.

At an organization with fairly accurate forecasts, the definition still gave only 35% "success". At another, steering by it made managers pad budgets, and half the projects deviated 233% or more from actuals. Limits: a 2010 paper on 2 anonymous organizations; recent CHAOS reports are paid and unread.

Cost control: scope, priorities and range estimates

Cost control starts from scope, not unit price. The frameworks below are Click Star's proposals.

• Scope in 3 groups: required to run, nice to have, later. The MVP holds only the first, and each item has a written completion criterion.
• Range estimates: each item has a low, a high and assumptions, such as "old data has been cleaned".
• When an assumption proves wrong, the estimate is updated through the change process.

Eveleens and Verhoef use Boehm's "cone of uncertainty", where forecasts converge on the actual value as a project progresses. A fixed quote is credible only when scope is specified in detail; if not, pay for a separate discovery stage.

Three contract models and payment milestones

No model always wins; the choice depends on how clear the scope is. The pros and cons below are Click Star's framework.

• Fixed price: predictable budget, but each change tends to become a dispute; fits only when scope is clear.
• Time and materials: flexible, but the budget is uncertain without a cap and needs close involvement.
• Hybrid: combines the two, but the contract is more complex.

Per the law firm Browne Jacobson (February 25, 2022, secondary, UK public sector), variants include time and materials capped per iteration, sharing the difference against a target cost, and a fixed price per iteration.

Payment milestones and completion criteria. Tie milestones to acceptance of each iteration, not calendar dates, and state the deliverable, criteria, signatory and review days. Hold back part of the final payment until the warranty ends.

Change management. Per the 2020 Scrum Guide, scope may be clarified and renegotiated with the Product Owner as more is learned, provided quality does not drop. Each change needs a ticket with content, reason, effect on time and cost, and approver.

Documentation and handover. Includes the source repository with history, architecture documents, the data model, API descriptions, operations guides and control of infrastructure accounts.

Source code ownership and intellectual property

Click Star gives no legal advice; ask a lawyer before signing. Below is what was read in a copy of consolidated text 07/VBHN-VPQH (June 25, 2019) of Law on Intellectual Property No. 50/2005/QH11 on caselaw.vn (October 21, 2026). The law has been amended; check the latest consolidated text.

• Article 22: computer programs are protected as literary works, whether in source code or machine code.
• Article 39, clause 2: the party that contracts with an author to create a work owns the property rights and the right to publish, unless agreed otherwise.
• Articles 45 and 46: assignment transfers ownership and must be in writing. Article 47: a license to use is only permission to use for a limited time.

How Article 39 applies when hiring a company is a question for a lawyer. Clauses to clarify: assignment or license, exclusivity, timing of transfer, delivery of source code, open source and third-party licenses, the right to hire another party for maintenance, and data ownership.

Digital Technology Industry Law No. 71/2025/QH15 (June 14, 2025, effective January 1, 2026, via a LuatVietnam copy) defines software products in Article 13 and lists software production as a specially preferred investment field in Article 28. Click Star found no article setting a software contract template.

Cost after handover and 3-year total cost

No prices are given because they differ by provider; take them from each official pricing page and note the date.

The formula is Click Star's framework, not a measurement. 3-year TCO = A + F + the yearly sum of (B + C + D + E):

• A: initial build cost, including discovery, design, development, acceptance and deployment.
• B: infrastructure, domain and third-party services per year.
• C: maintenance and support per year.
• D: security per year, including patching and reviews.
• E: upgrades and new features per year.
• F: internal staff time and switching cost if you change vendors.

Buy TCO = subscription plus configuration, integration, training and workaround effort, over the same 3 years.

Click Star's view. The biggest risk in small projects is usually unclear scope and acceptance without written criteria, not programming. Click Star sells custom software development, so the article puts existing options first; its service page (October 21, 2026) says the first meeting may conclude custom is not needed.

4-week plan before signing

• Week 1: write the current process and a measurable goal; try 2 to 3 existing products.
• Week 2: write scope in 3 priority groups and non-functional requirements; pick the acceptance owner.
• Week 3: request range quotes from at least 2 vendors, compare on the same scope and calculate the 3-year TCO.
• Week 4: draft the contract with milestones, completion criteria, changes, handover and ownership; send it to a lawyer.

Common mistakes

1. Choosing by the lowest quote without comparing the same scope and assumptions.
2. Signing a fixed price before the scope is specified.
3. Building custom before trying existing options.
4. Building every feature instead of an MVP covering one process end to end.
5. Paying by calendar date, with acceptance lacking written criteria.
6. Not stating source code ownership and third-party component licenses.
7. Counting only build cost and ignoring maintenance, security and internal staff time.

What is not known

Click Star has no measurements of cost, duration or overrun rates for small and mid-sized software projects in Vietnam, and gives no "standard" price or duration because no open source supports one. There is no source on maintenance cost ratios or reasonable contingency either.

Not read: recent CHAOS reports, the 9 characteristics of ISO/IEC 25010 (paid), the full 2025 DORA report, Decree 353/2025/NĐ-CP. Laws were read via transcribed copies and may miss amendments.