Siter.io for design studios

Several people, one website, and nobody standing on anybody. How the seats are counted, why most of a studio should not hold one, and the part of the job that stays in Figma.

Start for free -> Roles and seats in detail

The short answer.

A studio can run its client work here, and the process is probably not the shape you are expecting. Collaboration stays in Figma, where several people already share one file. Siter.io is where the agreed design becomes a published site, held by one person at a time — an arrangement the studio makes for itself, since real-time co-editing is listed as upcoming. Two things decide whether that suits a brief before anything else does: there is no CMS, so a client who wants to post their own updates cannot, and no e-commerce.

Seats are metered, access is not
Roles are listed on every plan and are how you organise who changes what, so a producer, a junior or a client can be given a viewer role instead of a seat. Exactly what each role permits is not documented, so check it in the app before handing over a client site. Editor seats are the metered part, and an extra one is added to the subscription rather than promoting you to a team tier.
Roles and seats in full
One person on the canvas at a time
Real-time co-editing is listed as upcoming, so there is no supported way for two people to work in one page the way they do in a Figma file. Agree who is editing before you both open it. That constraint decides how a studio organises everything else here.

How a studio shares one site.

Five decisions, and the first one is the whole thing.
1. Settle the design in Figma first.
2. Send the finished frame across.
3. Name one owner per site.
4. Default everyone else to viewer.
5. Build the repeated parts as components.
Where the boundary between the two files sits

The import runs one way. The plugin sends a frame across once, and later edits in Figma do not re-sync. That is the line telling you the design is finished. Carry a half-settled layout over and the studio makes the same decision twice, in two tools, then reconciles them by eye.

Prototype work does not travel. Animations and interactions wired in Figma’s prototype tab do not import. Movement is built again on the canvas. Budget it as production time rather than assuming it arrives with the frame.

One name against each site. After the import the canvas is the file that ships, and it wants a single owner — the person who makes structural changes and who everyone else asks. Everyone else reviews the site rather than the canvas, which is the better artefact anyway because it is what the client will see. The protocol for handing the canvas on is written out on the collaboration page.

Components are how a small team stays consistent.

A studio’s consistency problem is rarely that somebody designs badly. It is that four people touch one site over six months and the footer quietly becomes three different footers. Components are the mechanism against that.

What is worth making into one

The test is boring and it works. If changing this thing means opening eleven pages, it is a component. The navigation, the footer, the card that repeats down a listing, the button, the contact band at the foot of every service page. Anything carrying one-off copy is not a component; it is a layout that looks similar, and forcing it into one leaves you with eleven overrides and no benefit.

Name them for the person who did not build them

In a studio the file is picked up in March by whoever is free. Names describing the role survive that; names describing the appearance do not. A component called nav / primary is still correct after a rebrand. One called blue bar is a lie within a quarter, and the next person builds a second rather than trust it.

Editing one is the highest-stakes change anyone makes

What makes a component valuable in a shared file is exactly what makes it dangerous in one. Treat a component edit the way a development team treats a deploy — one person does it, deliberately, and says so afterwards. Version history is part of the product, so there is somewhere to look after a bad edit, though how far back it reaches and what a restore covers are not published. Find those edges on something disposable first.

Prove the mechanics on a throwaway site first

What Siter.io documents about components is that they exist. How an edit propagates to the instances, and what a component carries across the three fixed breakpoints, are not written down anywhere we can point you at. Those are first-afternoon questions. Build a two-page test site, put one component on both pages, change it, and watch each breakpoint. Ten minutes buys the answer, and committing a client system to an untested assumption is how a small inconsistency becomes a rebuild.

Seats, and who actually needs one.

The instinct is to buy a seat for everybody in the studio. Count the seats against the work instead.
Count the people who move things. Solo includes 2 editor seats, Plus includes 4, Pro includes 6. Past that, the pricing page lists each additional editor as added to the subscription cost: $4 on Solo, $6 on Plus, $8 on Pro. That is instead of promoting you to a team tier, because there is no tier above Pro.

Roles are how everyone else gets in. A producer tracking progress, a junior learning the file, a client watching a build — they need to see the site, not change it. If only two people in the studio actually move things, two is the number to buy for, whatever the headcount says.

A second seat is not a second cursor. With real-time co-editing listed as upcoming, a second seat lets a second person take the site once the first hands it on, or hold a different site entirely. Two people inside one page at the same moment is not supported, and splitting by page within one site is a convention the studio keeps for itself, not something the editor guarantees.

Sites are the meter that sizes the plan. 1 published website on Solo, 3 on Plus, 5 on Pro — seats are sized separately, by how much work genuinely runs in parallel rather than by headcount. Whether a view-only person consumes an included seat is not documented, so confirm that in the app before buying one, and the full matrix is on the collaboration page and the pricing page.

Four briefs to send elsewhere.

All four are far cheaper to catch in the first call than in the third week of a build.

The client will be posting
There is no CMS and no blog. A client who expects to write their own updates cannot, and somebody in the studio hand-builds a page every time.
Something is sold from the page
There is no e-commerce. Upcoming with no date, which in a scope of work means it does not exist. A checkout belongs on another platform.
The brand runs in two languages
Multi-language is not supported. A bilingual client means a second set of pages built by hand, billed as a second published website, drifting apart from the first within a quarter.
The deliverable is code
Layout is three fixed breakpoints rather than rules you write, custom code is site-wide head code on paid plans plus an on-canvas embed element with no per-page body scripts, and HTML download is on Pro only, a page at a time.
What the download is for

One detail before a white-label job: the “Made with Siter” badge comes off on any paid plan, so the deliverable carries a client’s name rather than ours. See the full feature list and how the three breakpoints work.

Frequently asked.

Can two designers work on the same site at once?

Not in the same page at the same moment — real-time co-editing is listed as upcoming. Different pages, one person holding the site at a time, is the workable pattern, and it is a rule the studio keeps rather than one the editor enforces. What the editor does if two people open the same page anyway is not documented, which is itself the argument against finding out on a client project. The collaboration page has the protocol.

How many editors does a studio plan include?

Solo includes 2, Plus includes 4, Pro includes 6. The pricing page lists each additional editor as added to the subscription cost: $4 on Solo, $6 on Plus, $8 on Pro. So bringing a freelancer in for six weeks is a small change rather than a new plan or a sales conversation. One caveat on counting heads: the free plan builds and previews privately and cannot publish, so whoever presses publish is on a paid plan.

What happens when the person who built it leaves?

Two moves. Roles are listed on every plan and organise who can change what, so access can be changed without touching the site — check in the app exactly what a role permits before you rely on it. And the pricing page lists transfer of a website to another email address on every plan, which is how a site leaves a personal account. Confirm what travels with it, and transfer while the person who understands the file is still there.

Should the studio’s own website live here?

If it is a portfolio with a handful of project pages and a contact form, it is a good fit and stays quick to change. If the studio publishes writing on a schedule, it is the wrong home — there is no CMS, so every article is a hand-built page. Keeping the site here and the writing elsewhere is a workable split.

Who else it is for

Also useful: roles, seats and the full plan matrix, Siter.io pricing in full and bringing the studio’s own fonts.

Put one site in front of the whole studio.

Send a finished frame across and see what the build actually takes before you commit a client project to it. Building and previewing costs nothing; publishing starts at $7/mo billed yearly.
Get the plugin ->
Start for free with Siter.io
Start for free ->