The brief came in on a Monday
The client - a mid-size fintech company - had a product launch in seven days. Their current site was three years old, built on a platform they'd outgrown, and couldn't represent the new product direction. Their agency had quoted eight weeks (minimum). They needed something live by Friday.
We said yes. We had five days.
This is the story of how that went, what we built, and what the experience taught us about how speed and quality actually relate to each other.
Day one: ruthless scoping
The first few hours weren't spent writing code. They were spent cutting scope.
A complete site redesign in five days is possible. A complete site redesign in five days with ten pages, a CMS, a custom animation library, three integrations, and a new brand system is not. The gap between these two things is where projects die.
We sat with the client for three hours on Monday morning and asked one question for every requested feature: "What is the cost of not having this at launch?" If the answer was "launch is still viable", it came out. If the answer was "launch fails without it", it stayed.
We went from 14 initial requirements to 6. Everything else went on a post-launch backlog.
The lesson: most projects aren't slow because they're hard. They're slow because the scope was never treated as a constraint. When it is - when the deadline is genuinely non-negotiable - scope becomes the first and most important design decision.
The stack decision
We chose Next.js with Tailwind and deployed to Vercel. These weren't exciting choices - they were the most boring choices available, which was exactly the point.
Fast turnaround projects have no margin for debugging unfamiliar tooling. You want the decisions that let you spend every hour moving forward rather than reading documentation. If you can build it in your sleep, build it in your sleep.
We also made a call not to use a CMS for the initial launch. The client's marketing team couldn't update content yet - they were still writing it. Adding a CMS at this stage would have created more work for us and created a dependency on content they didn't have. We hardcoded everything with clear comments for the post-launch migration.
Pragmatism over purity. Shipping over systems.
Day two and three: design in the browser
We didn't do a traditional design handoff. There was no Figma-to-code translation step.
One designer worked directly in Tailwind, making visual decisions in the browser while the second developer worked on data structures, API connections, and the sections that were already clearly specified. The design and development happened in parallel, inside the same codebase.
This only works if the team has a shared visual language and enough trust to move without waiting for sign-off on every decision. It also requires a designer who's comfortable with the constraints of the medium - not someone who designs an ideal and then watches it get compromised in implementation.
The output wasn't pixel-perfect execution of a Figma file. It was a living thing that was already designed for the web, because it was built on the web.
The content bottleneck
The thing that nearly derailed us wasn't technical. It was content.
On day three, we had the structure, the components, and the layouts ready. We were waiting on copy for two high-stakes sections - the product value proposition and the pricing tier descriptions. The client's team was writing it.
By mid-afternoon, we had placeholder copy in those sections and had made a decision: we'd build everything else and integrate the final copy on day five. We documented exactly what was needed, what character limits the layouts assumed, and what the tone should match.
When the copy came in Thursday morning, it fit in 20 minutes.
The lesson about content: treat it like a dependency with a specific interface. Be explicit about what you need - length, tone, format - before you need it. Abstract placeholders are friction. Concrete requirements are a contract.
Day four: the real test
On the fourth day, we had something that looked like a finished site. This is the most dangerous moment in a fast-turnaround project.
It looks done. It isn't done. And the temptation to call it done and spend day five relaxing is enormous.
We deliberately ran the full QA process we'd run on any project: cross-browser testing, mobile breakpoints across six device sizes, performance audits, accessibility checks, all external links, form submissions, and a walkthrough from someone who hadn't touched the codebase in 24 hours.
We found 22 issues. Eight were significant (one CTA link was broken, two mobile layouts were broken, a form wasn't submitting to the right endpoint). None of them would have shipped if we'd thought "it looks done" and stopped.
The fourth day is not the coasting day. It's the day you actively look for ways the project can fail.
The launch
The site went live Friday at 2pm. The client sent a message at 2:17pm: "I wasn't expecting this to be this good."
That framing matters. They had calibrated their expectations for a five-day site. Something competent and functional and not embarrassing. They got something that looked like it had taken six weeks.
The gap between their expectation and reality was almost entirely created by the scoping conversation on Monday, the browser-based design process, and the fourth-day QA. None of these were particularly novel techniques. They were the result of treating the constraints seriously.
What this applies to
This wasn't a unique situation. The conditions - a tight deadline, a limited scope, a team with a shared working style - are reproducible.
But the broader lesson is less about the specific techniques and more about where project speed actually comes from.
Speed doesn't come from working faster. It comes from eliminating the work that didn't need to happen - the scope creep, the design-to-development translation overhead, the content dependencies that nobody managed, the fourth day where everyone assumed someone else was finding the bugs.
Tight timelines make the causes of slowness obvious. That's what makes them worth taking on - even when, especially when, everyone else says it can't be done.