# Four Calendar Days, One Person, One Full Redesign
**Author:** Ivan Misic
**Published:** 2026-04-26
**URL:** https://ivanmisic.net/blog/digital-transformation/four-days-one-person-redesign
> Full site redesign, end to end: design system, admin stack, the lot. Four calendar days, one person, two evenings plus a weekend of real work. The interesting bit isn't the speed. It's what the new ship velocity asks of teams.
Anthropic shipped [Claude design](https://www.anthropic.com/news/claude-design-anthropic-labs), and the best way to evaluate a new tool is to put it to work on something real. So I pointed it at this site. Between April 23 and April 26, ivanmisic.net got a full redesign. Not a refresh. A redesign: new design system, new admin stack, new typography, new tokens, two layout systems rewritten, ~260 code files touched, 111 commits, roughly 20,000 lines of code added and 25,000 removed.
The point of this post isn't the volume. It's the calendar.
Four days. One person. The math is what matters.
## The design happened in two evenings
Before any of those commits existed, I spent two late evenings inside Claude design. Not Claude Code, the coding interface. The other one, where you describe a direction and watch it draw a real layout you can click around in.
> Quick honesty break. I usually keep a tight cap on token spend. Not this time. The tool was new, the canvas kept rendering things I wanted to push further, and I burned roughly $120 over the limit before I noticed. I'm normally the person preaching cost discipline. The novelty got me. Worth flagging.
I went in with almost nothing. "Dark theme, warm colors, help me redesign my site." Dropped a few screenshots of the old site. That was the brief. No moodboard, no tokens, no font picks.
For context, this is what I handed it. The v1 brutalist build, black canvas, Electric Lime accent, oversized outlined wordmark, monospace metadata everywhere:
What came back was three full directions, each with a Home, Blog index, Article, Tools, and Guides artboard:
- **A. Signal.** My old black-and-lime palette, evolved. Tighter type, editorial rhythm.
- **B. Atlas.** Swiss-editorial on warm paper. Serif display, library-catalog vibe.
- **C. Index.** Brutalist mono archive. Cool accent, terminal feel.
I told it I liked A and the typography across all three, but the lime green was tired and the palette needed warmth. From there, evening one became "make A warmer, lose the lime, push it toward something that doesn't feel like 2018." Evening two locked the system. Color tokens, typography pairing (Archivo Black plus Inter plus JetBrains Mono), the spacing scale, the component primitives. By the time I shut the PC down, I had a design brief I could hand to a developer. Said developer being, guess what... me. And the brief was about to feed straight into Claude Code.
That's already two roles I would have hired for. A senior product designer to drive the direction. A design system specialist to encode tokens and primitives. Both billing somewhere between four and eight weeks of calendar time, plus a discovery phase before that.
## The four days
April 23 at 18:42 the first commit landed, but that was base prep work: pulling the design brief into the repo, sketching the implementation plan, lining up the migrations and token files so the actual build had somewhere to land. The real building started Friday evening and finished April 26 at 20:54. Four calendar days. Two of them (Thursday and Friday) were workdays where I picked up after the day job ended, late afternoon into late evening. The other two were a weekend, and that weekend was, to be honest, more than just "evenings." In between:
| Metric | Value |
|-|-|
| Days | 4 |
| Commits | 111 |
| Code files touched | ~260 |
| Lines of code added | ~20,000 |
| Lines of code removed | ~25,000 |
| Major systems rewritten | Public CSS, admin UI, build pipeline, design tokens |
The public site got a new design system end to end. Admin moved off the old patchwork CSS onto a Tailwind stack with its own component library. That admin migration is worth flagging on its own. Nobody sees admin except me, so the calculation was simple: why would I spend evenings hand-crafting a layout no user will ever load? I asked Claude Code, from my phone, what it would do with the admin if I let it pick. It came back with three mock variations. I picked one, we clarified a few specs (sidebar behavior, table density, a few component primitives), and the entire admin shipped in roughly three or four hours of me opening the phone, instructing, and watching it land. No laptop in the room.
The build system split into public and admin pipelines. Tokens were consolidated. Three independent dead-code passes ran. By the end, admin and public were speaking completely different design languages on purpose, so that future public redesigns wouldn't drag admin along.
One quick aside on the line counts, because the question keeps coming up. This isn't really a personal site. It's a blog, a tools directory, guides, RSS-driven news aggregation, a marketing calendar, an admin notes system, OAuth + magic-link auth, content sync between local and production, and a fair bit of CMS underneath. Full scope inventory is in [How I Built This Site With Claude Code](/blog/ai-tools/how-i-built-this-site-with-claude-code#why-a-personal-site-has-this-much-code).
This is the part where someone usually asks "but is the code any good?" The honest answer is that I don't trust the first output of any AI tool, ever. The amnesia is real. Not full amnesia, just enough that things slip through, and the more you scale a build like this, the more obvious it gets. The mitigation is constant oversight, not a single review at the end.
What that looks like for me is a small framework of project-specific review skills: one for security, one for architecture, one for code quality, one for tech-debt scoring. They run on every meaningful chunk of work, not just at milestones. There's also a meta-skill on top that watches the findings over time and proposes updates to the review skills themselves, so the rules harden as the codebase changes. The architecture review on this redesign landed at 92 out of 100 with no critical or high issues. I'm not saying it's perfect. I'm saying it cleared the same gates I would apply at work, and it cleared them constantly, not just once.
## The mobile UAT was a screenshot loop
The most interesting part wasn't the work at the PC. It was Claude on my phone.
I would sit on the couch in the evening, open the redesigned site on my phone, find something that looked off (text overflowing on the guides hero, card padding wrong on the contact page, a hero animation that played too aggressively on small screens), and screenshot it. Drop the screenshot into Claude on the phone. Type "the breadcrumbs title is breaking mid-word on a narrow Android screen, fix the line wrapping." Send.
Claude would push the fix. I would refresh the page on my phone. Confirm it looked right. Move on.
It's mobile QA done by a single person, in real time, while watching TV. The thing it replaces isn't a developer. It's the entire ticket assignment, fix, review, deploy, retest cycle. The friction tax on small UI fixes is one of the most expensive line items in any product team's calendar, and it just got cut to seconds per fix.
## The math
If I had built this redesign through a normal product workflow, and I have been on the inside of plenty of those, the realistic *time* estimate looks like this. The scope I'm pricing is concrete: discovery and design exploration, a complete design system (tokens, type scale, components), three full-direction explorations, a public-site rebuild touching ~260 code files, an admin stack migration to Tailwind with its own component library, a build pipeline split, and the QA pass to make it all hold together on real devices.
| Role | Effort | Covers |
|-|-|-|
| Senior product designer | ~25-35 mandays | Discovery, three direction explorations, design system, handoff |
| Frontend engineer | ~25-35 mandays | Public site rebuild (~260 code files), responsive work, animations |
| Backend / platform engineer | ~5-10 mandays | Admin stack migration, build pipeline split, token consolidation |
| QA engineer | ~5-7 mandays | Cross-device, regression, accessibility |
| Product manager (part-time) | ~5-10 mandays | Coordination, scope, sign-off across phases |
| Calendar time end to end | 6-8 weeks | Handoffs, reviews, sprint cadence |
Roughly 65 to 95 mandays of effort, on a 6-to-8-week calendar. The two evenings I spent inside Claude design alone replaced the discovery-plus-three-explorations chunk that usually eats two to three weeks of a senior designer's calendar. The Claude Code work compressed the rest.
And that's only the work itself. The table doesn't count what comes before any of it: the meetings about whether it should happen at all, the alignment on how, the politics of who owns it, the back-and-forth on when it ships, the steering committee, the prioritisation deck, the slack thread that goes for two weeks. In most organisations that pre-work is where the real calendar disappears, and the math on that side is even worse than the build side.
Plug in your own day rate and you'll land where you land. I'm deliberately not putting a euro figure on it. The cost depends on geography, agency versus internal, seniority mix, and how disciplined the team is. A leaner setup could do this cheaper. This is a personal site, not an enterprise rebuild, and I'm not pretending the risk profile is the same.
The point isn't the invoice. The point is the **calendar collapse**. I shipped the equivalent solo, in four days, around a full-time job.
This is the part where I have to be careful, because the next sentence is the one most people get wrong.
## What this isn't saying
This is not "we don't need designers and engineers anymore." I wrote about this in [AI Isn't Coming for Your Team. It's Coming for Their Busywork](/blog/digital-transformation/ai-isnt-coming-for-your-team) and [AI Made Building Easy. Knowing What to Build Just Got Expensive](/blog/digital-transformation/ai-made-building-easy-knowing-what-to-build), and the argument hasn't moved.
Worth saying plainly. Claude Code is a tool. Claude design is a tool. The "AI" label is doing a lot of cultural work right now because it sounds like a category, but in practice these are tools, and tools need an operator. The output is only as good as the person briefing it, reviewing it, and deciding when it's wrong. Hand it to someone with no taste and you get faster bad work. Hand it to someone with twenty years of building real products and you get this post.
What I just did was possible because of years of product and engineering judgment. Knowing what to design. Knowing what good looks like. Catching when Claude's output is wrong, because it is wrong sometimes, and a constant review loop catches the things you wouldn't catch staring at the code yourself. Knowing the difference between code that ships and code that performs in production.
AI didn't replace those people. AI gave me a way to compress five people's *typing time* into four days. The thinking was still mine. The taste was still mine. The decisions were still mine. The ability to look at a result and know it was wrong before it broke production was still mine.
The thing AI replaces isn't the skill. It's the friction.
## The leadership question
If a senior practitioner can ship in four days what a team would spend two months on, that isn't a story about headcount. It's a story about ship velocity, and what your organization does with it.
Before the options, the part organizations keep skipping. None of this lands by handing the team a Claude subscription and a budget for tokens. The velocity gain is a function of trust, mindset, and how the team actually works day to day. Senior people have to be allowed to make calls without ceremony. Reviewers have to trust that a constant-review loop replaces the gate, not bypasses it. Leaders have to stop measuring activity and start measuring outcomes. Without that shift, the tools just speed up the meeting tax.
With that shift in place, three options for what the team does with the headroom:
**Ship more.** Use the velocity gain to do more work, faster. Same people, more output. The default most teams fall into.
**Ship better.** Same scope, more iteration. Higher quality, more thoughtful design, more user research, fewer rushed compromises.
**Ship the things you couldn't ship before.** Attack work that used to be off the table, not because it wasn't valuable, but because it wasn't worth the calendar cost. The teams that pull ahead live here.
Most organizations will pick option one by default. The interesting ones will deliberately pick two or three.
## What I am still figuring out
A few things I haven't fully resolved:
- The quality bar at velocity. The constant review loop caught real issues. Without it, this would have shipped a less honest version of itself. The discipline matters more, not less.
- The decision-making bottleneck. The faster the build, the more obvious it becomes that the slow part is figuring out *what* to build. That part hasn't gotten faster.
- The ergonomics. Four evenings (and one full weekend) in, my brain was tired in a different way than a normal sprint. Different cognitive load. I haven't decided yet what to do with that.
But the calendar is real. The commit count is real. The before and after is on the same domain you're reading this on.
There's an old line that laziness is the engine of progress. People build steam engines because they don't want to walk. People wire up macros because they don't want to retype. People build AI tools because they don't want to spend two months on something they could spend two evenings thinking through. The instinct that pushes humans to skip the boring middle is the same instinct that pushes the boundary of what's possible. AI is the latest, loudest version of that instinct.
So the question isn't whether your team will use these tools. They will. The question is whether your team is set up to be productively, creatively lazy, and to spend the time it just bought on the work that actually moves something forward.