Skip to content

Vue.js development

Vue is what we reach for when an interface has to get materially better without the application around it being replaced, and when a small team is better off with fewer decisions to invent.

01Capabilities

Where a Vue front end earns its place

Vue's real advantage is not that it is lighter. It is that you can adopt it one screen at a time, and that the router and the store are decided for you instead of being an argument every project.

  • Product

    Interfaces built around long, structured content

    Capture, structuring and editing of long, hierarchical documents, the shape of the SaaS research tool we built for knowledge workers. Where the underlying data is regulated the front end inherits obligations from the domain rather than from the framework, and healthcare is the clearest example of that.

  • Full stack

    A Vue client on a .NET or Node back end

    The full-stack shape we see most: Vue on the client, .NET or Node.js behind it, and an API contract that decides how good the interface can be. We design that contract rather than working around it, as part of web development.

  • Incremental

    Interaction added one screen at a time

    A server-rendered application gets a handful of screens that need to behave like a product. Vue mounts into a page without demanding the whole application become a single-page app first, which is the cheapest honest route to a better interface and the reason this page exists.

  • Portal

    Member portals with payments and reporting

    Registration, renewal, event entry, payment and the financial reporting behind them. The engineering is reconciliation and what the interface shows when a payment provider is slow or a renewal half-succeeds. The forms are the easy part. That is usually a custom software build with a Vue client on the front, not a front-end project.

03Fit

Choosing Vue, and when another route fits better

Vue competes with React, with Angular, and fairly often with not adopting a front-end framework at all. We recommend whichever fits, and each row below names the route we would take. The answer turns on your team and your existing application far more than on any property of the framework.

Six situations, and what we would tell you in each
Your situationWhat we recommend
An existing server-rendered application, and you want richer interaction without replacing it Use VueIts incremental adoption story is genuinely the best of the three, and this is the case where that is worth real money.
A small or mid-sized product team, one front-end codebase, limited appetite for tooling debates Use VueAn official router and an official store mean less local invention, and less to explain to the next person who joins.
A Vue 2 codebase, unsupported since 31 December 2023 Move to Vue 3Plan it as a migration rather than a rewrite. The Composition API and the build move are the substantive parts, and most components survive.
Hiring front-end engineers at scale, across several markets, for several teams Different pageWeigh React for the deeper pool or Angular for stronger conventions across teams. Vue can lose on availability rather than on merit.
Mostly content, where search visibility and first paint decide the outcome Pages firstServer-rendered or static, with interactive islands only where a screen has earned one.
A commerce storefront on a platform you are not replacing Start from the platformThe platform constrains the front end more than the framework does. Start from e-commerce development and let the platform decide the client.

Scope

On a Vue engagement we own that call and what follows from it: where the data lives, and whether the server-rendered and browser-rendered parts of a page can agree without two copies of the truth. The last thing we own is whether your team can keep changing the result after we hand it over. unicrew has been building web interfaces since 2012, with 100+ senior in-house engineers across six countries, and we hold ISO 27001:2022 and ISO 9001:2015, renewed through a multi-stage audit with Quay Audit UK. The work we propose is sized to what the interface actually needs.

Vue is the easiest of the big three front-end frameworks to hand to a mixed-skill team. On a new application, we choose the Options API or the Composition API and keep to it. Every new developer then has one mental model to learn.

Andrii BurdaSenior Engineering Manager, unicrew

04Delivery

How a Vue engagement gets moving

Four things we settle before changing anything, because each one changes what the rest of the work costs.

  1. Establish which Vue you are actually onVue 2 or Vue 3, Options API or Composition API, Webpack or Vite, and whether those answers are consistent across the codebase. Mixed-era Vue is common and it is fine, but it needs to be a decision rather than an accident.You getA one-page read of what you are running, and which of those answers is costing you the most.
  2. Find the state boundaryWhere server data is cached, what the store is genuinely responsible for, and what is component state that should have been either. Leftover event buses from the Vue 2 era are a reliable sign of where the boundary was never drawn.You getThe boundary drawn explicitly, with the places two copies of the same truth exist today.
  3. Make the types realTypeScript coverage inside single-file components is often thinner than the repository suggests, and props and emits are exactly where silent breakage hides. Tightening those first makes every later change cheaper to verify.You getTyped props and emits on the components everything else depends on, and a list of what is still loose.
  4. Ship feature by feature, behind the existing shellNew work goes in next to the old, sharing routing and session, so each feature is live before the next one starts. This is what lets a Vue 2 to Vue 3 move happen without a feature freeze anyone has to defend internally.You getEach feature live as it lands, with its automated coverage handed over alongside it.

07Questions

What teams ask when they are weighing Vue

Answered the way we would answer them on the call. If yours is not here, it is a good first message.

Our engineers can work inside your team, and that is a normal way to start. They own the technical result from the first fortnight, because on front-end work that is when the decisions that matter get made. The design is reviewed by an architect outside the delivery team, and QA and test automation runs with ISTQB-certified engineers in every sprint. Team extension is managed teams.

Vue when you are adding to an existing application, when one team owns the front end, and when you would rather inherit a router and a store than choose them. React when the product is large with heavy client state, or when you need the deepest hiring pool. Both build serious production software. Anyone who answers this without asking about your team and your existing codebase is guessing.

Vue 2 has been unsupported since 31 December 2023, so this is a security position as well as a technical one. The work splits three ways: the build move, usually Webpack to Vite, which is mostly mechanical; the reactivity and lifecycle changes, which are the real work; and your dependencies, where an abandoned component library normally sets the timeline. Most components survive. We read your dependency list first and estimate from that.

Yes, and it is one of the better reasons to pick Vue. It mounts into an existing page, so a screen can become a real interactive component while everything around it keeps being server-rendered. Two things we insist on: the boundary between server-rendered and client-rendered state is drawn deliberately, and the build output is bundled properly rather than pulled from a script tag. The informal version stops being maintainable at about the third screen.

A scoping call with an engineer, not a sales conversation. For an existing application we want repository access first and, on a Vue 2 estate, the dependency list, because that is what decides whether a migration is a month of work or a quarter. You get back a written read on the state boundary, the migration route and which parts need no change. Most engagements start within two to four weeks.

Three shapes, and the right one depends on how settled the scope is. Time and materials is billed hourly and quoted per project, for scope that is still moving. Fixed price is outcome based and quoted per project, offered once the first read is done rather than before it. Team extension is billed monthly per engineer, for people inside your own planning. The rate follows the seniority mix the work needs, so it is quoted rather than listed.

Adding Vue, or moving off Vue 2?

Tell us what the application does today and what has to change. You will get a straight read on whether Vue is the right client for it, and how much of the application it should reach.

Book a scoping call

Thank you

Thanks for your message. We will get in touch with you shortly.