When should a startup rewrite its product after traction? The six-question test

A rewrite can make sense when changing the existing system has become more expensive than replacing it. But that decision should not be based on frustration with old code or a belief that a newer technology will solve everything. You need to compare the cost of continuing with the current system against the cost of rebuilding it and the work you will have to delay while the rewrite is underway.

There are six inputs that can help you make that comparison: how long changes take, how often those changes fail, how easy it is to hire developers for each technology stack, whether the current platform has a limitation you cannot work around, how much runway the rewrite will consume, and whether you have a realistic migration path. If you cannot put numbers against at least four of these six areas, you probably do not have a decision yet. You have an argument.

Key takeaways

• Shopify rebuilt its Shop app from React Native to native in twelve weeks in 2026. This reversed a decision made in 2020 that the company had described as successful as recently as January 2025. The change shows how a rewrite decision can shift when one important factor changes.
• Joel Spolsky's long-standing rule from 2000 is to avoid rewriting software from scratch. The six questions in this article provide a way to test whether your situation is strong enough to justify breaking that rule.
• Two of the six inputs come from DORA delivery metrics, which have established definitions that you can begin measuring immediately. Two rely on adoption data that can be gathered through public APIs. The remaining two come from your own runway calculations.
• At the US mean wage, rebuilding a product with six engineers for three months would cost approximately $222,000 in salary before the new system ships anything. The table below shows how that cost changes depending on the startup's stage.
• Teams that have gone through modernisation tend to place significant value on their existing systems. Research based on 26 interviews and 198 survey responses also suggests that the challenges involved are not purely technical. Organisational factors can be just as important.

In this article

• When a rewrite is the right call, and when it is the loudest engineer winning
• The six questions to answer before approving a rewrite
• How Shopify decided to rebuild the Shop app natively
• What a rewrite costs in runway, by stage
• How to rewrite without stopping shipping
• What to do instead of a rewrite
• Where RocketDevs fits
• Conclusion
• Frequently asked questions

When is a rewrite the right call, and when is it the loudest engineer winning?

A rewrite is worth considering when something measurable has changed, not simply because the code feels old or difficult to work with. The most widely cited advice on the subject is more than 25 years old and takes a strong position against rewrites. The more practical answer is that a rewrite should be rare and should require evidence.

In April 2000, Joel Spolsky argued that rewriting a product from scratch is one of the worst strategic mistakes a software company can make. He used Netscape's nearly three-year gap between versions 4.0 and 6.0 to illustrate the risk. His reasoning still applies today: existing code has already been used, tested and debugged. It also contains knowledge that may not be obvious to someone reading it for the first time.

That last point explains why rewrite proposals can be misleading. An engineer may find an existing codebase difficult to understand and conclude that the code itself is poor. But difficult-to-read code is not necessarily broken code. A system that has accumulated years of fixes, edge cases and business rules can be difficult to understand precisely because it has been used extensively.

Research involving people who have actually worked through software modernisation supports this caution. One study interviewed 26 industrial practitioners and then validated its findings through a survey of 198 respondents. It found that practitioners placed significant value on their existing systems and that modernisation created business and organisational challenges as well as technical ones.

This means the real question is not whether the codebase is ugly. Once a product has gained traction, some ugliness is almost inevitable. The code has been changed under real-world pressure, often while the team was trying to ship features and respond to users. A mature codebase is more like a house that has been renovated room by room than a house designed from scratch: some parts may not look elegant, but they contain a history of decisions that still matter.

The more useful question is whether something measurable has crossed a meaningful threshold. That is where the six questions in this article come in.

DORA's research provides one way to think about that threshold. Its 2023 report, based on more than 36,000 professionals across nine years of research, found a relationship between focusing on users and organisational performance. This matters because a rewrite can consume months of engineering time that could otherwise be spent improving the product for those users.

A rewrite therefore needs to deliver a concrete improvement that users or the business can eventually experience. It is not enough for the new code to be cleaner, newer or more enjoyable for engineers to work with. The six questions are designed to make you identify exactly what the rewrite is expected to improve and whether the cost of getting there is justified.

What are the six questions to answer before approving a rewrite?

Before approving a rewrite, answer six questions: How long does it take to make and release a change? How often do those changes fail? How large is the hiring pool for each technology stack? Is there a platform limitation that the current system genuinely cannot overcome? How much runway will the rewrite consume? Finally, how will you migrate the product while continuing to ship?

Answer the questions in that order and use numbers wherever possible. The goal is to replace a debate about whether the code feels old with evidence about what the current system is actually costing the business.

1. What is our change lead time, and where is it going?

The first two questions measure the cost of changing the existing system. Both have standard definitions from DORA, so they can be measured using information you already have in your development and deployment systems.

DORA defines change lead time as the time between a change being committed to version control and that change being deployed to production. Change failure rate measures the proportion of deployments that require immediate intervention after release.

Neither metric requires complicated analysis. Your version-control and deployment logs should provide the underlying data. What matters most is the trend rather than a single number. If lead time has doubled over the past year while the team has stayed roughly the same size, the cost of working with the current system is increasing. That is useful evidence for a rewrite. If lead time has remained stable for two years, the case is harder to make.

2. What is our change failure rate?

Change failure rate provides a second view of the cost of the current system. A rising rate means more deployments are creating problems that require immediate intervention.

Again, the trend matters more than one unusually bad release. Look at the data over a meaningful period and compare it with changes in team size, deployment frequency and the complexity of the product. A rewrite proposal should be able to show that the current system is creating a measurable delivery problem rather than simply making engineers unhappy.

3. Who can we hire on each stack, and at what rate?

The third question is often missing from rewrite proposals. A new technology stack still has to be maintained after the rewrite is complete. If only a small number of developers can work with it, the company may simply be replacing one technical constraint with a hiring constraint.

Public data can provide a useful proxy for the size and activity of different technology communities. For example, the React Native package recorded 47,808,471 npm downloads in the month ending September 19, 2026, while Expo recorded 31,432,412. The React Native GitHub repository had 126,670 stars, 25,281 forks and 1,153 open issues on September 20. Stack Overflow also had 136,909 questions tagged React Native compared with 336,120 tagged Swift.

These figures do not tell you how many developers you could actually hire. They measure activity and adoption instead. That makes them useful for comparing two potential stacks, particularly when combined with your own recruitment data. Look at your last three searches and record how many relevant candidates applied, what rates they expected and how long it took to find suitable people.

The important question is not which technology has the biggest number. It is whether the proposed stack gives you a realistic pool of developers you can hire and afford.

4. Is there a platform constraint we cannot code around?

The fourth question should have a clear answer. If the current technology genuinely cannot provide a capability the product needs, identify exactly what that capability is and prove the limitation.

A short technical spike can help. Give the team a defined problem and a limited amount of time to determine whether the current stack can support it. If the experiment demonstrates that the capability is genuinely unavailable, you have evidence for the constraint. If the team finds a workable solution, the issue was probably a preference rather than a hard technical limitation.

5. How much runway does the rewrite consume?

The fifth question is about the financial cost of stopping or slowing other work while the rewrite happens. This includes the cost of the engineers working on the rewrite and the value of product work that will not be delivered during that period.

The next section looks at how to calculate this cost more precisely.

6. What is the migration path, and what ships in month one?

The final question is how the business gets from the current system to the new one without putting the entire product on hold.

A gradual migration can allow the team to replace parts of the system while continuing to ship useful work. Approaches such as the strangler fig pattern or module-by-module migration can reduce the risk of a single, high-stakes cutover.

The opposite approach is a big-bang rewrite in which the team spends months rebuilding everything before customers see a meaningful result. If the plan produces nothing useful for six months, that should be treated as a warning sign rather than an inevitable cost of rewriting.

The six questions therefore test two things at once: whether the existing system has become expensive to change and whether the proposed replacement can be delivered without consuming more time, money and product progress than the problem justifies.

How did Shopify decide to rebuild the Shop app natively?

Shopify's Shop app is a useful example of how a rewrite decision can change without the original decision having been wrong. In 2020, Shopify chose React Native because several important inputs favoured it. Five years later, one of those inputs had changed significantly. Shopify then reconsidered the decision and rebuilt the Shop app using native technologies.

The important lesson is not that React Native was a mistake or that native development is always better. Shopify's experience shows that technology decisions depend on the conditions that exist when the decision is made. When those conditions change, the decision can be reconsidered.

In January 2020, Shopify announced that it would build its new mobile apps using React Native after years of native mobile development. The company cited its existing React expertise and the potential to share code between iOS and Android. Its Arrive app had reached 95%code sharing between the two platforms, while Compass had reached approximately 99%.

Shopify also documented the limitations of its decision. React Native would not necessarily be suitable for apps targeting older hardware, apps requiring heavy processing or extremely high performance, or apps that needed many background threads. Existing apps would not automatically be rewritten either. Choosing React Native for new development was therefore not the same thing as deciding that every existing native app should be replaced.

By January 2025, Shopify was reporting strong results from its React Native strategy. The company reported screen loads below 500ms at the 75th percentile in the Shopify app and more than 99.9% crash-free sessions. It also said that avoiding the need to build the same features twice had produced a significant improvement in developer productivity.

Shopify's advice at the time was not to choose between native and React Native as if one technology had to win. Instead, it recommended using both where appropriate. The results showed that the original decision had delivered what Shopify wanted from it.

Then one of the underlying assumptions changed. In September 2026, Shopify explained that improvements in large language models had changed the economics of native development. By late 2025, its coding agents could use an iOS implementation as a reference when building the corresponding Android feature, and vice versa. This reduced one of the main costs that had influenced the 2020 decision: having to build the same feature separately for two platforms.

The result was a reversal. Shopify rebuilt the Shop app natively and reported that it went from proof of concept to a fully rebuilt app published in the stores in just 12 weeks.

The important point is that Shopify did not treat its earlier decision as something it had to defend forever. It reconsidered the decision when one of its core assumptions changed. A technology choice can be successful for years and still become the wrong choice when the conditions around it change.

What does the Shopify example tell us?

Viewed through the six-question test, Shopify provides public evidence for several parts of the decision.

The first two questions concern the cost of change. In Shopify's case, one of the costs of the existing approach was having to build features for both platforms separately. That cost became less significant when AI-assisted development made cross-platform native implementation faster.

The third question concerns the available hiring pool and the cost of maintaining the chosen stack. Shopify's argument was not simply that AI could write code. It was that its development process had changed enough that the team could work across both native platforms without carrying the same cost as before.

The fourth question was not the reason for the rewrite. Shopify had already reported strong performance from its React Native apps in 2025, so the case was not based on the existing technology being incapable of delivering a good product.

The sixth question was also relatively clear. Shopify did not announce a company-wide halt while it rebuilt everything. It rebuilt one app, and the company says the process took 12 weeks from proof of concept to publication in the app stores.

There is less public information about the fifth question: how much runway or engineering capacity Shopify's rewrite consumed. Shopify has also not published a measured comparison showing that the native Shop app performs better than the React Native version across the relevant product metrics. The decision to reverse course is documented, but the long-term outcome of that reversal is still developing.

The response to Shopify's announcement was substantial. The Hacker News discussion received 1,272 points and 958 comments, compared with 324 points and 216 comments for Shopify's 2025 post about its React Native experience. Public interest in a reversal can be much greater than interest in the original success story, but that attention is not evidence that the reversal itself was technically or commercially successful.

There is also an important limitation to Shopify's example. Native development still means maintaining separate iOS and Android implementations. Shopify's argument is that the cost of doing this fell enough for its own apps and development team to make the trade worthwhile. A smaller startup cannot automatically assume that the same economics apply to its team.

That is the real value of the case study. Shopify did not discover a universal answer to the native-versus-cross-platform debate. It showed what happens when a company measures the assumptions behind a technology decision and is willing to revisit them when those assumptions change.

What does a rewrite cost in runway, by stage?

The basic calculation is simple: multiply the number of engineers by the number of months they will spend on the rewrite and by their loaded cost. But that is only part of the cost. You also need to account for everything those engineers could have shipped if they had continued working on the existing product.

The first part can be estimated using public wage data. The second is much harder to calculate and is often left out of rewrite proposals. A team that spends six months rebuilding its technology is also a team that is not spending those six months delivering the features, improvements and fixes that would otherwise have reached customers.

The US Bureau of Labor Statistics reported a mean hourly wage of $71.20 for software developers in May 2025. Its public data also puts the mean annual wage at $148,100. Levels.fyi, which collects submitted compensation data, reported median total compensation of $195,000 for US software engineers as of September 20, 2026.

For the table below, we use the BLS mean annual wage of $148,100. That works out to approximately $12,342 per month per engineer. The rewrite durations are assumptions rather than measurements because there is no standard research-based timeline for how long a startup rewrite takes.

There are three important points to keep in mind when reading the table.

First, these figures are a floor rather than the full cost. Employer costs and other overheads make loaded employment costs higher than salary alone. The product work that does not happen during the rewrite also has an opportunity cost, although that can be difficult to put into a precise dollar amount.

Second, moving only part of the team onto a rewrite does not mean the remaining team is operating at full productivity. Those engineers may still have to maintain the existing system even though it is scheduled to be replaced. They can also be working around changes made by the rewrite team. That creates additional coordination and maintenance work.

Third, the assumed timelines should be treated cautiously. A rewrite proposal is usually created by the people who believe the rewrite should happen, so the initial estimate may not account for unexpected dependencies, migration problems or product work that gets added along the way. A more conservative estimate is useful when calculating whether the business can afford the project.

The hiring question can also change the runway calculation. Suppose a rewrite can be completed by senior engineers who are available at $30.99/hr. At 160 hours per month, that works out to approximately $4,958 per engineer per month. Three engineers working for three months would therefore cost about $45,000 in engineering time, compared with roughly $111,000 using the BLS annual mean salary.

That difference does not mean the cheaper option makes a rewrite worthwhile. It shows why the cost calculation needs to use the actual team you could realistically hire. The answer to the runway question depends partly on who will do the work, what they cost and how long they will be needed.

A rewrite should therefore be treated as a runway decision as well as a technical decision. The headline salary figure tells you what the engineering effort costs. The more important question for a startup is what else the company gives up while those engineers are rebuilding the product.

How do you rewrite without stopping shipping?

The safest way to rewrite a product without stopping development is to replace it in small, working pieces. Migrate one part of the system, put it into production, measure the result and then move on to the next part. The existing system can continue serving users while the replacement is built alongside it.

A six-month period in which engineers rebuild the product but customers receive nothing new creates a significant business risk. The longer the gap between starting the rewrite and delivering value, the more assumptions can change before the new system reaches production.

The strangler fig approach, a term associated with Martin Fowler, is designed around gradual replacement. New functionality is built separately from the legacy system, and existing behaviour is moved across piece by piece. Each migrated part can reach production before the team starts replacing the next part.

This approach also limits the amount of work you can lose. If the first migrated section performs poorly, you have a smaller problem to investigate. If it performs well, you have evidence that the approach is working before committing the rest of the product to it.

A module-by-module approach follows the same principle at a different level. Find the part of the system with the greatest measurable problem and replace that part first. Keep the interface between the module and the rest of the product stable where possible, then change the implementation behind it.

This works particularly well when the existing system has clear boundaries. If the code is so tightly connected that changing one module requires changes throughout the application, the approach becomes more difficult. That is itself useful information because it tells you something important about the migration risk.

A big-bang rewrite takes the opposite approach. The existing system is largely frozen while the new product is built, and the replacement does not reach users until a large amount of work has been completed. This can produce a cleaner starting point, but it also means the team has to rediscover and reproduce a large amount of existing behaviour before it can validate the result.

Shopify's 12-week native rebuild is an example of a relatively contained replacement rather than a company-wide rewrite. The company rebuilt one product rather than stopping development across its entire mobile organisation. That distinction matters when using the example as a model for a startup.

The best measurement for a migration is the same measurement that justified the change. If change lead time falls for the migrated parts while change failure rate stays stable, the migration is producing the improvement you expected. If the new system shows no improvement after the first couple of migrated sections, stop and investigate before replacing more of it.

That gives the team an opportunity to learn from a limited amount of work instead of discovering the problem after the entire product has been rebuilt.

What should you do instead of a rewrite?

Before approving a rewrite, test whether the problem can be addressed without replacing the technology stack. A slow delivery process can sometimes be caused by poor documentation, unclear ownership or a lack of experience with the existing technology rather than by the technology itself.

DORA's 2023 research found an association between high-quality documentation and higher team performance. It also reported higher organisational performance among teams with what it describes as generative cultures. Neither intervention requires a new technology stack.

This matters because a difficult-to-understand codebase can create the impression that the architecture itself is the problem. Improving documentation can make the system easier to understand and change without requiring the company to rebuild it.

Hiring can address another common problem. Shopify's experience with React Native also highlighted the value of having developers with both native and web expertise. If the existing team lacks experience with the current stack, adding someone with strong knowledge of that technology may change the cost of working with the system without changing the system itself.

Before putting a rewrite into the budget, run a smaller experiment. Measure change lead time and change failure rate over two quarters. Identify the three modules with the longest lead times and document the problems that are slowing them down.

Then give those areas to a senior engineer with strong experience in the existing stack for a defined period. Improve the documentation, simplify the problem areas and address the delivery bottlenecks. Measure the same metrics again.

If the numbers improve, you have evidence that the problem may have been related to documentation, staffing or delivery practices rather than the underlying technology. If they do not improve, you have stronger evidence for a rewrite proposal. You can then return to the six-question test with actual measurements instead of relying on how frustrating the codebase feels.

Where RocketDevs fits

Question three is one of the fastest variables for a founder to change. It is also where RocketDevs fits most directly. A rewrite depends partly on whether you can staff the target stack quickly enough and what that team costs against your runway.

Senior engineers on RocketDevs cost $30.99/hr, or about $4,958 for a 160-hour month. Every developer is assessed for 6–8 hours per developer, with RocketDevs selecting from the top 2% of applicants. That can change the staffing calculation in the runway table without changing the discipline of the six-question test.

If the numbers support a rewrite, you can use RocketDevs to build a vetted team on the target stack and test the first slice during the 14-day risk-free trial. If the evidence points toward refactoring instead, the same approach can be used to bring in senior engineers to tackle the three worst-performing modules for a quarter. The goal is not to rewrite because you have access to developers. It is to use the staffing option that fits the evidence.

Related reading: MVP development for startups, scaling a startup, engineering decisions by funding stage, the hidden cost of AI-generated code, and the AI technical debt crisis.

Conclusion

A rewrite is not a reward for reaching traction. It is an engineering investment that needs to earn its place on the roadmap.

The strongest case for rewriting is not that the code is old, the team dislikes the stack, or a newer technology looks better. It is evidence that the current system is slowing the business down in measurable ways. If changes take too long, failures are increasing, the hiring pool is too expensive or too small, the platform is blocking important work, the rewrite can be funded without putting the company at risk, and there is a credible path to migrating users, the case becomes much stronger.

If those numbers are not there, keep shipping and improve the system you already have. Better documentation, stronger engineering practices, targeted hiring, and replacing the worst-performing modules may solve the problem without consuming months of runway.

The key is to make the decision before frustration makes it for you. Measure the cost of staying. Measure the cost of changing. Then choose the path that gives the business the clearest route to shipping better software without sacrificing the runway it needs to survive.

A rewrite can be the right move after traction. It just needs to be a business decision backed by engineering evidence, not an engineering preference disguised as one.

Frequently asked questions

How long does a rewrite take for a startup?

No study provides a standard timeline for startup rewrites, so any estimate is an assumption. Shopify reported moving the Shop app from proof of concept to publication as a native rebuild in 12 weeks, but that was one app built by an organisation of Shopify’s scale using agent-assisted development. A startup should estimate its own scope, add a substantial contingency, and then ask what will reach users in the first month. If the answer is nothing, the plan needs a migration path before it needs a budget.

Should I rewrite or refactor?

Refactoring should usually be the starting point. A rewrite needs stronger evidence that the existing system is creating a measurable business constraint. Look at the six questions in this article: change lead time, change failure rate, the available hiring pool, platform constraints, runway, and the migration path. If several of these point toward replacement, a rewrite becomes easier to justify. If they do not, targeted refactoring may solve the problem without taking the same amount of time and runway.

Why did Shopify move away from React Native?

Shopify has said that one of the assumptions behind its 2020 React Native decision changed. Coding agents had reduced the cost of building the same feature separately in Swift and Kotlin, while allowing developers to use one platform as a reference for the other. Shopify's original decision was partly intended to avoid duplicating development work, so a change in that cost calculation changed the trade-off. Shopify has not published a full performance or cost comparison between the React Native and native versions of the Shop app.

How do you keep shipping during a rewrite?

Use a gradual migration, such as a strangler fig approach or a module-by-module replacement. Build and release one slice of the new system while the existing system continues serving users. Then move to the next slice and measure what changes along the way. Avoid freezing the old system for months while the replacement is built. If nothing reaches users for a prolonged period, the project is effectively a big-bang rewrite regardless of what the team calls it.

When is a rewrite too risky for a startup?

A rewrite becomes especially risky when it consumes a large share of the team’s capacity or runway without a clear migration path. If most engineers would be pulled away from customer-facing work, the existing product would stop receiving important fixes, or the company could run out of runway before the new system delivers value, the risk is high. In that situation, measure the cost of staying on the current stack and test smaller changes first. A rewrite should have enough financial and engineering room to survive unexpected delays without putting the company’s ability to keep operating at risk.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Shopify Engineering, Back to native, Mustafa Ali, 10 September 2026
• Shopify Engineering, React Native is the future of mobile at Shopify, Farhan Thawar, 29 January 2020
• Shopify Engineering, Five years of React Native at Shopify, Mustafa Ali, 13 January 2025
• Hacker News via Algolia, item 49643982
• Hacker News via Algolia, item 42690114
• Martin Fowler, Strangler Fig, 22 August 2024
• Joel Spolsky, Things You Should Never Do, Part I, 6 April 2000
• Khadka, Batlajery, Saeidi, Jansen and Hage, How do professionals perceive legacy systems and software modernization?, ICSE 2014
• Google Cloud, Announcing the 2023 State of DevOps Report
• DORA, Guide to DORA metrics: the four keys
• US Bureau of Labor Statistics, software developers, hourly mean wage
• US Bureau of Labor Statistics public API, software developers, annual mean wage
• Levels.fyi, Software Engineer compensation, United States
• npm registry downloads API, react-native
• GitHub API, facebook/react-native
• Stack Exchange API, react-native tag
• Wikimedia pageviews, React Native