Quick answer: what are the steps of custom software development?
A custom software project usually moves through 9 phases: discovery, requirements and scope, architecture, iterative build, quality assurance (QA), user acceptance testing (UAT), deployment, handover and maintenance. Each phase should end with a concrete deliverable that both sides sign off.
Success rarely hinges on technology. It depends on three things: a clearly written scope, measurable acceptance criteria, and rights to source code and documentation set out in the contract. This guide covers each so you can work effectively with any development team. If you are still deciding whether to build at all, read build vs buy software first.
The 9 phases and their deliverables
The table below is a reference frame. Names and depth vary with project size; what matters is that every phase has a clear output and an approver.
| Phase | Goal | Typical deliverables | Client involvement |
|---|---|---|---|
| 1. Discovery | Understand the business problem, users and existing systems | Discovery report, current process maps, risk list | Interviews, documents, sample data |
| 2. Requirements & scope | Agree what is in and out of scope | Software requirements specification (SRS) or prioritised user stories, acceptance criteria | Review and sign off scope |
| 3. Architecture | Choose system structure, data, integrations, security | Architecture document, data model, wireframes/prototype | Approve screen flows, confirm integrations |
| 4. Iterative build | Ship working pieces and get early feedback | Incremental builds after each iteration, release notes | Attend demos, give feedback, set priorities |
| 5. QA | Find functional, performance and security defects | Test plan and results, defect list with status | Provide realistic test data |
| 6. UAT | Real users confirm the software meets requirements | UAT scripts, acceptance record or list of fixes | Key users run scripts and sign |
| 7. Deployment | Release safely to production | Deployment and rollback plan, data migration, user guides | Prepare infrastructure/accounts, train users |
| 8. Handover | Transfer what was agreed | Source code, technical docs, access credentials, handover record (under contract) | Check every item, take admin ownership |
| 9. Maintenance & support | Keep the system stable and current | Incident reports, patches, dependency updates (under contract) | Report issues via agreed channel, approve changes |
Why build iteratively
During the build, many teams work in short cycles so working software appears early. The 2020 Scrum Guide describes Sprints as fixed-length events of one month or less, each producing an Increment that meets the Definition of Done (Scrum Guide). For a client, the practical benefit is seeing and commenting on real software regularly instead of waiting until the end.
The early phases: discovery, requirements and architecture
The first three phases take less time than the build but carry most of the risk. A requirement misunderstood here is multiplied in every later step.
Discovery
The aim is to understand the problem, not to choose technology yet. The team should watch the real process, look at sample data and talk to end users, not only managers. If the process involves AI or automation, mapping an AI workflow helps separate steps a machine does from steps a person approves.
Requirements and scope
Each requirement should have an owner, a priority and acceptance criteria. Write down what is out of scope too, because that is where disputes most often arise. Non-functional requirements (concurrent users, response time, backups, permissions, audit trails) should be written as carefully as functional ones.
Architecture and security from the start
NIST notes that few software development life cycle models address security in detail, so secure development practices need to be added to each one; it presents the SSDF (NIST SP 800-218, version 1.1; version 1.2 has been in public draft since December 2025) as a common vocabulary buyers can use with suppliers (NIST). You can use it as a question list when reviewing designs. If the product must scale over years, see SaaS systems that survive growth.
Contract models: fixed scope, time and materials, dedicated team
The contract model shapes how change is handled. No model fits every project; the table compares them by how certain your requirements are.
| Model | How it is billed | Fits when | Watch out for |
|---|---|---|---|
| Fixed scope | Scope, schedule and value agreed upfront | Clear, stable requirements of moderate size | Every change goes through a change request; disputes over how scope is interpreted |
| Time & materials | Billed on actual effort | Requirements still evolving, priorities need flexibility | Requires transparent effort reporting and a client-side person deciding priorities often |
| Dedicated team | A stable team works for you long-term | Continuously evolving product needing deep domain knowledge | Client needs product-management capacity; agree rules on replacing people and knowledge transfer |
What clients should prepare before starting
Most delays come from waiting for decisions or data, not from coding. Preparing the following keeps a project moving:
- One decision-maker (product owner) with time and authority to approve scope, priorities and acceptance.
- Measurable business goals: what work the software should remove, where it should be faster, who uses it.
- Documents and sample data: forms, reports, spreadsheets in use, with sensitive data masked if needed.
- A list of systems to integrate (accounting, CRM, ERP, payment gateway, e-invoicing) and an owner for each.
- Infrastructure and security requirements: cloud or own servers, personal-data policy, who may access production.
- Key users available for demos and UAT on schedule.
Acceptance criteria: make them measurable
Acceptance criteria are the specific conditions under which a requirement counts as done. Unlike the Definition of Done, which applies quality standards to every item, acceptance criteria belong to each requirement. Scrum.org describes the Definition of Done as a formal description of the Increment's state when it meets the product's quality measures (Scrum.org).
- Each criterion can be checked as yes/no; avoid vague words like “easy” or “fast”.
- Tie criteria to test data both sides hold.
- Classify defects (critical, major, minor) and agree which levels block acceptance.
- State who signs acceptance and within what period after receiving the UAT build.
Illustrative example
Illustrative example: instead of “the system exports reports quickly”, write “When an accountant selects a month and clicks Export, the system produces an Excel file in the attached template containing every order with status Delivered in that period; on the agreed test data the action completes within the time both sides recorded in the specification.” Good criteria state context, action, expected result and the data used to check.
Source code, documentation and warranty handover
Agree this when signing, not at the end. Items commonly agreed include source code with version history, architecture and API documentation, installation and operations guides, infrastructure admin accounts, and a list of third-party libraries with their licences. The exact scope, ownership of source code and timing of transfer are defined under contract.
Software copyright under Vietnamese law
Under Article 22(1) of the Law on Intellectual Property (as amended by Law No. 131/2025/QH15, in force from 1 April 2026), computer programs are protected as literary works in source or machine code, and the author and copyright owner may agree in writing on repairs and upgrades. Under Article 39(2), the party that contracts the author owns the economic rights and the right to publish the work unless otherwise agreed; Article 41 allows these rights to be transferred by contract. At handover, check the delivery list against the IP clause you signed; the detailed analysis of source-code ownership is in build or buy software.
Warranty and support
Warranty period, which defects are fixed at no extra charge, response times and any service level agreement (SLA) are all available under contract. Distinguish clearly between fixing defects against the accepted specification, changes or new features, and infrastructure operations; each is usually handled differently.
Signals to probe when choosing a development partner
These signals do not mean a partner is weak, but they are reasons to ask more before signing:
- Firm schedule and scope commitments before any discovery.
- No clear change-request process.
- No client access to the code repository or test environment during the project.
- No clear answer on how testing is done, by whom, and where results are kept.
- Vague or missing clauses on source code, documentation and intellectual property.
- No mention of security, backups or personal data.
- A single technical contact with no knowledge-transfer plan.
Checklist before signing
With this list complete, you can compare proposals on equal terms. To discuss a specific project, you can contact EYC.
- Scope, out-of-scope items and acceptance criteria are written down.
- The contract model matches how certain the requirements are.
- Change requests, progress reporting and demo schedule are agreed.
- Handover items (code, docs, accounts) and ownership are in the contract.
- Warranty, support and SLA terms are stated as agreed.
- Security and personal-data handling requirements are in the specification.
Frequently asked questions
How long does custom software development take?
It depends on scope, the number of integrations and how quickly both sides make decisions. The most reliable approach is to run discovery first, then estimate from the agreed requirement list.
Should I choose fixed scope or time and materials?
Fixed scope suits clear, stable requirements. Time and materials suits requirements still being discovered. Many projects run discovery on a fixed basis first, then choose the model for the build.
Who owns the source code of commissioned software in Vietnam?
Under Article 39(2) of the Law on Intellectual Property, the party that contracts the author owns the economic rights and the right to publish the work unless otherwise agreed. In practice, ownership and the scope of code handover are defined in the contract, so write them explicitly and have a lawyer review them.
How is UAT different from the developer's testing?
QA is done by the development team to find defects against the specification. UAT is done by the client's users on real business scenarios to confirm the software works for their job.
Who maintains the software after handover?
The developer under a maintenance contract, your internal team, or both. Either way you need documentation, access and a knowledge-transfer plan agreed in the contract.