July 13, 2026 · Handbook

The BuildMidas handbook: a map of the platform

This article describes the product at publication. See AI Builder and Agent Teams for current capabilities.

Let me walk you through one actual account, start to finish, instead of describing the sidebar item by item. Say it's a freelancer, first week on the platform, building a habit-tracking app for a small client. This is what happens to that build as it moves through the dashboard, in the order it actually happens — and where each stop either helped or wasted five minutes.

The prompt

They open AI Builder and type something close to "build me a habit tracker." That's a reasonable first sentence and a bad final prompt. What comes back isn't code — it's a plan, written in plain language, and if you stop reading at "looks fine" and click approve, you get something technically responsive to the words "habit tracker" and generic in every way that matters. The freelancer's client wanted no social features, local storage only, dark mode by default. None of that was in the first prompt. It goes into the plan instead, as three edits before approval: strike the "share your streak" feature the plan invented on its own, swap the storage line, flip the default theme. Thirty seconds of editing. The build that comes out the other side matches the brief instead of matching the word "habit tracker."

The plan step people skip

I've watched this exact moment go wrong for other users — approve the first plan without reading it, get three iterations deep, and start re-explaining constraints that should've been set at the plan stage. The plan step exists precisely so you don't do that. It costs almost nothing and it's the only point in the loop where you're negotiating with the agent in your language instead of debugging its output in code.

Where the build actually lands

Once it generates, the habit tracker shows up as a card in My Builds — the library page, filterable by type, and the one page this freelancer will open more than any other by week three once there are five or six builds stacked up. It doesn't show up in Showcase; that page is curated, not automatic, and a client build sitting there unpublicized is the correct default. It also doesn't show up in Templates unless the freelancer thinks to save it as one — worth doing here, actually, since a habit tracker skeleton is exactly the kind of thing a freelancer rebuilds for the next client with different branding. Most people don't discover "save as template" until build number six, wishing they'd done it on build number one.

Published, or something heavier

Now the distribution question. Three real options, not one option with three names. Published gives a free subdomain, live in seconds, zero setup — the right call while the client is still reviewing and might ask for a redesign. Domain Management is for when the client's own domain is ready to point at it, and that step does double duty: connecting a domain here isn't just a URL change, it's also what makes the analytics pages further down the sidebar have anything to attach to. Deploy, under settings, is the SFTP path for when the client insists the build live on infrastructure they control — more setup, and the freelancer owns none of the uptime story anymore, which is a real trade worth having explicitly rather than discovering by accident.

For this build, Published first. Moving from subdomain to custom domain later is a non-event. Undoing a custom-domain deploy on a client project that gets cancelled is more cleanup than it's worth — and the freelancer has, in fact, been burned by exactly that on an earlier project, which is the whole reason for the "default to Published" habit.

The app-store detour

This particular client also wanted an app-store listing, so the build goes through Shipped instead of stopping at Published — a page that exists because store review is asynchronous in a way web deploys just aren't. Submit to one store and it sits for two days; submit to another and it clears in twenty minutes. Shipped is where you track that without five browser tabs open to five different store consoles, each with its own login and its own status vocabulary.

The empty page nobody warned them about

A week after the domain connects, the freelancer opens Search Performance to check on it. Empty. Slightly sad-looking, in fact — no chart, no number, just a connect-an-account prompt. That's not broken, it's honest: there's no data yet, because Search Performance, Google Analytics, and Store Analytics all key off the Google account connection under settings, and none of them backfill. Sync runs from the moment you connect, forward only. Connect the domain on day one and you have a week of history by week two; connect it on day ten because you forgot, and you're starting from zero on day ten. The freelancer had connected the domain but not the Google account — two separate steps that look like they should be one.

The part that actually costs something here isn't the missing chart. It's that the optimization agents read from this same data, and an agent asked to improve a page's ranking with zero Search Performance history behind it is working from general best practice instead of this site's actual numbers. Skipping the connection doesn't just leave a dashboard page blank — it caps what the agents can do.

The brief that shows up unasked

Two weeks in, a card appears in Discovery: an opportunity brief flagging a content gap on the client's site, with a Build-this button attached. Genuinely useful when it lands on something you'd act on anyway. But Discovery leans toward volume over precision by design — more briefs than anyone acts on — so the right posture is a suggestions inbox, not a queue to clear. The freelancer skims it every few days and ignores most of it, which is the intended use, not a failure to keep up.

The settings that should've happened on day one

By this point the freelancer has touched four settings pages without ever opening the settings menu on purpose — each one discovered because something else was blank.

PageWhat it turned out to gate
Google AccountsSearch Performance, Google Analytics, and the agents' grounding data — one connection, three surfaces
DeploySFTP targets, only needed for the client-controlled-server path
AI mediaImage generation defaults used inside builds
Plans & CreditsUsage allowance, credit packs, receipts

Google Accounts is the one worth front-loading. It's a single connection point behind three separate dashboard surfaces, and finding that out the hard way — three different empty pages, three different moments of "oh, I need to connect something" — is the exact friction a five-minute setup pass on day one avoids.

The two things that were there the whole time

The floating Ask-AI button sat on every one of these pages the entire time, and it isn't a scoped-down FAQ bot — it can connect an account, kick off a build, or explain why a page is blank, on your behalf. The freelancer's client, non-English-speaking, needed the whole interface in a different language for a review call; the globe in the nav switches all twenty, mid-session, without losing the build in progress. Neither of these needed to be discovered through trial the way everything else in this walkthrough did. They were just there.

The order that works: build something small first, before reading a map like this one. Every page above is a concept until it has your own data in it.

That's the honest summary of this whole account's first two weeks — not "read the docs, then build," but the reverse. My Builds was an abstraction until there was a card in it. Search Performance was an empty state until a domain fed it. Reading the floor plan before the first build is fine background, but the floor plan only makes sense once there's a real habit tracker sitting somewhere in it.

Handbook
ShareXLinkedInFacebookRedditQuoraWhatsAppTelegramEmail
← All posts