Documentation/Building on Supero/The client portal that used to take three months — and what to charge for it now
The client portal that used to take three months — and what to charge for it now
How much to charge for a client portal: the four-week build shape, the week-zero questions that win the job, and the pricing model that makes it recurring.
- channel
- freelance
- agency
Overview
A playbook for freelancers and small agencies, from someone with an obvious interest in you reading it.
A client comes to you with a real product: a multi-location clinic wants a patient portal, or a distributor wants their retailers to place orders online, or a consultancy wants to productise a spreadsheet they have been selling for years.
You scope it. You find the same three things every time:
- •Every one of these is **multi-tenant**. Multiple locations, retailers, client companies — each seeing only their own data.
- •Every one needs **roles**, because an admin and a staff member and an end customer are three different audiences.
- •Every one has **a workflow with money or state in it**: an order, a booking, an approval, a signature.
And so a project the client thinks is "a portal" is three months, most of which is infrastructure they will never see and are reluctant to pay for. You either quote the real number and lose the job, or quote a number you can win with and eat the difference.
(Disclosure: I work on Supero. This playbook is written to be useful even if you use something else: the project structure and the pricing model are the transferable parts. The tooling section is obviously self-interested.)
---
Why these projects are priced wrong
The client's mental model is the screens. They can see screens. They cannot see tenant isolation, and they will not pay a line item called "tenant isolation" because from their side it does not exist.
So the invisible work gets absorbed into the visible work, and the visible work looks overpriced. That is the whole dynamic, and it is why "build me a portal" quotes lose to someone who has not thought about it as hard as you have.
Two ways out. Reduce the invisible work, or **stop selling the build**.
The second one is the bigger lever and I'll come back to it.
---
The four-week shape
This is the structure I would use regardless of platform. The tool changes how long week one takes; it does not change the shape.
**Week 1: Model and skeleton.** Entities, the tenant boundary, roles. Get a running app in front of the client by Friday, even if half the screens are placeholders. *This is the week where the platform choice matters most.* On a generated stack it is a day or two. Hand-rolled, it is most of the month.
**Week 2: The real workflow.** The order, the booking, the approval chain, the thing with money in it. Including what happens when it fails halfway, which the client has not thought about and which you should demo to them deliberately — it is the moment they realise you are a professional.
**Week 3: The edges.** Roles the client didn't mention in the brief, the report they always ask for in week three, the email or SMS notification, the import of their existing spreadsheet.
**Week 4: Handover.** Deploy, walk-through, and the maintenance conversation.
The mistake almost everyone makes is spending week 1 on infrastructure and showing the client nothing until week 3. Showing something running in week 1 changes the entire relationship for the rest of the project. You spend the following weeks refining against feedback instead of defending a plan.
---
What changes with a generated backend
Concretely, on the projects this playbook is about:
| Work item | Hand-rolled | Generated |
|---|---|---|
| Data model → API + DB | Days | Part of generation |
| Multi-tenant isolation | Days, and a permanent risk you own | Structural |
| Auth, roles, permissions | Days | Builtin roles + custom roles with a ceiling |
| Admin console | Days–weeks | Generated |
| Customer-facing UI | Weeks | Generated, then refined |
| Order/booking/approval flows | Days each, including the failure paths | Pre-built transactional services |
| Deploy | Days | One action |
**Week 1 collapses; weeks 2–4 stay.** Anyone telling you a client project becomes an afternoon is selling you something. The client's actual requirements (their pricing tiers, their weird approval rule, their branding, the report they want) are still work, and that work is still where your value is.
What changes is the ratio. You spend the month on things the client can see and will pay for.
One item for your own notes rather than the client's: generation is not reproducible. Two runs from the same input measured 0.635 similarity on the generated UI file, so roughly a third of it moved between them. Assume the same of a regeneration later in the engagement. It is a review with hours in it, not a button you press on a Friday afternoon, and it belongs in the change-request line of your contract.
---
The business model that follows
This is the part worth more than the tooling.
If a portal takes three months, you sell it once for a large number and then you are unemployed again. If the same portal takes four weeks, you can do something structurally better:
**Sell the outcome, not the build.** Setup fee plus monthly. The client gets the portal plus hosting, support, and small changes; you get recurring revenue. Ten of these is a business rather than a queue of projects.
**Productise a vertical.** Build one clinic portal, then sell it to eleven clinics. The second one is configuration. Multi-tenancy means one deployment serving all of them, which is exactly the architecture you already had to build for the first client.
**Sell the thing they actually want.** They do not want a portal. They want their retailers to stop emailing orders. Price against the outcome and the conversation stops being about your day rate.
So what do you charge?
I am not going to print rate bands I cannot source. Day rates for this work vary more by country and sector than by anything I could tell you, and a made-up number in a pricing article is worse than none. What I can give you is the method, which is the part that actually changes your invoice.
**1. Price the build off the weeks, not the features.** Four weeks at your day rate is the floor, not the quote. If you quote the floor you have priced a contractor.
**2. Price the monthly off the outcome, not your cost.** Ask what the outcome is worth to them per month: what does the distributor save by killing email orders, what does the clinic save in no-shows. Your monthly should be a visible fraction of that number. That is the conversation where your day rate stops being the subject.
*Worked, with your own rate as the variable:* four weeks at **your day rate × 20** is the floor. At £700 that is £14,000, and it is the number you must not quote. If killing emailed orders saves the distributor a day a week of admin, the outcome is worth roughly £2,000 a month to them; a £400 monthly is a visible fifth of their saving and an easy yes. Substitute your rate and their saving; the shape is the transferable part, not my numbers.
**3. Know your floor before the call.** Platform cost plus hosting plus the hours you will actually spend on support. Anything below that is a client you are subsidising, and the productised model only works if every client clears it.
**4. Charge for the second one too.** The second clinic is configuration, not a build, so the setup fee drops and the monthly does not. That gap is the whole business.
| Project model | Productised model | |
|---|---|---|
| Per client | one large fee | smaller setup + monthly |
| Second client | full build again | configuration at a fraction of the setup |
| Year two revenue | starts at zero | last year's clients still paying |
| Where the margin is | your day rate | the gap between build cost and outcome value |
The crossover is usually around client four: before that the project model pays better, after it the productised one pulls away and keeps pulling. The reason to care about the four-week shape is not that you can run more projects. It is that four weeks is short enough to reach client four in a year.
---
Where this doesn't fit
Do not take a client project onto this stack if:
- •**The design is the product.** A design-led consumer app or a brand-heavy marketing site. Use the design-first AI builders, or build it yourself. Generated UIs are conventional and competent, not distinctive.
- •**The client requires a certification you can't provide.** We are designed for SOC 2 and HIPAA controls; neither is certified. If procurement needs the certificate, that is a hard stop, and finding out in week three is a bad way to find out. **This rules out the clinic patient portal in my own opening example** — which is exactly the trap: the most appealing project in your pipeline is often the one with a compliance gate on it. Ask in week zero.
- •**The client demands full source independence.** You can export readable source and push it to your own GitHub or Bitbucket, which is more than most platforms offer. But the export is one-way, and the running app still calls the platform for auth, data and logic unless the whole platform is self-hosted. Say this to the client in week zero, in writing, and get it acknowledged. A freelancer who surfaces platform dependency up front looks like a professional; one who is asked about it in month six looks like a problem.
- •**It's a static site or a simple CRUD tool for one team.** Overkill. Use something smaller.
**And the platform weaknesses you should put in the contract, not discover in week six.** Access policy is permissive by default inside a tenant. Generated apps do attach a policy set, but **reviewing and extending it is billable scope, not something to assume.** Put it in the estimate. We log writes but not reads, so neither you nor your client can answer "who read this record." And separately, the read-side field guard runs in monitor mode today, which means it logs
would deny read and returns the rows. If your client's sector cares about either of those, raise it in week zero rather than month six. The whole list of what we are weak on.---
The week-zero checklist
Before you quote, get written answers to these five. Every one of them changes the estimate, and every one of them is cheaper to ask now than to discover in week three:
1. **How many separate organisations will use this, and can any of them have sub-units?** 2. **Which roles, and what can each one NOT see?** Push for the negative — that is where field permissions come from, and it is the requirement clients never volunteer. 3. **Does money move?** If yes, what has to happen when a payment succeeds and the next step fails? 4. **What existing system does this replace, and is that data coming with it?** 5. **Who operates this in year two?** Determines whether you are selling a build or a service.
The client will not have thought about #2 or #3. Walking them through those two questions is often the moment you win the job, because nobody else asked.
---
Before you quote: the agency questions
These are the four I would want answered before putting a client on any platform, and I am putting our answers where you can hold us to them.
**What the model already gives you.** The hierarchy is domain → project → tenant → user, and a project is the unit of an application. So one account can hold many client projects side by side, and a productised vertical (one clinic app serving eleven clinics) is **one project with eleven tenants**, not eleven projects. That is the architecture your margin depends on.
**And here is where that argument gets weaker, which you would find in month two anyway.** Tenants are a *metered* capacity dimension: each plan carries a tenant cap, and slots above it are a paid add-on. Custom roles and the audit log are a paid tier below Pro.
So "the second client is configuration, not a build" is true of your *labour* and not of your *cost of goods*. The eleventh clinic can cost more than the tenth, and if it crosses a plan cap it costs a step, not a trickle. That does not kill the productised model. The setup fee still collapses and the monthly still recurs, which is the whole argument. But it does mean **your per-tenant platform cost belongs in the floor calculation above, and your monthly price needs to clear it at the cap, not at today's count.** Get the current caps and add-on rate from the plan page before you quote a vertical, not after.
**What you must settle in writing at week zero**, with your client and with us:
- •**Who owns the account**: you, or the client. It determines everything below, and it is a contract question rather than a technical one.
- •**Transfer on exit.** The question your clients ask *you*, not the one you ask us. Agree the mechanism before the engagement starts, not at the end of it.
- •**Agency tier and white-label.** No published partner programme today. If you are building a vertical on this, say so when you request access. That is the case we most want to get right, and I am not going to invent terms for it on a marketing page.
One of those is answered by the model. The other two are contract questions, and you should settle them before you quote rather than after.
---
What to do next
**Sixteen platform-generated apps are live and need no account.** concierge.supero.live · atelier.supero.live · fieldops.supero.live, with the full list at
api.supero.dev/api/v1/public/showcase. All but two are single-tenant public demos, so what you get is the generated customer-facing product rather than the admin side.Open one and put a client's logo on it in your head. If you would ship that, the rest of this is a pricing exercise and the method is above. If you wouldn't, no amount of tenant isolation underneath is going to rescue the meeting, and you have found that out for free in four minutes.
Related: the multi-tenant SaaS checklist · what you can actually export · why "just use Lovable" isn't the whole answer
---
*supero.dev — early access. Platform details checked **September 2026**. If you build client work on it and hit something this playbook got wrong, tell us; the freelancer path is one we are actively trying to make good.*
See the shape of the deliverable before you quote it: 19 client-style apps with full source at github.com/supero-platform/supero-apps — a CRM, a booking system, a client portal and more, each clonable.
On this page