Engineering
Small teams, large
applications, less ceremony
Vue earns its place where four engineers maintain what twelve would normally build. We write Composition API with TypeScript, keep shared state in Pinia, and reach for Nuxt only when server rendering or file-based routing genuinely pays for itself.
Overview
Vue and Nuxt for teams that need to move quickly without inheriting a mess.
Single-file components put template, logic and styles in one file, which is either a separation-of-concerns violation or the most practical arrangement in front-end development, depending on who you ask. What we observe consistently is that a new engineer becomes useful in an unfamiliar Vue codebase faster than in the equivalent React one.
We write script setup with TypeScript throughout and keep the data boundary sharp. Pinia holds cross-view state. Anything derived from a server goes through TanStack Query or Nuxt's own data layer with explicit cache keys. Existing Options API code is fine to leave alone; we convert a file when it is being changed anyway, never as a standalone project.
Nuxt is a decision, not a default. It pays for itself on content-heavy or public products that need server rendering and route conventions, and it adds a layer you do not need for an internal dashboard behind single sign-on. We tell you which one we are recommending, and what it costs, in the first week.
- 5 weeks
- From empty repository to first live order on the Brightmoor Foods portal
- 1.4 MB to 380 kB
- Initial JavaScript payload after leaving Vue 2 and Webpack behind
- 31 screens
- Converted from Options API to script setup across two quarters, no freeze
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Composition API architecture
Logic extracted into composables with clear inputs and return shapes, typed end to end, so behaviour is reused across views without the implicit coupling that mixins used to introduce.
Nuxt rendering and routing
Hybrid rendering rules per route, server routes for backend-for-frontend work, and Nitro deployment to Node, containers or edge runtimes depending on where your data actually lives.
State design with Pinia
Stores scoped to a domain rather than a page, with actions that own their side effects and persisted slices chosen deliberately, because a store that mirrors every API response becomes a second database.
Vue 2 to Vue 3 migration
Migration build first to keep the application running, then component conversion in dependency order, with Vue Router and Vuex to Pinia moves staged so the product stays shippable throughout.
Component libraries and theming
PrimeVue or headless primitives wrapped in your own API surface, tokens driven from Tailwind configuration, and Storybook stories doubling as the accessibility test bed for each component.
Testing and delivery pipeline
Vitest with Vue Test Utils for component behaviour, Playwright for the journeys that carry revenue, and preview deployments per pull request so product people review the change, not a screenshot.
Deliverables
What you get
- Vue 3 application on script setup with TypeScript and no implicit any remaining
- Pinia store design document explaining what is stored, what is cached and why
- Component library with Storybook stories and accessibility checks per component
- Vitest and Playwright suites running on every pull request with preview deployments
- Nuxt or SPA recommendation written up with the trade-offs and running costs stated
- Migration log if converting from Vue 2, listing each component and its conversion status
Stack
What we build it with
- Vue 3
- Nuxt 4
- TypeScript
- Pinia
- Vite
- VueUse
- Vue Router
- Tailwind CSS
- PrimeVue
- Vitest
- Playwright
- Storybook
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Decide Nuxt or plain Vue
One week of assessment on rendering needs, search visibility, hosting constraints and team familiarity, ending in a written recommendation with the costs of each option.
Set conventions early
Folder structure, composable boundaries, store scope and naming agreed and encoded into ESLint rules, so consistency does not depend on who reviews the pull request.
Build feature by feature
Each feature ships with its composables, tests and stories together. A preview deployment goes to stakeholders before the work is considered ready to merge.
Measure and trim
Bundle analysis per route, unused component detection and image strategy applied once real content is loaded, rather than optimising against placeholder data.
Transfer ownership
Documentation written inside the repository, two workshops on the conventions, and a month of reviewing your team's pull requests before we step away.
When this is the wrong engagement
If your organisation has standardised on React and hires against it, picking Vue for one product creates a staffing island, and the framework is not the risk there, the recruitment pool is.
FAQ
Questions we get asked
- Is Vue a risk compared with React?
Technically, no. Vue 3 is stable, well documented and used at serious scale. The real question is hiring: if your recruiters have a pipeline of React engineers and none for Vue, that constraint should outweigh any framework preference we might have.
- Do we need Nuxt?
Only if you need server rendering for search visibility or first-load performance on public pages, or you want its routing and data conventions enforced. For an internal application behind authentication, Nuxt adds a server layer to operate for benefits you will not collect.
- How do you handle a Vue 2 application still in production?
The migration build first, so the application keeps running while both syntaxes coexist. Then conversion in dependency order, starting at leaf components. Vuex to Pinia happens store by store. At no point is there a branch that cannot be deployed to production.
- Can you work alongside our existing Vue developers?
Yes, and it is the arrangement we prefer. We normally take the architectural groundwork and the harder migration paths while your team continues feature delivery, then move to reviewing rather than writing once conventions are established and documented.
Related
More in Engineering
Engineering
Blockchain Solutions
Permissioned ledgers, tokenised assets and independently audited smart contracts.
Engineering
IoT Development
Firmware, connectivity and telemetry pipelines for devices you cannot easily reach.
Engineering
Legacy Modernisation
COBOL, Delphi, WebForms and Oracle Forms moved off, without a big-bang cutover.