Five products, one engine
One engine, a different landing page per vertical, because mixing them kills conversion for all.
Apollo Space Research
Apollo Space
A sales director and a finance controller walk into the same website. The director wants software that never lets a warm lead go cold. The controller wants software that chases the unpaid invoice so she doesn’t have to. They have nothing in common, except that the exact same machine could do both their jobs, and a single homepage trying to promise both will close neither.
So we built one engine and five front doors. Each buyer arrives at a page that talks about one job, their job, and never learns there are four other versions of it.
That is the whole strategy, and the rest of this post is why it has to be that way. One engine, a different landing page per vertical, because mixing them kills conversion for all.
The temptation is one page that says “everything”
When you’ve built a system that can genuinely do a dozen jobs, the honest instinct is to say so. Put the dozen on the homepage. “An AI operating system for your whole business.” It’s true, it’s impressive, and it converts almost nobody.
Here’s why it feels right. The product really is general. The same scheduler that watches a sales pipeline watches an invoice ledger. The same memory that remembers a prospect’s last objection remembers a contract’s renewal date. From the inside, the generality is the achievement, so you want the front door to show it off.
From the outside, generality reads as vagueness. A buyer doesn’t arrive looking for a platform. They arrive carrying one specific, named pain, “leads slip through the cracks,” “contracts pile up unread,” “we’re always 60 days late on collections”, and they’re scanning your page for that exact sentence. When the page answers “we do everything,” the buyer hears “we do nothing in particular, including your thing,” and leaves. Generality is a feature of the engine and a bug on the landing page.
A buyer doesn’t shop for a platform. They shop for the end of one specific pain, and they leave the moment your page makes them translate.
One engine, a different landing page per vertical, because mixing them kills conversion for all.
Naming the pain is the entire job of the front door
Let’s stage the failure mode plainly, because we’ve watched it happen and it never looks like a mistake while you’re making it.
You write a homepage headline that you, the founder, find precise: “Proactive AI agents that act on your operations.” Every word is accurate. You ship it. Traffic comes. And the bounce rate is brutal, because each visitor has to do unpaid translation work: okay, “operations”, does that include my collections problem? Are “agents” the thing that would chase my invoices? Maybe? Let me check three competitors who just said “get paid faster” instead.
The naive fix is to add more words. List the use cases on the homepage so nobody has to guess. Now the page says it does sales and legal and finance and ops and renewals. The translation tax didn’t go away, it got worse. The finance controller now has to find her one line in a wall of five, and worse, she has to wonder whether a tool that spreads itself across five departments is any good at hers. A page that claims five specialties reads as having zero.
The version that works is almost insultingly simple. Give the controller a page whose headline is her sentence: “Invoices that chase themselves.” No translation. No wall of options. No wondering if this is for her. The page is a mirror of the pain she walked in with, and the only question left in her mind is how, which is exactly the question you want a buyer asking. The headline did its one job: it told her she’s in the right room.
There’s a measured version of this that every marketing team eventually learns the hard way. When a landing page’s headline matches the visitor’s intent, conversion climbs; when the visitor has to reconcile a generic claim with their specific need, they leave. Message-match is one of the most consistently cited levers in landing-page optimization (Unbounce: Message Match). The reason isn’t psychology trivia. It’s that attention on a cold page is measured in seconds, and a buyer spends those seconds deciding one thing, is this for me?, before they’ll spend any deciding is this good? If the headline forces the first question to stay open, the second question never gets asked.
Five buyers, five rooms, five mirrors. The engine never changes. Only the door does.
Why not just build five companies, then?
If each vertical needs its own page, its own headline, its own promise, the obvious objection is: aren’t these just five separate products wearing a trench coat? Why pretend there’s one engine at all?
Because the engine is where the entire advantage lives, and splitting it would throw that advantage away. Run the alternative forward honestly: five teams, five codebases, five separate agents, each re-solving the same hard problems in isolation. Each one has to figure out how to schedule work on its own clock. Each one has to build a memory that doesn’t forget. Each one has to learn how to safely act on a buyer’s behalf without doing something reckless. Five times the hard part, solved five different ways, none of them learning from the others.
The shared engine means the hard part is solved once. The way an agent earns the right to act, read-only first, then draft-and-confirm, then send-and-notify, then act-and-report, is the same discipline whether it’s sending a follow-up or flagging a contract clause. The memory layer that lets the sales agent remember a prospect across six weeks is the identical machinery that lets the finance agent remember which client always pays late. Build that once, build it well, and every vertical inherits it the day it’s born.
There’s a second reason the trench-coat objection misses, and it’s about who you’re selling to. The five buyers don’t compete, they often sit in the same building. The sales director and the controller and the ops lead work at one company, and the day after the director’s follow-ups start sending themselves, he mentions it to the controller, who is still chasing invoices by hand. With five separate companies, that’s a referral to a vendor she’s never heard of. With one engine behind five doors, it’s the same tool she can turn on for her own job by the end of the week, already knowing the people who run it. The shared engine isn’t only cheaper to build. It’s the thing that lets one happy buyer become the next five.
So the five products aren’t five companies. They’re five views onto one capability, the way a spreadsheet and a presentation are both views onto the same numbers. The buyer sees a tool shaped exactly like their problem. Underneath, it’s the same four primitives every time.
One engine, a different landing page per vertical, because mixing them kills conversion for all.
The compounding nobody sees from the homepage
Here’s the part that only shows up over time, and it’s the reason this structure beats five real companies even on their own turf.
A standalone collections tool gets better at collections. That’s it. A collections product running on a shared engine gets better at collections and inherits every improvement the sales product earned this month, the legal product earned last month, the ops product is earning right now. When the team makes the engine remember context across longer time horizons because the renewals vertical needed it, the collections vertical wakes up smarter without a line of its own code changing. Improvements don’t stay in their lane. They flood the whole house through shared plumbing.
Run that forward and the gap widens on its own. A vertical specialist improves linearly, one team, one problem, one curve. A vertical view on a shared engine improves with the sum of every team’s work, the same way a city with one power grid lights up faster than five towns each wiring their own. The buyer chose a tool that says exactly one thing on the box. They got a tool that quietly compounds with four others they’ll never see.
This is the move that looks like a marketing decision and is actually an architecture decision. The five landing pages are not five paint jobs. They’re five honest contracts with five buyers, each backed by the same engine that’s getting better at all five jobs at once.
And it changes what “launch a new product” costs. For a company of five separate tools, a sixth product is a new company, a new team, a new codebase, a new everything, starting from a blank page. For one engine behind five doors, a sixth product is mostly a new door: a vertical’s worth of judgment about what matters in that job, a headline that names its pain, and the same primitives doing the work. The expensive part, the part that took years, was paid once. So the catalog can grow at the speed of understanding a new buyer’s job, not at the speed of rebuilding the machine. That’s why the strategy isn’t “five products.” It’s an engine that can wear as many faces as there are jobs worth doing well.
The turn: the page is a promise a person has to keep
None of this matters if the page lies.
A landing page that says “invoices that chase themselves” is making a promise to a real controller who is tired of being the one who chases. She doesn’t care about your engine, your shared memory, or your clever architecture. She cares whether, three weeks after she signs, the invoices are actually getting chased and she’s stopped being the person who does it. The page is the start of a relationship, not the end of a sale.
That’s the line we hold, and it’s the one part that doesn’t live in the engine. Anyone can write five headlines that name five pains, that’s an afternoon. The hard, human commitment is making each of those five promises true for the specific person who believed it, so the sales director’s follow-ups really do get sent, and the controller really does stop chasing, and neither of them ever needs to know they bought the same machine. The engine is the leverage. Keeping the promise on the page is the work that earns the right to use it.
A buyer trusts you with one sentence of their problem. Everything after depends on whether that sentence turns out to be true.
That’s what we’re building at Apollo Space: one engine that gets better at every job at once, behind a door for each buyer that speaks only their language. If you’ve ever bounced off a homepage that did everything except name the thing you came for, you already know why the door has to fit the person walking through it.
Apollo runs your company's repetitive ops so your team doesn't.
Join the waitlist for early access, founding-user pricing, and a front-row seat as we ship.
Join the waitlistPromotions are dead. Trust budgets replace them.
You won't promote an agent; you'll widen its trust budget one verified task at a time, and the same ledger should govern your people.
Automation ThesisThe job description is becoming a spec file
For an agent, a role becomes a versioned, testable spec, and that changes how you design every job, including the human ones.
Automation ThesisStop measuring output. Start measuring outcomes the company can’t forget.
An OS that remembers every decision and its result lets you grade the outcome, not the activity.