eople asking "what does a web design agency process actually look like" usually get one of two unsatisfying answers: a vague five-word list with no timeline, or a diagram so detailed it reads like it was written to look thorough rather than to be read. Our homepage answers it with four phases — discovery, design, build, launch — each with a real week range, laid out as cards you scroll through with a progress bar tracking how far along the whole thing you are.
Theinterestingpartisn'tthefourphases.It'sthatthecardsreplayeverytimeyouscrollbackintothem,andtheprogressbardoesn't.
Each card uses whileInView with viewport: { once: false } — deliberately the opposite of most of the reveal animations on this site, which play once and stay played. Scroll a phase card out of view and back in and it fades and slides in again, every single time. For a section that's explaining a sequence, that repeatability matters: if you scroll back up to re-read Design, you should see it arrive again, not sit there inert because it already "used up" its one entrance.
typescript
// Per-card: viewport-triggered, replayable <motion.div initial={{ opacity: 0, x: -20 }} whileInView={{ opacity: 1, x: 0 }} viewport={{ once: false, margin: '-20% 0px' }} /> // Whole-section progress: continuous scroll position, not viewport events const { scrollYProgress } = useScroll({ target: containerRef, offset: ['start 0.2', 'end 0.8'], }); const progressWidth = useTransform(scrollYProgress, [0, 1], ['0%', '100%']);
The cards and the progress bar are driven by two genuinely different mechanisms sitting a few lines apart. whileInView is event-based — it fires when an element crosses a viewport threshold, discrete and re-triggerable. The progress bar is value-based — useScroll continuously reports a 0-to-1 number for how far the pointer target has moved through its scroll range, and the bar's width is just that number, always current, never "triggered." Discrete events for things that should feel like arrivals; continuous values for things that should feel like a fact about where you are.
It would be easy to leave the phases untimed — safer, in the sense that nothing can be checked against reality later. We put ranges on them anyway, because a process description without a timeline isn't actually answering the question "how long does this take," which is the question underneath most of the others. Week 0–1 for discovery, weeks 1–3 for design, and so on aren't marketing copy; they're what we tell a client on the first call, published in the same words.
The calendar depends on scope and decision speed, but the order should be visible before work begins. A straightforward marketing site may move through these stages in weeks; a product with accounts, payments, integrations, or native apps needs longer because each stage creates more states to design, build, and test.
- Discovery: agree the business problem, users, evidence, constraints, ownership, and the definition of success.
- Scope: convert the findings into deliverables, dependencies, exclusions, milestones, acceptance criteria, price, and schedule.
- Design: establish content hierarchy and user flows before polishing visual details that may still move.
- Build: deliver working slices that can be reviewed in context instead of presenting the entire product at the end.
- Quality and launch: test accessibility, devices, performance, integrations, analytics, redirects, backups, and operational ownership.
- Aftercare: monitor the release, resolve defects under the agreed warranty, and move ongoing work into a support plan if one is needed.
Coding is rarely the only critical path. Missing content, unavailable decision-makers, unapproved designs, delayed access to payment or platform accounts, undocumented legacy systems, and late changes to the business rules can stop a project that still looks busy from the outside. A useful schedule names these client and third-party dependencies alongside the build tasks.
Review cadence matters as well. Small, regular approvals reduce the size of every disagreement. If feedback is held until a complete build is presented, a misunderstood assumption can survive for weeks and become expensive to reverse. The process should say what will be shown, who approves it, and how quickly the next stage can proceed.
- The production system and the accounts required to operate it.
- Source code, design assets, content, and deployment access under the agreed ownership terms.
- A record of testing, known limitations, analytics, monitoring, backup, and recovery arrangements.
- Documentation for routine updates and the route for warranty or support requests.