How long does it take to build a website? Measure your next one
· 7 min read
There is no honest general answer to how long it takes to build a website, because scope, content, revisions and your own tools vary too much. The answer that helps you is your own: measure one project from kickoff to launch, note which phase each day belonged to, and you have a real number to quote from next time. On a Mac, an automatic record of your day makes that possible without running a timer.
Why the published answers do not help
Search the question and you will find answers from “a weekend” to “several months”. They are not wrong so much as describing different things: a one-page portfolio and a store with a hundred products are both “a website”.
They also mix two different numbers:
- Elapsed time: the weeks between kickoff and launch, including every day spent waiting for the client’s copy, photos or approval.
- Working time: the hours you actually spent building.
Clients ask about the first. You price on the second. A project can take eight weeks and forty hours, and if you only know the eight weeks, your quote is a guess.
The phases worth measuring separately
A total is useful. A total split by phase is far more useful, because it shows where the next estimate will go wrong. For a typical client site, the phases are:
- Discovery and proposal. Calls, questions, reading the old site, writing the scope.
- Design. Mockups, a style direction, the first round of feedback.
- Build. Templates, layout, code or a site builder, the parts that feel like “the work”.
- Content. Entering copy, resizing and compressing images, fixing formatting pasted from documents.
- Revisions. Change requests, the second and third rounds, the email threads about them.
- Launch and fixes. Domains, forms, testing on phones, the things that break on the live server.
Content and revisions are the phases people most often leave out of a quote, because they do not feel like building. They are still hours.
Measuring a project without a timer
Timers fail on web projects because the work is fragmented. A quick fix between calls, twenty minutes on a client email at night: nobody starts a timer for those, and they add up.
Punchcard takes the timer out. It is a Mac menu bar app that notices which app is in front during your day, by app name only, and at the closing time you set it prints a receipt: the top five apps with time per line, the rest as MISC, and a day total. It needs no macOS permissions to do this.
A simple method for one project:
- Write the kickoff date in a plain text file or a spreadsheet.
- Each evening when the receipt prints, write the day total next to the date, with the phase that day mostly belonged to.
- On a day that mixed phases or clients, export the CSV instead. It has one row per session (start, end, app, idle, seconds), so you can see that the morning was design and the afternoon was a different client’s email.
- On launch day, add up the hours per phase.
Be clear about the limit: Punchcard has no per-project or per-client tracking. If you build two sites in parallel, it cannot tell which one a session was for; you split that by day or by the times in the CSV.
Reading a build day on the receipt
A build day usually prints your code editor or site builder near the top, then the browser, then email and messages. Three things are worth knowing when you read it.
The browser line is mixed. On a web project, it holds testing your own pages, reading documentation and answering client comments in a web app. Your browser is the biggest line on your time report explains why it is accurate and still hard to read, and how itemizing websites in supported browsers can split it.
The email line on a revision day is revision work. It is easy to count only the time in the editor and call the rest overhead, but the thread where the client explains what they meant is part of the change.
The day total includes everything in front of you while you were active. Leaving the desk stops the count, so a long lunch does not inflate the build.
Turning one project into a quote
Once the site is live, you have a table: six phases, hours per phase, and the elapsed weeks. From that:
- Price on the hours. Hours per phase times your rate, with the revision phase as its own line so clients see that revisions have a cost.
- Schedule on the elapsed time. If content arrived three weeks late last time, the timeline for the next quote should say when content is due.
- Adjust for scope. If the next site has twice the pages, the content phase roughly scales; discovery and launch mostly do not.
Punchcard does not do invoicing or billable rates; this part lives in your own spreadsheet. How to estimate hours for a quote when you never tracked the last job covers building the first estimate before you have any measured project at all.
What the number will not tell you
A measured project is one data point. It will not account for a client who changes direction halfway, or a feature you have never built before. It also misses work away from the Mac: a phone call about the brief, sketches on paper, the thinking you did on a walk. Add those from your calendar where you can, and treat the rest as the reason a quote has a margin.
Questions
Should I count the weeks spent waiting for the client? Not as hours. Count them as elapsed time, and put a content deadline in the next proposal so the waiting is visible to both of you.
Can Punchcard track two client sites separately? No. It has no projects or clients. Split by day where you can, and use the start and end times in the CSV for days that mixed both.
How many projects do I need to measure? One gives you a baseline that beats any published range. Each further project shows which phases vary and which stay steady.