Important concepts

These are the ideas everything else depends on. If you understand them, you will answer almost every "can Sajt do X?" question correctly. When in doubt, verify against the developer reference.

The six pillars

1. Two-world model. Editing changes draft tables (normalized websites / pages / sections / services / …). Publishing writes a separate, immutable snapshot. The public site reads only snapshots, so a draft edit can never corrupt or change the live site. See Draft vs published.
2. One shared renderer. The editor canvas, /preview, share links (/p/<token>) and the public /site all render through the same component (SectionRenderer). This is why preview equals production — there is no separate "design view" that can drift from what visitors see. It is never forked.
3. Structured, typed content (data, never code). A section's content is a discriminated union keyed by type, validated on every write. There is no raw HTML, no AI-generated React, no per-site codebase. Links are typed targets and icons are an allow-listed set — there is no free-text URL or markup primitive to abuse.
4. Constrained theming. Themes are pre-validated, AA-safe tokens (palette, font pair, density, radius, button style, light/dark). There is no raw hex and no color picker — the user cannot produce an unreadable or off-brand combination.
5. SEO is system output. Title, meta, canonical, Open Graph/Twitter, JSON-LD, sitemap, robots and hreflang are derived from the business data at publish time and frozen in the snapshot — not hand-authored fields the user can get wrong.
6. Plain language, bilingual. No technical jargon is surfaced. Every admin string is dictionaried (Swedish/English, plus Polish admin).

Publish is explicit

Nothing a user does in the editor is visible to the public until they press Publish. Editing is safe and private; publishing is a deliberate, owner-driven act with a QA gate in front of it. Treat "make a change" and "make it live" as two distinct steps — never assume an edit is already public.

Starter kits = business types (not a template store)

When a user describes their business, Sajt picks a vertical (business type) such as dentist, salon, cleaning, restaurant, fitness, handyman, consultant, coach, freelancer, clinic, or a generic fallback. That vertical carries a complete, deterministic recipe — which sections, in what order, with curated bilingual copy, service examples, FAQ, theme and brand direction — so the user gets a credible finished first draft, not a blank page.

This is not a template marketplace:

• There is no gallery of designs to browse, no per-design markup or thumbnails.
• A "starter kit" is just structured data feeding the one shared renderer; the result is fully editable afterward.
• The only stored artifact is websites.vertical. The recipe lives in code.

The deterministic recipe runs with no AI key; AI only polishes afterward and is never load-bearing. See the AI system.

Constraint is the feature

Sajt is deliberately not Webflow, WordPress, Figma, a freeform drag-and-drop canvas, an AI code generator, or a generic CMS. The mission is to make it effectively impossible for a non-technical owner to end up with an ugly, broken, inaccessible, or SEO-dead site. Limits (typed content, fixed layout variants, AA-safe themes) are how that promise is kept — they are intentional, not missing features.

The seven product questions

Every feature is judged against these. Use them to sanity-check any suggestion you make to a user:

1. Does it reduce work for the user?
2. Does it reduce decisions?
3. Does it prevent mistakes?
4. Does it make the website look more professional?
5. Can a non-technical 70-year-old understand it?
6. Can it be done from a phone?
7. Would removing it make the product simpler?

If a proposal fails these — especially anything that adds raw control, jargon, or decisions — it is probably against the product's grain. See Known limitations for the explicit non-goals.