We build first releases that can take money and be operated. That is not the same as the cheapest possible demonstration, and it is deliberately not a prototype with a payment form attached. The parts we insist on early are the ones that cannot be added later without a rewrite.

How is billing handled?

Through an established payment provider, never by holding card data. The work is in the state machine around it: what an account can do while a payment is failing, what happens at the end of a trial, and what a downgrade does to data that no longer fits the plan.

Can you work with an existing product?

Yes. Common engagements are introducing an entitlements boundary to a codebase where plan checks have spread, adding the internal support surface that was never built, or correcting a tenancy model before it becomes unaffordable to change.

Service

SaaS Product Development

The interesting part of a SaaS product is not the feature it launches with. It is billing, tenancy, entitlements and support, because those are the parts that decide whether it can take money reliably, isolate one customer's data from another's, and survive its first hundred accounts. They are also nearly impossible to retrofit.

Tenancy is a decision you make once

How tenants are isolated is the most expensive decision in a SaaS product to reverse. Shared schema with a tenant column, schema per tenant, and database per tenant each carry a different cost profile, a different blast radius when something goes wrong, and different answers to the compliance questions an enterprise buyer will eventually ask.

We settle it deliberately at the start, against the customers the product is actually for. The failure mode is not choosing wrong; it is not choosing at all and discovering the answer implicitly, distributed across two hundred queries that assume a single tenant.

Billing and entitlements are product, not plumbing

Entitlements decide what an account can do. Once plan checks are scattered through the codebase as conditionals, changing a plan means an engineering task and a release, which is why so many products cannot run an experiment on their own pricing.

So entitlements go behind one boundary that the rest of the product asks, and the awkward cases get designed rather than discovered: mid-cycle upgrades, failed payments, cancellation and what a downgrade does to data that exceeds the new limit. Every one of those is a support conversation and a refund if it is left to be worked out later.

Building for the people who run it

Every SaaS product needs an internal surface before it needs its second feature: impersonation for support with an audit record, the ability to see an account's real state, and a way to correct data when something has gone wrong.

Without it, support runs through the engineering team, and every customer problem becomes a database query written by hand against production by somebody who is in a hurry. That is both the slowest possible support and a standing risk to the data.

Onboarding decides retention

Most churn is decided in the first session, before any feature quality has been experienced. An account that reaches its first real result quickly stays; one that lands in an empty dashboard with no obvious next action mostly does not.

That makes the empty state, the sample data and the first task part of the product rather than polish to be added later. It is also the cheapest thing to instrument, because the drop-off point is usually obvious once anybody looks.

What an engagement includes

Tenancy and isolation model chosen against the intended customer
Authentication, accounts, roles and invitations
Subscription billing with upgrades, downgrades, failed payments and cancellation handled explicitly
Entitlements behind a single boundary, so plans change without a release
Internal support surface with audited impersonation and account state
Onboarding designed to a first real result, and instrumented
Per-tenant observability, limits and abuse controls
Data export and deletion paths, built before they are demanded

Common questions

Do you build MVPs?: We build first releases that can take money and be operated. That is not the same as the cheapest possible demonstration, and it is deliberately not a prototype with a payment form attached. The parts we insist on early are the ones that cannot be added later without a rewrite.
How is billing handled?: Through an established payment provider, never by holding card data. The work is in the state machine around it: what an account can do while a payment is failing, what happens at the end of a trial, and what a downgrade does to data that no longer fits the plan.
Can you work with an existing product?: Yes. Common engagements are introducing an entitlements boundary to a codebase where plan checks have spread, adding the internal support surface that was never built, or correcting a tenancy model before it becomes unaffordable to change.

Related practices

Let's Build Something Extraordinary.

Whether you're looking to collaborate, partner with us or simply follow our journey, we'd love to hear from you.

info@starblyn.com