Your product, from sign up to subscription
The parts every software product needs and nobody enjoys rebuilding: accounts, teams and roles, plans and billing, and the meter that counts usage. Built once, properly, and handed to you as code.
What you actually get
Not a prototype that falls over at the first paying customer. The plumbing a real product needs, built to be charged for.
Accounts, teams and roles
Sign up and sign in, organisations with members, and roles that decide who can do what. The boundary every multi customer product needs, enforced on the server rather than hidden in the interface.
Plans and billing
Subscription plans, checkout and the customer's own billing portal, wired to Stripe. Upgrades, downgrades and failed payments handled, so money is not a manual job.
Usage and limits
A meter that counts what each customer uses and a limit that holds when a plan runs out, checked where it matters rather than trusted from the browser. Zero means zero, not unlimited.
How we work
Small, paid, provable. You own the repository, the data and the Stripe account at every step.
One call to scope it
We map the plans, the roles and what each one is allowed to do, then agree what the first sellable version has to include.
A working product, fixed price
A first version real users can sign up to and pay for, on your own Stripe and your own database, on a staging URL before it goes live.
Run it, or take it
We host and maintain it, or we hand over the repository and the documentation and your team runs it. No lock-in either way.
What we hand over
A product people can sign up to, its source, and the limits that hold when a plan runs out.
Who is who, and who can do what
Accounts, organisations and roles, with access decided on the server so the interface cannot be talked around. This is the part that keeps one customer's data out of another's, and it is the part we build first.
Getting paid, without a manual step
Plans, checkout and the customer's billing portal, on your own Stripe. Test mode and live mode kept clearly apart, so a checkout never quietly runs against the wrong one.
What a plan allows, enforced
Each plan's allowances counted and checked at the point of use, with an absent limit treated as unknown rather than unlimited. A customer is never sold capacity they do not have, or refused capacity they paid for.
The repository
Source, configuration and the deployment setup, in your own organisation from day one.
The billing setup
Products, prices and webhooks configured on your own Stripe account, documented so you can change a plan later.
The documentation
How the account, billing and metering pieces fit together, written for your developers, not for us.
A support window
Thirty days after handover where we fix anything that came from our build, at no extra cost.
Questions we get first
Yours. The product, the prices and the webhooks live on your own Stripe, so the money goes straight to you and you can change a plan without us. We configure it and document it.
A fixed price, agreed after the scoping call once we know the plans and the roles. We quote one number for the first sellable version rather than an hourly rate.
Yes. We build the billing so plans are data, not hard coded, so adding or changing one later is a configuration change rather than a rebuild.
Access is scoped by organisation and enforced on the server, not in the browser. Every query is filtered by the customer it belongs to, and that boundary is the first thing we build and the first thing we test.
The SEO & GEO AI Engine is our own product, and it is itself a SaaS we built on this same plumbing. This page is agency work: we build that foundation for your product, on your stack, released under your name.
Tell us the product,
not the boilerplate
Describe what you want to sell. In one call we will tell you what the first sellable version needs, what it would cost, and how long it takes.