Why we built Apollo Space

The Tab Count That Broke Me

In January 2025, I had 47 browser tabs open. I know this because Chrome crashed and told me.

Fourteen of those tabs were different SaaS dashboards. Pipedrive for sales. Linear for engineering. Notion for docs. Slack for everything else. Google Analytics for traffic nobody was looking at. AWS console for infrastructure nobody understood except me. Three different monitoring tools because no single one covered everything. A spreadsheet that was supposed to be our “single source of truth” but was updated by nobody.

I’m the CTO of Moonxi. We’re a software consultancy. At the time, we had eight people and twelve active client projects. The math was simple: we were generating more operational overhead than we were generating revenue per hour.

That afternoon, after Chrome recovered, I closed every tab except one. I opened a blank document and wrote a single sentence: “What if the dashboards did the work instead of showing me the work?”

That sentence became Apollo Space.

The Real Problem Isn’t Tools, It’s the Gaps Between Them

Every founder I’ve talked to in the last year has the same disease. I call it SaaS fragmentation syndrome. You start with a simple stack. CRM, project management, maybe a communication tool. Then a client needs invoicing, so you add that. Then you realize you need monitoring, so you add that. Then someone quits and you realize half the process knowledge lived in their head and the other half in a Notion page nobody can find.

McKinsey published a report in 2024 showing that the average company with 50-200 employees uses 89 different SaaS applications. For companies under 50, it’s still 34. That’s 34 tools that don’t talk to each other, each with its own notification system, its own mental model, its own version of the truth.

But here’s what nobody talks about: the real cost isn’t the subscriptions. It’s the cognitive overhead.

A 2023 study by Qatalog and Cornell found that knowledge workers spend 58 minutes per day just searching for information across tools. That’s 5 hours a week. 250 hours a year. Six full work weeks spent not working, but looking for the context needed to work.

At Moonxi, we were worse than average. We had client-facing tools, internal tools, and tools that existed solely to bridge other tools. Zapier was our duct tape. We had 67 active Zaps at one point. Sixty-seven automated workflows, each one a tiny bridge between two systems that should have been one system.

When a Zap broke, and they broke constantly, someone had to diagnose which bridge collapsed, figure out which data was now out of sync, and manually patch things together. That someone was usually me, at 11 PM, because the broken Zap was between our monitoring system and our alerting system, and nobody else understood how they were connected.

The Moment I Stopped Thinking About Tools

In March 2025, I was on a call with Marcelo, my co-founder and CEO. He was frustrated. We’d just lost a deal because our follow-up was slow. The prospect had gone cold. The data was in Pipedrive, but nobody had checked it. The reminder had fired in Slack, but it was buried under 200 other notifications.

“We need to hire an SDR,” Marcelo said.

“We need to hire three people,” I said. “An SDR, someone to manage the CRM, and someone to make sure the SDR and the CRM person are actually doing their jobs.”

He laughed. I didn’t. Because I was serious, and the math was devastating. A junior SDR in Brazil costs around R$4,000/month. A CRM manager, another R$5,000. Suddenly you’re looking at R$120,000/year in new headcount to solve what is fundamentally an information-routing problem.

That night, I started building what I called “the SDR script.” It was ugly. A Python script that connected to our CRM API, pulled stale deals, drafted follow-up emails using GPT-4, and sent them to a Slack channel for approval. It took me four hours to build.

The next morning, it had surfaced six stale deals. Marcelo approved the follow-ups with a thumbs up in Slack. Two of those deals re-engaged that week.

I didn’t know it yet, but that was the first Apollo Space agent.

From Script to System

Over the next three months, I built more scripts. A QA agent that ran automated tests on staging environments and posted results before anyone asked. A meeting digest agent that consumed our Fireflies transcripts and extracted action items. A competitor watch agent that monitored five competitors’ blogs and pricing pages for changes.

Each script solved a specific problem. But together, they created a new problem: I was now maintaining a micro-SaaS empire of my own making. Twelve scripts, each with its own cron job, its own failure modes, its own logging. I had replaced dashboard fatigue with script fatigue.

The breakthrough came when I realized these scripts weren’t independent. They were a team. The SDR agent needed data from the deal intelligence agent. The QA agent’s results informed the code review agent. The meeting digest agent fed into the team intelligence agent.

What I needed wasn’t twelve scripts. I needed an operating system for them. A way to coordinate, prioritize, and escalate. A way for agents to communicate with each other and with humans, using a shared context.

That’s when Apollo Space stopped being a side project and became a product.

The Architecture of Doing

Most AI products I’ve seen are what I call “AI garnish.” They take an existing SaaS product and add a chat interface. Ask your CRM a question in natural language. Get an AI-generated summary of your dashboard. It’s cute. It’s also useless for anyone drowning in operational work.

The fundamental design decision in Apollo Space was this: agents don’t wait. They act.

Apollo Space’s SDR agent doesn’t wait for you to ask “who should I follow up with?” It checks your pipeline every four hours. It identifies stale deals using criteria you set once. It drafts outreach. It queues it for your approval or, if you trust it enough, sends it autonomously.

Apollo Space’s QA agent doesn’t wait for a developer to run tests. It watches your staging environment. When a deploy lands, it runs the test suite, compares screenshots for visual regressions, and posts a report. If something breaks, it creates a ticket and assigns it before any human even knows the deploy happened.

This is the difference between a dashboard and an agent. A dashboard is a window. An agent is a colleague.

Why We Almost Didn’t Build It

I want to be honest about something. We almost killed Apollo Space three times.

The first time was in June 2025, when our consultancy work picked up and we didn’t have bandwidth. Building an AI product while running a consultancy is like changing the engine while the car is moving. We almost decided to just keep the scripts internal and focus on client work.

The second time was in September 2025, when the AI hype cycle hit its local maximum and every startup was claiming to be an “AI agent platform.” I remember scrolling through Product Hunt and seeing five launches in a single day with the word “agent” in the name. The market felt saturated before we even entered it.

The third time was in December 2025, when a potential investor told us the market was “too horizontal.” You’re trying to do too many things, he said. Pick one agent and go deep.

We ignored him. Not out of arrogance, but because we’d learned something from running our own agents: the value isn’t in any single agent. It’s in the network effect between them. An SDR agent is useful. An SDR agent that’s informed by deal intelligence, competitive analysis, and meeting context is transformative. You can’t get that by going narrow.

What Apollo Space Is Today

Apollo Space is an AI operating system. Four directors, Growth, Ops, Finance, and Custom, manage twelve execution agents. The directors handle prioritization and escalation. The agents do the work.

The Growth Director manages the SDR agent, Deal Intelligence agent, and Content agent. When the SDR agent identifies a warm lead, the Deal Intelligence agent enriches the profile with firmographic data, and the Content agent can draft personalized outreach based on the prospect’s recent activity.

The Ops Director manages QA, Code Review, Observability, and Meeting Digest agents. When the Observability agent detects an anomaly, it can trigger the QA agent to run targeted tests and the Code Review agent to check recent commits for related changes.

The Finance Director manages the Budget Monitor agent. The Custom Director handles Team Intelligence, Competitor Watch, and Post-Sale Health agents.

It’s not a chatbot. It’s not a dashboard. It’s a workforce.

The Lesson We Learned Building It

Here’s what I wish someone had told me two years ago: the future of software isn’t intelligence. It’s agency.

Intelligence is knowing the answer. Agency is doing something about it. Every LLM on the market has intelligence. Very few products have agency. And agency requires something that’s much harder to build than a prompt chain: it requires an opinion about how work should flow.

Apollo Space has opinions. It believes stale deals should be followed up within 48 hours. It believes staging deploys should be tested within 15 minutes. It believes meeting action items should be extracted and assigned within an hour of the meeting ending. It believes budget anomalies should be flagged immediately, not discovered in a monthly review.

These opinions aren’t hardcoded. They’re configurable. But the fact that Apollo Space has defaults, that it ships with a point of view about how operations should work, is what makes it different from a toolkit.

A toolkit says: here are the pieces, assemble them yourself. An operating system says: here’s how the pieces fit together, and here’s what happens when you turn it on.

We built Apollo Space because we were tired of assembling. We were tired of being the glue between systems. We were tired of the cognitive overhead of managing tools that were supposed to reduce our cognitive overhead.

If you’ve ever stared at 47 browser tabs and felt the weight of all the operational work hiding behind them, Apollo Space was built for you. Because it was built by someone in exactly that position.

And honestly? The best part isn’t that Apollo Space does the work. It’s that I stopped opening those tabs. The SDR agent follows up. The QA agent tests. The meeting digest agent summarizes. I wake up, check one dashboard, the Apollo Space dashboard, and I know the state of everything.

That’s not efficiency. That’s sanity.