Building a customer portal with Emergent: a real walkthrough

This page may contain affiliate links from which Blur Studio earns commissions.

What is Emergent AI?

Emergent is an AI app builder: you describe an app in a chat window, in plain language, and it writes the frontend, backend and hosting for a working version. A customer portal, a place where your actual customers log in to see their own information, submit a request, or check the status of something, is a more demanding build than a purely internal tool, because it involves people outside your own team and, usually, information you're responsible for protecting.

Step 1: write the prompt plan before you start

Write down, specifically:

• What a customer can see and do once logged in (for example: view their order history, update their contact details, upload a document).
• What they explicitly should not be able to see, including other customers' information.
• How a customer gets an account in the first place (self-signup, or an account you create for them).
• Whether the portal needs to take payments, which raises the stakes considerably and usually means a developer should be involved regardless of how the rest of the build goes.

The "what they should not be able to see" line matters more here than on any internal tool, because it's the exact kind of rule an AI builder can get subtly wrong without you noticing until a customer does.

Step 2: build the first version

Describe the portal to Emergent using your plan, including the login requirement explicitly rather than assuming it's implied. Emergent will build the login flow, the customer-facing screens and the backend data storage together. This is where Emergent's "one-click LLM integration," the ability to switch which underlying AI model handles the build, can be worth trying if the first pass handles the login logic in a way you're not confident about: a different model sometimes approaches the same request differently.

Step 3: what the AI genuinely handles well

• The visible screens and flow: a clean dashboard layout, forms, and basic navigation are squarely inside what a chat-driven builder does well.
• Getting a first version live fast: you'll have something clickable to react to far faster than scoping out a traditional development project.
• Basic data display: showing a customer their own order history or submitted requests, once the data structure is right, is a straightforward task for the AI.

Step 4: what genuinely needs a developer before launch

A few things are worth a second set of eyes before real customers touch the portal, not because Emergent is uniquely bad at them, but because every AI builder in this category has the same structural risk: the AI is writing its own security rules, and it doesn't always get them right the first time.

• Access rules between customer accounts: confirm, deliberately, that one customer genuinely cannot see another customer's data, not just that the interface doesn't show a link to it. This exact category of flaw, weak data-access rules in AI-built apps, has been the subject of a real, published security disclosure against a competing AI builder in this category, which is the reason this check belongs on every launch checklist, not just Emergent's.
• Payments: if the portal handles any payment, failed cards, refunds and billing logic need a developer's review, since getting this wrong has real financial and legal consequences beyond a bug.
• What happens to existing data if you ask for a big change later: a chat-driven AI agent making a large structural change can behave unpredictably with existing data. Keep a backup of anything real customers have already entered before asking for a major change.

A short security checklist before customers log in

• Log in as two different test customer accounts and confirm neither can see the other's information, by actually trying, not just by assuming the interface prevents it.
• Confirm private project hosting is enabled (a Standard-plan feature and up), so the portal isn't publicly discoverable before you're ready.
• If the portal handles payments or sensitive personal data, have a developer review the access logic specifically, even if everything else about the build looks fine.
• Keep a copy of the code through GitHub integration (Standard plan and up), so you have a fallback outside the platform if something goes wrong later. My guide on where Emergent hosts your app and how to move it explains the options.

Deciding how customers actually get an account

This is worth deciding deliberately rather than letting the AI default to whatever it assumes. Self-signup, where anyone can create an account, is faster to set up but means you need to think through what happens with an account that was never meant to exist, a competitor poking around, or someone signing up with no real relationship to your business. An account you create for the customer yourself, with an invite link or a code you hand them, is slower to set up but gives you direct control over exactly who gets in, which is often the safer default for a portal tied to an existing paying relationship rather than open to the public. Say which approach you want explicitly in your prompt, since an AI builder left to guess will often default to open self-signup simply because it's the more common pattern across the apps it was likely trained on.

A worked example: testing the access rule yourself before launch

Here's a concrete version of the access-rule check mentioned above, since "test that customers can't see each other's data" is easy to agree with and easy to skip in practice. Create two test customer accounts, call them Customer A and Customer B, with clearly different sample data in each (different order histories, different uploaded documents, whatever your portal actually stores). Log in as Customer A, note exactly what you see. Log out, log in as Customer B, and deliberately try to reach Customer A's information, by changing a URL, trying an old link, or using any direct route you can think of, not just by clicking through the normal interface. If Customer B can see anything belonging to Customer A through any route, that's a access-rule flaw that needs fixing before a single real customer logs in, regardless of how well the rest of the portal looks and behaves.

When to call in a developer from the start, not just at the end

If the portal will handle payments, health information, financial records, or any data you're legally responsible for protecting, it's worth having a developer review the plan before you even start prompting, not just at the end. For a straightforward portal with light data and no payments, building in Emergent first and getting a focused security review before launch is a reasonable, genuinely common approach. Emergent for finance and regulated work lists what to check first.