⚡ AI Analyst
An investor update portal, built or bought: verified 2026 prices, the monthly schema investors expect, and the invite limits nobody publishes.
Money Flock
Recommended Contents
Comments
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.
An investor update portal is a private page where your existing investors sign in to read the monthly update, see the numbers behind it and pull the documents they need. Buying one costs between nothing and $199 a month. Building one is worth it only when the portal has to hold data your reporting tool will not.
Investors do not want a brochure. They want the ship's log: the same columns, in the same order, every month, so they can see the trend without asking you for it. That is the whole job of an investor update portal, and it is why the build-versus-buy question is narrower than the vendor pages make it look.
This article prices both sides with figures read on the vendor pages on 30 September 2026, sets out a monthly update schema you can copy, and covers the part almost nobody writes down: the plan gate that decides whether you can restrict who opens your portal at all, and the invite limits that decide how you run it month after month.
Verified in the browser on 30 September 2026: docs.lovable.dev/features/publish, visible.vc/pricing and lovable.dev/pricing with the credit dropdown opened.
The prompt used for this walkthrough, typed into the live Lovable composer on 30 September 2026.
A portal is a login-gated page for people who are already investors. They have your cap table entry, they signed the documents, and they want the numbers between board meetings. Nothing on that page is a pitch.
That distinction matters more than any feature list. The moment a portal starts carrying projections, target multiples or a subscribe button, it stops being reporting and starts being a solicitation, which is a different document with different obligations in every jurisdiction. Keep the portal to what has already happened, and send anything forward-looking through the channel your counsel tells you to use.
A working portal holds four things and nothing else:
Everything else, including a fundraising CRM, deck analytics and a data room for diligence, is a different product. Google's own result page for this topic asks the reader to sort themselves into those buckets before it shows a tool, which tells you how often people buy the wrong one.
Ignore feature grids. The question that decides it is: does the update need data that lives in a system your reporting tool cannot read?
If your update is cash, burn, runway, revenue and headcount typed in once a month, buy. Reporting tools do that well, they do the email delivery, and they track who opened it. If the update has to pull unit economics out of your own database, join them to billing, and present a per-investor view of something you compute yourself, building starts to earn its cost.
Buy when the update is typed. Build when the update is computed. That single line resolves most of these decisions in under a minute.
There is a second, quieter reason to build: the portal becomes the place you keep the internal version of the same numbers, with the fields your board actually argues about, and you publish a subset of it. That is a real advantage, and it is also how build projects sprawl. Decide which one you are doing before you start.
Visible is the clearest published price list in this category, so it makes a fair reference point. These are the founder plans as shown on visible.vc/pricing on 30 September 2026, at the annual rate with the monthly rate in brackets.
Visible founder plans, read 30 September 2026
| Plan | Per month, billed annually | Billed monthly | Update recipients | Data rooms | Users |
|---|---|---|---|---|---|
| Starter | $0 | $0 | 100 | 1 (25 files) | 2 |
| Base | $59 | $69 | 250 | 1 | 3 |
| Core | $129 | $149 | 500 | 3 | Unlimited |
| Growth | $199 | $249 | 1,000 | 5 | Unlimited |
Two things in that table are worth pausing on. The free tier already sends monthly updates to 100 investors and tracks KPIs, which covers a seed-stage cap table completely. And the paid rungs are priced on how many people you send to, not on how much you build, so the bill grows with the size of your investor list rather than the complexity of your reporting.
Visible's four founder plans, captured from the live pricing page on 30 September 2026. Prices shown are the annual rate.
Other portal vendors sell the same shape of product without publishing a comparable number. WeWeb's investor portal page and Softr's both lead with capital calls, document vaults and per-investor views, and both route you to a demo rather than a price. That is the practical argument for pricing the build against a vendor that publishes, then treating the quiet ones as at least that much.
Building with Lovable has two costs that behave differently: credits, which you spend making the app, and the plan, which decides what the finished app is allowed to do.
The credit ladders read on lovable.dev/pricing on 30 September 2026, logged out, were unchanged from every reading this month. Pro starts at 100 credits for $25 a month and runs to 10,000 for $2,250. Business starts at 100 credits for $50 a month and runs to 10,000 for $4,300, with the discount badges beginning at 1,200 credits. Business is roughly twice Pro per credit through the middle of the ladder.
The Business credit ladder, read from the live dropdown on lovable.dev/pricing on 30 September 2026. Third-party blogs still quote a single flat price for this plan.
$600 a year is Lovable Business at the 100-credit entry rung. $2,388 a year is Visible Growth at the annual rate. The gap is real, and it is also not the whole comparison, because the Lovable figure buys you capacity to build rather than a finished product.
Credits are consumed by building, not by having investors read the app. Publishing from the publish dialog is free and works at a zero balance. What does draw credits on an ongoing basis is the built-in backend serving requests and any in-app AI features, so a portal that twelve people open once a month costs very little to run and a portal with live charts recomputed on every load costs more. The full credit mechanics, including the daily build grants and what expires when, are in Lovable credits explained and the Free, Pro and Business comparison.
Build vs buy, first year, portal for 40 investors
| Line | Buy (Visible Base) | Build (Lovable Business) |
|---|---|---|
| Subscription | $708 a year at $59 a month annual | $600 a year at $50 a month |
| Build effort | None | Your own time, plus credits from the monthly allowance |
| Who can open it | Anyone you email, from your own domain | Only the audience you invite, enforced at login |
| Custom fields and charts | The fields the tool offers | Anything you can model |
| Delivery and open tracking | Built in | You build or integrate it |
| Ongoing maintenance | The vendor's problem | Yours |
Read that table honestly. The subscription lines are close enough to be noise. The decision is on the last three rows, and for most founders the delivery and maintenance rows are what make buying the right answer for a first portal.
This is the fact that should sit at the top of every article on this subject and almost never does. On Lovable, restricting who can view a published app requires a Business or Enterprise plan.
The publish documentation is unambiguous about the lower plans. On Free and Pro, anyone with the link can visit your published app, publishing is always external to the web, and you cannot restrict website access on those plans. A portal you build on Pro is a public URL. Obscurity is not access control, and an investor update sitting behind an unguessable address is still published to the open web.
On Business and Enterprise the publish dialog opens a Who can view your site? picker with three options: Public, Workspace (only workspace members, after logging in), and Custom, where you compose the audience from the whole workspace, groups, individual members, and people outside the workspace invited by email. Investors are that last category, which is why a real investor portal built with Lovable is a Business-plan product and not a Pro one.
Website access on Lovable, by plan, 30 September 2026
| Capability | Free | Pro | Business | Enterprise |
|---|---|---|---|---|
| Publish to a live URL | Yes | Yes | Yes | Yes |
| Restrict who can view | No | No | Yes | Yes |
| Workspace-only publishing | No | No | Yes | Yes |
| Custom audience with external email invites | No | No | Yes | Yes |
| Restrict who can publish externally | No | No | No | Yes |
There is a trap on the way back down. If you build the portal on Business, restrict it, then downgrade, the app stays live and the restriction keeps being enforced, but Lovable will not publish changes to an app that is published to a workspace or a custom audience. The publish dialog shows "Publish to workspace requires a Business plan" and the live version stays online. Your portal is frozen at whatever it looked like on the day you downgraded, until you either switch it to public or come back to Business. You can still unpublish on any plan.
The same audience mechanics power client dashboards, which are covered end to end in Lovable for agencies: client dashboards without seat fees. This article is the founder-to-investor case, so the rest of it stays on what makes an investor portal different.
Custom-audience invites are the operational heart of the portal, and the documented limits shape how you run it.
Invites do not expire. That sentence is the single most important operational detail on the page, and it is the one that quietly goes wrong. An investor who exits, a fund partner who moves firms, an advisor whose term ends: all of them keep access until somebody removes them from the audience and publishes. Removal revokes access when the change is applied, so the offboarding step is real and it is one click plus a publish.
Put it in the same calendar reminder as the update itself. Publish day is also offboarding day. If you only ever add people, a portal built in year one is showing your numbers to a list you stopped maintaining in year two.
One small inconsistency worth knowing before you rely on it: on 30 September 2026 the body of the publish page says re-inviting an address sends a fresh email, while the FAQ accordion on the same page says re-inviting does not send duplicate emails. Test it with your own address before you re-invite a whole list, and treat the behaviour as unsettled until Lovable reconciles the two.
The reason founders dread the monthly update is that they redesign it every month. Fix the schema once and the update takes thirty minutes.
Six fields, every month, in this order
| Field | What it is | Where it comes from |
|---|---|---|
| Cash | Bank balance at the last day of the month | Bank statement, not the ledger |
| Net burn | Cash out minus cash in, for the month | Bank movement, not the P&L |
| Runway | Cash divided by the burn figure you name | Computed, and you must say which burn |
| MRR | Recurring revenue at month end | Your billing system, reconciled |
| Headcount | People on the payroll at month end | Payroll, with open roles listed separately |
| The ask | One thing, with a name or a deadline attached | You |
Work the runway once and the ambiguity becomes obvious. Suppose cash at month end is $840,000 and the month's net burn is $112,000 out against $42,000 in, so $70,000. Runway is 840,000 divided by 70,000, which is 12.0 months.
Now suppose the last three months were $62,000, $70,000 and $78,000. The trailing three-month average is still $70,000, so the average still gives 12.0 months. Divide by the latest month instead and you get 10.8 months. Same company, same cash, a difference of more than a month, decided entirely by which burn you picked.
Name the method in the field label, not the footnote. "Runway, on trailing 3-month average net burn" is a column heading that never has to be explained again, and it is the kind of thing a built portal can enforce and a typed update cannot.
On MRR, the number that causes arguments is the one that does not match the payment processor's dashboard, usually because of proration, refunds, annual plans recognised monthly, or failed payments still counted as active. If your portal computes MRR, compute it once and show the reconciliation to the processor's figure next to it. The integration side of that is covered in the Lovable and Stripe finance dashboard guide.
Headcount deserves one line of discipline too: report people on payroll at month end, and list open roles separately. A headcount number that silently includes contractors and offers-out is the fastest way to lose a board's trust in every other number on the page.
There is a security benefit to the Business gate that has nothing to do with logins. Apps that are not publicly visible do not get an automatic social sharing image, and a login-gated page has nothing for a crawler to index. A public URL with an obscure address does: it can be discovered through a referrer, a link in an email that passes through a scanner, or a browser extension, and once it is indexed the numbers are searchable.
For a portal carrying cash, burn and revenue before they are public, that is the difference between a private document and a published one. It is also the reason to resist the temptation to put a portal on Pro with a hard-to-guess URL and tell yourself it is fine.
The broader picture of what Lovable does and does not attest to, and what stays your responsibility in the app you build, is in Is Lovable safe for financial data. Read it before you decide where the portal's database lives.
A portal for existing investors and a page for prospective ones are different documents with different risk. Keep the raise in the channel your counsel approves, and keep the portal to reporting on what has already happened.
Projections, target valuations and "on track to" language turn a report into a promise. If the board pack needs a forecast, that is a board pack. Your reporting duties vary by jurisdiction and by what your documents say, so send the question to your own counsel rather than copying a template.
Pipelines, prospect lists and deck analytics are a separate product, and they are the part the buy-side tools are genuinely good at. A portal that tries to be both takes four times as long and is worse at each.
Covered above and worth repeating because it is invisible until it is not. Invites do not expire. Removal is manual, and it only takes effect on the next publish.
If the portal was built on Pro, the first publish is public. There is no setting to fix that on Pro. Check the plan before you build, not after.
Changes are not pushed to the live app automatically. A dot on the Publish button marks undeployed changes, and an update you wrote but did not publish is an update your investors did not receive.
If the decision came out on build, the sequence below is the shortest honest path. It assumes a Business workspace, because of the plan gate above.
Six fields, one row per month, one document list, one ask. Decide which burn the runway divides by. Ten minutes here saves a rebuild.
Describe the records and the rules, not the colours. The prompt in the screenshot above is the shape to copy: what each update records, who signs in, and what they can see.
Set the audience while the app is empty. It removes the window where a real update is sitting on a public URL, and it surfaces any workspace restriction on external invites before you have investors waiting.
Ten per publish is the documented limit. Batch them, publish, confirm the first arrivals can sign in, then batch the next ten.
One recurring calendar entry: write the update, remove anyone who left, publish. The removal only applies on publish, so the order matters.
If you would rather not run this yourself, the Lovable Expert directory lists certified partners who build exactly this kind of internal app, including TJ Alam's profile.
A private, login-gated page where existing investors read your periodic update, see the underlying numbers and download documents. It is reporting, not fundraising, and it is separate from a data room used for diligence.
You can build one by describing it, using an AI app builder, and that is what this article prices. What you cannot skip is the plan decision: on Lovable, restricting who can open the published app needs a Business or Enterprise plan, so a portal built on a lower plan is a public web page.
Cash, net burn, runway with the method named, recurring revenue, headcount and one ask. Same fields, same order, every month. Consistency is worth more than completeness, because it is what lets a reader see the trend without asking.
A login-gated portal keeps the page out of search results and out of anyone's hands who was not invited, which a public URL cannot do however obscure it is. Whether the app itself is built safely is a separate question, and it is the one that actually decides your exposure.
Published founder pricing on 30 September 2026 ran from $0 for a free tier sending to 100 investors, to $199 a month billed annually for 1,000 recipients and five data rooms. Vendors that do not publish a price route you to a demo instead.
For diligence during a raise, usually yes, and that is a different access list with different expiry behaviour. A reporting portal is for people who already invested; a data room is for people deciding whether to.
The ship's log again: investors are not reading your portal for the prose. They are reading the same six columns in the same order, checking whether the line moved the way you said it would last month. Build or buy whichever gets those six columns in front of them on the same day every month, and stop optimising the rest.
If you are weighing the platform itself rather than this one use case, the full assessment is in Is Lovable worth it: a 2026 review for founders, and the internal-tool sibling to this article is building an expense approval app. For workspace roles and per-member controls, see Lovable team workspaces for a finance team.
Ready to build one? The audience controls this article depends on start on the Business plan, which you can compare on Lovable's pricing page. If you would rather have a certified Expert build and hand it over, the Lovable partner directory listing is the place to start.
TJ Alam is a certified Lovable Expert (Website Builder track) and the founder of Digi Flock Enterprises. He built tjalam.com and cyberdance.in with Lovable, and writes about building finance and internal tools for MoneyFlock.
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.