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.”

So: do you show only what’s ready, or do you show the full vision?

Showing the Vision

We went with the full product listing. 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.

This was a deliberate choice, and we debated it. The argument against is obvious: showing products that don’t exist yet could feel like vaporware. If a developer clicks through to Smpl Secrets and finds a placeholder, that’s a mild disappointment.

But the argument in favor is stronger. Developer platforms are evaluated on breadth. When an engineering team is deciding whether to adopt a config service, they want to know: is this a one-trick pony, or is it a platform I can grow into? Showing the full product lineup communicates that smplkit solves a category of problems, not just one.

The Coming Soon pages aren’t vaporware because we’re transparent about it — the badge is right there, the page doesn’t pretend the product is ready, and the email capture gives interested developers a way to stay informed.

Dedicated Pages Over a Single Product Page

The tempting alternative was a single page listing all products — a product catalog. This works fine for three products. It falls apart at fifteen.

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

The navigation flyout makes the full suite discoverable without cluttering the main nav bar. A developer can scan all fifteen products in a single dropdown without leaving whatever page they’re on.

Code Examples Belong on Product Pages

Our first version of the homepage included code snippets — a quick look at the SDK in action. We moved those to the product pages instead.

The homepage’s job is platform messaging: what is smplkit, why does it exist, who is it for. Code examples are product-level detail. A developer who wants to see how the Config SDK works should find that on the Config page, where they’ve already committed attention to that specific product.

This also scales better. When Smpl Flags ships, its code examples live on its own page. The homepage stays clean regardless of how many products we add.

The SEO Angle

Each product page is a landing page for a distinct search query. “SaaS configuration management API,” “feature flags as a service,” “managed secrets storage” — these are different searches with different intent. Dedicated pages let us target each one individually with relevant content, titles, and descriptions.

A single product catalog page can’t rank for fifteen different keyword clusters. Fifteen individual pages can.

What This Looks Like in Practice

The navigation flyout lists all fifteen products in a three-column grid. Clickable products (the ones that are live) link to their full product page. Products that aren’t ready yet show their name and icon but aren’t linked — no dead ends.

The product page template is consistent: product icon, name, description, feature highlights, and either full content with code examples (for shipped products) or a Coming Soon section with an email capture form (for upcoming products).

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

Lessons from Getting This 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. It worked for three products. By the time we had the full roadmap of fifteen, the page was overwhelming and unfocused.

The refactor to dedicated product pages took about a day. It would have taken less if we’d started there. The information architecture of a multi-product platform is not something you can “evolve into” gracefully from a single-page layout. The URL structure, the navigation model, the component templates — they’re all different.

If you’re building a multi-product platform and you have even a rough idea of your product lineup, start with dedicated pages and a flyout navigation. You can always simplify later if you have fewer products than expected. Going the other direction — from flat to structured — means rewriting navigation, creating redirect rules for URLs that are already indexed, and probably redesigning the page layout.

smplkit is a platform of operational services for SaaS teams. We’re starting with Smpl Config, with more products on the way.