Vue development and takeover

• You inherited a Vue application and nobody currently employed has read it
• It is on Vue 2, which has been end-of-life since the end of 2023, and the upgrade keeps getting deferred
• Small changes take far longer than they should, and nobody can say why

1. 01

   Read it

   I go through the code, the build setup and the dependencies, and hand back a written picture of what you own — including the parts that will bite later.

2. 02

   Make it safe

   Get it building reproducibly, get the dependencies to a supported version, and put tests around whatever would be catastrophic to break. In that order.

3. 03

   Keep going

   Then the features. By the project, or by the month if the codebase needs someone permanently attached to it.

• Vue 2 to Vue 3 migration, done in stages rather than as one weekend rewrite
• Dependency and build-tooling upgrades, including the move off deprecated tooling
• Continued feature work on an existing application
• Written documentation of what you own, which is often the thing that was actually missing
• Server rendering for the parts that have to be found in Google and in AI answers

What does it cost to take over a Vue application?

It starts with a technical review, because a migration cannot be priced on code nobody has read. After that it is either project work at an agreed price or a fixed monthly arrangement, and you get the figure in writing before anything begins.

We are still on Vue 2. How bad is that?

It stopped receiving updates at the end of 2023, so it is a security question. In most cases it is not an emergency, and it rarely calls for a rewrite from scratch. Vue 3 migration is usually incremental, and the first step is finding out how much of your code depends on the parts that actually changed.

Nobody documented it. Is that a problem?

No, it is the normal situation. Getting to grips with undocumented code is part of the job, and the written picture you get back at the end of a review is frequently the most valuable part of the engagement — it is the thing that stops you being dependent on any one person, me included.

Should we move it to React?

Usually no. A working Vue application rewritten in React is months of spending to arrive back where you started, with new bugs. Vue 3 is actively maintained and perfectly good. The real reasons to move are hiring — if you genuinely cannot find Vue people — or a fundamental architectural need, and neither is as common as the people proposing rewrites suggest.

The public part of our Vue app cannot be found in Google. Can that be fixed without a rewrite?

Usually yes. It is rarely the whole application that needs to be findable — it is a handful of pages: the front page, the services, the prices, a catalogue or a blog. Those can be server-rendered or pre-rendered on their own while the rest stays an ordinary client-side app behind the login. Titles, canonicals and markup get sorted per page at the same time, which is also what has to be in place before an AI assistant can quote you. That is days of work rather than a project.

Can you maintain it going forward?

Yes. That is the development partner arrangement at a fixed monthly price: you keep a ranked list, I take the top item and finish it before starting the next, with one month's notice and no lock-in.

• WordPress
• Laravel
• WooCommerce
• React
• Next.js
• Shopify

These are the technologies I work in most, not a limit. I also build in most other languages and frameworks, and on other webshop platforms.