Why I Built Ciralia: One Place to Run Three Small Products
I run three products on my own: SwitchWithAI, Vitta and this site. Each has analytics, search data, a repository, content going out on several channels, and a list of small things that should be fixed this week.
For a long time my morning looked like this: Google Analytics, Search Console, GitHub, a publishing tool, the ads console, back to Analytics because I had forgotten the number. Twelve tabs to learn three things.
Ciralia is what I built to stop doing that. It is not a dashboard with more charts. It is the layer that reads those tools for me, tells me what changed, proposes what to do about it, and does it once I say yes.
The loop
Every part of Ciralia is one step of the same loop:
- Read. Pull what happened overnight: traffic, search queries, rankings, commits, what was published and how it did.
- Brief. Write a short morning note with only new problems, wins and today's actions. Anything already flagged shows once as "still open" instead of repeating every day.
- Propose. Turn a finding into a concrete change: a fix to a page, a post draft, a keyword brief.
- Approve. Nothing leaves without a yes from me.
- Ship. The change becomes a commit, a pull request or a published post.
- Measure. The next morning's read includes whether it worked.
The loop is the product. The integrations are just how it gets its inputs.
Approval is the design, not a setting
The most important decision in Ciralia is where the human sits.
Its assistant has three tiers of tools. Read tools just look. Do tools take small, reversible actions. Confirm tools, such as publishing a post, stop and wait for me to press Confirm. The model cannot talk its way past that button.
Production changes get the same treatment, with two paths:
- I asked for it. I looked at the page, described the change and said the confirm phrase. Consent already happened, so the change is committed and deployed.
- Ciralia proposed it on its own, from evidence on a schedule. Nobody looked, nobody spoke. That is a different kind of trust, so it becomes a branch and a pull request, and the merge button is the consent.
An unattended agent that opens a bad pull request costs a review. One that pushes a bad commit costs a rollback. That asymmetry decides which path something takes.
Rollback has to be boring
Every production change Ciralia makes is tagged, so it can be undone with one instruction. The first version found the change to revert by searching commit messages for the tag.
That has a subtle bug. A revert's message contains the original message, so it also matches the search. Roll back twice and you revert the revert, which ships the change you were trying to remove.
The fix was to stop reading prose. Reverts now carry an explicit trailer naming the commit they undo, and the rollback logic matches on that trailer only. It is a small thing, and it is exactly the kind of small thing that decides whether you trust an automated system with production.
Never invent the inputs
Ciralia writes ad copy, articles and keyword briefs, and it has one hard rule about all of them: it does not invent the evidence.
Ad ideas come from real ads I paste in or that it finds online. Articles need a real keyword brief. When the search data source is unavailable, the writer does not guess. It logs that it is blocked and why, and waits. An empty day is better than a confident article built on numbers nobody measured.
What it is not
It is not an autopilot for a company. It works because the products are small, the owner is one person, and every action is either reversible or approved. I would not hand it a large team's roadmap.
But for a solo founder with several products and not enough mornings, one place that reads everything, says what matters and waits for a yes has been worth more than any single tool it replaced.
You can see what it looks like at ciralia.com.