I have capacity right now, as of October 2026. I’m looking for two things, and I mean both: consulting and long-term contract work, and the right full-time role.

Over 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 infrastructure, the deploy pipeline, the pager, the backend running on top of all of it, and sometimes even the mobile app out front.

The infrastructure half is the part I’d put first now: architecture, reliability, deploys, cost, and whether anyone has to be awake. Lately I’d rather write the services in Swift, specifically—though the language has rarely been the constraint.

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-developer 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; in my experience 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 or holds their private data has to be designed in from the start—you can’t bolt it on once the money and data are 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.

The rest of my Faculty time went into something much less demoable: API + database code, developer tooling, deployment pipelines, and reusable cloud infrastructure, so that a small team could take on engagements well out of proportion to its headcount. I led backend and infrastructure there, and that’s the work I’d point at when there isn’t one flashy problem to show. It’s harder to put a number on, and it’s most of what I actually do.

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

On my own, or 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:

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

One thing worth saying plainly, since I’d wonder too: Sloates & Coan is a partnership Nick and I take client work through, not a company I’m running instead of having a job. A full-time role is something I can say yes to.

→ sean@seancoates.com for just me, or hello@sloatescoan.com for both of us

Full-time

I’m open to lead and senior individual-contributor roles—and especially to a leadership role that’s genuinely hands-on, which is the one I want most. I’ve done the management side: V.P. of Technology at Matter, head of technology at Studioworks, department lead, partner. What I’m not looking for is the version where I stop touching the systems. The hands-on-lead job is rare, in my experience—but it’s what I’m best at, so I’d rather name it than quietly apply for both.

Where I’m most useful:

And on the off chance you need all of that plus someone to own your embedded platform—I’ve been writing embedded Swift on ESP32 and RP2350 for the love of it, and I’d be glad to do it for money. I gather there are IoT companies that need exactly this combination.

Remote, please. I’ve worked this way for more than two decades. 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 consulting or contract work with me directly, full-time roles, or anything else.

hello@sloatescoan.com for client work with Sloates & Coan.

I read everything and I answer.