Why I built YetiGrowthOS — and why I’m going back to ChatGPT

I wanted my own AI operating system

A few weeks ago I started building something called YetiGrowthOS. The idea made a lot of sense on paper. I already had a growing collection of SaaSYeti products, websites, communities, customer information, ideas, experiments and decisions. I wanted one private system that could understand the whole business rather than treating every conversation or product as an isolated piece of work.

My aim was to create a kind of business operating system: a place where an AI Chief of Staff could remember the products I had built, understand the direction of SaaSYeti, keep evidence behind decisions, organise projects, delegate work to specialist AI agents and tell me what needed attention next.

That was the attraction. Instead of repeatedly explaining the business to an AI, I wanted the intelligence and structure to live inside my own system.

And, technically, it worked

YetiGrowthOS grew surprisingly quickly. I built a Business Brain, product and website records, evidence, decisions, projects, task orchestration, approvals, agent execution, dependencies and a Chief of Staff interface. I added safeguards so approving a project did not automatically give an AI agent permission to publish something, change pricing, contact customers or alter infrastructure.

I kept improving the workflow. Projects gained tasks. Tasks gained dependencies. Agent work gained approvals. Approvals were grouped by project. My Work was redesigned to show the next action. Then I simplified it again so I could tell the difference between something I physically had to do and something I was merely approving an agent to prepare.

None of those changes were unreasonable. In isolation, almost every one of them improved the system.

But together they exposed the most useful lesson I got from the whole experiment.

I was starting to manage the operating system instead of the business

The warning sign was simple: I could open My Work, Projects, Tasks or Approvals and still have to stop and work out what I was actually supposed to do.

Was I approving a task to exist? Was I approving an agent to work on it? Was this something the agent had already prepared? Was I expected to make the Facebook change myself? Was this task waiting for another task? Had the original strategy already been covered somewhere else?

The software knew more about the structure of the work, but I had to know more about the structure of the software.

That is the opposite of what I wanted.

The uncomfortable comparison was ChatGPT itself

At the same time, I was continuing to use ChatGPT directly for the work I actually needed to get done. I could say, “Here is the problem”, “What should I do next?”, “Build this patch”, “Look at this idea”, or “Write this for me”, and continue from there.

There was no project screen I had to maintain before asking the question. I did not have to decide whether something should first become a project, task, approval or decision record. I could explain the goal in ordinary language and get on with the work.

I eventually had to admit that I was putting a lot of effort into making YetiGrowthOS feel as straightforward as the ChatGPT conversation I already had.

That does not make YetiGrowthOS a failed build. In fact, it makes it a useful experiment because it showed me where the value really was.

The lesson: ownership is not the same thing as usefulness

I like owning my software and infrastructure. A big part of SaaSYeti is about building useful tools rather than being completely dependent on somebody else's stack. But this project reminded me that owning a version of something does not automatically make it better for the job.

If I spend ten minutes maintaining a workflow so that it can save me five minutes later, I have not automated anything useful.

There is also a hidden cost to every feature. It is not only the time required to build it. It is the mental cost of understanding it, deciding when to use it, maintaining it and dealing with the extra states it creates.

A task system creates tasks. An approval system creates approvals. A project system creates projects. All of them can be useful, but once they become another layer between the person and the work, the system has started serving itself.

So I have decided to stop

I have downloaded a final developer snapshot of YetiGrowthOS and I am keeping it locally. I am not planning another round of workflow redesigns in an attempt to rescue the original idea.

Instead, I am going back to using ChatGPT directly as my working Chief of Staff: talking through ideas, making decisions, planning products, creating patches, writing marketing material and working out what needs to happen next.

That is simply the interface that currently works better for me.

The Hetzner server that has been running YetiGrowthOS will not go to waste either. Rather than using server resources to host another dashboard for me to manage, I intend to repurpose it as a SaaSYeti Shared Services Server. The first planned service is the Yeti Research Engine at research.saasyeti.com, using Crawlee and Playwright to provide website research to products such as Yeti Editorial Studio and, later, other SaaSYeti applications.

That feels like a much better use of self-hosted infrastructure: let the server perform specialist jobs my SaaS products actually need, while I use the conversational tool that already works well for thinking and building.

What I would tell another AI SaaS builder

If you are building with AI, it is very easy to keep adding features because building them has become so much faster. That makes restraint more important, not less.

Before adding another dashboard, workflow, agent, database table or automation, I now think the better question is:

Does this remove work from the user, or does it give the user another system to operate?

If the answer is the second one, the cleverer solution may be not to build it.

Another lesson is that stopping a project is not the same as wasting the work. I learned a great deal from YetiGrowthOS about approvals, AI agents, evidence, structured business memory, project orchestration and the difference between automated work and human-governed actions. Those lessons will influence other SaaSYeti products even though I am retiring the operating system itself.

And perhaps the biggest lesson is this: build the smallest layer that genuinely improves the way you already work. Do not replace a simple working process with a sophisticated one merely because you can.

Building in public also means showing what I stop building

I have always wanted the SaaSYeti journey to show the real process rather than only publishing finished products and success stories. That means documenting the projects that change direction as well.

YetiGrowthOS started as a sensible attempt to give SaaSYeti its own AI-powered business brain. It became a capable system. It also became more complicated than I wanted my daily work to be.

So I am taking the lesson, keeping the snapshot, clearing the server and moving on.

Sometimes the useful outcome of building something is discovering that you no longer need it.