How long does it take to build a website, an app or a system? Stage by stage, and what delays projects

Duration follows three things: the size of what is built, the number of parties who must agree, and how much depends on outside bodies. A six-page site in one language differs from a thirty-page bilingual site with booking and payment, even though both are called "a company website". An app for one kind of user differs from a platform with a customer, a provider and a driver, because each side is a full app with its own screens and testing.

So a duration means nothing without a written scope. An offer that promises three weeks with no list of pages or screens promises nothing specific. Ask for a schedule by stage, what you receive at the end of each stage, and what is needed from you and when. A schedule that lists the client’s tasks with dates is the mark of a company that knows where delay comes from.

Every serious project passes through the same stages, whatever their length. Analysis turns what is in your head into an agreed list of pages or screens and functions. Design draws the interfaces for you to see and approve before any code is written, and changing a drawing costs far less than changing a program. Development builds the front ends, the backend, the admin panel and the integrations. Testing tries everything on different devices and browsers and with unexpected cases. Then release and follow-up.

The common mistake is squeezing the first and fourth stages because they produce nothing you can "see". Thin analysis shows up later as "we never agreed on this", and thin testing shows up after launch, in front of your customers. A project that looks fast because it skipped those two pays the time back double at the end.

It is better for stages to be delivered in working pieces you can try, not all at once at the end. A test build every week or two means a drift is caught while it is small.

When a project runs late, the developer usually gets the blame, but the most frequent causes are shared between the two sides, and some sit with the client alone. Knowing them in advance is half the cure.

A large part of the date is in your hands. These actions cost no money and save weeks:

Yes, and the cleanest way is to shrink the first version, not to go faster. Ask: what is the smallest version a real customer could use? Launch that, then add the rest in phases. A website with five pages that sell launches in weeks, and its secondary pages are added while it is live. A system with one module enters service before the other modules are finished.

The second way is to rely on ready-made parts where the build does not set you apart: a ready payment gateway, a ready content system, a ready store platform if it is enough for you. The third is working in parallel: content, third-party accounts and data preparation run alongside development, not after it.

What cannot be shortened safely is testing, and adding developers at the end of the project. Putting new people on a late project usually makes it later, because the team spends its time explaining what has been built. And be wary of a promise of half the usual time with no reduction in scope. Something will be dropped, even if nobody says so.

Some durations are outside both parties’ hands and must go into your plan. Apple and Google review every app before it is published; review takes days and can come back with notes. Payment gateways ask for the business’s documents and approve the account in a time they set. A WhatsApp Business number goes through verification with Meta. Moving a domain between registrars has its own period. And integration with government services has its own approval procedures.

The rule: do not tie an ad campaign or an opening to delivery day itself. Leave a margin between delivery and announcement for outside reviews and for the notes of the first days. A project that goes live quietly two weeks before the announced date is better than one that launches on campaign day and stumbles in front of customers.

A verbal date protects nobody. Ask for the contract to include a delivery date for each stage and not only for the whole project, what the client receives on each date, each side’s response time, how the duration is counted if the client is late with content or approval, and how change requests are handled and how they affect the date. And ask each company one direct question: what happens if a delivery date is missed? Write the answer down.

At Fortune Code the delivery date is written into the contract and we keep it. We deliver in stages you can try yourself, and we work on Saudi time with daily follow-up on WhatsApp. We send a written quote within 24 hours that includes the schedule and what is needed from each side, the code and accounts are in your name, and you get fast technical support after launch.