The short answer
How long it takes to develop a system depends on the size of the problem, the integrations and how clear the scope is, and there is no single timeline. With delivery in short sprints, a first useful version usually ships in weeks, not months. The total timeline is set in the initial study.
Be wary of anyone who gives you a number before understanding your operation. A system that replaces an internal tracking spreadsheet and a system that serves citizens, talks to other databases and logs every action are different kinds of projects, even if both fit the sentence "we need a system". What can be guaranteed from the start is the pace: working software every cycle, so you see progress instead of waiting for the end.
What weighs most on a system's timeline
Five factors explain almost all the difference in timeline from one project to another. None of them is the programming language. The table shows what shortens and what lengthens each one.
| Factor | Shortens the timeline when | Lengthens the timeline when |
|---|---|---|
| Size of the problem | the system serves one user profile and a well defined routine | there are several profiles, like citizen, clerk and management in Ágil Cidadão, each using the same information in its own way |
| Integrations | the system stands alone or the other systems offer a documented API | each existing database has its own rules, access and tests, and that is where surprises usually live |
| Scope clarity | the operation already knows what needs to change and the decision makers agree | the problem is still tangled and validation has to separate the essential from the nice to have |
| Availability of decision makers | each sprint is approved at the demo | approval takes a while and the next cycle waits |
| Security, accessibility and Brazil's data protection law (LGPD) | the requirements are part of the design from the start | they show up at the end and force you to redo screens, permissions and records |
Notice that only the first factor has to do with the size of the system. The other four depend on organization, access and decision making, so you can work on them before the project even starts. If the scope is still fuzzy, the guide on how to define the scope of a software project helps you come better prepared to the first conversation.
The phases of development and what each one delivers
The cycle we follow has six stages, described in detail in how we work. They do not run in a rigid sequence: design, development and infrastructure overlap from the first sprints on, and that overlap is what avoids the summed timeline of six full phases.
- Product validation and study. We understand the operation, the users and the problem before proposing technology, with prototypes and conversations with the people who will actually use it. This produces the validated scope and the prioritized backlog, and this is where the total timeline is set.
- Interface design. Flows and clickable prototypes tested with the people who will use them, before they become code. Fixing a flow in the prototype costs far less than fixing it in the finished system.
- Development. Short sprints, reviewed code and automated tests. Each sprint ends with working software in staging, for you to test and approve.
- Infrastructure. Environments, automated deployment and monitoring sized for the operation, set up while the system grows.
- Security. Access control, data protection and LGPD compliance from the design stage, with checks before every release.
- Support and evolution. The system goes into production and real use feeds the next cycle of improvements.
Each sprint starts with planning, where we prioritize together what goes in and define the acceptance criteria for each item, and ends with the demo. This predictable pace is what lets you measure progress by what already works, not by an estimated percentage.
How an MVP shortens the time to the first useful version
The safest way to reach a useful system quickly is not to try to build everything at once. In the study, we separate what solves the main pain from what can wait and start with the part that delivers value sooner. This lean first version, used for real, is what the market calls an MVP, and we explain the concept in detail in the guide what an MVP is and how to validate a system.
An MVP does not make the project smaller. It changes the order. Instead of waiting for the whole system to start using it, the team starts working with the first part while the rest is built, and real use shows what actually matters. Features that seemed essential on paper sometimes lose priority, and others appear. Adjusting course every sprint costs less than discovering the detour at the end.
That is the case with our patient management system for urgent care, under development to replace an off the shelf system that could not keep up with the operation. The scope runs from patient intake to the management report, and each part goes through the same cycle of sprint and demo.
What speeds up and what delays a software project
A good part of the timeline is in the hands of whoever hires. These practices make a real difference:
- One accountable person on your side. Someone with the authority to prioritize and approve, present at the demos.
- Early access to the people who run the routine. Not only management. The people who carry out the process every day are the ones who point out the rule nobody wrote down.
- Integration documentation gathered beforehand. Contacts, access and manuals for the systems that will talk to the new one, so integration does not stall waiting for an answer.
- Accepting a lean first version. Start using what already solves the main pain, instead of waiting for the complete system.
- Recorded decisions. Documented acceptance criteria and changes avoid reopening what has already been agreed.
And some things almost always cause delays: changing priorities in the middle of a sprint, discovering a mandatory integration after the scope is closed and leaving user validation for the end. Scope changes are part of any project. What delays it is change without impact assessment, so every new request comes with its effect on the timeline, for you to decide what goes in now and what waits.
Why the timeline only becomes firm after the initial study
Before the study, any timeline is a guess. Nobody has talked to the users yet, nobody knows what the current systems allow and the scope is a wish list. A number given at that point tends to become one of two things: a timeline padded to cover the unknown, or one too short that breaks at the first integration.
The study exists to swap assumptions for information. It maps the operation, the integrations and the priorities, and returns a validated scope broken into stages. From there the timeline stops being a bet and becomes a plan, which you follow sprint by sprint. This applies to companies and also to public agencies, where procurement has its own rules and planning by stages helps make the schedule predictable, as we show in the guide on hiring software for a public agency.
How we arrive at a timeline for your case
Before any larger commitment, we run a short study that defines the scope, priorities, timeline and investment for your custom software. You come out of it knowing where to start and what goes into each stage. You do not need to arrive with a ready scope: just tell us what is causing work, delays or errors today.
If you would like a first read on your case, our consultant on the site asks the initial questions and passes the conversation on to the team.