SGEN in 90 seconds

The 90-second answer. SGEN is one platform with five surfaces that share one data layer. SG-Core owns the structural records — pages, users, media, custom fields. SG-Modules owns the features — forms, SEO, ecommerce, redirects (what you'd normally install as plugins). SG-Dashboard is your account-level view at dashboard.sgen.com — every site, billing, backups. SG-Admin is the single-site shell at /sg-admin — settings, publishing, day-to-day work. SG-Builder is the drag-and-drop page editor, opened from inside the admin when you edit a page. They're not separate apps — they share data, so a form built in SG-Modules submits into the SG-Core page that SG-Builder designed.

The five surfaces

SG-Core and SG-Modules are the foundation tier; SG-Dashboard, SG-Admin, and SG-Builder are the operator surfaces on top.

What you do in each

Knowing where you are saves you the most common new-user confusion — "which screen handles this?" Here is the short version of each surface as a place you work:

• SG-Dashboard is your home base across everything. You land here after signing in. It is where you create a new site, see all your sites at once, watch cross-site analytics, manage your team and roles at the account level, and handle billing and backups. When you are deciding what to work on, you are in the Dashboard.
• SG-Admin is one site's control room. Open a single site from the Dashboard and you are in its admin — your Pages and Posts, the site's settings, SEO defaults, menus, media, and the publish controls. When you are running one site, you are in SG-Admin.
• SG-Builder is where a page gets its shape. From inside SG-Admin you edit a page and SG-Builder opens — the drag-and-drop canvas where you place sections, text, images, buttons, and components, and style them across breakpoints. When you are designing a page, you are in SG-Builder.
• SG-Core is the layer you rarely visit directly but always rely on. It holds the structural records every site needs — pages, users, media, custom fields, templates. Most of what you do in the operator surfaces is reading from and writing to SG-Core underneath.
• SG-Modules is the feature layer. Forms, SEO controls, ecommerce, redirects, popups, and more live here as first-party parts of the platform, switched on inside SG-Admin rather than installed from a marketplace. When you add a capability to a site, you are turning on a module.

The takeaway: you spend almost all of your hands-on time in the three operator surfaces — Dashboard, Admin, Builder — while Core and Modules are the platform doing the work behind them.

What it replaces

First-party components that ship and update together — no plugin marketplace, no extension boundary to manage.

Why one data layer matters

The five surfaces are not five apps stitched together — they read and write the same records. SG-Core holds the structural data (pages, users, media, custom fields). SG-Modules adds the feature behavior on top of those same records. SG-Builder designs the page that SG-Core stores. SG-Admin and SG-Dashboard are views into that one set of records at the single-site and account level.

The practical payoff: a form you build in SG-Modules submits into a page record SG-Core already owns, and that page is the one SG-Builder laid out. You never export from one tool to import into another, and you never reconcile two copies of the same content. Change a record once and every surface that reads it reflects the change. That single shared layer is the difference between a platform and a bundle of plugins.

A request, traced across the surfaces

It helps to follow one ordinary task all the way through. Say a visitor fills in your contact form:

1. You built that form by turning on the form capability in SG-Modules and dropping it onto the page in SG-Builder.
2. The page itself is a record SG-Core stores — the same record SG-Builder lays out and SG-Admin lists under Pages.
3. When the visitor submits, the entry lands against that same record, with no export step and no second copy to keep in sync.
4. You read the submission in SG-Admin for that site, and the activity rolls up into SG-Dashboard alongside your other sites.

No glue code, no connector, no "does the form plugin still work with the page builder after the update?" — because there is one system, not five tools introduced to each other.

What this means for you

You do not have to learn five separate products. You learn one platform with five views into the same data. The practical consequences:

• There is nothing to assemble. The capabilities ship together and update together, so you spend your time building rather than wiring tools to each other.
• You always know where you are. Account-level decisions live in the Dashboard, single-site work lives in SG-Admin, and page design lives in SG-Builder — a clean split that maps to how you think about the work.
• Your content has one home. Because every surface reads the same records, you never wonder which copy is current.

See also

• What is SGEN — the full platform definition, surface by surface.
• Why SGEN exists — the problem statement behind the shape.
• For your role — the reading path for founders, marketers, designers, developers.
• Documentation map — find any page.

Bookmark this — it's the link to send a teammate who asks "what is SGEN?"