Do I need all three products?

Almost certainly not. Most people need one. StoryPages if you need a website with a CRM and email behind it. StoryOS if your problem is running the internal work — projects, clients, operations — in a system you define. StoryFunnels if you would rather have the launch built with you than build it yourself.

Is StoryOS just the back end of StoryPages?

No, and this is the most common misunderstanding. They are separate products with separate codebases, plans, and audiences. StoryOS is an open-source, self-hostable work OS that many people use with no website involved at all. StoryPages is a hosted AI website builder with a marketing CRM attached.

Are StoryPages and StoryOS integrated out of the box?

Not with deep prebuilt sync, and we would rather say so than imply otherwise. What both expose is an MCP server and an API, which means an AI assistant or a developer can work across the two. If you want a form submission on your site to create a record in a StoryOS database, that is an API or automation you build, not a toggle you flip.

Which one has the CRM?

StoryPages has a marketing CRM — contacts, tags, lists, custom fields, source, last activity, form submissions. StoryOS can model a CRM, because you define your own relational databases, but it ships as a blank capable system rather than a preconfigured marketing CRM. Different tools for different jobs.

Is StoryOS really open source?

Yes, AGPL-3.0, and self-hostable. If you want to run it on your own infrastructure and never pay us, that is a supported path. The hosted plans are free, $29 per workspace for Pro, and $99 per workspace for Business, with no record limits ever, and viewers and commenters always free.

What does StoryFunnels actually do?

It is the agency and funnel practice — story-driven funnel strategy and build work done with you rather than by you. It exists because some people do not want software, they want the outcome, and because that practice is where we learned most of what is now in the products.

Why not merge everything into one product?

Because the jobs are genuinely different, and merged products serve neither audience well. A marketing website builder and a general-purpose relational work OS have almost nothing in common in their data models, their users, or their pace of change. Keeping them separate is the reason each one is good at its own thing.

StoryPages vs StoryOS vs StoryFunnels: Which One Do You Need?

Three products with the same prefix invites a fair question: is this a suite, or is it three things a company happened to build?

It is neither, exactly. It is one observation split across three shapes.

Over years of building 300+ client websites and funnels, we kept meeting the same business with the same three unmet needs, and they were never the same need. A consultant needed a public site that would keep working without us. She also needed somewhere to run the actual work — clients, engagements, deliverables — that was not a spreadsheet. And sometimes what she wanted was not software at all but a person to build the launch with her.

Most software suites are one product with three price tiers. These are three products because the jobs do not overlap: your public face, your internal machine, and the human help.

Here is the division of labour, and — more usefully — what each one is not.

StoryPages: your public face and the front office attached to it

StoryPages is an AI website builder with the marketing front office built in.

The build path is a conversation: you describe your business, approve a style direction, approve a sitemap, approve wireframes, and the site goes live. Then you keep editing by talking to it.

The StoryPages AI builder with a consultant's business description typed into the prompt box — The entire starting surface for StoryPages: a description of your business, not a canvas.

Attached to the site, in the same product: a CRM, email marketing, a funnel builder, and hosting with domains and SSL. Webinars and calendar booking are on the roadmap — not shipped, and I am not going to pretend otherwise.

The differentiator we care most about is AI visibility, on by default. Structured data, llms.txt, semantic HTML, fast static pages — because a growing share of your buyers ask an assistant for a recommendation before they ever see a search results page.

StoryPages is not an internal operations tool. It does not model your delivery process, your project pipeline, or your custom business objects. If you find yourself trying to bend the contact record into a project tracker, you have reached the edge of the product and the answer is the next section.

StoryOS: where the business is actually run

StoryOS is an API-first work OS, and it is open source — AGPL-3.0, self-hostable if you want it on your own infrastructure.

The core idea is that you define the data model. Not “projects and tasks” as handed down by a vendor, but the relational databases your business actually has: engagements linked to clients linked to deliverables linked to invoices, with the fields and relations you decide on. Eight view types sit on top of that data — the same records shown as a table, a board, a calendar, and so on — plus automations for the work that should happen without you.

It also ships a native MCP server, which matters more than it sounds. It means an AI assistant can query and modify your operational data directly, as a first-class capability rather than a scraped API bolted on afterwards.

Pricing is a free plan, $29 per workspace for Pro, and $99 per workspace for Business — per workspace rather than per seat, with no record limits ever, and viewers and commenters always free. That pricing shape is deliberate: it means inviting your whole team to look at things costs nothing, which is how internal tools actually get adopted.

StoryOS is not a website builder. It has no page builder, no themes, no marketing email, no public-facing site to speak of. It is also not a preconfigured CRM — it can model one very well, but it hands you a capable blank system rather than an opinionated marketing pipeline. If you want contacts, tags, and broadcast email working this afternoon, that is StoryPages.

StoryFunnels: the practice, not a product

StoryFunnels is the story-driven funnel work and the agency services — done with you rather than sold to you as software.

Some people do not want a tool. They want the launch to exist, they want someone with pattern recognition to argue with them about the offer, and they want the narrative to be right before anything gets built. That is a service, and pretending it is a SaaS feature has never worked for anyone.

It is also worth saying that this practice is where the products came from. The reason StoryPages has opinions about sitemaps and story order is that we built hundreds of funnels by hand first and learned which sequences work.

StoryFunnels is not self-serve, and it is not the cheap option. If your budget is a monthly subscription, start with the software.

Which one you need, in one pass

Pick the first that describes you.

“I need a professional website, and a list I can actually email.” → StoryPages. See the plans.
“My website is fine; my problem is that the work runs on twelve spreadsheets.” → StoryOS.
“I need both, and I know it.” → Start with the one that is bleeding. In our experience that is usually the website, because it is the one your buyers see.
“I want it built with me, by people who have done it before.” → StoryFunnels.
“I want to self-host and own my data outright.” → StoryOS. It is the only one of the three that is open source.

Notice that four of those five answers are one product. That is intentional. We are not trying to sell you a suite.

The connective tissue, described honestly

This is the section where most ecosystem articles overclaim, so let me be precise about what does and does not exist.

What exists: both StoryPages and StoryOS expose MCP servers, and both have APIs. That combination is genuinely useful. An AI assistant connected to both can read your public site structure and your internal operational data in the same session — “which of the clients in my delivery database came in through the consulting page, and what did we last ship them” spans both systems and is answerable without a single export.

The StoryPages workspace integrations screen showing connected services and API access — Where the edges are kept open. Details of what connects today are on the integrations page.

What does not exist: a deep prebuilt two-way sync between StoryPages and StoryOS. There is no toggle that mirrors your CRM contacts into a StoryOS database. If you want a form submission on your site to create a record in your internal system, you build that with the API or an automation. It is a normal amount of work for a technical person and a real amount of work for a non-technical one.

We would rather you know that now than discover it after signing up for both. More on the current surface at integrations and the MCP server.

Why we did not merge them

The obvious product-strategy question: why three logins instead of one?

Because the data models have almost nothing in common. A website builder needs pages, sections, themes, sitemaps, and a contact record shaped for marketing. A work OS needs user-defined schemas, arbitrary relations, views, and permissions shaped for internal collaboration. Merging them produces a tool that does marketing badly and operations badly, which is a description of several products you have probably tried.

They also change at different speeds and serve different buyers. StoryPages serves a non-technical owner who wants the thing done. StoryOS serves someone who wants to model their own business precisely, including developers, including people who will read the source. Those are not the same person and they should not be forced into the same onboarding.

The thing they share is a bet: that AI assistants are becoming a primary interface to software, and that the products which expose themselves properly to those assistants — through MCP, through clean APIs, through machine-legible public pages — will be the ones worth using in three years. That bet is why both products shipped MCP servers early, and why every StoryPages site ships AI visibility by default.

The short version

StoryPages is your public face and the front office attached to it: website, CRM, email, funnels, AI visibility. Hosted, non-technical, see how it works.

StoryOS is the internal machine: user-defined relational databases, eight view types, automations, native MCP. Open source, self-hostable, storyos.dev.

StoryFunnels is the human help: story-driven funnels built with you. storyfunnels.ai.

Pick one. Add another only when you can name the specific thing it fixes.

StoryPages, StoryOS, and StoryFunnels: how the pieces fit