How to Build a Coworking Space Website Without Code

A coworking website has one job: turn a visitor into a tour booking or a day pass. Describe the space, the plans, and the booking action in plain English, and Zugo builds the pages. Stripe handles the payments, Supabase handles member logins. A simple build takes about a minute.

This guide is about that specific build. What belongs in the prompt, which pages carry weight, how paid passes and member accounts get wired in, and where an AI builder stops being enough for a space that already runs on a management system.

What does a coworking website have to do before it looks good?

People arrive at a coworking site with four questions, usually in this order: where is it, what does a desk cost, is one free, and can I see it first. A page that answers all four above the fold beats a beautiful page that hides the price behind a contact form.

That ordering should drive the build, not the design. Write the prompt so the hero states the location and the entry price, the plans block states what each tier includes, and the booking form is reachable from every page. Everything else, photography, community talk, the founder story, is supporting material.

The second thing worth deciding early: are you selling desks to individuals, offices to small teams, or both. A site aimed at solo freelancers reads very differently from one aimed at a five person startup looking for a lockable room, and mixing the two without labelling them produces a page that persuades nobody.

What should you actually type into the builder?

Name the space, the plans with real prices, the pages, and the single action you want. Vague prompts get filled in with generic assumptions, and generic assumptions in coworking usually mean stock photos of laptops and no pricing at all.

Build a website for [space name], a coworking space in [city, neighbourhood].
Audience: freelancers and small remote teams looking for a desk by the month.
Pages: Home, Plans and pricing, Spaces, Community, Contact.
Plans: hot desk [price/month], dedicated desk [price/month],
private office from [price/month], day pass [price].
Each plan lists what it includes: hours of access, meeting room credits, printing, mail.
Home hero: [one line about the space], button "Book a tour".
Spaces page: photo grid with a short caption per area
(open floor, phone booths, meeting rooms, kitchen).
Contact page: address, map embed, opening hours,
form with name, email, company, plan of interest, preferred tour date.
Tone: practical, no startup clichés.

If a blank prompt field is intimidating, start from one of Zugo's 25 templates and rewrite it in plain text instead. A template that already has a pricing block and a gallery gets you to a first honest draft faster than describing a layout from scratch. The same principle applies to any local business site, which how to build an app with AI covers in more general terms.

Which pages does a coworking site actually need?

Five is usually the right number. Fewer and you are hiding information people need before they visit; more and you are maintaining pages nobody opens. Here is what each page owes the visitor and what it costs to build.

In credits, a multi-page platform costs 12 plus 3 per page, so this five page site comes to 27 credits. A single landing page instead of a full site is a build at 6 credits. Each text edit afterwards costs 1, which matters because the plans page will change more often than you expect.

How do you take money for day passes and memberships?

Connect Stripe and the generated site can charge for both one-off day passes and recurring memberships. That distinction is the whole design of the payments layer: a day pass is a single payment, a hot desk membership is a subscription that renews, and they need different buttons and different confirmation copy.

Write it explicitly in the prompt: "Day pass is a one-time payment of [price]. Hot desk and dedicated desk are monthly subscriptions. After payment, send a confirmation email with the address, the door code instructions, and the opening hours." Email delivery runs through the Resend connector, so those confirmations reach real inboxes rather than sitting in a database.

What Stripe will not do for you is decide your refund and cancellation policy, and a coworking space needs one in writing before it takes the first subscription. Write the policy yourself, put it on the pricing page, and only then turn on recurring billing. The Stripe payments guide covers the mechanics of the connector in detail.

Do members need accounts, and what does that involve?

Only if you are giving them something behind the login. A brochure site with a booking form needs no accounts at all, and adding them is work you can skip. A member area with the meeting room calendar, house rules, event signups, and billing history is a different product, and that is where Supabase comes in.

Supabase gives the generated app a real Postgres database plus authentication under your own account. Members sign up, log in, and see records scoped to them. Say "only their own" in the prompt when data must not be shared across members, because that phrase is what tells the builder to scope records to the signed-in user rather than showing everyone everything.

The honest trade: a member portal is a multi-page platform with logic, not a website. Expect to build the first version, then spend several rounds of edits getting the details right. That is normal and cheap at 3 credits per edit, but it is not a one-prompt result. The Supabase connector guide explains the setup.

Where does an AI builder stop being enough?

Four places, and they are worth knowing before you start rather than after.

• Live desk availability. A page can say "desks available this month". A system that knows in real time which of 40 desks are free, and holds one while somebody pays, is application logic that you will build through iterations, not describe in a single sentence.
• Door access and hardware. Keycards, smart locks, and printer quotas run on physical systems. Zugo's connectors are Supabase, Stripe, GitHub, Vercel, Resend, Google Analytics, and your own domain. There is no connector for door hardware, and pretending otherwise would waste your afternoon.
• An existing coworking management platform. If your bookings, invoices, and members already live in a specialist tool, the sensible build is a marketing site that links to it, not a replacement for it. Rebuilding an operations platform is exactly the case where Zugo does not replace a development team.
• Very specific rules. Prorated first months, corporate billing, tiered meeting room credits: all reachable, none in one prompt. You get there by editing.

What does it cost to run?

Free comes with 5 credits. A build costs 6 and an edit costs 3, so the free tier is for looking around rather than shipping. Pro is $25 per month for 200 credits and adds a custom domain. Business is $99 per month. Prices are in US dollars.

Publishing puts the site on a yourspace.zugo.run address immediately, and a custom domain points at it when you are ready. Every build is booted in a sandbox first, so a build that fails to open is reported as a failure rather than handed to you as a blank page. That lowers the risk of shipping something broken; it does not remove it, and you should still click through the booking form yourself before sending traffic.

What is a sensible first step?

Write four sentences: where the space is, what the cheapest plan costs, what the visitor should do next, and who you are trying to attract. Build from that, publish to the zugo.run address, and send the link to three people who fit your target member. Their first question is your next edit.

Once the marketing site converts, decide whether the member portal is worth building or whether a link to your existing tools is enough. Most spaces find the site is the urgent half. Start at zugo.dev, and if you want the code as a normal repository later, GitHub export hands it over.