The brief was simple: invite clients, show project updates, protect internal notes, and make the product look polished enough to hand off. The real question was which tool kept working once roles, private data, and admin surfaces showed up.
Report signals
Quick Answer
Built the same client portal in Cursor, Lovable, Bolt, and Replit. The UI was easy. Permissions were the project.
Client portals expose the same truth repeatedly: private data and permission logic decide whether the app is real, not the UI. The hard part was never the dashboard UI. It was making sure clients could only see their data, internal notes stayed private, and admin routes stopped behaving like temporary shortcuts. Every fast build path hid that work until the product looked deceptively close to launch.
What shipped fast
Lovable was the best first step because the portal needed data, auth, and a client-facing shell immediately. Cursor became the best second step because role checks, private records, and long-term code ownership mattered more than speed once the portal had to survive real client use.
What broke
The hard part was never the dashboard UI. It was making sure clients could only see their data, internal notes stayed private, and admin routes stopped behaving like temporary shortcuts. Every fast build path hid that work until the product looked deceptively close to launch.
What they would do differently
I would define permissions and ownership rules before I let the generated stack feel finished. The visible app gets built quickly. The invisible trust layer does not.
Related failure modes
Why builders get stuck at auth and databases
The real reasons auth, RLS, schema design, and database assumptions stall AI-built products.
Read the failure mode ->
Why Stripe, subscriptions, and webhooks break so many AI-built apps
The core failure modes around checkout, webhook drift, stale access state, and subscription logic.
Read the failure mode ->
Why builders get stuck at deployment
Why apps that work locally fall apart at domains, env vars, hosting, and production setup.
Read the failure mode ->
Learn the workflow
A Landing Page
The hard part is not the layout. It is knowing what promise the page makes, who it is for, and why someone should trust it enough to click.
Read the workflow ->
A Newsletter
The hard part is not the signup form. It is deciding what the newsletter is actually about, what angle it owns, and what makes it worth opening next week too.
Read the workflow ->
A Blog
The hard part is not the page shell. It is creating content that is sharper than the average AI sludge and structuring it so search and humans can both trust it.
Read the workflow ->
More real builds
The project was an internal operations tool with forms, filters, team-only actions, and a few admin automations. It looked like a straightforward CRUD build until edge cases, permission scope, and deployment friction started showing up.
What shipped fast
Replit was more useful than expected because internal tools often live in a messy middle: more code than a pure builder ...
What broke
The workflow got ugly in exactly the way internal tools usually do: exceptions, permissions, stale states, and operations logic th...
Verdict: For internal tooling, the right stack depends less on polish and more on how quickly the workflow becomes exception-heavy.
Read the full build report ->
The test project was the same every time: waitlist, auth, paid plan, gated dashboard, and a small admin surface. The goal was to see which tool stayed useful once money, access, and state drift entered the build.
What shipped fast
Lovable was strongest when the job was full-stack momentum without owning every engineering detail yet. Bolt was useful ...
What broke
Every version looked closer to done than it really was until Stripe and access state got involved. The same project exposed the re...
Verdict: The same app test made the tradeoff obvious: Lovable for fastest credible MVP, Cursor for the version I would trust with money.
Read the full build report ->
A founder had a Lovable-built SaaS MVP that looked launch-ready until subscription state, user roles, and protected screens started drifting out of sync.
What shipped fast
Lovable got the shell and product flow live quickly. Cursor was useful once the team needed to inspect the real auth, bi...
What broke
The handoff exposed how much hidden state the team had not modeled clearly. Stripe looked connected, auth looked connected, but pr...
Verdict: Fast MVP plus code-first hardening is a valid path. Pretending the first pass is launch-safe is where teams get hurt.
Read the full build report ->