A first version of a web product that people pay for usually takes 6–14 weeks with an experienced freelancer. A clickable demo takes 1–3 weeks, an internal tool 4–10 weeks, and a full platform 3–6 months. The biggest factor isn't the number of screens, it's how many kinds of users it serves on day one.
A first version, often called an MVP (minimum viable product), is the smallest product people can actually use and pay for. Timelines vary mostly because of scope and decisions, not coding speed: the same product can take eight weeks or five months depending on how much goes into version one and how quickly questions get answered. Below: timelines by type, six real products, a week-by-week plan, what causes delays, and how to launch sooner. For a marketing website rather than a product, see how long a custom website takes.
How long a web product takes, by type
| Type | Timeline | What's in it |
|---|---|---|
| Clickable prototype or demo | 1–3 weeks | Enough to pitch or test with users |
| Internal tool or admin platform | 4–10 weeks | One job for your own team, with logins and roles |
| First version people pay for | 6–14 weeks | Accounts, payments, the core job, admin, live hosting |
| Full platform | 3–6 months | Several user types and many integrations, in phases |
| Type | Typical range | Real projects |
|---|---|---|
| Clickable prototype or demo | 1–3 weeks | — |
| Internal tool or admin platform | 4–10 weeks | — |
| First version people pay for | 6–14 weeks | — |
| Full platform (3–6 months) | 13–26 weeks | — |
| Six products I built | — | Digital business card: 8 weeks; Personalization engine: 8 weeks; School platform: 10 weeks; Farm rental platform: 14 weeks; Campaign platform: 14 weeks; Printing platform: 20 weeks |
Six real products and how long each took
| Product | Time | What it had to do at launch |
|---|---|---|
| Digital business card platform | 8 weeks | Profile builder, public pages, NFC sharing, plan payments |
| Personalization engine | 8 weeks | Contact import, templates, bulk page generation |
| School management platform | 10 weeks | Students, attendance, fees, report cards, parent messages |
| Farm rental platform | 14 weeks | Customer dashboard, live cameras, farmer tools, subscriptions |
| Campaign platform | 14 weeks | Campaign wizard, landing pages, gifts, postcards, checkout |
| On-demand printing platform | 20 weeks | Ordering app, checkout, branch routing, branch and admin tools |
Why some took twice as long
The eight-week products served one main type of user. The printing platform served three at launch: customers placing orders, 40+ branches receiving them, and admins running the whole network. Each group needed its own screens, and orders had to be routed to the nearest branch. It now handles 400+ orders a day. The school platform sits in between: staff, teachers, and parents, in ten weeks. Count your user types before you pick a launch date.
A first version, week by week
This is how a typical ten-week first version runs. Each stage ends with something you can see and try, on a private preview link.
| Weeks | What happens | What I need from you |
|---|---|---|
| 1 | Written plan: users, the core job, what's cut | One kickoff call, and access to any existing accounts |
| 2 | Key screens designed, on phone and desktop | One round of feedback within two days |
| 3–5 | Accounts, data, and the core job working end to end | A quick look at the preview each week |
| 6–7 | Payments, emails, and the admin view | Payment account set up and verified in your name |
| 8–9 | Testing, including failures, with a few real users | Three to five people willing to try it |
| 10 | Launch, monitoring, and handover notes | A go-ahead, and a quiet day to launch on |
What makes a first version take longer
Most delays have nothing to do with how fast code gets written. These are the usual causes, roughly in order of how many weeks they add.
Features added during the build
Every "while you're at it" pushes the date. Keep a list of new ideas and review it after launch, when real users have told you which ones matter.
Slow decisions and feedback
A design that waits a week for approval moves the launch by a week. One person who can say yes, replying within two days, keeps the timeline intact.
Waiting on other companies
Payment account verification, API access from a partner, or data from another team can each take days. Start these in week one, not week six.
More user types than planned
As the printing platform showed, each extra type of user adds its own screens and permissions. Launch for one group first if you can. Staff and partner tools can often be handled by hand, or in a spreadsheet, for the first few months.
How to launch a first version sooner
The fastest way to launch sooner is to launch less. These cut the most time without hurting what early users see:
- One type of user, one core job. Everything else waits for version two.
- One decision-maker. Feedback in days, not weeks.
- Existing services. Ready-made login, payments, and email instead of building them.
- Access on day one. Domains, payment accounts, and any data the product needs, ready before kickoff.
- A small first launch. Ten real users in week ten beats a thousand in week twenty.
Deciding what makes the cut is covered in what to put in a first version, and what each size costs is in what a web product costs. If a date is fixed, like an event or a funding deadline, work backwards from it: decide what must be live on that day, and treat everything else as the next release rather than a delay.
Do more developers make it faster?
Rarely, on a first version. Adding people adds coordination: the new developer needs to learn the plan, the work has to be split, and decisions now need two people to agree. Software teams have a well-known name for this, Brooks's law: adding people to a late project makes it later.
A first version is usually small enough that one experienced developer holding the whole thing in their head is the fastest setup. More people start to help once the product is live and there are separate pieces of work that can run side by side, like a mobile app and a web dashboard, or new features alongside fixes. If you need to go faster before that point, cut scope rather than add people. It works every time, and it costs less. The exception is a separate, well-defined piece, like a mobile app on the same backend, which a second developer can build in parallel once the core is stable.
The weeks after a first version launches
Launch day isn't the end of the timeline. The first two to four weeks after launch are when real users find the gaps no test did: a confusing step, a missing option, an edge case in payments. Plan time and budget for quick fixes in that window, rather than moving straight on to the next big feature.
After that, most products settle into a rhythm of small improvements based on what users actually do. That's when a monthly support plan makes sense. For web apps mine costs $400–1,800 a month, and what it covers is in what maintenance costs. Whichever way you go, make sure the code, hosting, and accounts are in your name, so the product isn't tied to one person. Ask for short written notes on how to deploy it and where everything lives, as part of the launch.
What to have ready before week one
Every item here, ready before kickoff, is time saved later. Most of them take you an hour, and each one can save a week:
With this ready, a first version stays on the short end of its range. See the kind of products I build on my SaaS and web products page, or send me your dateand what the product must do, and I'll tell you whether it fits. If it doesn't, I'll tell you what to cut so it does, or which date would work instead.
