Software other people log in to. Accounts, billing, teams and portals.
We build products with many customers, each with their own team, data and invoice: subscription tools, agency dashboards and client portals. The visible features are the easy half, so we spend just as long on sign-up, permissions, billing and what happens when a card fails.
This is for you if
Three signs it is time.
- You built a tool for your own business, and other companies are asking to pay for it.
- Your clients email you for reports and files they could fetch from a portal.
- You have a working product, but billing, seats and permissions were bolted on later.
What changes
Customers sign themselves up
Sign-up, trials, plan choice and payment work without a sales call, and customers invite their own team members.
Each customer sees only their own data
Accounts are separated from day one, with roles inside each team and an agency view for people who look after several.
Billing that mostly runs itself
Subscriptions, seats, invoices, plan changes and failed cards are handled by the payment provider and reflected in the app.
What's included
The usual scope. Every quote says exactly what is in and what is out.
Accounts
- Sign-up, sign-in and password reset
- Teams, seats and roles
- An agency or parent view across many accounts
- A log of who changed what
Billing
- Plans, trials and subscriptions
- Card payments and invoices through an established payment provider
- Per-seat or usage-based pricing
- Reminder emails when a card fails
Product
- Customer portals and an admin console
- API keys for customers who want to connect their own tools
- Plan limits and feature switches
- Onboarding emails and in-app help
- WordPress plugins and embeddable badges
How it runs
The general process, shaped for this kind of job.
- 01
Decide who pays for what
Before any design, we write down the customer types, what each plan includes and how billing works. A pricing model is much harder to change later than a screen.
- 02
Build accounts and billing first
Sign-up, teams, roles and payments go in before the headline feature, so everything after is built on accounts that already work.
- 03
Launch the feature people pay for
We ship the one thing customers will pay for to a small group, then watch what they do in their first weeks.
- 04
Grow it in the open
New features come from what customers ask for and what usage shows, with a changelog so they can see the product getting better.
More of this kind of work. From the index.
Questions
Asked on first calls about this.
Can you build the whole thing, not just the app?
Yes: the design, the app, the server, billing and the marketing site. We'll usually push back on the first version's scope so you launch with the part people will pay for, then add the rest.
How do you keep one customer's data away from another's?
Every record belongs to an account, and every request is checked against it on the server, not just hidden on the screen. Before launch we test that one customer can't reach another's data.
Do we have to handle card numbers?
No. We build on an established payment provider, so card details go straight to them and never sit on your servers. If you already have a provider, we'll work with it.
Can we start as a client portal and sell it later?
Yes, and it's a sensible way to start. If accounts and permissions are built properly from the beginning, opening it to paying customers is mostly a matter of adding plans and billing, not a rewrite.
Goes well with
Services
Want this for your business?
Tell us what you have today and what is getting in the way. A person reads it and replies within two business days.