GoHighLevel Client App Builder: Full Setup in 5 Minutes

GoHighLevel just dropped the Client App Builder, so you can describe your business and AI builds a full client portal for your customers.

Client App Builder is a Labs AI app builder that turns one prompt into a Web or Mobile customer portal, with setup questions, a design system, device previews, chat edits and a Publish checklist for unfinished pages. This guide is the written version of the Faceless GHL tour 👇

New to the product? Start with What Is GoHighLevel or the Explained tour. Pairing portals with automations? See Workflow Maps. Shipping AI chat next? Read Conversation AI Build Agents and Flow Builder V2.

TL;DR: Client App Builder

• Enable: Settings → Labs → Client App Builder, then Control K → Client App Builder.
• Prompt: describe the business and what customers should do (bookings, invoices, files).
• Lock-in: pick Web or Mobile once, you cannot change it later.
• Build: answer questions, pick a design system, wait for generate (about fifteen minutes in the demo).
• Before go-live: chat-edit pages, Build unfinished Publish items, connect a calendar, check phone numbers, and remember the five-app limit.

What Client App Builder does

Client App Builder sits in Labs. You describe the business and what customers should be able to do. HighLevel then generates a portal with pages, navigation and working flows such as booking, instead of you designing every screen by hand.

It is not a replacement for your CRM, calendars or funnels. It is a customer-facing shell that sits on top of those systems. Booking still needs a calendar. Invoices and files still need the data behind them. The builder speeds up the portal UI, it does not invent a finished operations team.

Turn this into a system you can sell. Watch the free masterclass for the agency method, or get free access to the community through Greg's GoHighLevel link.

Cloning finished assets across accounts still pairs with the Snapshots tutorial. Client App Builder creates the portal experience; snapshots move packs of assets between sub accounts when you are ready to repeat the setup.

Think of three layers. The CRM holds contacts, pipelines and calendars. Client App Builder builds the customer-facing shell those people log into. Snapshots and Agency Build help you repeat the stack for the next client without redrawing every page from memory. Mixing those layers up is how teams ship a pretty portal with no booking calendar behind it.

The builder also sits beside, not instead of, Conversation AI. A portal is where customers manage bookings and paperwork. An agent is where they chat or get followed up. Many agencies will want both, but you should finish one Labs path cleanly before you open the next.

Who this is for

Agencies selling client portals

Home services, clinics and trade businesses often want bookings, quotes, invoices and paperwork in one login. Client App Builder is aimed at that brief when you would rather prompt than hire a developer for version one.

Operators tired of funnel-only customer experiences

Funnels win leads. Portals keep customers after the sale. If your HighLevel stack stops at forms and pipelines, this Labs tool is how you add a customer home without leaving the platform.

Teams testing Labs early

In the demo the Labs card said live in fifty six days, you are getting in early. That means rough edges, long first builds and limits such as five apps per sub account. Early testers who read the Publish warnings carefully will have a better week than people who hit Publish on day one.

If your next job is AI chat on the phone or website, keep Conversation AI and Flow Builder V2 in the plan after the portal shell exists. Portals and agents solve different moments of the customer journey.

Niche operators with repeat paperwork

Warranties, estimates and shared files show up in almost every trade portal brief. If your customers keep asking for the same PDFs and booking links by text, Client App Builder is a candidate for that self-serve layer, as long as you verify the AI-filled phone numbers and hours before go-live.

Skip it for now if you only need a one-page funnel and a calendar link. The Labs tool earns its wait time when customers return after the sale, not when you only need a lead form.

Watch the walkthrough

Prefer to watch first? The Labs → prompt → Web/Mobile → design system → device preview → chat edit → tips tour is below, recorded in a Northline Plumbing demo sub account.

• 0:00 GoHighLevel Client App Builder is here
• 0:09 What it does and the plan
• 0:26 Switch it on in Labs
• 0:45 One prompt for a client portal
• 1:04 Web or Mobile and the setup questions
• 1:30 Pick a look and build the app
• 1:48 The finished portal on desktop, phone and tablet
• 2:22 Make a change in the chat
• 2:50 Tips before you go live
• 3:20 More GoHighLevel updates

The plan

The reason for this walkthrough is simple: Client App Builder only landed in Labs a few days before the video, and it feels like having a developer build your client portal from one prompt.

The plan in the video is short. Switch it on, build a customer portal, check it on a phone, make a change, then finish with tips so you do not get caught out. This article follows that same order so you can pause any chapter and read the matching section.

Switch it on in Labs

Open a demo sub account (a plumbing company in the tour). Go to Settings → Labs and find the Client App Builder card. Switch it on.

The card in the demo said live in fifty six days, so you are early. After the switch, the quickest path in is search: hit Control K, type app builder, and click Client App Builder.

If search does not show it, confirm the Labs toggle is on for that location and refresh. Client App Builder is not a buried submenu item you should hunt for ten minutes, Control K is the intended shortcut once Labs is enabled.

Agency tip: decide who is allowed to burn app slots. Five apps per sub account sounds generous until three people each spin up a test portal and delete nothing. Set a naming rule before the first prompt.

A simple naming pattern helps: niche + purpose + date, such as Northline Portal Web 2026-11. When someone later asks which app is safe to delete, the name answers the question. Remember deletes are permanent in the guidance from the tour, treat slots like limited licences.

Also decide whether Labs stays on for every sub account or only sandboxes. Early features change. Keeping experiments in a demo location protects live client portals while you learn Publish warnings and build times.

One prompt for a client portal

In the middle of the builder you get the prompt box. This is where you describe your business and what customers should be able to do. Underneath are example prompts such as Client portal, but the useful path is your own brief.

In the demo Greg pasted a portal for Northline Plumbing and Heating with bookings, invoices, estimates and boiler warranties, then hit the arrow.

Write the prompt like a customer wish list: who the business is, what logged-in customers need to do, and which documents or bookings matter. Vague prompts produce vague portals.

Include niche nouns. Boiler warranties, service plans and winter tips tell the builder more than “make a nice portal.” Trade names and product lines help the generated sections match what your customers already expect.

You do not need perfect prose. You do need clear jobs: book a visit, see invoices, approve estimates, download paperwork. Those verbs become the pages and buttons the builder proposes.

Paste the prompt in plain language, then reread it once for missing verbs. If you mention boiler warranties but never say customers should view or download them, the builder may underplay that section. If you want approvals on estimates, say approve, not just “show quotes.”

Keep brand colour sermons out of the first prompt. Design systems handle fonts and shapes on the next screen. The prompt’s job is business + customer jobs. Style comes after Continue.

Web or Mobile and the setup questions

The first choice after the prompt is a big one: Web or Mobile. In the walkthrough you cannot change it later. Greg leaves it on Web and keeps Describe it so every page is designed from the prompt, then clicks Continue.

Next come setup questions. The builder already ticked Appointments, Invoices, Estimates and Shared files from the Northline prompt, that auto-tick is the clever bit. For booking, pick how customers choose a slot (date and time in the demo). For custom objects, answer carefully: yes saves new data in your CRM. Greg said no for now to keep the first build simpler.

If you know you need new CRM objects for warranties or equipment records, say yes and plan the fields. If you are only testing the UI, say no and add objects later when the portal shape is proven.

Web vs Mobile is the decision people rush. Mobile makes sense when the product is meant to feel like an installed app experience later. Web fits most agency client portals today, especially while App Store publishing is not available. If your customers mainly open links from SMS and email on a phone browser, Web plus a serious phone preview is usually enough for version one.

The auto-ticked features are a gift and a trap. A gift because the builder listened to your prompt. A trap if you leave tickets you cannot support yet, such as invoices with no invoice data. Untick anything you cannot back with real HighLevel setup before Publish.

Pick a look and build the app

Then you choose your look. Each design system sets fonts, colours and shapes. The builder marked Groundwork as the best fit in the demo, so Greg kept that and clicked Build my app.

Be honest about time: the generate step took about fifteen minutes in the recording. That is why the video skips ahead. Do not schedule a client screen-share that assumes a thirty-second magic trick.

While it builds, use the wait productively. Connect the calendar you will need for booking. Draft the real phone number and opening hours you will verify later. Skim the Explained tour if someone on your team still mixes up sub account menus.

When the build finishes you get a summary of what it built on the left and a working preview on the right. That split view is your QA surface, not a screenshot gallery.

Groundwork was marked best fit in the demo, but you can still browse the other design systems before you commit. Pick the one that matches the client’s real brand closest, then stop fiddling. You can chat-edit content later; you cannot undo a fifteen-minute generate by swapping themes every two minutes.

If a build fails or stalls past your patience, note the time and retry once. Do not open three parallel apps “just to see.” That is how the five-app cap disappears before you have a portal worth publishing.

The finished portal on desktop, phone and tablet

In the Northline preview you could see a welcome section, a Book a visit button, quotes waiting for approval, invoices and paperwork. Clicking Book a visit opened a proper booking page.

Across the top you can flip between desktop, phone and tablet. Check the phone view before you celebrate. Customer portals live on phones more than agency offices do.

Walk the happy path yourself: land on Overview, open booking, peek at invoices or paperwork sections, then return. If a button leads nowhere or a section is empty, note it for chat edits or the Publish Build list later, do not assume the first generate is final.

Device switching is also where you catch overflow text, stacked buttons and forms that looked fine on desktop. Spend two minutes on phone and tablet even if the desktop preview looks polished.

Click through Book a visit on the phone preview the way a customer would with one thumb. If the booking page says to ring the office, that is your calendar reminder, not a copy bug. Fix the calendar, then retest before you rewrite the button label.

Quotes waiting for approval and paperwork sections should show the empty states you expect in a demo. Empty is fine in a sandbox. Misleading sample phone numbers are not fine once a real customer can see them, that is why the tips section insists you check AI-filled details.

Make a change in the chat

Edits are conversational. Type what you want in the chat. In the demo: add a Boiler care tips section to the Overview page with three short winter tips. That refine took about three minutes.

After the wait, Overview showed three tips and a button to book a boiler service. You can also click Visual edits, select one thing on the page, and ask for a change to just that bit when you do not want a whole-page rewrite.

Good chat prompts are specific: which page, what section, how many items, and what the button should do. Bad chat prompts are “make it nicer.” The builder already chose a design system, tell it the content job.

Visual edits help when one card or headline is wrong but the rest of the page is fine. Select the target, describe the change, and keep the rest of the layout stable. That is faster than regenerating the whole Overview for a single line.

Tips before you go live

1. Build the pages Publish flags

When you hit Publish it warns you about pages that are not built yet. In the demo that included Invoices, Documents and Account settings. Click Build on each one before customers log in.

2. Check the details AI fills in

The AI fills in details such as phone numbers and opening hours. Verify them against the real business before a customer sees the portal. Placeholder contact data is how early Labs demos embarrass live accounts.

3. Connect a calendar for booking

Online booking needs a calendar behind it. Otherwise the page tells the customer to give the office a ring. Connect the calendar, then retest Book a visit on phone and desktop.

4. App stores, five apps, permanent deletes

Can you put this in the app stores? Not yet. You also get five apps per sub account, and deleting one is permanent, do not burn through slots testing. Name apps clearly and delete only when you are sure.

For a feature a few days old, the first prompt result is impressive. Treat go-live as a checklist, not a vibe. Publish warnings, calendar, contact details and the five-app limit are the parts that catch people out.

After the portal is stable, clone supporting assets with snapshots if you need the same pipelines and calendars in the next client sub account. Keep Workflow Maps handy when automations start attaching to portal events.

Write your go-live checklist somewhere your team will actually see it: Labs on, Web/Mobile chosen on purpose, calendar connected, Publish Build items cleared, phone/hours verified, app named, slot count checked. Client App Builder is impressive from one prompt, go-live is still an operations job.

Turn this into a system you can sell. Watch the free masterclass for the agency method, or get free access to the community through Greg's GoHighLevel link.

Pros and Cons

FAQs

Verdict

Client App Builder is the Labs path to a customer portal when you can describe the business clearly and accept an early-feature checklist. Prompt carefully, lock Web or Mobile on purpose, wait out the first build, preview on a phone, chat in the missing sections, then Publish only after unfinished pages, calendar and contact details are fixed.

Turn this into a system you can sell. Watch the free masterclass for the agency method, or get free access to the community through Greg's GoHighLevel link.

Practical week plan: day one enable Labs and paste a niche prompt. Day two connect calendars and fix Publish Build items. Day three chat-edit Overview content and recheck phone layout. Day four document the prompt and naming rules for your team. That beats burning all five app slots on Friday experiments.

Turn this into a system you can sell. Watch the free masterclass for the agency method, or get free access to the community through Greg's GoHighLevel link.

More from the Faceless GHL series lives on YouTube. This page tracks video 10 (Client App Builder). HighLevel® is a registered trademark of its owner. This site is not affiliated with or endorsed by HighLevel.