Management signs off on a budget for a dispatch system. Six months later, the vendor delivers something that works in the demo but that nobody in the warehouse wants to use. The screens don't match how a real order gets picked, and the ERP integration breaks every time a product code changes. When someone finally rereads the contract, the real problem shows up: nobody ever defined what would be delivered at each stage, so there was never a formal moment to say "this isn't what we asked for."
In software design and development, projects rarely fail because of the code. They fail earlier, when nobody writes down what is going to be built, or later, when nobody knows how to run what was built. This article walks through the stages of a custom software project and the deliverables worth asking for at each one. It applies whether you're hiring a software development consultancy or your internal team is running the project.
Discovery: understand the problem before pricing the solution
This is the stage that gets cut first to "save time," and the one that costs the most time later. Discovery documents how the process works today, who uses it, which systems it touches and what success actually means.
By the end you should have:
- A map of the current process and the target process, validated by the people who do the work (not just their managers).
- A prioritized initial backlog: the list of features ranked by business value.
- The scope of the first release, with what's out written down as clearly as what's in.
- An inventory of integrations and data, including which personal data the system will handle.
- Known risks and assumptions, such as "the ERP exposes an API to check stock."
That last point matters more than it looks. An assumption nobody checked during discovery tends to become a scope change halfway through. And if the system will handle national ID numbers, addresses or health data, say so now. Chile's Law 21,719 includes, in article 14 quáter, a duty of data protection by design and by default. Bolting privacy controls on at the end costs far more than designing them in from the start.
UX design: test with users before writing code
Designing the experience means deciding how a person will complete their task with as little friction as possible, and checking that before anyone programs it. Making it look good comes after.
At this stage, ask for user flows for the main tasks and a clickable prototype (in Figma or similar) that can be put in front of real users. Also ask for a short record of what those tests showed and what changed because of them.
The warehouse case above could have been avoided with one afternoon, three operators and a prototype. Fixing a flow in Figma takes hours. Fixing it once the system is live takes weeks, and then you have to convince people to give it another chance.
Architecture: the decisions that are expensive to undo
Architecture defines where the system runs, how it's split into components, how it connects to other systems and how it's secured. These decisions are hard to change later, so they deserve to be written down along with the reasoning behind them.
| Deliverable | What it should answer |
|---|---|
| Architecture diagram | Components, cloud or servers, integrations and data flow |
| Architecture decision records (ADRs) | What was chosen, which alternatives were rejected and why |
| Data model | Main entities and where each piece of personal data lives |
| Security design | Authentication, roles and permissions, encryption, secrets handling |
| Non-functional requirements | Concurrent users, response times, expected availability |
| Operating cost estimate | What the infrastructure will cost per month at the expected volume |
Pay special attention to access control. In the OWASP Top 10:2025, the standard reference list of web application risks, broken access control is still in first place: users who can see or change data that isn't theirs. You prevent that by getting roles right in the architecture, not by patching one screen at a time.
Development in sprints: progress you can see
Once discovery, design and architecture are settled, development runs in short cycles. The Scrum Guide defines a sprint as a fixed period of one month or less that contains planning, the daily scrum, the review and the retrospective. In practice, many teams work in two-week sprints.
What matters to whoever is paying is that every sprint ends with something you can check:
- A sprint goal agreed at the start.
- A working increment in a test environment that you can actually use, not just watch in a slide deck.
- A review at the end where finished work is shown and the backlog gets adjusted.
- A shared definition of "done," for example: code reviewed by another person, automated tests passing and documentation updated.
If three sprints go by and you still haven't been able to try anything yourself, something is off, and it's much better to notice in week six than in month six. AI now speeds up a good part of this stage, but it doesn't replace human review; we look at the data in Software development with artificial intelligence today.
QA: testing throughout the project, not at the end
When testing is left for the end, bugs pile up and the deadline eats the time meant for fixing them. That's why quality assurance runs alongside development from the first sprint.
A well-run project delivers:
- Automated tests (unit and integration) that run every time someone pushes a change.
- Functional test cases written from each story's acceptance criteria.
- A security test report before going live.
- User acceptance testing (UAT) with business users, with a signed record of what was approved.
One detail people miss: test environments shouldn't run on copies of the production database with real data. If you need realistic data, anonymize it first. We cover this in Real data in test environments and Law 21,719.
Deployment and operations: what happens after launch
The day the system goes live is when the longest part of its life begins. For this stage, ask for a documented CI/CD pipeline, a deployment plan with a rollback path in case something fails, an operations manual, monitoring with alerts, and the handover of source code and credentials to your company.
To measure whether the team delivers well over time, Google's DORA research program proposes five software delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. You don't need all five from day one. You do want to know how long a change takes to reach production and how many changes end up needing an urgent fix.
If you're comparing vendors, Software factory in Chile: 10 questions before signing has concrete questions for the sales stage.
Frequently asked questions
How long does a custom software project take?
It depends on scope. Serious discovery takes weeks, not days, and a useful first release usually takes a few months. Be wary of fixed deadlines quoted before discovery has happened.
Can I skip discovery if I already know what I need?
You can shorten it, not skip it. Even if the problem is clear to you, the team building the system needs to validate integrations, data and technical assumptions before committing to dates.
What happens with personal data if Law 21,719 is postponed?
The law still takes effect on December 1, 2026. A bill (Bulletin 18.623-07) proposes moving that to December 2027, and the Senate Constitution Committee only began discussing it on October 19, 2026. Until it's published as law, the date stands. A system designed today will run for years, so it makes sense to build it to comply either way.
Before you sign, ask for the deliverables plan
Stage-by-stage deliverables give you checkpoints while changing course is still cheap. If a vendor can't tell you what you'll receive at the end of each stage, that answer already tells you a lot. At Disrupsoft we design and build custom web and mobile applications, staying in constant contact with your team throughout the project. If you're about to start one, let's talk about your custom software development project.
