# Four calendar days, one person, one full redesign
**Author:** Ivan Misic
**Published:** 2026-04-26
**URL:** https://ivanmisic.net/blog/ways-of-working/four-days-one-person-redesign
**In plain English**
I redesigned this site in four calendar days, changing the design system, public styling, admin area, build process, and hundreds of files. I estimated that a conventional team might need six to eight weeks for the same scope, but I did not measure that comparison. The speed depended on constant review and years of product and engineering judgment. Leaders still need to decide whether saved time should buy more output, better work, or work that was previously too expensive.
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: new design system, new admin stack, new typography, new tokens, and two layout systems rewritten. Hundreds of files changed across the public site, admin, and build pipeline.
The point of this post is 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. This was the launch version of Claude Design. I usually keep a tight cap on token spend, but I burned roughly USD 120 over my limit before I noticed. That amount came from the bill. Claude Design has improved since then and now uses much less of my allowance, so do not treat USD 120 as the current cost of doing this. The novelty got me.
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 work I would normally split between a senior product designer and the engineer turning the direction into tokens and primitives. The planning scenario below includes both inside one six-to-eight-week estimate, alongside the rest of the build and QA.
## The four days
The work ran from April 23 to April 26. Thursday started with the design brief, implementation plan, migrations, and token files, then moved into the public redesign. Friday continued the public work. Saturday brought the build-system split and the admin migration, and the work finished Sunday. Four calendar days.
| Metric | Value |
|-|-|
| Days | 4 |
| 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.
This is more than a static personal site. It includes a blog, tools directory, guides, RSS-driven news aggregation, marketing calendar, admin notes, authentication, content sync, and a CMS. The full scope 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 one project-specific review skill with separate security, architecture, and code-quality passes, plus a stricter tech-debt mode. It runs on every meaningful chunk of work, not just at milestones. A separate learning workflow watches findings over time and proposes updates to the review rules, so the checks harden as the codebase changes. The final architecture review found no critical or high issues. I ran the same project-specific checks throughout the redesign, not only at the end.
## The mobile UAT was a screenshot loop
The most interesting part happened away from the PC, on my phone with Claude.
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. In this build, the screenshot loop cut a small UI fix from a ticket cycle to a few minutes of spotting, prompting, deploying, and checking.
## The math
For comparison, this is my rough estimate for the same scope in a conventional team. It is a planning scenario, not a measured counterfactual. The scope includes discovery and design exploration, a complete design system, three full directions, the public-site rebuild, an admin stack migration, a build pipeline split, and QA 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, 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 97 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 is the **calendar collapse**, not the invoice. I shipped the equivalent solo, in four days, around a full-time job.
The next conclusion is tempting, and 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/ways-of-working/ai-isnt-coming-for-your-team) and [AI Made Building Easy. Knowing What to Build Just Got Expensive](/blog/ways-of-working/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. Without someone who can judge the output, the tool produces bad work faster. My experience helped me spot what was wrong and keep correcting it.
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, the taste, the decisions, the ability to look at a result and know it was wrong before it broke production. All of it 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's a question 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. I would not expect that speed without trust, room to decide, and a workflow built around it. 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, the headroom goes one of three ways. Most teams spend it shipping more: same people, more output, the velocity gain poured back into volume. That's the reflex. A smaller group aims for better instead, holding the scope flat but buying more iteration, more thoughtful design, more user research, fewer rushed compromises. The better bet is work that was always valuable but never worth the calendar cost.
I would not default to more output. Decide whether the saved time should buy more volume, better work, or work that was previously too expensive.
## 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.
We keep building tools to remove repetitive work. AI is the latest one. The useful question is what your team does with the time it gives back.
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.