AI compressed the 15% of our website rebuild that was typing, not the other 85%

Back to all insights

Published on 9 Jun 2026

AI

420 hours → 78 hours: rebuilding bitnoise.pl with Claude Code and Figma MCP

Łukasz Roth

CTO & Co-founder

19 minutes read

An honest accounting of where the speed came from, where it didn't, and which parts of the work we'd never hand to a machine.

Not a single line of code on the website you're reading was typed by a human.

Every .tsx file, every animation curve, every Strapi fetcher, every piece of SEO scaffolding — 24,296 lines of it across 120 React components — came out of a Claude Code session. We wrote zero of it by hand. We reviewed all of it by hand.

And it still took us eight weeks.

That second number is the one we want to talk about. The story the industry keeps telling itself right now is "AI writes the code, the developer goes for coffee." That isn't what happened here. What happened is that the 15% of the project that used to be typing got compressed by about 5×, and the other 85% — strategy, copy, design, motion prototyping, code review, QA, SEO — got exactly the attention it always needed. The keyboard stopped being the bottleneck. Everything else stayed expensive.

This post is the honest accounting. The numbers come straight from git log . The comparison points come from time reports of the previous bitnoise.pl build. We're sharing both because we think the interesting question for any team considering this stack isn't "can the model code?" — it obviously can — but "what does the rest of the team have to do for the model's output to be worth shipping?"

TL;DR — the numbers, up front

~5.4× less developer time on the dev portion alone — and the new site has more pages, more animation, full Strapi integration for blog and case studies, and SEO/GEO scaffolding the old one never had.

The repo itself, audited from git log between 2026-04-08 (first commit) and 2026-06-02 (launch-ready):

Calendar span: 56 days (~8 weeks).

Active development days: 25. The other 31 were design, copy, review, QA, and waiting on decisions — all the work the model doesn't do.

Total commits: 181. Every one of them generated by Claude Code, reviewed by Claude Code in a fresh-context pass, signed off by a human.

Lines added / removed: 47,173 inserted, 5,676 deleted, across 857 file-changes.

Codebase shape today: 24,296 LOC across 120 .tsx files, 47 .ts files, and a single .css file (Tailwind v4 — yes, one stylesheet).

Focused coding time: ~78 hours across 53 discrete sessions. (Method: sum the wall-clock intervals between commits within a session; a gap longer than 90 minutes starts a new session. It's not a billing-grade figure, but it's the right shape.)

Average commit: ~26 minutes of attention. Most diffs are small enough to read in under a minute. That's deliberate.

Tooling, named explicitly so you can replicate the setup:

Claude Code — for code generation and for the code review pass.

Figma MCP — the design system, components, frames, variables, and motion prototypes live in Figma and the model reads them directly. No "implement from screenshot" guesswork.

Stack: TanStack Start + Vite 7 + React 19 + Motion 12 + Tailwind v4. Strapi as the CMS. Resend for the contact form.

Tokens and cost (rough):

52,800 changed lines × 70 chars ÷ 4 chars-per-token = 925k output tokens of shipped code.

With read context, retries, and review passes, end-to-end usage was roughly ~10–20 million tokens.

We actually paid for this with a Claude Max plan, but if you're estimating for your own team on pay-as-you-go API rates with prompt caching, the equivalent cost lands roughly $90–$180 depending on your Opus/Sonnet mix — Opus-heavy with effective caching sits near the top of that, a Sonnet-leaning mix near the bottom. Budget $200 and you'll almost certainly come in under it.

420 hours of typing replaced by 78 hours of judgment. The judgment is the part you can't outsource.

The legacy migration that took one day

If we had to pick the single moment that justified the whole approach, it would be May 20, 2026 — the day we ported the entire blog and case-studies sections off the old site and onto the new stack, with Strapi behind both.

Here's the actual timeline, straight from the commit log — timestamps and all:

From empty route to live, SEO-clean, Strapi-backed blog and case-studies sections: about eight and a half hours of one working day. Eight commits. One developer. Each commit small enough to review in a couple of minutes.

A few things we want to be honest about, because this is the part of the post that's easiest to over-sell:

The Strapi schemas weren't designed that morning. The content model — collections, components, relations — was decided ahead of time by the team that knew the content best. Claude Code wired the frontend to a schema that already existed.

The content itself didn't have to be migrated at all. Strapi was already the headless CMS behind the old site, so every post and case study already lived there, edited and polished. We just pointed the new frontend at the same Strapi instance. There was no content move, no copy- paste, no re-editing — the only thing that changed was how that existing content gets rendered in the new design.

Polish kept landing over the following week — a responsive image ladder for Strapi assets, the filter chip set tightened to a fixed five, image sizing tuned to stop pulling full-resolution originals onto blog tiles. The migration was a day. The finish took a week of small commits.

But the part that used to be "this is a sprint" was a day. And it was a day we spent reviewing more than typing.

The comparison point that anchors the whole post: the previous bitnoise.pl build came in at 420 dev hours total across three developers — Nowak (249h), Daria (66h), Gąsiorek (105h), dev-only, no design hours included. Even allocating the proportional slice of those 420 hours that was originally blog + case studies, the rebuild of those two sections fit inside a single working day. That isn't a model trick. That's what happens when you stop typing and start steering.

Why we rebuilt (the part the model never touched)

The old bitnoise.pl had drifted. Not in any single embarrassing way — drift is rarely loud. The positioning had moved, the case-study mix had changed, the services we actually sold in 2026 weren't the services the homepage led with. The site was a 2023 snapshot of a 2026 company.

Fixing that is a founder-level job. Before we wrote a prompt, we wrote:

A positioning doc: who we are now, who we sell to, what proof we want on the front page.

A sitemap with intent for every route — what each page is for, not what it is.

A page-by-page content brief, pinned to that intent.

None of that came out of Claude Code. It came out of a room. The model later read every one of those documents as context, and it referred back to them often, but it didn't write any of them, and we wouldn't have wanted it to. This is the layer where LLMs are dangerously fluent — they will happily produce a plausible-sounding positioning that is, on inspection, a description of a different company.

The takeaway for anyone replicating this: don't start with the model. Start with the document the model needs to read.

Copy was a human job, and we'd do it that way again

Every hero headline, every services blurb, every case-study lede was written or heavily rewritten by the CEO/CTO. The model was a thesaurus and a length trimmer. We did not let it freestyle copy.

Why not? Three reasons, in order of severity:

Voice drift. The model's defaults are everyone else's defaults. Letting it write the homepage is the fastest way to look like every other agency.

Hallucinated capability claims. A model writing services copy is one bad prompt away from promising a capability we don't sell, on a page Google indexes.

Generic SaaS-speak. Even when nothing is technically wrong, the result reads like a thousand other sites. The site is a sales asset. The words have to be ours.

A concrete example: the services slides

The clearest place to see this is the services section on the homepage — the sticky stack of four slides (Team Augmentation, Project Delivery, AI Solutions, Custom Solutions) with the rectangle- morph transitions between them. Each slide had a model-drafted copy block and a shipped copy block, and the diff between them is what the work of voice ownership actually looks like.

For one slide (we'd pick Project Delivery — the bubble-to-progress-bar one), the pattern was the same every time:

The model's draft hedged: "We can help you deliver projects on time and on budget."

The shipped version named a concrete deliverable, anchored to an actual engagement model, and dropped every "we can" and "we help".

About 40% of the words survived. About 100% of the structure was rewritten.

That ratio held across every page of the site. The model is not the writer. The model is the writer's first-draft generator — which is useful, but it is not the same thing.

Design and motion, plumbed in through Figma MCP

The visual language of the new site — the scroll-driven hero, the sticky services stack with the morphing rectangle, the scramble-text reveal on the highlights, the cursor-repulsion dots field, the snake animation on the Custom Solutions section, the Z-shape spacer — came entirely from the UX/UI team, as Figma flows and motion prototypes. Claude Code implemented them. It did not invent them.

This is the single biggest reason the site doesn't look AI-generic.

The unlock is Figma MCP — the Figma plug-in for the Model Context Protocol. With it connected, Claude Code can read the actual Figma file: components, frames, auto-layout, variables, design tokens, exact spacing. The implementation pass becomes translation, not invention. There is no "make it feel premium" prompt; there is "implement this frame, using these tokens, matching this motion reference."

If you're replicating this setup, the three things that earned their keep:

Wire Figma MCP on day one. A screenshot is a bad prompt. The actual frame is a good one.

Make the design tokens authoritative. Our Tailwind scale and our Figma variables share the same numbers. The model never has to guess what gap-6 is supposed to be.

Treat motion as a loop between designer and developer, not a hand-off. This is the part the "AI writes the code" story always skips, so it's worth spelling out exactly how a single animation got built.

How one animation actually got made

For every non-trivial interaction on the site, the work moved through the same loop. None of these steps is the model working alone:

The designers set the two ends in Figma — the starting frame and the final frame, as real states with real values.

The designers built a motion prototype showing how one becomes the other: the timing, the easing, the feel.

That got turned into a written brief — a full description of the animation with its technical requirements and an implementation plan — which the developer reviewed before a line of code was written.

Claude Code implemented it against the two frames, the prototype, and the brief.

The developer checked the result in a real browser and on a real phone — because a curve that feels right in a prototype can feel wrong at 60fps on a mid-range Android.

The developer tuned it — sometimes by going back to Claude Code, more often by hand-adjusting the raw numbers: speed, duration, easing, acceleration, delay — until the motion matched the prototype.

The designers reviewed the final, running effect and signed off. Their approval, on the real thing in the browser, was the gate. Not the model's, not the developer's.

The model wrote the keyframes. It did not decide what "right" felt like, and it was never the one who got to call an animation done. That stayed a conversation between the people who designed the motion and the person who could feel it running on a real device.

Some of the distinctive interactions on the site, each one

[truncated for AI cost control]