Describe a website. Watch it get built. Put it online.

Tell Steve what you want in a sentence. The code appears in front of you, line by line, in a real code panel. Seconds later the site is running in a live preview you can click. When it's right, say "publish it" - and it's on the internet at your own address with an HTTPS certificate that provisions itself.

No hosting account. No DNS records. No deploy pipeline. No developer.

What actually happens, in order

1. Steve starts writing - within about 3 seconds. One short sentence in the chat, and then the code panel opens by itself and the file starts typing itself out: real HTML, real CSS, real JavaScript, character by character. Not a progress bar. Not a spinner. The actual file, as it is being written.

2. The site comes up in a live preview. When the file is finished, it's served in a real preview inside the workspace. You click through it like any website - links, buttons, the menu, the lot.

3. You ask for changes in plain language. "Make the hero darker." "Move the hours above the map." "The button text should say Order now." Steve edits the file and the preview refreshes.

4. You say "publish". Your site goes live at <slug>.unyo.site - a real public URL, a real TLS certificate, reachable by anyone you send it to.

What Steve builds - and what he doesn't

This is the honest boundary, and it's the most useful thing on this page.

Steve builds static front-end websites. HTML, CSS and JavaScript - styling loaded from a CSS CDN, web fonts, and plain JavaScript for the interactive parts.

Good fits:

• Landing pages and one-pagers
• Portfolios and personal sites
• Event, launch and "coming soon" pages
• Menus, price lists, service pages
• Small interactive tools and prototypes - calculators, quizzes, little games

Steve does not build:

If your idea needs a login and a database, Steve is not the tool. If it needs to look excellent and be online today, he is.

The workspace: Code and Preview, side by side

Steve's panel is a real workspace, not a screenshot.

Code tab - a file tree on the left, a syntax-highlighted editor on the right, line numbers in the gutter. Every file Steve wrote, exactly as it is. The file currently being written pulses in the tree, and the caret blinks at the end of the line. It's read-only: this is your window into the code, and Steve is the one holding the keyboard.

Preview tab - your site, running, clickable.

Multi-file is normal: index.html, css/style.css, js/app.js. Reading your own code is free - it costs zero credits, always.

Click the thing you want to change

This is the trick that removes the "which paragraph do you mean" conversation.

Turn on Select an element in the Preview tab, hover, and elements light up. Click one - the heading, the price card, that stubborn button. A chip appears in your message box. Now type what you want, and Steve changes that element instead of rebuilding the page.

Every edit shows its work

When Steve changes a file, a compact chip appears in the chat: ✎ index.html +12 −3. Click it and the red/green diff opens in the Code tab. You see exactly which lines changed - added in green, removed in red - instead of taking his word for it.

The whole run reads like a terminal transcript rather than a chatbot monologue:

⏺ create_site(index.html)              ✓
  └ Bakery landing · live preview
⏺ edit_site(index.html)                ✓
  ✎ index.html +12 −3
⏺ publish → ma-patisserie.unyo.site    ✓

Spinners while running, a ✓ or ✗ when done, foldable results. Steve is explicitly forbidden from writing "Here's what I did:" recap bullets - you can see the site.

Borrow a structure, not a website

Give Steve a reference URL and he'll take inspiration from it - properly.

What Steve extracts: the page's title and description, its headings, a sample of its text, its colour palette (up to 8 colours) and its internal links. That's a blueprint.

What Steve never does: download an image, hotlink an image, copy the HTML, or reproduce the text verbatim. There is no image-fetching code path - it doesn't exist. He reads the shape of the page and then builds your version of it.

The fetcher is hardened against being pointed somewhere it shouldn't go: private IP ranges, loopback, link-local, cloud metadata endpoints and non-HTTP schemes are all blocked, redirects are capped, and the page must be real HTML under 3 MB.

Publishing: a real URL, a real certificate

Say it, and only then does it happen.

• Your site deploys and your subdomain is attached: ma-patisserie.unyo.site.
• The TLS certificate is provisioned automatically. The link works when Steve hands it to you.
• Pick your own slug, or let Steve derive one from the site name. Slugs are 3–40 characters, lowercase letters, numbers and hyphens; a blocklist keeps infrastructure, commerce, auth and brand names out.
• Edited since you published? Say republish - same URL, new content.
• Done with it? Say unpublish. The address 404s. That's free.

The panel tells you the truth at a glance: a green Online badge when the site is live, and an amber unpublished changes badge the moment you edit a site that's already out there. You always know whether what you're looking at is what the world sees.

Your site is yours

Say "export it as a ZIP" and you get the whole project as a download - HTML, CSS, JS, your images. Host it wherever you like; it's static files, so anywhere will do.

The ZIP lands in a private, owner-only storage bucket. No shareable link is ever created or stored - the download runs on your own logged-in session and nobody else's. Export costs 10 credits.

The preview doesn't die

The build machine behind a live preview is short-lived - about ten minutes - because leaving one running would be wasteful and, frankly, a bit rude to the planet.

Your code isn't in it. Your code lives in your project record. So when you reopen a Steve conversation weeks later and click Preview, the preview quietly restarts itself from the saved files, in a few seconds. You never see a "sandbox not found" error, because there's nothing to find - it just gets rebuilt.

Restarting your preview costs zero credits.

Only a published site is permanently online. That's the difference between the preview and the URL.

The sandbox has no internet and no secrets

The machine that serves your preview has outbound internet access switched off entirely. It cannot make a single call out. When your preview loads its styling from a CDN, that's your browser fetching it inside the iframe - not the build machine.

No environment variable from our infrastructure ever enters it. And if a file contains something that is obviously a backend secret - a private key, a live payment secret key, a service-role token - publishing is refused before anything ships. A public front-end has no business carrying a server key.

What it costs

Priced in credits, per action:

Model usage during the build is billed separately on its real cost, not a flat per-message fee.

If it fails, you're not charged. Every one of Steve's paid actions is refundable on error - a build that errors, an edit that can't find what it's changing, a deploy that doesn't come up. The refund is automatic.

New accounts start with 2 500 free credits and no card. That's enough to build a site, iterate on it, and put it online.

See Pricing for plans and top-ups.

The boundaries, stated plainly

Enforced limits are features. Here are Steve's.

• Steve is the only agent who can touch your websites. The website tools are mounted for Steve and for no one else - the other nine agents cannot see them, let alone call them. Ask Blake to code you an app and he will hand you to Steve rather than write throwaway code.
• You cannot delegate a website to another agent. Steve isn't on the delegation roster. The only way to build a site is to open a Steve conversation yourself - which also means no other agent can start deploying things on your behalf.
• One site per conversation. A Steve conversation is bound to one project. Building a second site? Start a new conversation - otherwise the new one takes over the old one's slot.
• No custom domains yet. <slug>.unyo.site subdomains only.
• No version history. Your project stores its current state. There's no rollback, so before a big rework, export a ZIP.
• Nothing publishes itself, ever.

When you delete your account, your sites come down first

Erasure that stops at the database isn't erasure. Before your data is purged, every site you published is read out and taken offline - the deployment is deleted, the subdomain 404s. Then the rest goes. And it completes even if something along the way is unreachable, because deletion must never be blocked.

More on this in Security.

Try it

Open a conversation with Steve and type one sentence.

Start building →

Questions