Fileloom
A PDF engine exposed as a developer API, built to generate and process documents at scale.
United States
SaaS Product Development
From first customer to a product that runs itself
The hard part of SaaS is not building the application. It is everything wrapped around it: the signup that works at 3am without you, the invoice that reconciles, the support view that lets someone answer a customer question without a database console.
We build that machinery as part of the product, not as an afterthought, because it is what separates a SaaS business from a web app with a login page.
The decisions that are expensive to change
Three architectural choices set the ceiling on a SaaS product, and all three are cheap now and costly later.
The tenancy model. How customer data is separated determines your migration story, your compliance story, and your per-customer cost. We pick it deliberately and write down why.
The permission model. Organisations, teams, roles, invitations, and the awkward cases: a user who belongs to two customers, an admin who leaves, a seat that gets reassigned. Modelled once, correctly, at the start.
The billing boundary. What your database believes about a subscription and what the payment processor believes must never diverge. We build the webhook handling, the idempotency, and the reconciliation to guarantee that.
Instrumented from day one
You cannot improve activation if you cannot see it. We instrument the product for the questions you will ask in month three: who signed up, where they stalled, what they actually used, and which accounts are quietly about to churn.
Operations you can hand over
Infrastructure defined as code, environments that match, deployments that are one command and reversible, and monitoring that pages a human when it should. When you eventually hire your own team, they inherit a system, not a mystery.
- Deliverables
- Multi-tenant architecture with tenant isolation and data partitioning
- Subscription billing, metering, plans, and dunning
- Authentication, SSO, and organisation-level permissions
- Admin tooling, customer support views, and audit logs
- Usage analytics and product instrumentation
- Onboarding flows and self-serve signup
- Infrastructure as code, staged environments, and automated deploys
- Typical stack
Questions, answered.
What makes SaaS different from a normal web application?
Three things: tenancy, billing, and operations. You are running one system for many customers who must never see each other's data, money moves on a schedule and has to reconcile, and you are on the hook for uptime. Each of those is a design decision made early, and each is expensive to retrofit.
Should tenants share a database or get their own?
For most products, a shared database with row-level tenant isolation is right: cheaper, simpler to migrate, easier to operate. Separate databases per tenant make sense when you have enterprise customers with data residency requirements or very uneven load. We decide this before the first migration, because changing it later is a project of its own.
Do you handle billing?
Yes. Stripe in most cases: plans, trials, proration, usage metering, failed-payment recovery, and the webhook handling that keeps your database and the payment processor in agreement. Billing that silently drifts out of sync is one of the most costly bugs a SaaS product can have.
Can you build the MVP and hand it over to our team?
That is a common arrangement. We build the first version, document the architecture, and run a structured handover with your engineers, staying available on a retainer while they take ownership.
How do you approach pricing and packaging?
We are engineers and designers, not pricing consultants, but we build the billing system so that pricing is a configuration change rather than a code change. You will want to change your pricing, probably more than once, and the software should not fight you.
Related work
SaaS products we have shipped.
Need saas products?
Tell us what you're working on. We'll tell you how we'd make it real.
Start a project