When to Rebuild vs Convert: A Figma to Code Decision Framework

The Question Every CTO Eventually Faces

Your product has been in market for a year or two. The design team has created a comprehensive new design in Figma — updated visual language, improved information architecture, refined component patterns. The new designs are significantly better than what is currently in production. Now you face the decision: do you convert the existing codebase to match the new designs, or do you rebuild the frontend from scratch?

This decision is consequential. Choose wrong and you either spend months refactoring code that should have been replaced, or you rebuild a codebase that could have been evolved at a fraction of the cost. Both mistakes are common, and both are expensive.

After guiding dozens of SaaS companies through this decision, we have developed a framework that consistently produces the right answer. It is not about gut feeling or engineering preference — it is about measurable factors that predict which approach will deliver better outcomes.

Factor 1: Component Architecture Quality

The single most predictive factor is the quality of your existing component architecture. Open your codebase and answer these questions honestly:

• Are your components built with a consistent pattern — typed props, separated concerns, predictable file structure?
• Do your components use design tokens (CSS custom properties, theme variables) rather than hardcoded values?
• Can you change the visual appearance of a component by modifying tokens and props, without changing the component's internal logic?
• Are your components composed from smaller, reusable primitives?

If you answered yes to three or more: your component architecture can likely absorb a new design. The conversion approach — updating tokens, adjusting props, and modifying styles — will be significantly cheaper than a rebuild.

If you answered no to three or more: your components are likely tightly coupled to the current visual design. Changing their appearance means changing their structure, which means changing their behaviour, which means risking bugs. A rebuild will probably be faster and safer.

Factor 2: Design System Distance

How far apart are the old and new designs? This is not about aesthetics — it is about structural similarity.

Low distance (conversion favoured): The new design uses the same layout patterns, the same component types, and the same information hierarchy, but with updated colours, typography, spacing, and visual polish. A settings page is still a settings page. A data table is still a data table. The visual language changed but the structural language did not.

High distance (rebuild favoured): The new design fundamentally restructures how information is presented. A sidebar navigation becomes a top navigation. A single-page dashboard becomes a multi-tab layout. Data that was in tables is now in cards. The structural patterns are different, not just the visual treatment.

When the structural distance is high, conversion becomes a Ship of Theseus problem — by the time you have replaced every structural element, you have rebuilt the frontend anyway, but with the additional complexity of working within the old codebase's constraints.

Factor 3: Test Coverage

Conversion is a refactoring operation. Refactoring without tests is gambling. If your existing codebase has solid test coverage — unit tests for component behaviour, integration tests for user flows, and ideally visual regression tests — conversion is safe. Tests catch regressions as you modify components.

If your codebase has minimal or no test coverage, conversion is risky. You will change a component's styling and accidentally break its behaviour because there is no test to catch the regression. In this scenario, a rebuild with tests written from the start is often safer than converting an untested codebase.

Factor 4: Technology Debt

A design refresh is sometimes the excuse to address technology debt that has been accumulating. Consider:

• Are you on a significantly outdated version of React, Next.js, or your styling solution?
• Does your codebase use deprecated patterns (class components, legacy context API, CSS-in-JS libraries that are no longer maintained)?
• Is your bundling and build tooling causing performance or developer experience issues?
• Are there known performance problems that stem from architectural decisions rather than implementation details?

If the technology debt is significant, a rebuild that addresses both the visual refresh and the technology modernisation simultaneously can be more efficient than doing them as separate projects. You are already touching every component — better to rebuild them on a modern foundation than to convert them to new visuals and then rebuild them again for technology reasons.

Factor 5: Timeline and Resource Constraints

Conversion is typically faster for small-to-medium scope changes. You are modifying existing, working code rather than building from zero. The product remains functional throughout the process because changes are incremental.

A rebuild requires a parallel codebase and a cutover point. Until the rebuild reaches feature parity with the existing product, you are maintaining two codebases. This is resource-intensive and creates a period of risk where bugs in the old codebase still need to be fixed even though the codebase is being replaced.

If your timeline is tight and the design changes are moderate, conversion is usually the safer choice. If you have the runway for a longer project and the design changes are substantial, a rebuild can produce a better long-term outcome.

The Decision Matrix

Score each factor on a scale of 1 (favours conversion) to 5 (favours rebuild):

• Component architecture quality: 1 = excellent, token-based, composable. 5 = poor, hardcoded, monolithic.
• Design system distance: 1 = visual refresh only. 5 = structural redesign.
• Test coverage: 1 = comprehensive. 5 = minimal or none.
• Technology debt: 1 = modern stack, no significant debt. 5 = major framework, tooling, or pattern debt.
• Timeline pressure: 1 = need results quickly. 5 = have runway for a longer project.

Total score 5-12: Convert. Your codebase is healthy enough to absorb the new design, and the changes are evolutionary rather than revolutionary.

Total score 13-17: Evaluate carefully. Consider a hybrid approach — converting well-structured sections and rebuilding poorly-structured ones.

Total score 18-25: Rebuild. The existing codebase will fight you at every step, and the result of conversion will be worse than starting fresh.

The Hybrid Approach

In practice, many projects benefit from a hybrid approach. Well-structured sections of the codebase — areas with good component architecture, solid test coverage, and designs that require only visual updates — are converted. Poorly-structured sections — areas with significant tech debt, low test coverage, or fundamental structural changes — are rebuilt.

The key to making this work is clear boundaries. Each section of the application operates independently, with shared design tokens and a shared component library at the foundation. Converted sections and rebuilt sections both reference the same tokens and use the same primitive components, ensuring visual consistency even though their underlying code has different histories.

Cost Comparison

Based on our project data across dozens of SaaS frontend projects:

• Conversion: Typically 40-60% of the cost of a full rebuild, delivered 30-50% faster. Best ROI when the existing architecture is sound and the design changes are primarily visual.
• Rebuild: Higher upfront cost but produces a modern, clean codebase with no inherited debt. Best ROI when the existing architecture has significant problems or the design changes are structural.
• Hybrid: Typically 60-80% of a full rebuild cost, delivered at a similar timeline to conversion. Best ROI when code quality varies significantly across different parts of the application.

If you are facing this decision and want an objective assessment based on your specific codebase and designs, book a free consultation. We will review your current code architecture and new Figma designs and recommend the approach that delivers the best outcome for your situation.