SaaS Product Development
Multi-tenancy, subscriptions, onboarding and the architecture decisions that are painful to reverse later.
More on SaaS Product DevelopmentTwo 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.
Multi-tenancy, subscriptions, onboarding and the architecture decisions that are painful to reverse later.
More on SaaS Product DevelopmentREST, JSON:API, GraphQL and webhooks — plus the retry, idempotency and reconciliation nobody budgets for.
More on APIs & IntegrationsI 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.
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.
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.
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.
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.
Describe the problem in your own words — I will tell you what I would actually build, and what I would not.
Start a conversation