Lovable: A Client Status Page From One Prompt, and the Wrong-Name Test Most Vibe-Coded Portals Skip

In tax season, a small bookkeeping firm gets the same phone call over and over: where is my return, and what do you still need from me?

Say it's 12 calls a week at 6 minutes each. That's 1.2 hours a week, or about 17 hours over a season, spent reading out a status that could sit on a page. (Those are example numbers. Count your own calls for a week and swap them in.)

A page where clients look up their own status is a simple customer portal. Before anyone pays a developer for one, it's worth building a demo in an AI app builder and showing it to the team. Here's how that went in Lovable, with the exact prompt and what came back. The build used 1 credit.

The prompt

This is word for word what went into the Lovable home screen. Brightside Bookkeeping and its clients are made up:

Build a client status page for Brightside Bookkeeping, a small tax and bookkeeping firm. Clients type their client code and last name and see where their 2025 tax return is: Documents received, In preparation, Review, Ready to sign. Show the current stage as a progress bar, what we still need from them, and who to call. Sample clients for this demo: BB-1042 Ortiz (In preparation, still need the 1099-INT from their bank), BB-1077 Chen (Ready to sign, nothing missing), BB-1103 Walsh (Documents received, still need last year's return). If the code and name do not match, say: We could not find that client code. Call us at (555) 010-2040. Clean and friendly, teal and white. No logins and no database: this is a demo with sample data only.

What it spells out:

1. The stages, in order, so the progress bar has something to show.
2. What the client types (code and last name) and what they see (stage, missing items, who to call).
3. Three sample clients, each in a different stage, so you can test more than one case.
4. The exact sentence for a failed lookup, with the next step.
5. The limit: no logins, no database, a demo with sample data only.

Item 4 is the one people leave out. If you don't say what happens when nothing matches, the AI picks its own wording, and it may show too much.

What came back

The preview was ready in about a minute and a half. Lovable listed the three sample clients in its reply, noted that capital letters don't matter in the code or name, and suggested testing a right name and then a wrong one.

The right lookup, code BB-1042 with last name Ortiz:

Current stage In preparation on a four-stage bar, 1099-INT from your bank under "What we still need", and the number to call.

The test most people skip

Every portal needs two tests:

• The right person sees their record.
• The wrong person sees nothing.

The second one protects your clients, and it's the one people forget. Same code, BB-1042, but last name Smith:

Nothing about Ortiz. Just the sentence from the prompt: We could not find that client code. Call us at (555) 010-2040.

The lesson ran the prompt twice (once while capturing the screens, once again as a learner) and got the same result both times. The only difference was the button label, "Check status" one time and "Check my status" the other. After that, try a blank box and a lower-case code. Anything odd, you fix by chat.

Why this demo is not a portal yet

The prompt said "no logins and no database", so Lovable did the simplest thing: it wrote the three clients into the page code itself (src/lib/clients.ts).

That's fine for showing the idea to the partners with made-up names. It is never fine for real clients, because anything in the page code is downloaded by every visitor, whether the screen shows it or not. Someone who opens the browser's developer tools can read every record. A code plus a surname isn't much of a lock either.

Lovable's built-in security scan reported no issues on this project. That's not a contradiction. A scan looks for known mistakes like exposed keys or open database tables. It can't know your client list was meant to be private.

Before real data goes in, a real version needs three things together:

1. Logins, so the app knows who someone is.
2. A database, so the records live off the page.
3. Row-level security, the rule that lets each client read only their own rows. Logins without it still let any logged-in client read everyone's records.

The next lesson in the course does those checks in the same project, without publishing or spending a credit: who can open the app, where the data lives, and what a safe version would cost.

What one prompt is good for

A working demo for 1 credit is a cheap way to answer "is this worth building?" before you spend real money. Show it to the team, count how many calls it would save, and then decide whether to buy a client portal, build the safe version, or drop the idea.

Practice it step by step

The lesson, Lovable: Cut "Where's My Return?" Calls with a Status Page, walks through every screen above in the real Lovable app: the prompt, the right lookup and the wrong one. It's module 9 of the free Vibe Coding for Business course. Module 10, Check Logins, Data and Cost Before You Share an App, does the safety checks. There's also a one-page vibe coding cheat sheet.

Practice it step by step, free: https://learn.ynteractive.com/content/lovable-client-status-portal