FinTech · SaaS
Automated multi-exchange crypto trading platform
Crypto trading SaaS
Node.jsAngularMongoDBWebSocketFirebaseGCP
SaaS platforms
Multi-tenant SaaS engineered to be sold, billed and scaled.
Your product is multi-tenant SaaS and the buyers are strangers. Tenancy, plan limits and billing have to be right before the first paid seat — retrofitting them is a rewrite.
The brief, honestly
Tenancy, plans and money are the architecture.
Founders arrive with a working demo and a waiting list. What the demo lacks is a tenant boundary, a plan someone can be downgraded from, and an answer for the day two customers want the same feature at different prices. Those aren't features. They're the shape of the system.
So the first decision is the tenant model, and it is close to irreversible. Shared schema with a tenant key is cheaper to run and easier to report across; a database per tenant is easier to isolate and to delete on request. We pick one against your compliance obligations and your seat economics, then write down why.
Billing comes next, because it is where products quietly bleed. Subscription billing, usage metering and plan limits have to agree with each other and with what the product actually enforces. When they drift, you either give away capacity or invoice for something a customer never received — and churn follows both.
Problem 01
We have a demo and a waiting list, not a platform.
The gap is tenancy, plans and money. We take the demo as the spec, then build the boundaries underneath it so the next signup doesn't need your attention.
Problem 02
Two customers asked for the same feature at different prices.
That's an entitlement problem, not a feature problem. Plan limits and feature flags live in one place the product checks, so pricing changes don't become code changes.
Problem 03
Our billing and our product don't agree on what's included.
The meter and the enforcement point become the same code, and we reconcile against the payment provider on a schedule. Disagreements surface as alerts, not as refunds.
Problem 04
One noisy tenant slowed the whole app down.
Tenant isolation isn't only a privacy control, it's a blast radius. Per-tenant query limits, queue partitioning and load testing against the loudest account you have.
What's included
Scope, spelled out.
Tenant model and isolation
Shared schema with a tenant key or a database per tenant, chosen against your compliance needs and enforced at the query layer, not in if-statements.
Roles and entitlements
Role-based access inside each tenant and entitlements that decide what a plan may do — checked before the product allows anything.
Subscription billing wiring
Stripe plans, proration, trials, dunning and failed-payment handling, reconciled against your own records so the two never quietly diverge.
Usage metering and limits
Counters the product itself enforces, exposed to the customer before they hit the ceiling. Nobody should discover a plan limit from an error page.
Signup, free trial, upgrade
The path from a stranger to a paid seat, including the free trial, the downgrade nobody designs, and the day someone cancels and comes back.
Load and isolation testing
We test with one tenant behaving badly, because that is how it fails in production: not evenly, but from a single loud account.
MVP to production path
The first release is scoped to what earns money, with the seams left in the right places so the next release isn't a rewrite.
How we work
What actually happens, week by week.
01
Tenant model
Shared schema or a database per tenant, decided against compliance and seat economics, then written down.
02
Plans and limits
Every plan expressed as entitlements the product can check, including the ones sales will invent later.
03
Billing and meters
Subscription billing, proration and dunning wired to the counters the product already trusts.
04
Signup and trial
The free trial, the first paid seat, the upgrade and the cancellation, built as one flow.
05
Isolation tests
One tenant made deliberately loud, one deliberately nosy, and a load profile from your growth plan.
Tech stack
The tools we actually use here.
The database is chosen by the tenant model rather than by habit, and Stripe handles money because it already knows the edge cases you haven't hit yet.
PHPLaravelNode.jsTypeScriptReactAngularMySQLPostgreSQLMongoDBStripeFirebase AuthGoogle CloudAWSDigitalOcean
What you get
Deliverables, outcomes and who this is for.
Deliverables
- Tenant model decision record
- Plan and entitlement matrix
- Billing and metering, reconciled
- Signup, trial and upgrade flows
- Isolation and load test results
- Runbooks and onboarding docs
Outcomes
- You can charge the first customer
- Plan changes without a release
- One loud tenant stays contained
- Churn visible before it happens
Ideal client
Founders and CTOs selling software to third parties who need tenancy, plans and billing right before the first paid seat.
Proof
Platforms built to be sold, not just shipped.
Construction · CRM
A multi-agency CRM for roofing companies
Roofing services platform (US)
CodeIgniterReactPHPMySQLStripeTwilioQuickBooks
Why the exchanges were treated as one
Its users traded on several exchanges from one dashboard, and every exchange had a different idea of an order. We normalised orders and balances into one internal shape before the UI ever touched them, so adding an exchange never reached the front end. The 70% faster execution sat on top of that shape.
Isolated panels, decided up front
Each roofing agency needed its own panel, its own users and its own admin controls inside one deployment. That was settled in the data model before the first screen existed, because per-agency roles bolted on afterwards is a rewrite dressed as a migration.
Frequently asked
Questions we get on the first call.
Shared schema with a tenant key, unless something forces otherwise. It is cheaper to operate, easier to migrate and easier to report across. A database per tenant wins when a contract demands physical separation, when tenants need different retention rules, or when one customer is large enough to deserve its own blast radius.
More than the build. Undercounted usage is revenue you never invoice; overcounted usage is a refund plus a trust problem. The expensive version is discovering months later that the product and the invoice were counting different things. That's why the meter and the enforcement point are the same code.
It was never ours to sign over. Code, infrastructure and documentation sit in your accounts from the first commit, and we'll happily say that in writing for a data room. If your investors want a technical review, we can hand them the architecture notes and the decision records we already keep.
Sooner than the full platform, if you let us scope for it. The shortest honest path is one tenant model, one plan, one payment path and the flow from signup to paid seat. Everything else waits. We would rather you take money from a narrow product than demo a broad one.
Yes, and it usually works best that way. Your team keeps the domain, we take the tenancy, billing and metering layer nobody enjoys building twice. Same repository, same review process, short branches. We'd rather your engineers own the parts they'll be maintaining after we've gone.
Related services
More in Custom Software & SaaS.
Get the tenancy and the billing right before you sell.
Bring the demo and the pricing page you sketched. Those two together tell us the tenant model, and the tenant model is the decision you can't undo.