A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Vue's hiring problem is not quality. It is arithmetic, and then it is a version boundary.
There are considerably fewer Vue developers in the market than React developers, and the ones available are divided by a line that runs straight through the ecosystem. Vue 2 reached end of life on 31 December 2023. A great deal of production Vue is still sitting on it, either paying for commercial extended support or quietly running unpatched.
The second split is the API. The Options API — data, methods, computed — is what most people learned. The Composition API with <script setup> is what new Vue is written in. Fluency in one does not make somebody productive in the other, and a lot of CVs say "Vue 3" when what they mean is "Vue 3 written in the Options API".
Ask which they reach for by default, and why. The answer separates candidates faster than any version number on a CV.
Vue screening is mostly about establishing which Vue someone actually writes.
Whether they write <script setup> by default or translate Options API habits into it. The difference shows up immediately in how they structure composables.
ref versus reactive, why destructuring a reactive object silently breaks updates, and when a computed beats a watch.
Whether they have taken a codebase off @vue/compat and finished, or only started one. We ask what stalled and what they did about it.
Pinia store design, and the judgement to leave component state in the component instead of promoting it to a global store.
Server rendering, data fetching and routing conventions are a distinct skill. We do not assume Vue experience covers them.
A live conversation in English, every time. Migration work depends on someone flagging an unmaintained dependency early rather than absorbing it quietly.
The expensive Vue outcome is a migration that stops halfway.
A team starts on @vue/compat, the migration build, because it lets Vue 2 code run under Vue 3 while emitting deprecation warnings. That is the correct first move. The trap is that it works well enough to stop being urgent. Six months later the application is still on the compat build, half the components use the Composition API and half do not, and every new developer needs both mental models before touching anything.
The individual breakages are known and tedious rather than hard. Filters are gone. The event-bus pattern is gone, because $on, $off and $once were removed from the instance. The .sync modifier folded into v-model with a different signature, and v-model on a component changed its default prop and event names. None of these is difficult on its own. There are simply several hundred of them across a real codebase, and the compat build's warning output is the only inventory anybody gets.
The reactivity change is the one that produces genuine bugs. Vue 2 used Object.defineProperty, which is why Vue.set existed and why assigning to an array index never triggered an update. Vue 3 uses a Proxy, so those workarounds are unnecessary — and a developer still carrying the old rules will destructure a reactive() object, lose reactivity silently, and produce a component that renders once with correct data and then never updates again. Nothing throws. Nothing is logged. The value is simply stale, and the bug is usually reported as "the page doesn't refresh".
If the application runs on Nuxt, add a second migration on top of the first. Nuxt 2 to Nuxt 3 is the larger of the two jobs, and Nuxt 2 reached end of life in June 2024.
Mid-level (3–5 years). Builds components and views against an architecture somebody else set. Comfortable with Vue Router, Pinia or Vuex, and form handling. Usually fluent in one API style rather than both.
Senior (5–8 years). Sets the composable structure, decides what belongs in a store and what should have stayed in the component, and owns the build configuration. Has completed at least one version migration and can tell you what it actually cost rather than what it was scoped at.
Lead (8+ years). Owns frontend direction, makes the Nuxt-or-SPA call, sets performance budgets, and can move a team through an API-style change without ending up maintaining two codebases in one repository.
Vue 2 to Vue 3 migration. The dominant request since end of life, and the one place prior migration experience is worth paying a premium for. Having read about the compat build is not the same as having driven one to completion.
Feature work on an existing Vue 3 application. The largest category by seat count, and the most straightforward to staff.
Nuxt work. Server rendering, routing conventions and data fetching are Nuxt concerns rather than Vue ones. We screen for it separately and suggest you do too.
Vuex to Pinia. Usually bundled into a migration. Mechanically simple, and a good moment to delete the stores nobody has read in two years.
Vue alongside a React codebase. More common than you would expect, usually after an acquisition. If that is your situation, see hire React developers as well.
Week one. They establish which version you are actually on. That sounds trivial and is not: plenty of codebases sit on the compat build with a mix of both API styles, so the honest answer to "are we on Vue 3" is often "partly". Expect a written note on which components are migrated, which are not, and where the two styles meet.
Weeks two to four. On a migration, one defined slice finished properly — a single route or feature area moved off the compat layer with its deprecation warnings at zero. On feature work, a shipped feature plus an opinion about the composable structure, because that is where Vue 3 codebases quietly go wrong.
The warning sign is a developer who migrates by pattern-matching. Stripping Vue.set calls and deleting filters without asking what the code was for produces something that compiles and behaves subtly differently. Someone who comes back with "this filter was formatting currency in three places and two of them disagreed" is doing the job properly.
Hiring for "Vue" without naming the version. The most common error here, and it costs the first fortnight. Vue 2 with the Options API and Vue 3 with <script setup> are close relatives, not the same job. Put the version and the API style in the brief and you will halve the noise in your pipeline.
Treating a React developer as a drop-in. The concepts transfer; the reactivity model does not. React re-renders a component and you control that with memoisation. Vue tracks dependencies and updates what changed. Developers carrying React habits across write a watch where a computed belongs, then spend an afternoon debugging an update loop they created.
Budgeting the migration as a sprint. The framework upgrade is the small part. The long tail is the component library, the date picker nobody has maintained since 2021, and the chart wrapper that depended on the event bus. Inventory the dependencies before you commit to a date — that is where migrations actually stall, not in your own components.
Letting the compat build become permanent. It is a bridge with a real cost: extra bundle weight and a codebase that has to make sense in two versions at once. Set the date you come off it in the same meeting where you decide to go on it, or you will still be running it in two years.
Rates depend on seniority, migration experience, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.