SaaS Development

A focused v1 with authentication, billing, and one core workflow takes 10 to 14 weeks. Products with compliance requirements, complex integrations, or multiple user personas typically run 16 to 24 weeks. We commit to the schedule at the end of a two-week technical discovery, not before.

We default to a shared-database, row-level multi-tenant model with tenant IDs enforced at the query layer, because it keeps per-customer cost low. When a client sells into regulated enterprise buyers, we design schema-per-tenant or database-per-tenant isolation instead, and we make that decision during discovery rather than after launch.

You do, from the first commit. Work happens in your GitHub organisation under a work-for-hire agreement, with no licensing, no proprietary framework, and no vendor lock-in. If you end the engagement mid-build, you keep everything shipped to that point.

Yes. We start with a two-week technical audit covering architecture, test coverage, dependency health, security posture, and delivery bottlenecks. You receive a written findings report with a prioritised remediation plan, and you are free to execute it with your own team.

Engagements are billed as fixed-scope phases rather than open-ended hourly work, so the number is agreed before the build starts and does not move unless you change scope in writing. Ongoing product engineering after launch is a monthly retainer sized to the team you need, typically two to four engineers. We quote after technical discovery.

A first billable version typically takes three to five months from discovery, depending on how much of the tenancy, billing and permissions model is genuinely custom. Products that need enterprise single sign-on, provisioning or audit logs from day one sit at the longer end, because those are structural rather than additive.

Shared schema with database-enforced isolation suits most products: cheapest to operate, simplest to migrate, and safe when row-level security makes an unscoped query impossible. Schema per tenant helps at dozens of customers with per-customer restore needs. Database per tenant fits enterprise contracts where full isolation is a procurement requirement.

By making isolation structural rather than remembered. Row-level security in the database, or a data access layer where an unscoped query cannot be written, means a forgotten filter returns nothing instead of everything. Test fixtures always contain at least two tenants, because a single-tenant fixture cannot detect the bug.

Yes, and the important decision is architectural rather than which provider. The payment provider holds subscription state and your database mirrors it via webhooks, rather than maintaining a parallel truth that drifts. Entitlements are stored separately from plan names, so a custom enterprise deal does not require code changes.

Single sign-on via SAML or OIDC is the most common procurement blocker, followed by SCIM provisioning, audit logs and role-based access beyond admin-and-member. None need building on day one, but the user model should anticipate them: users belong to organisations, permissions attach to roles, and mutations write an audit record.

Yes. Usage billing needs event counting that is durable and idempotent so a retried request cannot double-bill, customer-visible consumption before the invoice arrives, and soft limits with warnings rather than hard cutoffs. If usage pricing is on the roadmap, record the events now even while billing on seats.