Quillette
Switchback is Quillette's ops and DevOps function. Not a vendor they call when something breaks — the team that owns the infrastructure and keeps an established, at-scale publication running so the editorial side never has to think about it.
It started as a typography-led rebuild of their Ghost theme. It has grown into an ongoing retainer where we operate the whole stack the publication runs on.
The engagement
Most publications at Quillette's stage end up in one of two bad spots: over-hiring a full-time DevOps person they don't need forty hours a week of, or under-resourcing it and leaving a founder to duct-tape the server at 2am.
We're the third option. An engineer who owns the entire infrastructure surface for a fraction of a full-time hire, shows up when it matters, and quietly keeps the lights on the rest of the time. Quillette doesn't think about their server. That's the product.
The scale
This isn't a side project. It's a real publication with paying members and real revenue, running on infrastructure where every decision has consequences.
- ~85k paying members behind a membership paywall — real traffic, real money on the line
- Self-hosted rather than on a managed platform — we operate the actual servers, not a hosting company doing it for us
- A database big enough that a careless change has real consequences, on hardware kept deliberately lean — so the site stays fast because the engineering is right, not because someone threw money at a bigger machine
What owning the infrastructure looks like
The less dramatic part of the job is the real story: running the stack day to day so nothing ever reaches the point of being a crisis.
- We own the whole server. Hands on the box, top to bottom — there's no piece of the stack that's someone else's problem.
- We keep the platform updated without taking the site down. Upgrades on a live publication are risky; we turned that into a repeatable, low-drama process instead of a thing everyone holds their breath through.
- We manage how the site is served and cached worldwide, including the paywall — the layer that decides whether a page loads instantly or hammers the server.
- We built the monitoring to see problems coming, so issues surface as warnings instead of outages — especially around big newsletter sends, the riskiest moment for a publication this size.
- We tune the system to stay fast under load and find the slow spots before they turn into downtime.
- We track what's lurking. A running list of technical debt, prioritized against actual risk rather than vibes — so the boring problems get handled before they become loud ones.
When production goes sideways
The other half of the job is the "oh shit" moments. When prod goes sideways on a publication with 85k members — the site goes down, a deploy breaks something, delivery degrades mid-send — we're the ones who diagnose it methodically and fix it. Then we write it up so the same failure can't happen twice. Every incident becomes a runbook, and the system gets a little harder to knock over each time.
Why this is fractional engineering
The reason this works isn't a contract or a ticket queue — it's that one team owns the whole surface end to end. We know how the system is put together, where it's fragile, and what to watch before a busy moment turns into an outage. That context compounds: every month we hold it, the site gets a little more solid and a little less likely to surprise anyone.
That's the difference between fractional engineering and just buying hours. You're not handing off tasks — you're handing off an entire problem, to someone who treats it like theirs.
Working with us
Fractional engineering is one of the two ways we work: we plug in as design and engineering capacity that owns real surface area and doesn't need hand-holding.
If you've got a product that needs someone to own the parts you shouldn't have to think about: get in touch.