Software & Applications · Service 08

One product, many customers, billed monthly.

Building software other businesses subscribe to is a different discipline from building software for one company. Every customer shares a codebase but must never see each other's data; every price change has to work for people who signed up under the old one. We build the version that can be launched, then grow it around what paying users actually do.

Multi-tenant from day oneBilling that survives edge cases Ship early, then iterateYou own the source
Talk about your product → Negotiate the scope
One codebase · many tenants

The hardest conversation

What actually ships in version one

Almost every failed product was too big at launch. Click a feature to move it between columns and watch what it does to the first release. The goal is not to build less — it is to learn sooner.

Ships at launch0 items
Deliberately later0 items
A launchable first releaseabout 6–8 weeks of build

Small enough to reach real users while the idea is still fresh, and large enough that they can actually do the thing your product is for.

Commercial model

How you charge changes what gets built

Pricing is not a marketing decision made at the end. Each model implies different engineering, and choosing late means rebuilding. Here is what each one costs you to support.

What founders underestimate

The half of the product nobody demos

The feature you are excited about is rarely the work. These are the parts that decide whether a SaaS survives its first hundred customers.

Isolation

Tenant separation

Every query, every file, every background job scoped to the right account. One leak between customers is the kind of incident a young product does not recover from.

Billing

The awkward cases

Mid-cycle upgrades, proration, failed cards, dunning emails, refunds, tax by province and country. This is weeks of work that no demo ever shows.

Onboarding

The first ten minutes

Most trial users decide inside one session. Empty states, sample data and a guided first task matter more than any feature added later.

Access

Roles, invites and SSO

Team accounts need owners, admins and read-only members. Larger customers will ask for single sign-on, and asking early is cheaper than retrofitting.

Support

Seeing what a user sees

Impersonation, audit logs and useful error reporting. Without them every support ticket becomes a guessing game across accounts.

Trust

Data export and deletion

Customers want to know they can leave, and privacy law increasingly requires it. Building export early also forces a cleaner data model.

Questions

SaaS product development, answered

How much does it cost to build a SaaS product?
More than a website, and the honest range is wide because "a SaaS" describes anything from a single-purpose tool to a platform. What we can do is scope a genuine first release, price that firmly, and be clear about what is deliberately excluded. Anyone quoting a whole product before understanding your billing model is guessing.
Should I build an MVP or the full product?
A first release, always — but "MVP" has been abused into meaning "unfinished". The version you launch should do one job properly for a real customer who pays. That is different from a demo with half-working features, and it is the difference between learning something and learning nothing.
Do I need funding before building?
Not necessarily. Plenty of profitable products were built by one business solving its own problem and then selling the solution. Funding buys speed, not certainty. If you already have customers asking for this, that is a stronger signal than a term sheet.
Who owns the code and the customer data?
You do — both. The repository is yours, hosted in your account where possible, and the infrastructure is set up in your name rather than ours. If you later hire an in-house team, they inherit a documented codebase rather than a dependency on us.
What happens after launch?
The work changes shape. Early on it is fixing what real usage exposes; later it is the features paying customers ask for, plus the operational side — monitoring, scaling, support tooling. Some clients keep us on a retainer, some hire internally and we hand over. Both are fine.
Can you take over an existing product?
Yes, and it starts with an audit rather than a plan. We look at the code, the data model, the billing setup and what is actually deployed, then tell you plainly what is worth keeping. Products built quickly under pressure usually have one or two structural problems worth fixing before adding anything new.