Choosing the Right Stack for a Live Rewrite

Most tech-stack debates are about taste. On a live rewrite, they are about money and risk. The right stack is not the most fashionable one, or even the most capable one. It is the one that delivers the most value for the least risk on the timeline the business can actually afford. Get that calculation wrong and you either ship late on something over-engineered, or ship fast on something you will be apologizing for within a year.

Here is how we evaluate the choice, and the reasoning behind the calls we made rebuilding a live platform: stay on Laravel, ship in Vue, and plan deliberate moves to React and Next.js.

#Evaluate the project, not the trend

The stack decision does not start with frameworks. It starts with the project. How much data and business logic already exist, and in what language? Is the system live, and what does an hour of downtime cost? What does the team know well enough to be both fast and safe in? How tight is the timeline, and how real is the budget?

Answer those honestly and the stack often chooses itself. Skip them and you end up importing someone's conference-talk preferences into a codebase that has to keep taking payments on Monday. Evaluation comes before selection. For a takeover, that evaluation is the same assessment of the existing system we run before quoting any timeline, because you cannot choose where to go until you know where you are.

#Our comfort comes second

The path of least resistance in this field is to reach for whatever the team already likes. It ships faster for us, it is more pleasant for us to maintain, and it is easy to rationalize after the fact. It is also how a business ends up with software shaped around an agency's habits instead of its own needs.

We try to invert that. The starting point is the project's requirements and constraints, and our own preferences are an input rather than the answer. Sometimes that means working in a stack we are less comfortable with because it genuinely fits the problem better, and sometimes it means the mature, slightly boring option over the one we would personally enjoy more.

One nuance is worth being honest about, because it sits right next to the case for staying on Laravel below. Team familiarity is a legitimate factor, but only because it lowers risk and time for the client, not because it is easier for us. When the thing we know well is also the lowest-risk route to the client's goal, everyone wins. When it is not, the project wins and we do the less comfortable thing. A stack chosen for an agency's convenience optimizes the wrong variable: clients do not benefit from our comfort, they benefit from software that fits their problem and stays cheap to run. Putting our preferences second is not a sacrifice. It is aiming at the right target.

#Stay where the value already lives

The single biggest stack decision in a rewrite is whether to change the language, and the default answer should be no. We stayed on PHP and moved to Laravel 12 because the domain logic and years of data already lived in PHP and MySQL. Porting all of that into a different runtime would have multiplied the risk and the timeline for no proportional benefit to the business.

The tradeoff is real and worth naming out loud. Another language might be objectively nicer for certain tasks. But "nicer" rarely survives contact with a migration that has to preserve every business rule without losing a single record. Laravel gave us a modern foundation, a first-class testing story, and a type-safe contract layer to the front end, all without abandoning the ecosystem the data was already expressed in. The value was already in PHP. We built on top of it rather than translating it.

#The front end is a decision you can defer

Here is the call that surprises people: we built the application in Vue 3.5 with the Composition API now, while planning to migrate the admin and client panels to React later. That is not indecision. It is sequencing.

Vue got us to a safe, modern, type-safe single-page app fastest given where we started. The Composition API and a typed component layer let us rebuild the admin and customer experiences quickly and cleanly:

// ProductList.vue (Composition API)
import { useQuery } from '@tanstack/vue-query'
import axios from '@/lib/axios'
import type { ProductData } from '@/types/generated'

const { data: products, isLoading } = useQuery({
  queryKey: ['products'],
  queryFn: async (): Promise<ProductData[]> => {
    const { data } = await axios.get<ProductData[]>('/api/products')
    return data
  },
})

The longer-term direction favors React for those panels, mainly for the size of the talent pool and the breadth of the ecosystem we want to draw on as the product grows. Normally "we built it in one framework but want another" is a horror story. It is not one here, and the reason is a decision made on the back end: every endpoint exposes a typed contract generated into TypeScript. The same ProductData type backs a Vue component today and a React component tomorrow. The contract is the constant; the framework is the variable. That is what turns a terrifying rewrite into a planned, panel-by-panel migration with no back-end changes at all.

#The marketing site: keep it, then move it

The public marketing site runs on Wix, and during the rebuild we deliberately left it exactly as it was. Gold-plating the front door while the engine is being replaced is a misallocation of budget. Wix was doing its job: cheap, zero-maintenance, and good enough.

The long-term plan is to move it to Next.js, and the reasoning is about control and compounding value. Next.js gives us real performance and SEO headroom, a proper content pipeline, and shared design and components with the application, so marketing and product stop being two disconnected worlds. The tradeoff is honest: Wix costs almost nothing to keep, and Next.js costs real effort to build. So it waits until that effort is justified by the return. That timing is a business decision, not a technical one.

#Planning on two clocks

Every choice above has two answers: what we ship now, and where we are heading. Holding both at once is the heart of technical planning. The short clock is about getting a safe, valuable product live. The long clock is about keeping it cheap to change for years. A decision that is right on one clock and wrong on the other is still a bad decision.

Estimation works the same way. We estimate the near-term build against the system as it actually is, and we treat the longer-term moves, the React migration and the Next.js marketing site, as separately scoped and separately budgeted increments rather than vague someday intentions. The roadmap stays honest about which clock each item is on. Those columns are not hypothetical: they are the actual roadmap behind the Submitit rebuild, captured in full, alongside the live cutover, in the Submitit case study.

#The stack is a financial decision

Strip away the engineering and a stack choice is a financial one. The right stack maximizes value delivered per unit of time and risk, and minimizes total cost of ownership over the years the software will live. Over-engineering spends the client's money on flexibility they may never use, and delays the revenue a working product would already be earning. Under-investing saves money now and spends more later, in maintenance, in bugs, and in the cost of hiring people willing to work on it.

Our job is to land in the middle on purpose, for this specific client: ship the value soon, keep the risk low, and leave a system that is cheap to evolve. Sometimes that means the boring choice, and a boring stack that ships and earns beats an exciting one that slips. The client feels the difference on their balance sheet, which is the only scoreboard that ultimately matters.

#Choose for the balance sheet

Choosing a stack for a live rewrite is not about knowing the most frameworks. It is about evaluating the project honestly, naming the tradeoffs out loud, and planning on two clocks so today's speed does not become tomorrow's debt. Stay where the value already lives. Defer the decisions you can. And measure every choice against the client's bottom line.

If you are weighing a rewrite and want that evaluation done with your finances in mind rather than a framework wishlist, let's talk.