Information architecture for a multi-product SaaS platform

Here’s a question that sounds simple until you try to answer it: how do you organize a website for a product that doesn’t exist yet?

smplkit isn’t one product. It’s a platform of operational services — Config, Flags, Logging, Secrets, Jobs, and about ten more. When we launched the marketing site, exactly one of those products was ready. The rest were roadmap items with varying degrees of “coming soon.”

We got it wrong first

Our earliest version of the site put everything on one page: a long scrolling page with product cards, code examples, pricing, and a signup form. For three products this worked fine. By the time the roadmap had grown to fifteen, the page was overwhelming and unfocused.

The refactor to dedicated product pages took about a day, and it would have taken less if we’d started there. The lesson worth passing on: the information architecture of a multi-product platform is not something you evolve into gracefully from a single-page layout. The URL structure, the navigation model, the component templates — all different. Going from flat to structured means rewriting navigation, adding redirect rules for URLs already indexed, and probably redesigning the page layout. Going the other direction is no trouble — you can always simplify later if you end up with fewer products than expected. Start structured.

Show the vision, or only what’s ready?

With the structure settled, the harder question: do you show only the products that exist, or the full lineup?

We went with the full lineup. Every product gets a dedicated page at /products/{name}, a spot in the navigation flyout, and its own icon. Products that aren’t ready show a Coming Soon badge and an email capture form.

We debated this, because the argument against is obvious: showing products that don’t exist yet can read as vaporware. A developer who clicks through to Smpl Secrets and finds a placeholder has every right to a moment of disappointment.

Here’s why we did it anyway. Developer platforms are evaluated on breadth. An engineering team deciding whether to adopt a config service wants to know whether they’re buying a one-trick pony or a platform they can grow into. Showing the full lineup communicates that smplkit is aimed at a category of problems, not one problem.

And the line between vision and vaporware, as far as we can tell, is honesty about the present. Vaporware pretends the product is ready. A Coming Soon page with the badge right there, no fake screenshots, and an email form for anyone interested is a roadmap, stated publicly. The reader can judge whether to believe it.

Fifteen pages, not one catalog

The tempting alternative was a single catalog page listing every product. That works fine at three products and falls apart at fifteen.

Dedicated pages give each product its own URL for SEO, room for code examples and technical detail, and space to grow into a full landing page when the product ships. When we eventually write SDK documentation for Smpl Flags, there’s already a /products/flags page to link to and build on.

The navigation flyout is what keeps fifteen products from cluttering the nav bar: the full suite, scannable in one dropdown, from any page on the site.

Code examples belong on product pages

The first version of the homepage had code snippets on it — a quick look at the SDK in action. We moved them to the product pages.

The homepage’s job is platform messaging: what smplkit is, why it exists, who it’s for. Code is product-level detail. A developer who wants to see how the Config SDK works should meet it on the Config page, where they’ve already committed attention to that specific product. It scales better, too — when Smpl Flags ships, its examples live on its own page, and the homepage stays clean no matter how many products we add.

The SEO angle

Each product page is a landing page for a distinct search. “SaaS configuration management API,” “feature flags as a service,” “managed secrets storage” — different queries, different intent. Fifteen pages can each target their own keyword cluster with relevant content, titles, and descriptions. One catalog page can’t rank for fifteen clusters.

What it looks like in practice

The flyout lists all fifteen products in a three-column grid. Live products link to their full pages; products that aren’t ready show their name and icon but aren’t linked — no dead ends. The product page template is the same everywhere: icon, name, description, feature highlights, and then either real content with code examples or a Coming Soon section with the email form.

As products ship, the template fills in naturally. No information architecture changes required.