Key takeaways
Published timelines for a simple app range from about one month to three. For a system with integrations, vendors quote anywhere from 2–4 to 4–8 months, and for a complex platform, from 3–6 months to more than nine.
Most delays don’t happen in the code, but during waiting time: for decisions, feedback, access to systems, and data for migration.
Adding people to a late project usually doesn’t speed it up — every new person needs onboarding and increases the number of communication channels.
The most effective way to shorten a project is a narrower first version and a single decision-maker on the company side.
The short answer
It depends on what you’re building — but it’s possible to give sensible ranges. Here’s what Polish vendors publish (sources in Polish):
- Simple web app or admin panel: 4–8 weeks according to WaspIT, 2–3 months according to MadeByRogal
- System with API integrations: 8–16 weeks (WaspIT), a mid-complexity app 4–8 months (MadeByRogal)
- Complex platform or system: 3–6 months (WaspIT), 9 months and up (MadeByRogal)
For us, a first working MVP usually comes together within a month — but an MVP is not the same as a full production version.
Why is the spread so wide? Because every vendor defines “simple” and “done” differently. We break that problem down in our guide to custom software. Here we focus on something else: what a schedule consists of and what actually makes it longer.
Published timelines by project size
Timelines stated by WaspIT (2026). Other vendors quote periods up to two to three times longer for similar categories — so always ask what exactly the timeline covers:
What a schedule consists of
The stages are similar at most vendors. For each one, it’s worth knowing what its length depends on:
Analysis
Understanding the process, priorities, and constraints. It goes faster when the company has one person who knows the process and can make decisions.
Design and UX
Mockups, screen flows, sometimes a design system. Its length depends mainly on the pace of approvals — every round of revisions takes days, not hours.
Iterative build
The longest stage, but the most predictable, as long as the scope doesn’t change along the way. Each integration with an external system extends it the most.
Testing and acceptance
The vendor’s testing plus acceptance testing on the company side. Often an underestimated stage — your team has to find time to check the system against real scenarios.
Launch and migration
Moving data, training, go-live. The quality of data in your current systems can come as a surprise and add weeks of work.
Most delays don’t happen in the code
When a project runs late, the first question is usually: “why didn’t the developers make it?” Yet a large part of the calendar is taken up not by work, but by waiting time.
Take a simple example. A team works in two-week cycles. At the end of each cycle, it shows a working version and needs a decision to move on. If that decision comes three working days later, then in a ten-day cycle nearly a third of the time is spent waiting — at least for the tasks that depend on that decision. Over six months, those “just three days” add up to many weeks of delay.
Waiting for API access, an account with a payment provider, or a data export from your current system works the same way. Each of these looks like a minor detail, but it blocks specific work — and the team can neither do that work earlier nor route around it.
That’s why the most effective way to shorten a project rarely comes down to “coding faster.” It comes down to making sure work never has to wait.
Seven things that most often delay a project
Go through this list before you start — you can act early on most of them:
Scope changes along the way — Every new feature added halfway through pushes back the deadline for everything that depends on it. Good ideas are worth saving for the next version.
No single decision-maker — When decisions need sign-off from several departments, each one takes weeks instead of days.
Delayed feedback — A version shown at the end of a cycle that waits a week for comments means a week taken out of the schedule.
Access and accounts — API keys, payment provider accounts, domains, developer accounts in app stores. Setting them up can take longer than the integration itself.
Data for migration — Duplicates, missing fields, and inconsistent formats in your current systems usually only surface when the data is being moved.
Integrations with external systems — Poor documentation, no test environment, or a team on the other side that replies once a week.
Formalities — A data processing agreement, security team approval, procurement procedures. It’s worth starting them in parallel with the analysis, not after it.
Can you speed things up by adding people?
Intuition says twice as many developers means a project twice as short. In practice, that rarely works — Fred Brooks described the phenomenon back in 1975 in “The Mythical Man-Month,” formulating what’s known today as Brooks’s law: adding people to a late software project makes it later.
There are two reasons. First, every new person has to learn the project, and they’re brought up to speed by people who aren’t coding in the meantime. Second, the number of communication channels grows: a team of 3 has 3 pairs who need to communicate with each other, a team of 6 already has 15.
A bigger team makes sense when the project can be split into independent parts and that’s planned from the start. As a rescue for a late schedule, it usually fails.
How to realistically shorten a project
Four things that sit on the ordering company’s side and have the biggest impact:
A narrower first version
Choose one process and the smallest scope that can be measured. Add further features on top of a working system.
One decision-maker
With the authority to approve mockups and versions, and with time set aside in their calendar for the project.
Access and data before the start
Accounts, API keys, and sample data ready before the team needs them.
A steady review rhythm
A fixed meeting at the end of every cycle and feedback within one or two days.
Want a realistic schedule for your project?
Describe what you want to build. We’ll break the timeline down into stages with a concrete outcome for each and point out what’s worth preparing on your side before the start.
What to watch for in the schedule in an offer
The schedule in an offer is a promise worth checking before you sign a contract. A few questions quickly show whether it’s realistic:
- Does the deadline refer to an MVP or a production version? This is the most common source of disappointment.
- Does it include acceptance testing and data migration? If not, they’ll be added later.
- Are the dependencies on your side listed? A good schedule states plainly when the vendor needs decisions, access, and data.
- Does each stage end with a concrete outcome? “Stage 2 — development” isn’t enough. “Stage 2 — a working orders module in the test environment” is a milestone you can actually accept.
- Is there a risk buffer? A schedule with no slack at all for a project with integrations is a warning sign, not an advantage.
It’s worth tying milestones to acceptance and payments in the contract — we write about this in what a software development contract must include.
Frequently asked questions
How long does it take to build a simple app?+
How long does it take to build an MVP?+
Why do IT projects run late?+
Does a fixed price guarantee the deadline will be met?+
How long does launch take once development is finished?+
Have a project in mind?
We’ll help you design and deliver it — from strategy to a finished solution.
