The brief
Two-person team. A real product that wasn't ready to demo publicly yet, but a tier-one VC about to write a check, and a deck deadline two weeks out. They needed a website that would survive a serious investor pasting the URL into a Slack channel. It had to feel built, not generated. Original art. Real copy. Fast. Crawlable. Hand-tuned.
And they had no money for an agency.
The team shape
One Intellilabs senior front-end engineer. Founder available for a 30-minute review every morning. That was the whole team.
The framing that worked: a real design system before a single page was built. Components composed from tokens, never the other way around. Daily reviews to catch drift before it shipped. Three short iteration loops per page rather than one long one. Fewer hands meant every decision had to be deliberate — which is the part most projects skip when the timeline gets tight.
"The discipline that makes a small team fast on a small project is the same discipline that makes any team fast on any project. The constraint just makes it visible." — Intellilabs engineer
What we built
- Next.js 15 + App Router, deployed to Vercel. Static where possible, ISR where useful.
- Sanity CMS for content the founder needed to edit weekly — blog, changelog, pricing.
- Tailwind on a custom design token set. No off-the-shelf UI kit. The site looks like the product, not like a template.
- A custom SVG illustration system for the hero and section dividers, sketched in Figma and iterated by hand in code.
- Full technical SEO — sitemap, structured data, OG generation, Lighthouse 100 on the homepage.
The eleven days, honestly
Days 1–2: shape and tokens
Half a day on a moodboard. Half a day defining colour, type and spacing tokens. The rest of the time building components against those tokens — with one rule: nothing gets a hard-coded value, ever. By the end of day two there were no pages yet, but a tokens file, twelve composable components, and one ugly preview page that proved the system worked.
Days 3–6: pages and content
Home, product, pricing, blog template, contact. Real copy, drafted against a writing-style brief and edited live by the founder over a shared doc. The pattern that worked: place the draft into the actual page, founder broke it on a five-minute Loom, fix, reship. Three loops per page, average. Pages composed almost entirely from the components built in days 1–2 — the new code in each page was structural, not stylistic.
Days 7–8: illustrations and animation
This was the part everyone was nervous about. It turned out fine — but only because illustrations were treated as deliberate craft work, not decoration. The engineer sketched concepts on paper, drafted them as SVG in code, refined paths by hand, then added animation. Most of the visual polish in the final site came from human eyes catching that something was 4px off. Patience, in other words.
Days 9–10: performance and accessibility
The boring part — the part that's actually the difference between a real site and a portfolio piece. Image budgets, font subsetting, lazy components, ARIA passes, keyboard navigation, reduced-motion fallbacks. Each one a separate pass with a separate testing rhythm. None of it visible, all of it audible if you used the site with a screen reader or on a budget phone.
Day 11: ship
Deploy to a real domain. Final Lighthouse run. OG image regeneration. Cache warmup. Pasted in the investor's Slack at 18:42.
The outcome
The investor signed. More importantly, the founder could keep the site moving. By month two they'd shipped twelve new blog posts and three product pages themselves — because the design system meant they were never inventing anything from scratch, only composing. The site stopped being a deliverable and started being a thing they owned.
What we learned
A design system first beats a design system later.
The temptation on a tight timeline is to skip the system and just build pages — we'll refactor later. Later never comes. Two days spent on tokens, primitives and components paid for itself by day four and kept paying for the rest of the build. The system is the speed.
Taste is the bottleneck.
A solid stack and a tight budget can produce any quality of site, including a bad one. The thing that decides whether the output is good is whether someone with taste is making decisions about every part of it — copy, spacing, motion, image choices. The cheapest things to ship are also the easiest to ship badly. Pay attention.
Spend the time you saved on the boring stuff.
Every hour the design system saved on layout rework was an hour spent on illustration, accessibility passes, and copy editing. That's the real productivity story — not raw speed, but a redistribution of effort toward the things that actually make a site feel made.
The one thing to take away
Shipping fast and shipping well aren't trade-offs. They're both downstream of one thing: making decisions in the right order. Foundations first, pages second, polish third. The expensive thing is rework — and a good design system is the cheapest insurance against it.