Architecture preflight • Keep, rewrite, protect • Before you rebuild
Pre-redesign audit
Map code and product UX architecture before you fund new screens, so the redesign rebuilds the right system.
A pre-redesign audit (a preflight architecture audit) maps your product's code and UX architecture before you fund new screens. The deliverable is a prioritized keep, rewrite, protect, and defer map: which flows are load-bearing, which screens are zombies, what the design system actually covers in production, and which engineering constraints a new UI cannot wish away. The read is non-destructive until you choose a path.
This is the commercial front door to Clearly's judgment work on a funded product UI redesign. It is not a messy-library cleanup. That offer is the design system audit. It is not an essay about whether the timing is right. Those decisions live on when to redesign your SaaS website and when to invest in a design system. If you already know which slice to rebuild, the method after this map is prototype-first discovery, often staffed as a design partner.
Search results for a UX audit before a redesign are mostly Spark-style UX reviews and CRO-first audits. Those fit when the question is conversion or a heuristic score. They are the wrong instrument when the question is whether the redesign will rebuild the right system. Their packages and prices stay on their sites.
Why redesigns fail without a preflight
The failure mode is simple. A team paints a new UI onto flows, dead features, and engineering constraints nobody mapped. The quarter looks productive. The product that ships is the old system in a new coat, minus a few paths someone deleted by accident.
Undocumented flows. The happy path lives in a demo. The real product is branches: admin overrides, billing edge cases, permissions, empty states, the screen only customer success uses. A Figma file that redraws the tour misses the flows that carry revenue. If those flows are not on the map, the redesign ignores them or "simplifies" them away.
Zombie features. Screens that still ship, still have routes, and still confuse new hires, but no one can name the job they do. Redesigning them spends the budget on surfaces you should have retired. Leaving them in because "they're in the nav" forces the new design system to cover debt. A preflight names them so leadership can defer or delete with a reason.
Engineering constraints. Auth, data shape, a legacy module nobody wants to open, a shared component that a dozen routes depend on. If the redesign ignores those, engineering will block the work or fork the UI. Both outcomes look like a design failure. They started as an unread codebase. Audit the code before you redraw the product. A React or Next.js tree will tell you which surfaces are one-offs and which are load-bearing primitives. A moodboard will not.
Design-system coverage myths. A Figma library with dozens of components does not mean production uses them. Coverage in the file and coverage in the running app are different maps. Rebuild screens on the assumption that "we have a system," and you will invent a second one. If the library itself is the mess (tokens that drifted, components nobody trusts, AI tools inheriting the drift), start with the design system audit. This preflight asks a prior question: which parts of the product should the redesign touch at all.
AI tools amplify the wrong patterns. Cursor, Claude, and v0 read the repo. Undocumented one-offs become the pattern the model scales. A redesign that starts in an AI tool before the architecture is mapped ships the old structure faster. Design systems for AI teams is the build when you already know the foundation has to be made readable. It does not decide what the redesign is allowed to change.
You need a preflight when the team cannot answer, in the same meeting, which flows are load-bearing and which screens are safe to leave alone.
What Clearly's preflight covers
Three layers. All of them read-only until you pick a path. We are not redesigning mid-read, and we are not dropping a new component library you did not ask for.
Product UX. Critical journeys, not every pixel. We walk the jobs customers and internal users actually hire the product to do, then compare that to the UI that shipped. The output is a surface map: which routes and states are load-bearing, which are zombies, and which jobs have no product UI at all (they live in Slack, a spreadsheet, or a founder's head). This is jobs-to-be-done against shipped UI. It is not a conversion-rate teardown and not a brand moodboard.
Code realities. A route and module map of the frontend you actually run. Shared components versus one-offs. Where state, permissions, and data shape constrain the interface. What a redesign must not touch because the blast radius is larger than the screen. Access is read-only. If the stack is React, we read that tree. If older surfaces are mixed in, we say so. Auditing the code before a redesign is constraint visibility, not a surprise rewrite.
Decision output. Every major surface lands in one bucket:
- Keep. The job is real and the implementation is sound enough to restyle, or to leave alone.
- Rewrite. The job is real. The current UI or structure will not survive the redesign.
- Protect. Do not "improve" this in the same pass. Billing, auth, a compliance path, a shared primitive with a wide blast radius.
- Defer. Real, but not this redesign. Naming it keeps it out of the critical path and out of the Figma file.
You leave with that map and the reasoning behind each call. Priorities, not a wish list of screens.
The boundary with neighboring work is deliberate. A messy library is the design system audit. A timing question about the marketing site is when to redesign your SaaS website. A timing question about system investment is when to invest in a design system. This page assumes a product UI redesign is already in play and asks what the architecture will allow.
Preflight vs design system audit vs when to redesign
Different problems need different work. Here is the honest comparison. More of the commercial map sits on our Solutions index if you are still sorting the shape of the engagement.
| Work | What you get | When it fits |
|---|---|---|
| Pre-redesign audit (this page) | Keep, rewrite, protect, and defer map across flows, surfaces, and code constraints | A product UI redesign is funded or imminent, and the team cannot say which system to rebuild |
| Design system audit | Messy-library readout: tokens, components, Figma-to-code drift, AI-readiness | The library is the problem. You need cleanup or an AI-ready path, not an architecture preflight |
| When to redesign your SaaS website | A timing decision for the marketing site | You are unsure whether the website should change at all |
| When to invest in a design system | A timing decision for system spend | You are unsure whether a design system is the next investment |
| Prototype-first redesign slice | Working interactions that decide one slice before production | The map already says which rewrite matters, and you need evidence before engineering commits |
| Design partner retainer | Ongoing embedded product design on a subscription | The map is clear enough to staff a workstream |
| Design systems for AI teams | An AI-ready system build | You already know the foundation needs to be built, not just mapped |
If you are about to redraw the product and you cannot defend what to keep, stay on this page. If the Figma library is what nobody trusts, use the design system audit. If you are still asking whether a redesign should happen, read the timing guide first. Do not hire a preflight to avoid that decision.
How it works
Four steps. None of them change the product until you pick a path.
-
Access and intake. A product walkthrough plus read access to the repo. We ask a short set of questions: what the redesign is supposed to change, what the team is afraid to touch, and which surfaces leadership has already promised to rebuild. No three-week kickoff.
-
Read-only preflight. We map journeys, surfaces, and code realities without editing the product. No mid-read redesign. No new screens "while we're in there."
-
Readout. A prioritized keep, rewrite, protect, and defer map, walked through together. Severity and sequence, so a founder or Head of Product can fund the next step without guessing.
-
Path choice. Three legitimate outcomes.
- DIY. You take the roadmap and run the redesign with your own team. The map is yours either way.
- Prototype-first redesign slice. We take the highest-leverage rewrite and decide it in a working prototype before production makes it permanent. That method is prototype-first discovery.
- Design-partner retainer. Ongoing product design with Clearly, on the live Standard or Advanced plan. How the engagement works is design partner for SaaS. The commercial shape (whole features, not a ticket queue) is the product design subscription.
The preflight does not lock you into the next step. It exists so the next check you write is for the right system.
If the readout says the marketing site is the actual problem, we will point you at when to redesign your SaaS website instead of forcing a product UI engagement. If it says the library is the bottleneck, the next offer is the design system audit, and the full build (when you already want it) is design systems for AI teams.
Investment
We do not publish a standalone preflight list price. Scope depends on how much product surface you have, how tangled the frontend is, and what you want after the readout. Book a discovery call and we will tell you how we would structure the work. We will not invent an audit SKU to make the page look complete.
What we can quote from live public pricing on clearly.design:
- Standard, $4,995/mo. One workstream at a time. Async, with weekly progress. Prototype-first discovery. Pause or cancel. Details on homepage pricing.
- Advanced, $7,495/mo. Two workstreams. Check-ins as needed. Engineering integration. Custom React and Tailwind components, plus the Standard stack. Same page.
Those bands are design-partner retainers. They are how ongoing partner work is priced after you choose a path. They are not a disguised price for the preflight itself. The design partner guide and the product design subscription page describe what each plan includes. Confirm the numbers on the homepage before you buy. They are the only Clearly prices this offer publishes.
If a fixed-price sibling is the better container after the readout, we name that page on the call. We do not copy a second price onto this offer or mint a preflight package beside the retainers.
Spark-style UX-before-redesign audits and CRO-first shops sell their own packages. Those offers are theirs. We do not restate their prices.
Who this is for (and who it is not)
This is for you if:
- You are a SaaS founder, Head of Product, or eng lead about to fund a product UI redesign or rebrand of the product interface
- Budget or board pressure is real, and the architecture is not
- The team cannot say which flows are load-bearing, which screens are zombies, what production actually uses from the design system, or what AI tools will inherit
- You can grant a product walkthrough and read access to the repo
This is not for you if:
- You want greenfield brand moodboards and there is no product to audit
- You want someone to "just make it pretty" and you will not share code access. A preflight without the repo is a tour, not an architecture read
- The real problem is a messy Figma library. Go to the design system audit
- You are still deciding whether the marketing site should change. Read when to redesign your SaaS website first
- You are still deciding whether a design system is the investment. Read when to invest in a design system first
Questions for product teams before we talk:
- Which redesign has already been promised, and to whom?
- Which flow would hurt revenue if it broke next week?
- Which screens does the team avoid opening in the repo?
- Can you grant read access, or is the audit supposed to happen from screenshots?
If this is the right shape, book a discovery call. Bring the walkthrough and repo read access. We'll say whether a readout, a prototype-first slice, or a design-partner retainer fits. If the library is already the mess, start at the design system audit. If you want the retainer and the map can come from the work, homepage pricing lists Standard at $4,995/mo and Advanced at $7,495/mo.