How to redesign an app: Change nothing

A development team completed a full app redesign in four weeks by constraining the problem to visual and structural changes only, hand-crafting reusable components, and using an LLM to handle the assembly of pages. The team, consisting of three developers and a fractional head of design, avoided logic changes to keep scope fixed and shipped with virtually no production bugs.

I've never seen a project go so smoothly. Three developers, one fractional head of design, six weeks, virtually no production bugs. No heroics, no overtime — just a solid plan: constrain the problem, hand-craft the building blocks, and let an LLM safely do the manual labour. The app worked, it was simple, users even called it idiot-proof, but to be fair it didn't do all that much. None of us were really proud of it. The design wasn't consistent anywhere, each feature built with the design system du jour. The latest, a complete design system, with every level and every page accounted for and built to the brand spec, was just sitting on a shelf quietly going mouldy from lack of use. We had bold plans for new features, the kind meant to put us ahead of the competition, but there was nowhere good to put them. We could squeeze them in somewhere, sure, but it's hard to go to market with new features squished into an ill-fitting and inconsistent design. To address both of these issues, our fractional head of design pitched a full app refresh: our existing unadopted design system but elevated with a clear vision of the future. The designs were polished and beautiful, with the new features at their core, and with more ideas thrown in for good measure. The execs signed off without a fuss. The gap between "what we have" and "what we could have" was impossible not to see. The developers were happy, too — nobody enjoys maintaining a Frankenstein app. The plan was "eventual consistency": as pages got touched and flows were changed, we'd upgrade them to the new design system. But we just weren't making a dent that way. We finally had the excuse we needed to down tools and just do the redesign. But we were already worried about timeframes for these new ambitious features. We were now looking at having to complete a full app refresh first — the last time we put together an estimate for that it came back as four months and we had, functionally, negative time. What's more, the pitch didn't cover every page — mocking up the whole app in detail would have been wasted effort just to get exec buy-in. We'd need to improvise some of the flows. We decided to do it anyway. If this was happening, we were time-boxing it. Four weeks. Four weeks to build as much as we could, then UAT, bug fixes, and ship. No extensions, no scope creep, no "just one more page." The one rule that made this not actually insane: no logic changes. Visual and structural only. We didn't have time to rebuild the UI and rethink behaviour at the same time, and we certainly didn't have the time to test changes to UX with users, nor could we risk needing a rollback because users found some new flow confusing. That's exactly how a fixed-scope project turns into an open-ended one and we couldn't afford that. We wrote a ticket for every flow, every page, every feature. Then we ranked them by usage and value and drew a line at two sprints' worth of work. That line was our go/no-go: if we couldn't convince ourselves we'd clear it, we didn't start. Spoiler: enough fit under that line to make it worth a go. We still didn't have a formalised design system, and we didn't have a design for every page in the app. We knew we'd have to build the system as we went and make sure the pages that we didn't have a design for just followed it. We picked out the components that showed up across the designs — anything shared got pulled out and hand-built for reuse, built to enforce consistency rather than just to look right once. No arbitrary partials. No single-use HTML. No copy-pasting a card layout and tweaking the padding "just this once" — if it needed copying, it became a component. Once we had the base components we trusted — built by hand, matching the designs, well understood by the whole team — the rest of the app stopped being a design problem and became an assembly problem. For each new page: "Claude, here's the current version, here's roughly what we want it to become, only use these components." Sometimes we had a design reference. Sometimes we didn't, and it didn't matter — the content wasn't changing, only the system it was rendered through. With a small, tightly scoped set of building blocks as the only legal moves, there wasn't much room for Claude to invent something wrong. Plus, since we weren't making any logic changes, it was pretty difficult for it to make a mess and introduce bugs. The constraint on the inputs is what made the autonomy on the output safe. Four weeks later we'd worked through every page and flow we'd committed to — and then some. Claude built pages we didn't have designs for, a couple we'd genuinely forgotten we still had, and all of it held together as one consistent system. UAT turned up a handful of minor bugs but nothing that gave us pause. We got it ready to ship. In final review before the release, while discussing what made the cut and what didn't, our designer flagged a handful of must-haves that had never made the plan — because they weren't redesign work, they were feature changes. We'd spotted these back when we wrote the original tickets and deliberately deprioritised them below the new features roadmap. They were small enough that building them wouldn't threaten UAT or blow the timeline, so we said yes — but we didn't let them block the rollout. To be clear, if they would have invalidated the UAT or taken longer than the rollout plan covered, I wouldn't have let us do them. I wasn't about to push our release and lose valuable de-risking time. We didn't wait for these to be done before releasing to 10% — they only had to be ready before we rolled out to 100%. Then a pricing change landed that required functional changes so the app wouldn't confuse anyone — and it had a hard deadline the following week. We didn't want to build it twice, once for the old UI and once for the new, so we compressed the rollout: instead of two weeks stepping through 10%, 50%, and 100%, we went straight from 10% to 100% a few days later. We rolled out to 10%, with internal comms telling the rest of the company what was coming. Internally, there was excitement, but our users? Nobody said a word — not a complaint, not a comment. We finished the extra features and the pricing change, then rolled out to everyone, external comms and all. Still: nothing but positive internal remarks. No spike in support tickets, no mentions on social. A success? A week later we found one small bug and fixed it the same day. That was the entire post-launch list. The last few extras finished up in the background while we moved on to the next thing. A success. I've run a lot of projects and been a part of many more. Few have gone this cleanly, and none felt this fast. Four weeks of development, one week of UAT, one week of rollout and sneaking in some extras. No overtime, no burnout, just a solid plan. We didn't let ourselves be distracted from the task at hand and we made it safe and simple for Claude to work autonomously. I've never used the word "sprint" so literally in my life.