← All posts

We run adoovi on adoovi

Our docs are an app mr-bill built. This blog is published through an app mr-bill built. Dogfooding isn't a value statement here — it's the org chart.

We run adoovi on adoovi

There's a question you should ask any platform that claims its AI builds real software: do you trust it with your own?

Here's our answer, in the form of an inventory.

This blog

The post you're reading was not written into a blog engine. It was authored in the content studio — an app built by mr-bill in the adoovi build workspace, with its own database, versioning, and media generation. The blog you're looking at is a thin public reading layer: when we publish, it takes an immutable snapshot of a content-studio version and serves it as fast, cacheable HTML.

Which means every post here carries provenance. The platform can tell you which content item, which version — and, for generated content, which mr-bill run — a public post came from. We built that lineage for your apps; the blog gets it for free.

The docs

Our user guide — the public documentation for the whole platform — is an app that mr-bill built. We wrote requirements in the build workspace describing a documentation product: sections, articles, search, a public reading experience. mr-bill built it; the docs corpus lives in that app's database; the site you read is that app serving its content.

When the platform changes, updating the docs is a content operation in a running app — not a static-site rebuild.

The instruments

Running a platform means watching it, and we watch adoovi through adoovi:

  • The cost dashboard — where we track what every app, workflow, and build

actually spends — is an app on the platform, reading the same metering data your usage page reads. When we tightened its time-window handling recently, it was because we kept staring at it and wanted it more honest.

  • The workflow lens — our live view of every running build across the

fleet — is an app on the platform. When a build misbehaves, this is the screen we open.

Why we're strict about this

Dogfooding is easy to claim and easy to fake — a demo account, a sample app, a screenshot. We hold ourselves to a harder rule: if adoovi can't build and run the tool, we don't get the tool.

The rule has teeth. It means we hit the platform's rough edges before you do, at full force, on things we need to work. A surprising number of adoovi improvements started life as one of us getting annoyed at our own product while trying to ship something with it. The launcher's account handling, the workspace autosave, iframe theming, honest empty states in dashboards — all of it got fixed because dogfooding made the problem unbearable.

It also keeps our incentives aligned with yours in the most literal way: our own work runs on the same wallet metering, the same run observability, the same review pipeline. When we say every token is accounted for, we mean ours too.

The standard we're aiming at

You should judge a software factory by whether its owners are its customers. Ours are. The blog, the docs, the dashboards, the research apps we're proudest of — they came off the same line yours will.

If something on that line isn't good enough, we're usually the first to know. And now you know where to look us up when we're wrong: the receipts are public, one post up.