Products and the plumbing between them

Two kinds of work sit here. Building a SaaS product, where a handful of early architecture decisions determine how painful the next three years are. And connecting systems that were never designed to talk to each other, where the difficulty is almost never the API call and almost always what happens when it fails.

How I approach product work

I work as a senior technical partner rather than a pair of hands: involved in the decisions about what to build and what to defer, not only the implementation. For a small team that usually means arguing for less — a narrower first release, fewer configurable options, decisions postponed until there is evidence to make them with.

The decisions that are expensive to reverse

A short list, and it is worth being deliberate about all of them at the start: how tenants are isolated, whether identifiers are sequential or opaque, how money and time are represented, whether the schema assumes a single currency or region, and what your audit trail captures.

None of these are hard on day one. All of them are migrations later, and several of them are migrations you cannot do without downtime.

Billing deserves more care than it gets

Subscription logic looks simple until you meet mid-cycle plan changes, proration, failed payments and dunning, refunds, tax by jurisdiction, and the invoice a customer disputes eight months later. Getting the data model right matters more than which payment provider you pick — the provider is replaceable, your billing history is not.

Integrations fail, and that is the design problem

Any integration that runs long enough will encounter a timeout after the remote side already committed, a webhook delivered twice, a webhook never delivered at all, and a partner who changed a field without telling anyone.

Idempotency keys, a durable queue rather than a synchronous call, retries with backoff, a dead-letter path someone actually monitors, and a reconciliation job that catches the drift anyway. This is the unglamorous part that determines whether the integration is trustworthy.

Where the CMS and AI work overlaps

A good deal of product work touches the other practices: a headless CMS behind a product marketing site or in-app content, or an LLM feature inside the application. Having one person across the CMS, the product and the infrastructure removes a category of integration problems that otherwise surface as three vendors disagreeing.

Have a project in mind?

Describe the problem in your own words — I will tell you what I would actually build, and what I would not.

Start a conversation