Platform capabilities and limits

A factual map of what SGEN can and cannot do at the platform level.

This page lays out the platform capabilities SGEN ships and the honest limits around them. It is written for evaluators, developers, and technical buyers who need to map their own requirements to what the platform provides today — and to know, up front, where the boundaries are. Every capability below is something the platform supports today. Every limit is a real boundary, named plainly rather than hidden behind a feature grid.

In short. SGEN is a server-first content management platform. Out of the box it gives you pages and templates, a visual Site Builder, themes and menus, forms with reporting, a media library, blog and events, a Stripe-backed store, popups, discussions, locations, SEO controls, redirects, analytics, user accounts, backups, and a custom-code surface for the rest. It does not ship a third-party plugin marketplace, a general public content API, a native importer for other platforms, or vertical modules like bookings, memberships, courses, A/B testing, or translations. That trade is deliberate: fewer moving parts, no plugin tax, no update anxiety.

On this page: What is this for · Good use cases · What NOT to use this for · How this connects · Before you start · Where to find it · The building blocks · Honest limits · Steps · Troubleshooting

What is this for?

This overview exists so you can answer one question before you commit: does the platform cover the work I need to do, and where will I hit a wall?

SGEN is a content management platform with server-side rendering at its core. The building blocks ship together as one system rather than as a base install plus a tower of add-ons. That means the capability list below is the whole surface — there is no separate marketplace you assemble afterward to reach a working site.

The platform groups into six working areas. Each row is a real area you operate from the dashboard.

The point of reading this page first: you map your requirements to these areas, then you read the limits section to confirm none of your must-haves land in a boundary.

Good use cases

Reach for SGEN when your requirements match the shape of the platform — a content-driven site that needs design control, data capture, and commerce without a stack of add-ons.

• A marketing site that has to load fast. Server-side rendering ships finished HTML to the browser, so pages arrive ready rather than waiting on client-side assembly. The visual Site Builder controls the layout; Themes and global Styles control the look.
• A site that collects leads. Forms capture submissions, store them, and report on leads by source and over time. Submissions export to a spreadsheet, and Form Integrations push entries to outside destinations.
• A small-to-mid catalog store. Products, Categories, and Attributes model the catalog. Coupons run promotions. Orders, refunds, and order notes handle fulfilment. Card payments at checkout are processed through Stripe.
• A content publisher. Blog with categories and tags, Events with categories, revision history on every post, and per-area SEO controls cover the publishing workflow.
• A multi-location business. Locations model each site or storefront, sync from a source list, and surface a public locator. Phone Taps log click-to-call interest.
• A site a developer extends rather than rebuilds. Custom Codes, Custom CSS, and Custom Fonts are the extension surface — paste a vendor snippet once and it runs site-wide, with no plugin to install, update, or watch break.

What NOT to use this for

Name the mismatch early. These are the cases where SGEN is the wrong tool, and trying to force them ends in disappointment.

• A booking or appointment business that needs a calendar engine. There is no bookings module in the platform. You would be hand-building scheduling on top of Forms, which is not what Forms is for.
• A membership or recurring-subscription product. The store handles products, coupons, orders, and one-time card checkout. There is no recurring-billing or gated-membership module.
• An online course platform. There is no courses or learning-management surface. Content can describe a course, but the platform will not run lessons, progress, or enrolment.
• A site whose growth depends on built-in A/B testing. There is no experimentation or split-test module. You would route experiments through an external tool added via Custom Codes.
• A multi-language site that needs a translation workflow. There is no built-in translation or locale-switching module. Each language version is authored as its own content.
• A site that needs to be assembled from third-party plugins. There is no plugin marketplace. If your plan assumes "we'll just add a plugin for that," confirm the capability is native first.

How this connects to other features

The building blocks are not islands — each capability hands off to a neighbour. Knowing the seams helps you pick the right one.

• Custom Codes and Custom CSS are the extension seam. When a capability is not native, the answer is a snippet site-wide, not a plugin. See Add a new custom code and Create a custom CSS snippet.
• Navigation is owned by the Menu Builder. Menus, the mobile menu, and the header/footer chrome are managed there rather than hand-coded into a content block. See Build a navigation menu.
• Analytics and Google integration sit beside each other. The built-in Analytics area reports events over time and top paths; the Google integration panel wires in your analytics property. See Event logs.
• Forms feed both reporting and integrations. A single form is the source for submissions, the lead reports, the spreadsheet export, and any connected outside destination.
• Backups underpin migration. The same backup-and-restore surface that protects a site is the path you use to move content between SGEN sites.
• SEO and Redirects work together on a rebuild. Per-area SEO controls protect rankings while Redirects preserve old URLs, so a rebuilt site keeps the equity it earned.
• Consent and protection combine for compliance. Tracking Consent, the age-verification gate, and Site Protection are separate switches you mix to meet a gating or compliance need.

Before you start

To get an accurate read on whether the platform fits, have these ready before you evaluate:

• A written list of your must-have building blocks. Pull them from your current site or your spec. Be specific: "lead form with spreadsheet export" maps cleanly; "marketing automation" does not.
• A trial or staging site to click through. Capability lists are a starting point; a working dashboard confirms the fit. Map each must-have to a real area and try it.
• Your media inventory in a supported format. The media library accepts PNG, JPG, and WEBP. If your assets are SVG, plan to convert them before upload.
• Your payment expectations. If you sell, confirm that one-time card checkout through Stripe matches your model. If you need recurring billing, that is a boundary, not a feature.
• Your extensibility plan. Decide which gaps you will fill with Custom Codes and which are genuine deal-breakers. The custom-code surface covers a lot, but it is snippets, not a plugin system.

Where to find it

Everything described here is reachable from the admin dashboard sidebar. The capability areas map to sidebar groups:

• Content lives under Pages, Posts, Blog, and Events.
• Design lives under Appearance (Themes, Header, Footer, Menu, Mobile Menu, Widgets, Styles & Layouts, Fonts, Icons) and the Site Builder that opens from a page.
• Data capture lives under Forms, Custom Fields, and Custom Objects.
• Commerce lives under the Ecommerce group: Products, Orders, Coupons, and Configuration.
• Audience lives under Media, Popups, Discussions, Locations, and Phone Taps.
• Operations lives under SEO, Redirects, Analytics, Users, Migration, Tools, and Settings.

There is no separate "capabilities" screen in the product — the dashboard sidebar is the capability map. This page mirrors it so you can evaluate without logging in.

The building blocks SGEN provides

This section is the detailed catalog. Each table is a real area of the platform, described in plain product terms.

Capability checklist (quick reference)

A fast yes/no scan before the detailed tables. A "Yes" is native to the platform; a "No" is a real boundary covered in the limits section.

Content: pages, posts, templates

The content system is where pages and posts are created, organized, and versioned.

Design: builder, themes, navigation, custom code

The design system controls layout, look, and navigation.

Data capture: forms, custom fields, custom objects

The data-capture system collects, stores, reports on, and routes visitor input.

Commerce: products, orders, coupons, checkout

The store covers catalog, promotions, fulfilment, and card checkout.

Audience: media, blog, events, popups, discussions, locations

The audience system covers assets, publishing, engagement, and presence.

Operations: SEO, redirects, analytics, users, backups, settings

The operations system keeps the site discoverable, measured, protected, and recoverable.

Foundations: performance, background work, and recovery

Underneath the visible areas sit the platform foundations — the parts that keep a site fast, current, and recoverable. These are not pieces you build with; they are behaviours the platform provides.

The release model matters to evaluators as much as the feature list. Because the platform is one system rather than a base install plus a tower of add-ons, there is no plugin version matrix to reconcile on every update — the part of site maintenance that turns into update anxiety on a plugin stack. Updates land at the platform level, and the building blocks stay in step with each other.

Honest limits and boundaries

This is the section evaluators come for. Each limit is real, named, and sourced from the platform itself rather than softened.

Vertical modules that do not exist

Some sites need a vertical engine the platform does not provide. These are not on the roadmap section of this page — they are not in the product at all:

• Bookings / appointments — no scheduling engine.
• Memberships / subscriptions — no recurring-billing or gated-access module.
• Courses / LMS — no lessons, progress, or enrolment.
• A/B testing — no native experimentation or split-test surface.
• Translations / multi-language — no built-in locale switching or translation workflow.

If your project depends on one of these, plan for an external tool wired in through Custom Codes, or confirm it is genuinely required before choosing the platform.

The data services surface, in plain terms

Developers evaluating the platform tend to ask the same first question: is there an API I can build against? The honest answer for v1 is narrow. The platform exposes data services for installation, provisioning, theming, and a small set of reads — order status, site details, locations, and theme colors among them. There is no general read-write content API that an outside program drives to create or edit pages, posts, or products. Content is authored and managed in the dashboard.

For most integration needs this is less of a blocker than it first appears. Outbound connections — analytics, pixels, chat, marketing tools — attach through Custom Codes and Form Integrations rather than through a service you call from your own code. If your plan depends on an outside system writing content into the site programmatically, treat that as a boundary and confirm the approach before you commit.

Steps — Evaluate SGEN against your requirements

Use this procedure to turn the capability map into a go or no-go decision.

1. List your must-have building blocks

Write down every capability your site cannot launch without. Pull them from your current site or your spec. Phrase each one concretely — "product catalog with coupons," "lead form with spreadsheet export," "multi-location locator" — so each maps to a named area rather than a vague theme.

2. Map each must-have to a platform area

Walk your list against the six areas in the catalog above. For each item, find the area that owns it. Items that map cleanly are covered. Items you cannot place are your risk list — carry them to the next step.

3. Check your risk list against the limits

Take every unmapped item and read it against the limits and the vertical-modules list. If a must-have lands on a boundary — bookings, memberships, courses, A/B testing, translations, a plugin dependency, or a content API — flag it. A flagged must-have is a real decision point, not a detail.

4. Decide the extensibility approach for each gap

For each gap that is not a hard boundary, decide how you will fill it. Most integrations — analytics, pixels, chat, third-party widgets — are a snippet in Custom Codes. Confirm the gap is snippet-shaped and not something that needs a native module.

5. Validate the fit in a trial site

Open a trial or staging site and try your top three must-haves end to end. A capability list tells you what exists; a working dashboard tells you it fits your workflow. Finish this step before you commit.

What success looks like

A complete evaluation ends with a clear, defensible answer rather than a hunch.

You should be able to say, for every must-have on your list, which area owns it or which boundary blocks it. Your risk list should be empty, or short and accepted with an extensibility plan attached. Nothing on your list should be a surprise after launch.

A good outcome also means you have separated wants from needs. If the only blockers are vertical modules the platform does not provide, you have a precise, factual basis for the decision — not a vague worry.

Troubleshooting

These are the confusion points evaluators hit most. Each one has a plain clarification.

1. "I can't find the API documentation." There is no general public content API in v1. The platform's data services are for installation, provisioning, theming, and limited reads. Content is managed in the dashboard, not driven by an outside program.
2. "The importer won't take my other-platform export." Migration moves content between SGEN sites only. A site from elsewhere is rebuilt in the Site Builder; there is no automatic import of third-party formats.
3. "My SVG logo won't upload." The media library accepts PNG, JPG, and WEBP. Convert the asset to a supported raster format and upload again.
4. "Where is the bookings / memberships / courses module?" These vertical engines are not in the product. Confirm whether your project genuinely requires one before choosing the platform.
5. "My hand-coded menu markup disappeared after saving." Navigation is owned by the Menu Builder. Build the menu there rather than placing navigation markup inside a content block, where it is stripped on save.
6. "I expected a plugin for that." There is no plugin marketplace. Check whether the capability is native; if not, the extension path is a snippet in Custom Codes.

If a capability you need is missing from both the catalog and the limits, treat it as absent and verify in a trial site before relying on it.

Examples

Three concrete evaluator scenarios, each with the decision the platform supports.

Example 1 — A regional cafe chain. Requirements: a fast marketing site, a store-locator across twelve sites, a contact form with spreadsheet export, and click-to-call tracking. Every item maps cleanly: Pages and Themes for the site, Locations for the locator, Forms with export, and Phone Taps for calls. Outcome: covered, no risk list. The platform fits without an add-on.

Example 2 — A boutique apparel store. Requirements: a 200-product catalog, coupons, card checkout, and a blog. Catalog, Categories, Attributes, Coupons, Stripe checkout, and Blog all map. The one open question — recurring subscription boxes — lands on a boundary: there is no recurring-billing module. Outcome: covered for the launch catalog, with the subscription idea flagged as a future external integration, decided up front rather than discovered later.

Example 3 — A training company. Requirements: marketing pages, lead forms, and a full course platform with lessons and enrolment. Pages and Forms map; the course platform does not — there is no LMS surface. Outcome: a precise no-go for the course portion. The company can run its marketing site on SGEN and host courses on a dedicated tool, a clean split made on facts rather than after a failed build.

Example 4 — An agency moving a client from another platform. Requirements: rebuild a brochure site, keep the existing URL structure, and protect search rankings. The rebuild maps to Pages, Templates, and the Site Builder; the URL structure maps to Redirects; rankings map to the per-area SEO controls. The one constraint is the rebuild itself — there is no automatic import from the old platform, so the content is recreated in the Site Builder rather than pulled in. Outcome: covered, with the rebuild effort scoped honestly from day one instead of discovered mid-project.

Where this leaves you

Read together, the capability catalog, the limits, and these examples give you a decision you can defend to a stakeholder. The platform covers content, design, data capture, commerce, audience, and operations as one system. The boundaries are few and named: no plugin marketplace, no general content API, no native cross-platform import, and no vertical modules for bookings, memberships, courses, A/B testing, or translations. Match your must-haves against that, and the choice stops being a guess.

Related reading

• Add a new custom code — the primary extension surface for capabilities that are not native.
• Create a custom CSS snippet — site-wide styling without a plugin.
• Build a navigation menu — the Menu Builder that owns site navigation.
• Event logs — the built-in analytics that report events and top paths.