A business website takes four to eight weeks. An e-commerce store takes eight to fourteen weeks. A custom web application takes three to nine months.
Those are working timelines assuming a responsive client. The word “assuming” is doing a great deal of work in that sentence, because the most common cause of a late website is not development speed. It is waiting for content, feedback or a decision from the client side.
Here is what each phase actually involves, where the time goes, and what you can do to compress it.
Timelines by project type
| Project | Typical duration | Longest phase | Most common delay |
|---|---|---|---|
| Landing page | 1–2 weeks | Design | Copy approval |
| Business website (5–10 pages) | 4–8 weeks | Design + build | Content delivery |
| E-commerce store | 8–14 weeks | Build + testing | Product data |
| Custom web application | 3–9 months | Build | Requirement changes |
| Enterprise platform | 6 months+ | Build + QA | Stakeholder alignment |
Week by week: a business website
Week 1 — Discovery. Goals, audience, competitors, page inventory, technical requirements. Ends with an agreed sitemap and scope. Skipping this does not save a week; it relocates the week to somewhere more expensive later.
Weeks 2–3 — Design. Wireframes for key templates, then visual design. Expect two rounds of feedback. This is where projects most often stall, because design feedback needs a decision-maker and decision-makers are busy.
Weeks 3–5 — Build. Templates built, CMS configured, content loaded, forms and integrations wired up. Often overlaps with design — later templates can be built while earlier ones are still under review.
Week 6 — Content and testing. Final content in place, cross-browser and cross-device testing, form testing, speed optimisation, basic accessibility checks.
Week 7 — Review and launch. Your review, fixes, then deployment: DNS, SSL, analytics, sitemap submission, redirects from any old URLs.
Week 8 — Post-launch. Monitoring, small fixes, training your team. Things always surface in the first fortnight of real traffic.
Compressing to four weeks is possible when content is ready on day one, the brand already exists, and one person can approve without consulting anyone. Those three conditions are rarer than clients expect.
Week by week: e-commerce
Everything above, plus:
Product data is the hidden project. A hundred products with variants, images, descriptions, prices, stock levels and categories is days of structured work, and it is usually the client’s to do. This single item delays more e-commerce launches than any technical factor.
Payment integration means gateway setup, sandbox testing, and testing the failure cases — declined cards, timeouts, duplicate submissions. Merchant account approval can itself take a week or more.
Shipping and tax logic ranges from trivial to genuinely complex depending on zones, weights and rules.
Order flow testing covers the full path including refunds, cancellations and out-of-stock handling.
Realistic total: ten to twelve weeks for a straightforward store — and the commercial decisions should be settled before any of it starts. See e-commerce development for scope detail.
Custom applications: why months, not weeks
Applications carry work that websites do not: data modelling, authentication, role-based permissions, business logic, automated testing, and a deployment pipeline. None of it is visible on screen, which is why application timelines surprise people who are mentally comparing them to a website.
A rough shape for a mid-size application:
- Weeks 1–3: Requirements, data model, permission matrix, technical architecture
- Weeks 4–6: Design of core screens and flows
- Weeks 7–18: Build, in reviewable increments
- Weeks 19–22: Integration, QA, user acceptance testing
- Weeks 23–24: Deployment, data migration, training
Anything with regulatory obligations sits at the longer end, because compliance is structural rather than a feature — we covered why in building NDIS-compliant care software.
What actually delays projects
In our experience, in order of frequency.
1. Content. By a wide margin. Clients underestimate how long it takes to write twelve pages of copy, find photography and gather what already exists. A design cannot be finalised against placeholder text, because real content is always a different length and shape.
2. Feedback cycles. A round of design feedback that takes eight days instead of two adds nearly a week — and there are usually three or four rounds. This is the single easiest thing to fix on the client side.
3. Too many approvers. Committee feedback arrives contradictory and late. One person must own the decision, even if several people contribute.
4. Scope creep. Each mid-project addition costs its own build time plus the disruption of changing direction. Not fatal, but it must be acknowledged as a timeline change rather than absorbed silently.
5. Third parties. Payment gateway approval, hosting migrations, DNS controlled by someone who has left, an API whose documentation is wrong. Identify these in week one.
How to speed yours up
- Write your content before design starts. The highest-leverage thing available to you. Even rough drafts let design work against real material.
- Name one decision-maker with authority to approve.
- Commit to a feedback window — 48 hours, in writing, at kickoff.
- Consolidate feedback into one document per round rather than trickling comments.
- Gather access early: domain registrar, hosting, analytics, third-party accounts.
- Say no to mid-project additions and keep a list for phase two.
Clients who do these things routinely finish two to three weeks earlier than clients who do not, on identical scope.
Frequently asked questions
Can a website be built in a week?
A landing page, yes. A small site on a template with your content ready, sometimes. A custom business website, no — not without cutting discovery, testing or both, and those are the parts that determine whether the site works.
Why do agencies quote different timelines for the same project?
Usually because they are quoting different scopes, or because some include your review time and others quote only their working days. Ask specifically: does this timeline assume we supply content, and how many feedback rounds does it include?
What if I need it by a specific date?
Say so at the first conversation, along with what is driving it. A fixed date is workable if scope flexes — launch with six pages and add four later. A fixed date with fixed scope and a short timeline generally means quality absorbs the difference.
How long does a redesign take compared to a new site?
Often similar, occasionally longer. You have existing content to audit and migrate, existing URLs needing redirects, and existing search rankings to protect. The design may be faster; the migration is not.
Does the timeline include SEO?
Technical SEO foundations should be part of the build — structure, speed, metadata, sitemap. Ranking is ongoing work that starts after launch and runs for months. See how much SEO costs in Nepal.
What happens if the project runs late?
It depends on why, which is why the cause should be tracked openly as you go. Good agencies flag slippage at the point it happens rather than at the deadline. Ask at kickoff how delays get communicated — the answer tells you a lot.
Planning your own timeline
Work backwards from the date you need to be live, add two weeks of contingency, and start your content the day you sign rather than the day someone asks for it.
If you want a timeline for a specific project, tell us what you are building and we will give you a phased schedule showing what we need from you and when. For budgets, see what a website costs in Nepal.
