I have capacity right now, as of August 2026. I’m looking for two things: consulting clients, and the right full-time role.

Twenty-five years in, what I do is consistent. I build and run production systems, and I’m usually the person who owns the whole stack: the backend, the infrastructure it runs on, the deploy pipeline, the pager, and even the mobile app in front of it.

What that looks like

Two examples, picked because they’re eight years and two entirely different stacks apart.

The first is Bifrost, the integration layer between Samsung’s ecommerce platforms and their third-party logistics providers worldwide. Samsung wanted to roll out into many countries quickly, and logistics was the obstacle: nearly every market had a different 3PL provider with a different integration, and twenty markets meant twenty bespoke integrations—which really made the rollout schedule a function of how many engineers we could throw at it.

So we inverted it. We designed one generic API covering order handoff, pricing, inventory, and shipping, then did the genuinely unglamorous part: documented and supported it well enough that a logistics provider in a new market could integrate themselves. Where a partner couldn’t or wouldn’t, we wrote the adapter.

We deployed the first version in six months. Most new-country onboardings took a month or less. It ran in more than twenty countries, carrying every Samsung consumer ecommerce transaction in those markets, with 100% uptime, on a team that never exceeded ten people, for under $1,500 a month in hosting—that’s all countries combined, not per country (we did spend some real money on logging and reporting, but none of that was in the customer-to-order flow).

The second, eight years later, is Studioworks, a business platform for creative studios. I was head of technology and half of a two-engineer team at a four-person company. We built the backend in Swift (Hummingbird) on AWS and DynamoDB, and I owned all of the infrastructure.

It ran at 100% production uptime from launch onward. Nodes that died came back on their own; traffic spikes scaled without anyone waking up. Internal requests all stayed under 100ms—usually under 20ms. The whole thing cost under $200 a month to operate, and served up to a thousand studios. The payment/invoice state machine I designed never produced a financial or accounting error.

I mention the cost numbers because they’re the part people don’t expect. Reliability at that price isn’t frugality; it’s what happens when the architecture is right and the system runs itself. And the correctness numbers matter more to me than either. You can buy uptime and low latency with money and attention. Correctness in a system that moves other people’s money has to be designed in from the start—you can’t bolt it on once the money’s already moving.

Two other bits I’m particularly proud of:

At Matter I built a privacy architecture around simply not having the data. It started with a question I asked our CEO, early on: “why would I ever send you a private photo and a positive rating for a sexual desire emotion? I would never send that to Facebook, so why would I send it to us?” So we designed the system to never receive it. Users’ emotional content stayed on their own devices, and anything backed up was encrypted client-side, so what we held was noise we had no key for. Not a policy, not a promise in a footer: the architecture made the private thing unavailable to us. I’ve written up how it worked.

At Faculty I designed the token format behind Simply Framed’s custom framing platform. Custom framing has roughly 10.5 sextillion valid permutations, and the entire product depended on encoding a customer’s choices compactly enough to sit in a URL while also driving the API, the live preview, sharing, and fulfillment. Get that encoding wrong and nothing else on the page is buildable.

I also contribute upstream to the tools I run in production. I’m a contributor to Hummingbird, the Swift server framework behind Studioworks, and build hummingbird-macrorouting. I was a developer on Zappa, the serverless deployment tool Bifrost ran on. I’m a long-term contributor to PHP. There’s a pattern there, and it isn’t an accident: I’d rather fix the tool than work around it.

Consulting

Through Sloates & Coan, with Nick Sloan, who I’ve built software alongside at four companies since 2008, most recently as Studioworks’s entire engineering team. On a platform that reinvents itself every couple of years, getting to keep working with someone that long is a rare privilege.

We take on:

  • Backend systems, APIs, and cloud infrastructure: architecture, build, migration, or cleanup
  • Native iOS and macOS apps: Swift and SwiftUI
  • Full-stack web applications
  • Infrastructure and reliability work: getting a system to run itself, cost reduction, monitoring, deploys that don’t require ceremony
  • Integration work: the unglamorous layer between your system and everyone else’s, done so it doesn’t wake you up
  • Performance investigation: the “why is this slow and nobody knows” engagement
  • Architecture review: a second set of experienced eyes before you commit
  • Training: I’ve taught, written, and spoken about this work for two decades

We keep the roster small on purpose. You collaborate directly with the people doing the work.

hello@sloatescoan.com

Full-time

I’m open to senior individual-contributor and founding-engineer roles. I’ve done the management thing (V.P. of Technology, department lead, partner) and I’m good at it, but I’d rather be building right now. I’d love a leadership role that’s genuinely hands-on; in my experience they’re rare.

Where I’m most useful:

  • Small teams where one person needs to cover backend, infrastructure, and mobile
  • Zero-to-one product work, where the early architectural calls matter
  • Systems where correctness, privacy, or reliability are load-bearing rather than aspirational
  • Teams adopting Swift on the server, which I’ve now run in production and contribute to upstream

Remote, please. I’ve worked this way for more than two decades and I’m good at it. I’m in Montréal and open to hybrid here, but remote is the strong preference.

A couple of honest filters, to save us both time: I’m not interested in crypto or adtech, and I’m not looking to join a company whose product is AI. I’m happy working on products that use AI as a component, but I’d rather not tie my next few years entirely to that particular bubble.

Elsewhere

Get in touch

sean@seancoates.com for full-time roles, or anything else.

hello@sloatescoan.com for client work.

I read everything and I answer.