Smart Systems
Web Platforms and Portals.
End-to-end product engineering
Multi-tenant product engineering: billing, roles, audit, and the operational surface a support team needs on day one. The features that decide whether a SaaS business is viable are rarely the ones in the pitch deck.
Who this is for
You are selling software to more than one customer and the architecture still assumes one. Or you are about to be, and would rather not learn this the expensive way.
What you get
Artifacts, not activities.
- 01
Tenancy model
Isolation, data residency and the migration path between tiers, decided before the first customer rather than after the second complains.
- 02
Billing and entitlements
Plans, metering, proration and the dunning flow. The part every SaaS underestimates and then rebuilds twice.
- 03
Roles and audit
Permissions a customer's security review will accept, and a log that answers who did what, when, from where.
- 04
Admin and support console
The internal tool your support team uses so they stop asking engineers to run queries.
- 05
Operational runbook
What to do at 3am, written for the person who did not build it.
- 06
Workflow map
The job as it is actually done, including the shortcuts people invented. Those shortcuts are requirements, not deviations.
- 07
The portal
Built around the task rather than around the source systems it happens to read from.
- 08
Integration layer
The connections to the systems of record, with the lag and failure behaviour made visible instead of hidden.
- 09
Role model
Who sees what, aligned to your directory, so access reviews stop being a quarterly archaeology project.
- 10
Adoption plan
Training, a migration window, and the named people who will answer questions in week one.
How it runs
Every phase has a duration on it.
Weeks 1–3
Decide the model
Tenancy, identity, billing shape and audit. These four are hard to change later and cheap to decide now, which is the whole argument for doing them first.
Weeks 4–12
Build the spine
Core product, the admin surface and the entitlement system, in parallel. Shipped behind flags so the sequence is ours and the release date is yours.
Weeks 13–16
Make it operable
Observability, runbooks, load testing against your actual growth curve, and the security questionnaire answered in advance.
What it's built on
Named, so you can hire for it later.
We publish the stack because one of our refusals is building on something you cannot staff after we leave. If a choice here does not suit your hiring market, that is a conversation for week one, not a surprise in year two.
Product
- Next.js
- TypeScript
- tRPC / REST
- Row-level security
Platform
- Postgres
- Redis
- Temporal
- S3-compatible storage
Commercial
- Stripe Billing
- Entitlement service
- Usage metering
- SCIM / SSO
What good looks like
The numbers we hold ourselves to.
- 99.95%
Availability
Measured on the customer-facing path
- < 1 day
Security review
Questionnaire answered from existing evidence
- 4
Decisions up front
Tenancy, identity, billing, audit
These are the targets we work to on this kind of engagement, not averages from past ones. Measured outcomes carry a baseline, a period and the name of whoever measured them, and they live in See Impact in Action.
Ready to scope web platforms and portals?
It starts the same way every engagement does — four weeks, fixed scope, fixed price, and eight artifacts you keep whether or not you build with us.
The Usool Method
- Principle
- Pattern
- Prototype
- Production
- Proof