The email lands on a Tuesday. The client wants somewhere their customers can log in, check job status, and upload files. It needs their logo on it and it needs to exist before their busy season. Your developer is booked through October, and the last time you subcontracted a portal it took six weeks and ate the margin on the whole engagement.
Can an agency use an AI building tool for client work like this? Yes, and portals are the case where it pays off most. A client portal is a login, a few roles, a data model, and a handful of screens. On most AI app builders, that's one working session to a functional prototype and a few days to a deployed URL the client signs off on. Here is the workflow, what it costs against the alternatives, and who owns what when the engagement ends.
Why portals are the deliverable to start with
Agencies pitch websites. The work that keeps running after launch is the operational software behind them: portals, intake systems, internal tools. In our data on 501,479 agency projects, that category reaches production at 1.6 times the rate of client websites; the full breakdown is in what agency work actually lasts. A portal is also the deliverable a client comes back for. It changes when their business changes, which means a second engagement instead of a one-time build.
The reason agencies have avoided them is cost. A portal used to mean a developer, and a developer meant either a hire you can't fill for one project or a subcontractor whose quote sets your margin.
The agency workflow: brief to live URL in six steps
- Scope the brief to one workflow. Pick the thing the client's customers do most. Job status and file upload. Appointment booking and confirmation. Invoice view and payment. One workflow, two or three roles (the client's team, the client's customers, and you as admin), and the statuses each role can change. Write it as a paragraph, because that paragraph is your first prompt.
- Build the functional prototype on day one. Paste the scoped brief into Bolt and let it generate the app: the login, the roles, the data model, and the screens. This is a working prototype, so click through it as each role. If a customer can see another customer's records, you have found the bug before the client does.
- Connect the real data. Point the app at a database (Bolt Database or the client's existing Supabase project) and turn on authentication, so the prototype stops running on placeholder records. From here every screen shows the client's actual customers and statuses.
- Iterate during the client review, live. Share the running app in the review call. When the client says the status labels are wrong or the upload step needs a second field, describe the change and watch Bolt make it while they are on the call. Revision rounds stop being tickets, which is where portal projects used to lose their margin.
- Brand it and put it on their domain. Bring in the client's colors, type, and components, and publish through Bolt Cloud to a custom domain so the portal reads as theirs. Custom domains and a badge-free site both need a paid plan; free-tier sites carry a "Made in Bolt" badge until you upgrade (Bolt Cloud hosting plans).
- Hand off a deployed URL and the project behind it. The client gets the live portal. You keep the project synced to GitHub as a standard codebase, with the environment variables and service keys documented, so either of you can change it later. The mechanics of that handoff are the subject of the next post in this series: who owns the code? the agency handoff guide.
Six steps, and the calendar time is measured in days because the build step is measured in hours.
What it costs
| Route | What you pay | What you get |
|---|---|---|
| Subcontract a US developer | $100 to $300 an hour (FullStack Labs and Clutch, 2025). A modest portal lands in the $5,000 to $15,000 range before hosting and maintenance. | A custom build on the developer's timeline. Changes after launch go back through the developer. |
| Off-the-shelf portal software | A monthly fee per client, for as long as the portal runs | Fast to start. The client's brand competes with the vendor's, and the workflow bends to the template. |
| Build it in Bolt | A monthly plan that costs less than one billable hour of US freelance development, with hosting, database, and authentication included | A working portal in days, on the client's domain, with the code exportable and yours to hand over. |
The subcontractor route isn't wrong. It's the right call when the portal needs unusual compliance work or heavy integration into systems your team can't see. For the portal most clients ask for, the cost gap is the margin.
Who owns the code?
You do, and then the client does, depending on how you scope the engagement. A Bolt project is a standard web project: sync it to GitHub, export the repository, run it locally, deploy it on the client's infrastructure if that's what the contract says. The codebase is not locked to Bolt. Write the ownership terms into the statement of work the same way you would for any deliverable, and hand over the repo access with the URL.
Will the client accept work built with AI tools?
No survey measures buyer-side acceptance yet, so distrust any number that claims to. What clients judge is whether the portal does what the brief said, whether it looks like their brand, and whether it can be changed later. A working portal they clicked through in the review call answers all three. Show the running app before you say how it was built.
Start with the next portal request in your inbox. Scope it to one workflow, build the prototype the same day, and review it live. See what other agencies are shipping in-house on Bolt for agencies.
