Vue / Nuxt refactoring — code you're not afraid to work with
I clean up an existing project: fix the architecture, add TypeScript, migrate to Vue 3 and the Composition API. No rewrite from scratch, no stopping production.
Refactor
or start fresh?
Подходит
- You have a working project, but every commit is a gamble
- You need to migrate from Vue 2 / Options API to the Composition API
- Tech debt is growing faster than the team can fix it
- You want to introduce TypeScript into an existing JS project
Не подходит
- The project is small and one-off — it's simpler to rewrite from scratch
- There's no team to maintain the code after the refactor
- The stack isn't Vue / Nuxt
Is the code holding you
back?
Refactoring isn't about "making it pretty." It's about lowering the cost of every next feature and removing the fear that slows the team down.
Tech debt has piled up — every new feature costs more than the last.
The team is afraid to touch modules: "it works, don't fix it."
The project is on Vue 2 or the Options API — you want the Composition API and a modern stack.
You added a new section and it doesn't fit the architecture.
Cleaning up,
layer by layer.
I work iteratively — every stage adds value without breaking what's already running in production.
Audit and priorities
I go through the codebase, identify the bottlenecks, and set priorities — so we fix what actually hurts, not just what's visible.
Architectural refactor
Module structure, separation of concerns, state management — I remove coupling and add predictability.
Typing
I add TypeScript where it's missing, or clean it up where it's only nominally in place.
Migration
Vue 2 → 3, Options API → Composition API, Vuex → Pinia — systematically, without stopping production.
Code you're not afraid
to open.
A project where the team works with confidence and new features don't break old ones.
- 01Architecture built for growth
New sections fit into the structure instead of getting duct-taped on the side.
- 02TypeScript that actually works
Not "as any" everywhere, but real types — your IDE actually helps instead of staying silent.
- 03The team understands the code
No guided tour from the author needed, no fear of breaking something extra.
- 04A modern stack
Vue 3, Composition API, Pinia — no outdated API it's time to forget.
What changes
in the end.
| Before | After |
|---|---|
| Afraid to touch modules — "it works, don't fix it" | The team understands the code and makes changes with confidence |
Options API, Vuex, any everywhere | Composition API, Pinia, TypeScript with real types |
| A new feature unpredictably breaks an old one | Architecture with clear boundaries — new code doesn't break old code |
| Tech debt grows faster than the team can keep up | The cost of the next feature is predictable and decreasing |
We don't break it —
we improve it. Step by step.
We dig in
I study the codebase and put together a problem map and a plan. If there's an NDA, we sign it before starting.
1–2 daysWe agree on scope
We fix the order of work, timeline, and cost — before we start, in writing.
~ 1 dayWe refactor in iterations
I change one part at a time, with a demo at every stage. Production never stops.
from 2 weeksI deliver with documentation
I hand over the updated code and walk through what changed and why.
~ 1–2 hrsI work with what's
already there —
I don't throw it out.
- ✓8 years working with legacy code. Airline booking systems carry years of accumulated tech debt you have to work with, not rewrite.
- ✓I know the pitfalls of migrations. Where the Options API resists moving to Composition, where Vuex fights being replaced by Pinia — I've seen it firsthand.
- ✓TypeScript that's more than a claim. My public npm packages are typed — you can read the code before hiring me.
- ✓Refactoring for results, not for looks. I'll only propose what actually lowers the cost of maintenance.
FAQ
Show me the project — I'll tell you where to start.
Describe your stack and what hurts the most. I'll tell you whether it's a refactor or a rewrite — and which one gets you results faster.