Platform Values
SGEN is built on a set of explicit architectural decisions. Each decision chose one approach over a viable alternative. The choices are visible in the product — they shape how the admin works, how modules load, how publishing behaves, and how multi-site operations are organized. This page documents those decisions: what was chosen, what was not chosen, and why. Understanding the values makes the platform's behavior predictable and reduces the friction of "why does it work this way?"
Architectural commitments
Platform values are not marketing claims. They are architectural commitments with observable consequences in the product.
Five explicit choices
Multi-site over silos, native modules over plugins, opinionated defaults, edit-in-place, and governed operations — each chosen over a real alternative.
Observable in the product
Each value has observable consequences in the admin today. They explain why the platform behaves the way it does, not what it plans to do someday.
What is this for?
Platform values are the principles that governed structural decisions during SGEN's design. They are not marketing claims. They are architectural commitments with observable consequences in the product.
When a product behavior seems unusual
Read this page when a product behavior seems unusual and you want to understand the reasoning behind it.
When building on top of SGEN
Read this page when you are building on top of SGEN and need to understand which behaviors are by design rather than by accident.
When explaining SGEN to others
Read this page when you are explaining SGEN to a stakeholder, a new team member, or an agency client and need to describe why the platform works the way it does.
Scope
This page covers the five primary architectural values baked into SGEN, what each value chose and what it rejected, the observable consequences of each choice in the product, and where these values interact with each other.
This page does not cover: how to perform tasks (those live in Guides) · per-feature implementation detail (those live in per-module Reference pages) · business pricing or licensing decisions (those live on sgen.com) · future planned decisions (the values documented here are shipped and observable today).
Vocabulary
Five platform values, each with a short form and a one-line summary.
| Value | Short form | What it says |
|---|---|---|
| Multi-site over silos | Multi-site first | One platform, one account, multiple sites. No separate installs. |
| Native modules over plugins | Zero plugin tax | Capability ships inside the platform, not as installable third-party additions. |
| Opinionated defaults over infinite config | Sensible defaults | The platform ships with correct defaults. Operators configure when they need to, not as a prerequisite. |
| Edit-in-place over draft branches | No draft-and-publish theatre | Changes are made to the live record directly with controlled publishing. No hidden draft layer. |
| Governed operations over ad-hoc access | Structured administration | Platform operations go through structured, auditable flows, not raw database access. |
Value 1 — Multi-Site Over Silos
What SGEN chose: one account governs a portfolio of sites through a shared account layer. What SGEN did not choose: separate installs per site, separate credentials per site, no account-level visibility across the portfolio.
Before SGEN, managing multiple client sites meant logging into each one independently. There was no aggregate view of what was running, no centralized billing, no unified team management. Each site was a silo.
SGEN chose multi-site as a structural property, not an add-on. SG-Dashboard governs the portfolio. Every site the account holds appears there. Provisioning, billing, reporting, and team invitations operate at the account level — once, not per site.
The observable consequences in the product:
SG-Dashboard at dashboard.sgen.com
A separate surface from any individual site admin. Creating a new site is a SG-Dashboard operation, not a per-site operation.
Billing is account-level
Billing changes affect the account's portfolio, not a single site's configuration. Account-level users have access across the portfolio; site-level users are scoped to one site.
Why multi-site first matters: A 20-site agency portfolio on SGEN has 1 billing relationship, 1 team roster, 1 update cadence. The same 20 sites on a plugin-stack model have 20 billing relationships, 20 sets of credentials, and 20 independent update schedules. The multi-site structure compresses management overhead by an order of magnitude at scale.
Value 2 — Native Modules Over Plugins
What SGEN chose: capabilities ship inside the platform as first-class modules. What SGEN did not choose: a marketplace of third-party plugins that extend a thin core.
The plugin model has a known failure mode: Plugin Tower. A functional site requires 15, 20, 30 plugins. Each plugin has its own update schedule, its own compatibility constraints, and its own failure mode. An update to one plugin breaks another. A security patch to the CMS core requires every plugin to update before the site is safe. The result is update anxiety — operators deferring updates because the cost of an update failure is too high.
SGEN chose to ship capabilities — ecommerce, forms, events, bookings, members — as native modules inside the platform. A module ships, updates, and is maintained as part of the platform release cycle.
The observable consequences in the product:
Capabilities live inside the admin
Ecommerce, Forms, Events, and other capabilities live inside the admin — no separate install. Module updates ship with platform updates — there is no "update your plugins" step.
Platform-level regression testing
Module behavior is covered by the platform's regression testing, not by a third-party vendor. Operators choose which modules to activate on a site — they are not installed independently.
What this means for operators: Zero plugin roulette. Zero update anxiety. The platform ships with what it ships with. When a new capability is needed, the question is whether SGEN's native module covers it — not which of twenty plugins to trust.
| Dimension | Plugin model | Native modules (SGEN) |
|---|---|---|
| Update cadence | Each plugin updates independently | Platform-level, single release cycle |
| Compatibility | N plugins × N versions = exponential surface | Platform governs compatibility across all modules |
| Security | Core patch + plugin patches separately | One patch covers core and all modules |
| Failure mode | One plugin update can break others | Module regression is tested inside the platform release |
| Discovery | Browse a marketplace of third parties | Modules are first-class features — listed in the admin |
Value 3 — Opinionated Defaults Over Infinite Config
What SGEN chose: the platform ships with defaults that are correct for most operators. What SGEN did not choose: a blank-slate configuration where every setting must be touched before the site works.
Infinite configuration sounds like flexibility. In practice, it means operators spend hours in settings screens before writing a single line of content. Every setting that must be configured to make the site minimally functional is a configuration tax.
SGEN ships opinionated defaults. A new site is ready to publish content without touching any configuration screen. Defaults are chosen to be correct for the majority of use cases: sensible SEO defaults, reasonable image compression, useful redirect behavior, logical permission models. Operators configure when their use case diverges from the default — not as a prerequisite to using the platform.
The observable consequences in the product:
Working SEO out of the box
A new site has a working SEO setup out of the box — meta defaults, sitemap, robots.txt. Image compression and format conversion have defaults that work for most publishing workflows.
Redirect behavior and role permissions
Redirect behavior on slug changes is on by default — old URLs do not become broken links when a slug changes. Permission roles ship with meaningful defaults — an Editor can create and edit but not publish; an Admin can do everything.
The constraint this creates: Opinionated defaults mean SGEN does not expose every configuration option. Some things the platform does cannot be turned off. Operators who need a behavior the default makes unavailable must use a workaround (Custom Codes, Custom CSS) or identify whether the option exists in settings. The trade-off is deliberate: depth of configuration is capped to maintain the correctness of the defaults.
| Feature | Default state | Configuration available? |
|---|---|---|
| SEO meta defaults | On — title + description generated from page title | Yes — override per page |
| Redirect on slug change | On — 301 redirect from old slug | Yes — disable per page if needed |
| Image optimization | On — compression applied at upload | Yes — toggle per upload or globally |
| Role permissions | Sensible role presets | Yes — per-user adjustments available |
| Sitemap | Auto-generated, includes all published pages | Yes — exclude pages individually |
Value 4 — Edit-in-Place Over Draft Branches
What SGEN chose: operators work on the live record directly, with publishing as the gate. What SGEN did not choose: a hidden draft-copy system where every edit creates a diverging branch that must be merged.
Draft-branch systems sound safe. In practice, they create confusion: which version is the current one, which version is scheduled, and which draft was never published and is now stale. The result is content operations that require version management expertise before publishing a blog post.
SGEN chose edit-in-place. A record (a page, a post, a product) exists in one state at a time. When an operator edits it, they are editing the record. When they publish, the record goes live. Staging environments provide the branch isolation that content teams need for previewing changes before they hit the live site — without creating hidden draft objects inside the live site's record system.
The observable consequences in the product:
One version per record
The admin shows one version of each record — the current state. Staging provides the preview-and-approve workflow for teams that need it.
Draft state is a publishing status
There is no "drafts folder" inside the record list — draft state is a publishing status on the record, not a separate copy. Publishing state (draft, scheduled, published, archived) is a field on the record, not a versioning construct.
When staging is the right tool: Operators who need to preview significant changes before they go live use the staging environment. The staging-to-live promotion moves content from the staging context to the live context. This is the structured branch model SGEN supports — environment-level, not record-level.
Value 5 — Governed Operations Over Ad-Hoc Access
What SGEN chose: platform operations go through structured, auditable flows. What SGEN did not choose: raw database access, direct file editing, or unconstrained shell-level operations.
Ad-hoc access is fast. It is also the source of most "I didn't mean to do that" incidents in CMS operations. A direct database edit bypasses validation. A raw file edit bypasses the publishing model. Neither is logged, audited, or reversible through the CMS itself.
SGEN governs operations through structured surfaces. Content changes happen through the admin. Configuration changes happen through settings screens. The platform validates inputs, logs changes, and applies the publishing model to every record that touches the live site.
The observable consequences in the product:
All changes through the admin
All changes to site records go through the admin — there is no exposed file system for content operations. Publishing requires an explicit publish action — no content goes live by accident.
Field constraints and audit logging
The admin enforces field constraints — an invalid slug, an oversized upload, an unresolvable redirect — before saving. Audit logging is part of the platform, not a plugin.
What operators cannot do by design: Operators cannot write directly to the database through any SGEN admin screen. Operators cannot edit template files through the admin — theme customization goes through the Theme Editor or SG-Builder. These constraints are intentional governance, not missing features.
| Operation | What the platform validates | Why |
|---|---|---|
| Publishing a page | Slug is valid and unique, title is present | Prevents broken URLs and blank-title pages on the live site |
| Uploading media | File size, format, compression settings | Prevents unoptimized assets reaching the live site |
| Adding a redirect | Target URL is not a loop, source slug does not conflict | Prevents redirect chains that break site navigation |
| Creating a user | Role is assigned, email is valid | Prevents accounts with no permissions or unreachable verification |
| Publishing a blog post | Author is assigned, content is non-empty | Prevents blank or authorless posts appearing on the live site |
How the Values Interact
The five values are not independent. They reinforce each other.
Multi-site requires governed operations
Multi-site over silos requires governed operations — an account-level governance layer only works if operations inside each site are structured enough to be safe across all sites simultaneously.
Native modules require opinionated defaults
Native modules over plugins requires opinionated defaults — if every module required configuration before it was usable, the native-module model would still impose a configuration tax.
Opinionated defaults require governed operations
Opinionated defaults require governed operations — defaults are only trustworthy if the platform validates that inputs stay within the expected range.
Edit-in-place requires governed operations
Edit-in-place over draft branches works because governed operations enforce publishing as the gate — operators can edit directly because publishing is explicit, validated, and reversible via staging.
Examples
Three common moments where understanding platform values resolves confusion.
Value 2
Why there is no plugin marketplace
A new operator asks why they cannot add a plugin to SGEN the way they added plugins to their previous CMS. The answer is Value 2. SGEN chose native modules because the plugin model creates update anxiety and compatibility failures at scale. The capability they need is either already a native module in SGEN or is on the module roadmap. If neither, Custom Codes provides a targeted injection point for third-party scripts that do not need to be full CMS modules.
Value 4
Why there is no drafts folder
An operator used to a different CMS expects to find a "drafts" folder in the Pages list. SGEN does not have one. The answer is Value 4. Draft state is a publishing status on the page record (draft). The page appears in the Pages list with a draft badge. It is not a hidden copy. The operator publishes the draft by opening it and clicking Publish — no merge step, no version history to resolve.
Value 5
Why template file editing is not in the admin
An operator wants to edit a theme file directly from the admin. The admin does not provide a raw file editor. The answer is Value 5. Theme file editing bypasses the theme validation model. The correct path is the Theme Editor (for theme-level settings) or SG-Builder (for page-level visual adjustments). The constraint is not a missing feature — it is a deliberate governance boundary.
Edge cases
Situations where a platform value creates a question worth addressing directly.
When the opinionated defaults are wrong for a use case
Not all defaults are correct for all operators. An operator who needs a non-standard publishing model, an unusual SEO configuration, or a custom permission structure can configure those areas. The defaults are a starting point, not a cage. The Reference page for each feature documents what is configurable and what is fixed.
When multi-site creates complexity for a single-site operator
A single-site operator on SG-Dashboard still has an account layer even though their portfolio has one site. The account layer is lightweight in the single-site case — the portfolio screen shows one site card. The governance overhead is minimal. The value of the structure appears when the portfolio grows.
When native modules do not cover a capability the operator needs
Custom Codes covers injection of third-party scripts that do not need to be native modules. Integrations covers connections to external services (payment processors, email platforms, CRM systems) that SGEN governs through structured connectors. The gap between "needs a native module" and "can be solved with Custom Codes or Integrations" is narrow in practice. When the gap is real, the operator's request enters the module roadmap.