API design, versioning and documentation
Endpoints designed against how the front end and your partners actually use them. Contracts written down, versions retired on a plan, and breaking changes flagged before anyone builds against them.
Fractional Teammates · Development
A senior back-end developer for part of your week
Your APIs, data models, queues and integrations get an owner who joins your standups and works in your repositories. When a job needs a second discipline, the rest of the OlDevs studio in Vancouver is behind them.
A senior specialist, not a junior placement You own the work and the accounts Reply within one business day
infra · ci/cd
$oldevs deploy --env production
✓Build passed · 212 tests · 0 warnings
✓Migrations applied · postgres 16
✓API v2 healthy · 142ms p95
→Rolling out to 3 regions…
API
Postgres
Redis
K8s
What a back-end developer is
OlDevs defines a fractional back-end developer as a senior server-side engineer who works a defined slice of each week inside one organisation's team, rather than taking on a fixed-scope project.They own the parts users never see: APIs and their contracts, database schemas and migrations, background jobs, queues, third-party integrations, authentication, and the reliability of everything the interface depends on. They work in the client's repositories, ticket board and standups, review other developers' code, and answer for uptime and data integrity. The arrangement suits organisations whose back-end work is constant and consequential but not yet large enough to justify a full-time hire. The client owns all code, accounts and data.
Key facts
- 01Group
- Development
- 02Owns
- APIs, data models, jobs, queues, integrations
- 03Shape
- A set share of one senior week, ongoing
- 04Works in
- Your repositories, board and standups
- 05Typical commitment
- 1–2 days a week
- 06Judged on
- p95 latency · Error rate · Background job failures
Development
What this teammate takes off your plate
What this teammate takes off your plate
Data models, migrations and integrity
Schemas that match the business, not last year's guess. Migrations written to run on live data without downtime, with indexes, constraints and backfills reviewed before they reach production.
Background jobs, queues and scheduled work
The work that happens off the request: imports, exports, notifications, nightly reconciliations. Built to be idempotent, retried safely, and visible when a job fails instead of failing quietly.
Integrations with systems you do not control
Payment providers, CRMs, ERPs, government portals and partner feeds. Built with rate limits, outages and schema changes assumed, so a supplier's bad afternoon does not become your incident.
Authentication, permissions and data protection
Sessions, tokens, roles and the rules about who can read what. Sensitive fields handled deliberately, secrets kept out of the repository, and access reviewed when people join or leave.
Reliability, performance and the on-call story
Logging and alerts that name the failing thing, runbooks your own staff can follow, and slow queries found before customers report them. Load tested ahead of your busy season.
Benefits
What changes when the back end stops drifting
01
The API stops shaping the product
Screens stop being trimmed to what the current endpoints happen to return, and interface work stops waiting on a field that nobody has added. What gets planned widens, because someone can change the server side.
02
Releases stop being an event
Nobody books a meeting to decide whether Thursday is safe to deploy on. Migrations run in a known order, a bad change can be reversed, and one person is no longer the only one who could do it.
03
One set of numbers, not four
When the data model holds its own rules, finance and operations stop keeping private spreadsheets to correct what the system reports. Board packs, invoices and dashboards get argued about on their merits rather than on whether the figures are real.
04
Failed jobs surface before customers do
A payment webhook that silently stopped arriving, a nightly import that half-ran, a queue quietly backing up: these turn into an alert someone owns and a retry that works, rather than a customer telling your staff about it.
05
Today's shortcut stops becoming next year's rewrite
Schema shape, what becomes a queued job rather than an in-line request, how far identity is delegated: choices that are easy this month and costly in three years, made by someone who has watched them age.
06
The system stops being oral history
Migrations, runbooks, secrets rotation and the restore procedure are written as the work happens, in your repositories and your own cloud accounts. When the engagement or the person changes, nobody is reverse-engineering the server from behaviour.
How it works
How the engagement runs
A call about the work, not the CV
We ask what breaks, what is queued and who depends on it. If a fractional back-end developer is the wrong answer, we say so on that call.
A written proposal and quote
Scope of ownership, the share of the week, the rituals your teammate joins, and how work is reviewed. Every engagement is quoted; nothing here is priced off a list.
Access, then a first read of the system
Your teammate is added to your repositories, board and chat. The first days go on reading the code, the data and the incident history before changing anything.
A ranked list you approve
Risks, debts and the work you asked for, put in one order and prioritised with your team. You decide what the week's slice is spent on.
Weekly demo, written update, open board
Every week you see what shipped, what moved and what is blocked. Tickets stay in your tracker, so progress is legible without asking anyone for a status report.
Who it's for
Who a fractional back-end developer suits
A fractional back-end developer fits a real, continuing need that does not fill a full-time role. Here is where the arrangement works, and one place it does not.
Product teams that are front-end heavy
You have designers and interface developers shipping quickly, and one person quietly holding the server side together. The fractional teammate takes that load and raises the standard behind it.
Associations and public bodies with long-lived systems
Membership databases, permits, registries and reporting that run for years. You need someone senior who documents decisions and leaves records your staff can still read in five years.
Franchises and multi-location operators
Point of sale, bookings, payroll and a head-office dashboard that all need to agree. The work is integration and data, and it never quite ends, which is why fixed-scope projects keep disappointing.
Where fractional is the wrong choice
If you need a person in the room every day, or a rewrite delivered by a fixed date, this is not it. That is a full-time hire or a scoped project.
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
Often paired with
01
Full-Stack Developer
One person who takes a ticket from design through front-end, API, database and deployment without a handoff.
Explore02DevOps & Cloud Engineer
A senior DevOps and cloud engineer from our Vancouver studio joins your team for a defined part of each week.
Explore03Systems Integration Specialist
A senior integration specialist from our Vancouver studio joins your team part-time, in your repositories and your standups.
ExploreFAQ
Questions buyers ask before committing
They stay yours, because they were always yours. Code lives in your repositories, infrastructure and third-party services sit in your accounts under your billing, and secrets are held in your vault. Before the last week we write a handover: architecture notes, runbooks, open risks and the state of anything half-built. There is no licence to buy back and nothing to unpick.
A hire gives you full-time attention, and you carry the recruiting, the onboarding and the risk of a mismatch. An agency usually sells a project with a scope and an end date. A fractional teammate is a defined share of one senior person's week, ongoing, inside your own tools and rituals. Hiring is the better answer when the work genuinely fills a week. An agency is better when the job is a discrete build. This sits between the two.
The studio answers. Your teammate is one person from OlDevs, not a lone contractor, so a second developer is briefed on your system and can pick up urgent work during holidays or illness. If the person changes permanently, we overlap the handover rather than restarting. Documentation and tickets live in your accounts, which is what makes cover possible in the first place.
Tell us your stack on the first call and we will answer plainly. OlDevs has built and maintained server-side systems since 2014, across mainstream web languages, relational and document databases, message queues and the major cloud platforms. Where something sits outside what our team is genuinely senior in, we say so and suggest another route rather than learning it on your project.
You get a defined slice, agreed in the quote and held to. It is usually expressed as days or half-days per week on a repeating schedule, so your team knows when the teammate is present and when they are not. The slice is reviewed on a set cadence and can grow, shrink or pause with notice. Sudden production incidents are handled by the studio, not squeezed into a rigid rota.
Work with them. A fractional back-end developer joins your standups, reviews your team's pull requests and follows your conventions, including the ones we would have chosen differently, until the team agrees to change them. Many engagements exist to give an in-house team a senior second opinion on data models and reliability. If replacing someone is what you are considering, tell us early, because the onboarding and handover look different.
Let’s connect
Let’s talk about the back-end developer gap.
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.