@aaronshipsit

About

How I build

I'm Aaron. I run a very small software factory: one person, a fleet of AI agents, and a rule that anything claimed out loud has to be checkable.

This page is about how the building works rather than who is doing it. The how is the part you can actually use.


One person, a lot of agents

I write the spec, set the constraints, and review the work. The agents do most of the typing — and a fair amount of the reading, the testing, and the arguing with each other about the right approach.

That arrangement is the whole experiment, so it gets written down rather than hidden: the orchestration that worked, the runs that went sideways, the moments where a human had to step in and say no.

What I won't do is overclaim. Nothing here builds itself. Work does get finished while I'm asleep, but only because somebody was extremely specific about what to build, and reads every line of it in the morning.

What's worth building

Three filters, and an idea has to survive all three.

Most ideas die at one of the three. That is what they are for.

  • It fits in a sentence. If explaining the product needs a diagram, I don't understand it well enough to build it yet.
  • It fits in a month. Not because a month is magic, but because a deadline you can see the end of keeps scope honest. Ambitious is fine; it just has to arrive one shippable month at a time.
  • I'd pay for it myself. Not "someone would pay" — me, with my own money, at the price printed on the page.

Shipping fast without shipping garbage

Speed comes from removing hesitation, not from removing care. In practice that's a short list of things that don't get negotiated away when a launch is close.

  • The gates hold. Types, tests, and a clean build before anything merges. Agents are fast and extremely confident; the gates are what turn that into an advantage instead of a liability.
  • Every change leaves a receipt. A commit, a changelog entry, a roadmap item that visibly moves. Work that shipped and left no trace may as well not have.
  • Rough is fine. Broken is not. A small thing done properly beats a big thing done approximately. What people see is allowed to be plain. It is not allowed to be careless.
  • Write the why down. If I can't explain a decision in a paragraph, it isn't a decision yet — it's a preference wearing a decision's clothes.
  • Kill it on schedule. Ninety days and one paying customer, or the product gets an honest post-mortem instead of a birthday. For a shop this small, sunk cost is a bigger threat than failure.

What gets published

A monthly recap with exact numbers: revenue, signups, trials, churn, spend. Including the months where the number is zero, and the months where the honest summary is "that didn't work, and here's what it cost to find out."

Publishing the misses is the only thing that makes publishing the wins worth reading. Numbers that only appear when they're flattering aren't numbers, they're marketing.

Where this actually stands

Plainly: FeatureJet is the first product. It's live and it takes payment, but nobody has paid yet — no customers, no revenue, no churn, no streak. FeatureJet's own roadmap is public, at feedback.featurejet.com, and the work is real; the results section of this site is still empty.

I'd rather say that than pad it. When there are numbers, they'll be the real ones — including the ones I'd rather round up.

A note on the name

First name only, no photo. The byline is the persona: @aaronshipsit.

That's deliberate. This site is a record of the work, and the work is the part that has to hold up — every claim on it is meant to be checkable without knowing a thing about me.