How We Run PropelAI on AI

I sell AI operations to small businesses. It would be strange if I didn't run my own company on the same thing.

So here's the honest version of how PropelAI actually operates day to day. Not a pitch. Not a diagram with glowing nodes. The real setup — how strategy turns into shipped work, what the AI does, and where I still have to be the one holding the pen. If you're a small-business owner trying to figure out what "running on AI" means past the demo, this is a look under the hood of a company that lives on it.

The problem a tiny firm actually has

PropelAI is small. Deliberately. But small firms have a specific failure mode: everything lives in the founder's head. Strategy, priorities, the reason we did it that way in March, the half-finished thought about a client's integration — it's all in one skull, and it doesn't scale, doesn't parallelize, and disappears the moment I get on a plane.

Big firms solve this with headcount. A director translates strategy into projects, project managers translate projects into tasks, and a small army executes. I don't have that army, and I don't want it. What I wanted was the coordination a bigger org gets without the payroll that comes with it.

That turned into three moving parts: a place where strategy lives and gets turned into written work, disposable workers that execute that written work, and a shared memory so nothing has to be re-explained. Every one of those parts leans on AI. None of them removes me from the decisions that matter.

One planning surface that writes the work down

The first piece is a single planning surface where I think out loud and the thinking gets turned into small, written work orders.

The important word is written. Not "let's sync on this." Not a Slack message that scrolls away. A work order: one document that says what the objective is, why it matters right now, what's in scope and explicitly out of scope, and — this is the part most people skip — how we'll know it's done. A checklist of conditions that can actually be verified.

If that structure sounds familiar, it should. It's the same discipline I preach to clients about scoping engagements: ambiguity is where projects die. A vague task handed to a person produces a vague result and an argument later. A vague task handed to an AI produces a confident, wrong result and no argument at all, which is worse. So I force the ambiguity out at the top, in writing, before anything gets built.

Writing the work down does two things. It makes the work executable by something other than me. And it leaves a paper trail — I can look back at what I asked for and hold the result against it. That single habit, more than any specific tool, is what lets a one-person-shaped company behave like it has a team.

Disposable workers that execute and report back

The second piece is the execution layer: disposable AI coding sessions that pick up a work order, do the build inside the relevant codebase, and report back what they did and whether the "done" conditions passed.

I call them disposable on purpose. Each session is spun up for a specific work order and thrown away when it's finished. It doesn't accumulate opinions or drift. If one goes sideways, I kill it and start clean — no sunk cost, no untangling. Because the work order is written and the success conditions are explicit, I can run several of these at once, against different repositories, on different problems, and they don't collide.

This is where the parallelism I couldn't afford in headcount actually shows up. Three or four streams of work move at the same time. Each one reports back in the same shape: here's what changed, here's the check I ran, here's what passed and what I couldn't verify. I read the reports, not the keystrokes.

The failure mode here is trusting the report because it's confident and well-formatted. AI is very good at producing a tidy summary of work that is subtly wrong. So the reports are inputs to my judgment, not substitutes for it. When the stakes are low — a formatting pass, a routine change — I skim and move on. When the stakes are real, I go read what actually happened. Which brings me to the part that matters most.

A company brain that keeps everything oriented

The third piece is a git-versioned "company brain": a set of one-page project cards, each describing a single project — what it is, where it stands, what's decided, what's open. Plain text, version-controlled, boring on purpose.

This is the shared memory. When I open a new planning session or spin up a new execution session, it starts by reading the relevant card. It doesn't ask me to re-explain the project. It doesn't invent context. It reads the same one-page truth every other surface reads. When something changes, the card changes, and the change is tracked like any other commit — I can see what we believed last month versus now.

Boring and portable is the whole point. A one-page text file that any tool can read is worth more than a beautiful knowledge base locked inside a platform I'd have to migrate off of later. The moat isn't the software around the memory. It's the memory itself, and I keep it somewhere I own outright.

Where humans stay load-bearing

Here's the part the excited version of this story leaves out. The AI proposes. The operator disposes. And "the operator" is me, for anything that's hard to reverse.

Merges are mine. AI drafts the change; I decide whether it goes into the trunk. Money is mine — no session sends an invoice, moves a dollar, or commits us to a cost. Anything binding is mine: a promise to a client, a contract term, a public claim on this website. The rule is simple and I don't bend it. If getting it wrong is cheap and reversible, the machine can run. If getting it wrong is expensive or can't be undone, a human signs off first.

That's not caution for its own sake. It's the same standard I hold client systems to. The point of building on AI isn't to remove judgment from the loop. It's to remove the typing, chasing, and re-explaining from the loop so the judgment has room to happen.

What it actually buys

Three things, concretely. Parallelism — several streams of real work moving at once, which is how a small firm covers ground a small firm shouldn't be able to cover. Memory — nothing has to be re-explained, and decisions leave a trail. Auditability — because the work is written down going in and reported against coming out, I can always answer "why did we do it this way," which turns out to be most of the job.

And an honest limit: this makes a good operator faster; it does not make a bad plan good. Garbage work orders produce garbage output, quicker. The leverage is real, but it sits on top of the thinking. It doesn't replace it.

That's the same thing I tell every client. The system is worth building. Just don't expect it to do the deciding for you.

If you want to see what a working operating system looks like inside your own business — not a slide about one — that's the conversation we should have.