The shared component library
They build and maintain the components your product is assembled from, with variants documented, states covered and changes versioned, so new screens stop being rebuilt from scratch every time.
Fractional Teammates · Development
Your interface layer gets an owner: components, responsive layout, state, performance budgets and WCAG 2.2 AA. They work in your repository, your board and your standup, with the rest of the studio behind them.
A senior specialist, not a junior placement You own the work and the accounts Reply within one business day
OlDevs embeds a fractional front-end developer — a senior specialist from our Vancouver studio — in your team for a defined share of each week, on an ongoing basis.They own the interface layer: the shared component library and design tokens, responsive layout across breakpoints, client-side state and data fetching, performance budgets, and accessibility to WCAG 2.2 AA. They work in your repository, your ticket board and your standup, review other developers' pull requests, and leave documented components behind them. It suits organisations whose front-end work is steady but does not yet justify a full-time role, and who need seniority rather than more hands.
Key facts
Development
What this teammate takes off your plate
They build and maintain the components your product is assembled from, with variants documented, states covered and changes versioned, so new screens stop being rebuilt from scratch every time.
Design tokens · Storybook · Variants · Figma handover · Versioning
Layouts that behave from a narrow phone to a wide desktop, checked on real devices, with typography, spacing and container queries that scale by intent rather than by accident.
Fluid type · CSS grid · Container queries · Breakpoints · Device testing
They decide how state is held, cached and invalidated, wire the interface to your APIs, and cover loading, empty and error paths so the product behaves predictably under real data.
Data fetching · Caching · Forms · Error states · Optimistic updates
They agree budgets for Core Web Vitals and bundle size, wire them into the pipeline so a regression fails the build, then spend the hours fixing what the numbers point at.
Core Web Vitals · Bundle budgets · Code splitting · Images · Lighthouse CI
Semantic markup, keyboard paths, focus management, colour contrast and screen-reader labelling, tested by tooling and by hand, with findings written up as tickets your team can prioritise.
Semantic HTML · ARIA · Keyboard · Focus order · Contrast · Screen readers
They review pull requests, set the linting, testing and naming conventions, and pair with your developers, so the standard they hold stays with your team instead of leaving with them.
Code review · Linting · Component tests · Pairing · Documentation
Benefits
Browser quirks, focus states and responsive breakpoints stop landing on people who took a back-end job and do interface work reluctantly. They go back to the data, the APIs and the queries they were hired for.
The gap between the design file and the live page closes, so review time is no longer spent re-specifying spacing, hover and empty states. Designers raise intent and edge cases instead of filing the same visual corrections every round.
Someone watches what each release adds — another font, a tag manager script, a component that re-renders on every keystroke — and checks it on a mid-range phone, so page weight stays a decision rather than a surprise.
Procurement questionnaires, customer complaints and internal audits stop setting off a fire drill, because keyboard paths, focus order and contrast have been held to all along. You can say where you stand and show the evidence.
Rendering strategy, whether the component set gets rebuilt or patched again, when a framework move earns its disruption: a handful of calls that shape years of work, and too few to keep that level of experience busy full-time.
Naming conventions, the component library, design tokens and the build configuration live in your repository, with the reasons recorded beside them. Your first permanent front-end hire inherits a system, not a folder of files nobody can explain.
How it works
A fixed slice of the week
We agree the days and hours before the engagement starts, and they stay the same week to week, so your planning and your sprints can rely on them.
Your tools, your rituals
They work in your repository, ticket board, design files and chat, and join standup and planning. Nothing is built in a private workspace and revealed later.
The first weeks are spent reading
Before shipping features they read the codebase, design files and analytics, then give you a written note on what is fragile, what is slow and what to fix first.
Weekly demo, written summary
Every week ends with a working demo and a short note: what shipped, what is next, and what is blocked and needs a decision from someone on your side.
Cover comes from the studio
If your teammate is away, the studio still answers. A second front-end developer keeps enough context on your codebase to unblock a review or a release.
Who it's for
The need is real and continuous, but it does not yet fill a permanent role — or the role exists and needs someone senior working beside it.
Back-end engineers are covering the interface between their own work. It ships, but components drift apart, the bundle grows and accessibility belongs to nobody in particular.
Member and citizen services that must meet WCAG 2.2 AA, often in English and French, where the front-end workload is constant but never quite fills a week.
One interface serving many locations, where a shared component library keeps every site consistent and a single change is made once instead of repeated by hand.
The first version was built fast and now has real users. You need a senior pair of hands to make the interface maintainable before the next wave of features.
12+
Years of studio experience since 2014
1–2
Typical commitment — 1–2 days a week
EN/FR
Languages this engagement can be delivered in
Other fractional roles
Research, task flows, wireframes, a component library in your brand, and specifications your developers can build from.
Explore02Your APIs, data models, queues and integrations get an owner who joins your standups and works in your repositories.
Explore03A senior QA specialist from the OlDevs team, embedded part-time in your organisation.
ExploreFAQ
They stay yours, because they were never ours. Work lives in your repository, your design files and your hosting and analytics accounts from day one; we hold access, not ownership. When an engagement ends we remove our access, write a handover note covering the component library, the build pipeline and any outstanding front-end debt, and stay reachable while your team picks it up.
Hiring gives you a full week and a long memory of your product. Fractional gives you a senior person for part of the week, starting sooner and without running a recruitment process. We will not claim it is always cheaper, because that depends on the role you would otherwise fill. It fits best when the work is real but does not fill a week, or when you need seniority now and a permanent hire later.
An agency project is fixed in scope and ends with a delivery. A contractor is usually one person with nobody behind them. A fractional teammate is ongoing and embedded: they carry tickets on your board, sit in your standup, and can pull a designer, back-end developer or DevOps engineer from the studio for the hours a job needs, without a new statement of work.
When front-end work genuinely fills a week, every week, hire instead. When you need one fixed deliverable by a fixed date and no ongoing involvement, a scoped project is the better shape. And when nobody internally can review work or make decisions, part-time embedding stalls, because the teammate needs a counterpart. We say so at the quoting stage rather than take the engagement.
React and Next.js, Vue and Nuxt, Svelte, and TypeScript throughout, plus the CSS layer, whether that is Tailwind, CSS modules or modern plain CSS. They join existing codebases as often as new ones, including WordPress and Shopify front ends. We match the teammate to your stack rather than asking you to change it, and say plainly when a stack sits outside what we support.
In your own tools, not in a status report we write about ourselves. Tickets move on your board, pull requests arrive for your team to review, and each week brings a working demo and a short written summary. Performance and accessibility are reported as numbers against the budgets we agreed, so progress is measured rather than asserted.
Let’s connect
Tell us what is not getting done and roughly how much of a week it needs. We’ll reply within one business day with who would cover it and a tailored quote — no obligation.
Thanks — we’ll reply within one business day.