How long it takes, and what makes it take longer
Ranges we actually hit, week by week, for the work we do most. Including the honest part: the delays are usually not the building.
Why we give ranges instead of dates
A firm date given before anyone has seen the scope is a guess wearing a suit. We give you a range up front, then a specific date once discovery has told us what is actually in there.
What moves a project inside its range is rarely the code. It is how many edge cases your workflow has, how many other systems are involved, and how quickly decisions come back.
Once we are underway you see progress every two weeks, so a schedule slipping is something you find out about early rather than at the end.
A typical website build, week by week
This is a mid-size website rebuild, roughly eight to twelve weeks. A smaller project compresses the same steps. A larger one repeats the build and review cycle more times.
Discovery and access
Conversations with the people who use the site, a look at the analytics and the existing code, and the account access we need. Getting access takes longer than anyone expects, so we start it on day one.
Structure and design
Sitemap, page structure, and design for the templates that carry the site. We design the patterns rather than every page, because pages made from shared patterns are what let your team build the next one without us.
Build, in two-week cycles
Templates, then content, then the integrations. At the end of each cycle you see what is working on a staging site and tell us what to adjust. Content usually arrives during this stretch, and it is the most common reason this phase stretches.
Testing and accessibility
Keyboard and screen reader testing, cross-device checks, form and integration testing end to end, and a redirect map so your search rankings survive the move. Fixes come out of this, and we plan for them.
Go live, deliberately
We launch early in the week and early in the day, never on a Friday afternoon, with someone watching analytics and error logs afterward. Training for your team happens just before, while it is still fresh.
Stabilization
Every build comes with a thirty-day stabilization period for the things real traffic surfaces. After that, most clients move into an ongoing arrangement, and some take it from here themselves.
Timelines for the work we do most
These are the ranges we quote and generally hit. Anything with a wide spread has a wide spread for a reason, and we will tell you which end you are looking at once we have seen the detail.
A single page
One to two weeks for the first one, while we learn your platform and get access. A few business days for each one after that, sometimes faster when the content is ready.
A set of pages or a microsite
One to two weeks if the pages are closely related, two to four weeks when the layouts and content differ meaningfully from each other.
An audit
One to four weeks depending on scope. Accessibility remediation afterward runs from a few weeks on a simpler site to six to eight weeks or longer when the problems are structural.
An integration
A few days for a one-direction sync between two platforms with a standard API. Weeks when there is custom authentication, conditional logic, or two-way syncing involved.
An application
Six to eight weeks from kickoff to launch for a focused tool like an intake system or a directory. Three to four months for a member portal with several integrations. Larger platforms run longer.
Questions about how we work
- What is the most common reason a project runs late?
-
Content, by a wide margin. Copy, photos, bios, and product details take longer to gather than anyone plans for, because the people who have them have other jobs. Approvals and third-party access are the next two.
All three are easier to solve before the work starts. At kickoff we agree who is writing what, who approves, and which accounts we need, which removes most of the risk of a slipping date.
- How soon can you start?
-
Usually within a few weeks, sometimes sooner for a small piece of work. We keep our client list deliberately short so existing clients get real attention, which means our start dates depend on what is already in flight.
Tell us your deadline in the consultation and we will give you a straight answer about whether we can meet it. If we cannot, we will say so rather than take the work and hope.
- How fast can you turn a page around?
-
For the first page we build for you, usually 1–2 weeks. We spend some of that time getting oriented: learning your platform, getting access, understanding how your site is structured. After that, subsequent pages can land in a few business days. Sometimes faster, depending on complexity and how ready the content is.
- How long does a typical application take to build?
-
A focused application, a simple intake system or directory, usually takes six to eight weeks from kickoff to launch. A mid-size application, a member portal with several integrations, typically runs three to four months. Larger or more complex builds stretch further. The wide range is honest: what drives it is how many edge cases your workflow has and how many integrations are involved. The requirements document from Discovery will give you a tighter estimate for your specific situation.
- How long does an integration actually take?
-
Longer than most people expect. A simple one-direction sync between two platforms with a standard API can take a few days. Anything with custom auth, conditional logic, bidirectional sync, or a platform that requires generating keys through an admin account can stretch to a few weeks. We scope carefully before we start, so you know what you're in for.
- What's the typical timeline for an audit?
-
Typically one to four weeks depending on scope.
Have a date you are working toward?
Bring it to the consultation. We will tell you whether it is realistic, what would have to be true to hit it, and what we would cut first if it is not.
We would rather turn down a deadline than agree to one we cannot meet.