AI website builder for agencies and studios
Agencies do not need another tool that produces something almost good enough. What they need is to compress the least valuable part of the process, the stretch between an approved direction and a working front end, without giving up ownership of the output.
Siteglade generates real projects: a codebase you read and edit in a file explorer and a Monaco editor beside the live preview, exportable to your own GitHub repository on Pro and Max. That makes it usable inside a normal agency workflow rather than a walled garden you have to escape from at handover.
This page is about where it fits, where it does not, and how to prompt on behalf of a client whose taste is not your own.
Where an AI builder fits into agency work
The honest framing is that this replaces a specific slice of work, not a discipline. Strategy, positioning, art direction, copy, and the judgement about what a client actually needs are unaffected. What changes is how quickly a direction becomes something clickable.
Three points in the process benefit most. The pitch, where a working prototype changes the conversation. The early build, where a generated structure gives your developers something to refine rather than scaffold. And the long tail of small sites, campaign pages, event microsites, one-page launches, where the fee never justified the setup cost.
It also changes who can do what. A strategist or a designer can produce a working page without booking developer time, which means fewer blocked afternoons and fewer half-finished ideas that died waiting for capacity.
- Pitch prototypes instead of flat mockups.
- Structure and component scaffolding for a build your team then refines.
- Small-fee work that was previously not worth quoting for.
- Internal tools and one-off pages that never reach the top of the queue.
Pitching with a working prototype instead of a mockup
A static comp asks a client to imagine. A working page asks them to react. The second conversation is far more productive, and it moves the decision away from whether they like a colour toward whether the structure serves the business.
Practically: build two directions rather than one, generate each from a distinct prompt, and share both. Every project can be shared through a tokenized preview link at a share URL, separate from publishing to production, so the client can open it on their own phone in their own meeting without you deploying anything.
The visual style editor is useful live in the room. Click an element in the preview and change its type, spacing, imagery or motion while the client is watching, and the objection that would have cost a week of revisions gets resolved in ninety seconds. Style overrides can also be encoded into a shareable preview link, so what you agreed on the call is what they open afterwards.
Handover is what decides whether this works
Any tool that generates a site is only usable in agency work if the client can be handed something real at the end. Otherwise you have sold them a dependency, and either you carry it forever or they discover the problem a year later.
On Pro and Max, an OAuth flow creates a repository in the account you choose and pushes the project code to it, which is the handover route most client engagements need. Max adds a temporary repository access token, valid for one hour, with git clone access through a built-in git server, which is what you want when a client development team is taking the codebase over directly.
Domains and hosting follow the same pattern. Publishing goes to real hosting through Vercel and is available on every plan, and custom domains on Pro and Max let you connect a domain the client already owns, with DNS records generated and verification handled automatically. Domain purchases hand off to a third-party registrar checkout, so the client remains the registrant rather than inheriting a domain locked to your account.
Set the expectation in the contract: what you deliver is a repository, a deployment, and documentation. Whether it was typed by a person or generated is not a material term, but it is worth being straightforward with clients who ask.
Keeping your own studio site alive
The oldest joke in the industry is the agency whose own website is four years out of date, and it persists because internal work loses to billable work every single time. The only fix that works is making the update small enough that it survives a busy week.
Treat your site as the thing you update on the day a project ships, while the client is still pleased and the screenshots are on your desktop. Adding a case study becomes one message plus a few images rather than a ticket that waits for a sprint.
The same logic applies to your capability pages. When your positioning shifts, the site should shift that week. A studio that describes work it stopped doing eighteen months ago is filtering for exactly the wrong briefs.
- Add a case study on ship day, not at the next redesign.
- Prune old work as aggressively as you add new work.
- Keep the positioning statement current, since it is the only thing most visitors read.
- Publish a real availability or contact route, not a generic hello address nobody monitors.
The prompt structure we use for a client project
Prompting for a client is different from prompting for yourself, because you are encoding somebody elses brand rather than your own taste. Structure the prompt like a design brief: audience, positioning, tone, visual system, page inventory, and the one conversion action.
For example: 'Build a marketing site for a B2B logistics software company selling to operations directors at mid-sized distributors. Serious and technical rather than playful. Visual system: near-white background, one deep navy, one signal orange used sparingly, a neutral grotesk at three weights, an eight-point spacing scale, square corners, no gradients, no illustration. Pages: home, platform, integrations, pricing, about, request a demo. Home leads with a single sentence about reducing failed deliveries, then three capability blocks, then a logos placeholder section I will fill in, then a demo request. Platform is four feature sections alternating text and screenshot. Pricing is three tiers plus an enterprise column with contact sales. The demo form asks for company, fleet size, work email and message. Every page ends with the same demo call to action. Build it as reusable sections so my team can restyle them.'
That last sentence matters in agency use. Prebuilt page sections and components are browsable in the chat and inserted with one click, landing in the project source where the agent can restyle them like any other file. Asking for a section-based structure up front gives your developers something they can refactor rather than untangle.
When you need a specific model for a specific job, the model picker and typed slash commands select builder models across many providers, and higher plans get more build turns and a larger context budget: sixty turns on Free, a hundred and twenty on Pro, a hundred and sixty on Max. Ambitious multi-page client work benefits from the headroom.
What the agent will not do for you
It will not decide what the client should say. Positioning, message hierarchy and the argument the site is making are still the most valuable things you sell, and a generated site with a weak proposition is a fast route to a bad outcome.
It will not know the brand guidelines you did not give it. If the client has a defined type scale, colour tokens and spacing system, state them explicitly. Vague direction produces plausible generic output, which is the failure mode that wastes the most time.
It will not perform accessibility, legal or compliance review on the clients behalf. Ask for accessible contrast, keyboard navigation and semantic structure in the prompt, then test properly before handover. And it will not replace the conversation where you tell a client that what they asked for is not what they need.
| Capability | Free | Pro | Max |
|---|---|---|---|
| Projects | 3 | 50 | Unlimited |
| Publish to production hosting | Yes, with Siteglade badge | Yes | Yes |
| Custom domains | No | Yes | Yes |
| Export to GitHub | No | Yes | Yes |
| Repository access token and git clone | No | No | Yes |
| Visitor and traffic analytics | No | Yes | Yes |
| Blogs | No | No | Yes |
| Build turns per run | 60 | 120 | 160 |
Frequently asked questions
Can I hand the finished code to a client development team?
Yes. On Pro and Max an OAuth flow creates a repository and pushes the project to it, and Max adds a temporary repository access token with git clone access through a built-in git server. Plan for at least Pro on any engagement that ends in a handover, so the client leaves with a repository rather than a dependency on your account.
How many client projects can I keep in one account?
Free allows three projects, Pro allows fifty, and Max is unlimited. For an agency running several concurrent clients plus prototypes and pitches, the project cap is usually the deciding factor rather than credits.
Can I show a client a site without publishing it?
Yes. Every project can be shared through a tokenized preview link at a share URL, which is separate from publishing to production. Visual style overrides can be encoded into that link too, so a client opens exactly the version you agreed on the call.
Do we have to tell clients the site was AI-generated?
That is a commercial and contractual question rather than a technical one, and different clients feel differently. What we would say is that the deliverable is real code in a repository, and that being straightforward when asked costs nothing. Note also that media generated through Siteglade carries machine-readable AI provenance markup in the published site.