A client portal for financial advisors is a private web app where a prospect becomes a client: they complete a fact find, answer a risk questionnaire, upload documents, sign agreements and pass an identity check. Build the workflow and the document vault yourself. Buy identity verification and e-signature. The plan you are on decides who can open the thing at all.
Every page ranking for this phrase today is either a wealth-technology vendor selling a suite or an advisory firm's own login page. Checked in a browser on 1 October 2026, the first results were Orion, eMoney, AdvisorEngine, Adviceworks and the Kitces AdvisorTech directory. None of them answers the question an independent advisor or a small firm actually asks, which is: how much of this do I have to buy, and what can I put together myself in a weekend?
This article answers that. It is written from the live product documentation, re-read and dated on 1 October 2026, because the plan gates in particular changed during 2026 and most third-party write-ups still describe the old behaviour. Verified in the browser on 1 October 2026: the Lovable pricing page, the publish documentation, the storage documentation and the workspace identity pages.
What a client onboarding portal actually has to do
Strip away the branding and an advisor onboarding portal is five jobs in a fixed order. Each one has a different risk profile, and that is why the build-or-buy answer is different for each.
- Fact find. Personal details, dependants, income sources, existing holdings, goals and time horizon. Long, boring, and abandoned halfway through unless it saves progress.
- Risk questionnaire. A scored instrument that produces a risk profile the client agrees to in writing.
- Document upload. Statements, tax documents, trust deeds, corporate papers. The part clients currently do by email attachment, which is the problem you are solving.
- Agreements and e-signature. The advisory agreement, fee schedule and disclosures, signed and timestamped.
- Identity check. Confirming the person is who they say they are, against documents and data sources you do not hold.
Two of those five are regulated specialisms with their own vendors and their own liability. Three of them are forms, files and status tracking, which is ordinary software. Keep that line clear and the project gets much smaller.
Build or buy, step by step
This is the table the vendor listicles do not print, because every row that says "build" is a row they do not sell. Prices and plan gates below were read on 1 October 2026.
That last row matters more than it looks. A portal that becomes a second, competing client database is worse than no portal. The portal collects, the customer relationship system keeps. If yours is Salesforce, the connector route and what it can and cannot read is covered separately in our piece on using Salesforce as the system of record behind an app.
Identity verification: buy it, and store almost nothing
The single most common mistake in a self-built client portal is treating the identity check as another file upload. An advisor adds a field called "photo ID", clients upload passport scans, and the firm is now holding a bucket of government identity documents it never meant to become the custodian of.
Do it the other way around. Send the client to a specialist identity verification provider, let the provider hold the images and run the checks, and have your app store three things and nothing else:
- A status: not started, in progress, passed, referred, failed.
- A reference identifier issued by the provider, so you can retrieve the full result from them if you are ever asked for it.
- A timestamp and the name of the provider that performed the check.
No images. No document numbers. No dates of birth copied out of a scan. If the check needs to be re-examined years later, you follow the reference back to the provider, which is where the evidence belongs anyway. This keeps the most sensitive category of data out of your app, which shrinks your exposure, shortens the security conversation, and makes the portal far easier to hand to a compliance officer for review.
The same logic applies to e-signature. Your app stores an envelope identifier and a status, and links out to the provider's certificate. It does not try to be the evidence.
Three kinds of sign-in, and the one your clients use
Lovable has three features whose names all contain some form of the word identity, and they are constantly confused in third-party guides. The documentation itself now opens with a table disambiguating them, which tells you how often it comes up.
For an advisor portal the mapping is simple:
- Your clients are the app's end users. They sign in with email, or with a company identity provider through SAML single sign-on if you are serving corporate trustees or company directors. That is configured per project under the built-in backend's user settings.
- Your staff log in to Lovable itself. If you want advisors and paraplanners signing in through your own identity provider, that is workspace single sign-on, and it sits on the Business plan.
- Workspace identity reuse is the third one, and it is almost certainly not what you want here. It lets an app recognise a logged-in workspace member without a login page, which is right for an internal tool and wrong for a client portal, because your clients are not members of your workspace.
Workspace single sign-on also has a prerequisite that trips people up: the button to add a provider stays disabled until the workspace has a verified domain, proven with a text record in your domain name settings. Plan for that before you promise your operations lead a go-live date.
The plan gate that decides whether you have a portal at all
Here is the finding that should change the project plan, and it is the one every Lovable client portal tutorial currently omits. On the Free and Pro plans, a published app is public. The documentation is blunt about it: anyone with the link can visit your published app, publishing is always external to the web, and you cannot restrict website access on these plans.
A client portal whose only protection is that the address is hard to guess is not a client portal. You can of course build a login screen inside the app, and for many portals that is the actual access control. But the page itself is still served to the open internet, which means the login screen is the only thing between an unauthenticated visitor and whatever the app renders before it checks who is asking. That is a much thinner margin than most advisors assume they are buying.
On Business and Enterprise, the publish dialog opens an audience picker with three settings: Public, Workspace, or Custom. Workspace means only logged-in workspace members can reach it. Custom lets you compose the audience from the whole workspace, groups, individual members, and people outside the workspace invited by email. That last option is the one that makes a client portal work: you can give a client viewer access without adding them to your workspace and without making the site public.
There is a trap on the way back down, and it is worth knowing before you choose a plan. If you restrict access on Business and later downgrade, the restriction keeps being enforced and the app stays live, but you can no longer publish changes to it. The dialog shows "Publish to workspace requires a Business plan" and the live version stays frozen where it is. Your options at that point are to make the portal public, upgrade again, or unpublish. Verified on the publish documentation, 1 October 2026.
Per-client audiences, groups and the invite limits nobody publishes
Once you are on a plan that can restrict access, the practical question is how you run it per client. Two mechanisms do the work.
External invites
From the Custom audience you invite a client by email address. They are not added to your workspace. They log in with the invited address, creating an account with it if they do not have one, and their access is tagged with an EXT label in the audience list. The limits, which are documented and almost never quoted:
- Up to 10 email invites per update.
- Each address can receive at most 10 invite emails per day.
- Invites are inert until you select Publish or Publish changes. That is when the emails go out and access is applied, which is exactly the kind of detail that makes an onboarding run look broken on a Friday afternoon.
- Workspace administrators can turn external invites off entirely, or restrict them to verified company domains, in which case other addresses show a message saying only verified-domain emails can be invited.
- Workspace members cannot be invited as external viewers. Add them through the workspace instead.
One honest note, because it still has not been resolved. On the same documentation page, read again on 1 October 2026, the body text says re-inviting an address sends a fresh email, while the frequently asked questions section immediately below says re-inviting the same address does not send duplicate emails. Those cannot both be true. Test it with your own address before you build a client communication around it.
Groups
For a firm with segments, Business and Enterprise workspaces can organise members into named groups and grant a published app's visibility to a group rather than to individuals. Group membership changes take effect immediately, and groups synchronised from an identity provider appear alongside manually created ones. For an advisory firm that is the clean way to express "the private client team can see the private client portal" without maintaining a list by hand.
A governance detail worth knowing if you work in a larger firm: the Security insights view flags internally published projects that have external viewers, so an administrator can review who has access. Assume someone will look at your portal's audience list. Keep it tidy.
The plan feature rows above were read on 1 October 2026. Internal publish, role-based access, workspace single sign-on and the Security center sit on Business. Directory synchronisation and audit logs sit on Enterprise. That last point is worth stating plainly because a widely shared September announcement listed directory synchronisation and audit logs as Business and Enterprise; the pricing page and the documentation both place them on Enterprise. Where they disagree, follow the product pages, and re-check before you commit to a plan in a proposal.
Documents: private buckets, one-hour links, and the export trap
The document vault is the part clients judge you on, and it is also the part with the most surprising defaults. Three facts from the storage documentation, read 1 October 2026.
Public storage buckets are blocked by default on every plan. A workspace owner or administrator can turn that block off, and for a client portal there is no reason on earth to do so. Private is the default, and access to a private bucket is governed by row-level security rules, the same mechanism that protects your tables. If row-level security is unfamiliar territory, we covered how it goes wrong, and what a leak actually looks like, in our piece on whether Lovable is safe for financial data.
Sharing a file out of a private bucket produces a temporary signed link that expires after one hour. That is a sensible default and a terrible one to discover by accident, because it means you cannot paste a document link into an email and expect a client to open it tomorrow. Build the download into the portal, behind the client's own session, rather than mailing links around.
Uploads are capped at 2 GB by default, adjustable up to 5 GB. For statements and tax documents that is irrelevant; for scanned historical files from an acquired book, it occasionally is not.
And the one that will bite somebody eventually: storage files are not included in database exports. An export covers schema and table data only. If you ever migrate the portal, wind it down, or produce a complete record set, you must download the files separately from the storage view. A firm that exported the database, assumed it had everything, and removed the backend would have the index of its client documents and none of the documents.
Related: storage keeps accruing usage while a project is paused, because the files stay in place. Pausing a portal does not make its document costs go away.
Records and retention: a duty that outlives the app
Every jurisdiction MoneyFlock's readers work in imposes some form of record-keeping duty on advice businesses: keep the advice, the basis for it, the client agreement and the communications, for a defined period, and be able to produce them. The periods and the wording differ. The duty itself is close to universal, and it is longer than you think. It frequently outlives the client relationship, and it certainly outlives whatever software you are using this year.
That has three consequences for a portal you build yourself.
- Retention is a product requirement, not an afterthought. Decide at design time what the portal keeps, for how long, and what happens to it when a client leaves. Write it down before you write the schema.
- Deletion must be deliberate. A client asking you to delete their data and a record-keeping duty can point in opposite directions. That is a question for your compliance officer, not for your developer, and the app should make the distinction visible rather than quietly destroying things.
- Exit has to be rehearsed. If the portal had to be wound down next quarter, could you produce a complete, readable record set including the documents? Try it once, on a test project, while nothing depends on it.
MoneyFlock does not name a regulator here on purpose, because this article is read in a dozen jurisdictions and the specifics differ in every one. Take the structure to whoever signs off your compliance process and let them set the periods. And a flat warning, because self-built tools attract this error: do not describe your portal as compliant. Software is not compliant. A firm's process can be, and the software either supports that process or gets in its way.
What the platform can give you is evidence rather than assurance. Externally published apps can expose a Trust center, a security page generated on your app's own domain at a well-known address, re-evaluated on every publish. It is explicitly informational and explicitly not a certification, but it is a far better answer to a client's security question than a paragraph you wrote about yourself.
What this actually costs
Prices read logged out on the pricing page, 1 October 2026, and unchanged across every reading since mid-September.
Both paid plans run on a credit ladder rather than a flat fee. Pro runs from 100 credits at $25 a month up to 10,000 at $2,250. Business runs from 100 at $50 up to 10,000 at $4,300, with a discount that reaches 14 percent at the top rung. Business is roughly twice Pro per credit through the middle of the ladder, and the pricing page's own answer to why is that the difference pays for the team and governance features rather than for compute. The full ladder, and how to size it, is in our breakdown of Lovable's Free, Pro and Business plans.
Credits are consumed by building, not by having clients. Publishing from the publish dialog is free and works at a zero balance. What does consume credits once you are live is the built-in backend serving requests and any in-app artificial intelligence features, so a portal with twenty clients and a portal with two hundred are not the same monthly number.
Against that, the vendor side of this market does not publish prices at all. Of the pages ranking for this phrase on 1 October 2026, not one shows a figure without a demo call. That asymmetry is the real argument for building: not that building is free, but that you can see what it costs.
On the specialist steps, budget separately for identity verification and e-signature, both of which are usually priced per check or per envelope. Those are the line items that scale with client count, and they are the ones you cannot engineer away.
The printable client onboarding checklist
Print this, or paste it into your project chat as the specification. It is ordered the way a client experiences it, which is not the order a developer would naturally build it.
Before the client sees anything
- Decide the plan. If the portal must be private, that is Business or above.
- Verify your domain if you intend to use workspace single sign-on for staff.
- Confirm public storage buckets are blocked, which is the default.
- Choose and contract your identity verification provider and your e-signature provider.
- Agree the retention period and the deletion rule with whoever owns compliance.
The client journey
- Invitation. Email invite from the Custom audience, maximum ten per publish.
- Account. Client signs in with the invited address.
- Fact find. Saves progress. Shows how much is left.
- Risk questionnaire. Scored, with the result shown back and acknowledged.
- Documents. Named, dated, private bucket, visible checklist of what is still outstanding.
- Agreements. Sent to the signature provider, status returned to the portal.
- Identity check. Handed to the provider. Portal stores status, reference and timestamp only.
- Confirmation. A single page the client can read showing everything is complete.
Behind the scenes
- Each step writes its status into your customer relationship system, not just into the portal.
- Reminders fire on the outstanding items, not on the whole process.
- A staff view shows every client's stage at a glance. This is the feature that pays for the project.
- An audit of who looked at what, if your plan provides it.
- A rehearsed export, documents included.
If you want a worked example of the same shape applied to a different audience, our walkthrough of a private investor update portal covers the build-versus-buy arithmetic with real vendor prices, and the invoice app guide covers the document and status patterns in more depth.
When you should just buy one
Building is not the right answer for everyone, and an article that only ever says build is selling something. Buy instead when:
- Your custodian or platform already includes a client portal your clients will actually log in to. A second portal is worse than one imperfect portal.
- You need account aggregation, live holdings and performance reporting. That is a data problem with licensing attached, not an application you assemble in a weekend.
- Nobody in the firm will own the thing. Software you build is software you maintain.
- Your firm is large enough that procurement, vendor due diligence and a named support contract are requirements in themselves.
Build when the portal is a workflow problem rather than a data problem: when the pain is chasing documents, not displaying valuations. That is the case for most independent advisors and small firms, and it is the case the incumbent suites serve worst, because they price for the whole stack.
A middle path is worth naming: build the onboarding portal, keep the incumbent for reporting. The two do not have to be the same product, and onboarding is the half that is actually broken. If you want the build without doing it yourself, a certified Expert can take this specification and ship it.
Frequently asked questions
Is a self-built client portal secure enough for financial documents?
It can be, and the honest answer is that it depends on three things you control: whether the published app can be restricted to an audience, whether your storage buckets are private with access rules that actually work, and whether you kept identity documents out of the app entirely. Get those three right and the portal is on a reasonable footing. Get the first one wrong by publishing on a plan that cannot restrict access, and the other two will not save you. We went through the failure modes in detail in our security piece.
Can clients log in without creating yet another account?
Partly. External viewers invited to a restricted app log in with the invited email address, creating an account with it if they do not have one, so there is a sign-up step. For corporate clients, SAML single sign-on at the app level lets them use their own company credentials. There is no way to give a retail client access with no account at all, and you would not want one.
Is there a free way to run a client portal?
Not a private one. The free tier is genuinely useful for building and testing, but a published app on Free or Pro is reachable by anyone with the link. Treat the free tier as the place you prove the workflow, and budget for a paid plan before any real client data goes in.
How long does it take to build?
The first working version, meaning forms, uploads, statuses and a staff view, is a few evenings of work for someone who has built with Lovable before. The parts that take real time are the ones that are not software: choosing providers, agreeing retention with compliance, and rewriting your fact find so people finish it.
What about accountants, lawyers and other professional firms?
The structure transfers almost unchanged. The five steps are the same, identity verification and signature are still bought rather than built, and the retention duty is still the thing that outlives the app. Only the fact find and the questionnaire are profession-specific.
Should the portal hold the client record, or should the customer relationship system?
The customer relationship system, always. The portal is a collection surface and a status display. The moment two systems both claim to hold the client record, one of them is wrong and nobody knows which. Connect them and let the established system win.
Where to start
If you are building this yourself, start on Lovable and prove the workflow before you pay for anything. When the portal has to be private, which for real client data it does, the Business plan is the tier where restricted publishing, groups and workspace single sign-on live.
If you would rather not build it, you can hire a certified Lovable Expert through the partner directory and keep the architecture in this article as your brief.
For the wider picture of what building with Lovable is and is not good for, including where it is the wrong tool, see our full review for founders.
Related reading from this series: the advisor marketing website, the team workspace setup for a finance team, and the expense approval workflow, which shares this article's approvals-and-audit shape.
About the author
TJ Alam is a certified Lovable Expert (Website Builder track) and the founder of Digi Flock Enterprises. He built tjalam.com and cyberdance.in on Lovable. The certification is an independent credential and is not an endorsement by Lovable.
Disclosure: MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.