Why I Built TinyOps

The problem hiding in our workflow

Working on payments infrastructure, I started noticing how much of our day-to-day quietly depended on a sprawl of GitHub Actions and hand-written rules. It's a small part of a huge machine — but it shapes how every engineer ships.

I kept writing YAML. Wire the test suite into a Vercel check. Gate a deploy. Block releases on weekends. Writing those files was never the hard part — with AI, it takes minutes. The hard part was everything after.

We had no real way to monitor any of it. Our "monitoring" was a cron job that posted to Slack and hoped someone was paying attention. You end up with a pile of files and scripts that all work — until one quietly doesn't, and nobody notices until something has already shipped.

Why the existing tools didn't cut it

GitHub branch protection covers part of this. But the pieces you actually want sit behind a paid plan. Without it, you stitch together access tokens, scripts, and cron jobs into a patchwork.

It functions. But nobody can reason about it. Is that rule still firing? Did a check break last week? You don't find out until something slips through. For a small team — or a large team that would rather spend its attention on the product — babysitting that plumbing is a real, recurring tax.

The clarity of a declarative rule

Here's the thing that clicked: the problem was never writing the rules. It was seeing them.

YAML's strength is that it's human-readable. Here's a real TinyOps rule:

name: Missing Tests Alert
trigger:
  type: webhook
  event: pull_request.opened
condition:
  provider: github
  check: pr.files
  operator: none_match
  value: "*.test.*"
  repo: "Okekejr/tinyops"
action:
  provider: github
  method: pr_comment
  params:
    body: "⚠️ This PR doesn't include any test files. Consider adding tests for your changes."
  repo: "Okekejr/tinyops"

You don't need a manual to read that. When a pull request opens, if none of the changed files match *.test.*, TinyOps leaves a comment. Trigger, condition, action — that's the whole shape of a rule.

I wanted guardrails that kept that clarity but added the part that was always missing — visibility. So TinyOps is built around rules that are declarative and observable. You connect your integrations, pick a trigger, set a condition, and you have an automated guardrail in seconds — one you can actually watch run, in one place.

What TinyOps is

TinyOps is a guardrail layer for engineering teams. Block weekend deploys. Require review on risky pull requests. Catch a billing spike before it becomes a bill. And see every rule fire — without a cron job and a prayer.

It doesn't replace your judgment. It replaces the patchwork.

Where it's going

TinyOps just launched. I'm looking for teams who feel this exact pain — the ones quietly maintaining their own workflow plumbing and wishing they didn't have to.

If that sounds familiar, take a look: tinyops.cc.