Day after launch: 7 things I learned building BUS Core v1.0

Yesterday I shipped v1.0 of BUS Core.

It’s a local-first ERP/workshop OS for very small manufacturing shops: inventory, vendors, runs, costing, journals, that kind of thing.

The product matters, but the more useful part for other builders is probably what I learned while building it.

I’m not a traditional software engineer, so a lot of this was learned the hard way.

1. “Clever scripts” are usually a trap

I started by trying to glue GPT prompts and scripts together to manage the problem.

That worked right up until it didn’t.

At some point the scripts became convoluted enough that I no longer trusted them as a foundation. That was the moment I stopped pretending I was building a shortcut and started building a real app instead.

2. AI without a Source of Truth becomes a loose hose

The biggest failure mode wasn’t bad code. It was drift.

One session would invent a structure. Another would rename something. Another would partially rewrite a flow and leave dead assumptions behind.

The fix was a living Source of Truth document.

Not a vision doc. Not a wishlist. A mirror of what the system actually is.

3. Update the spec before the code

This was probably the highest-leverage rule in the whole project:

the model was not allowed to output code until the SoT was updated first.

That sounds bureaucratic, but it solved a real problem: it forced the model to reread the system before touching it. It massively reduced hallucinated structure and naming drift.

4. Smoke tests beat confidence

I stopped trusting “this looks right.”

Every change had to survive smoke: app boots, endpoints respond, persistence works, core flow still runs.

That sounds obvious, but with AI-assisted development it matters even more. Models are very good at producing code that feels plausible. Smoke is what tells you whether it’s real.

5. Treat LLMs like junior devs, not architects

The most useful mental model I found was:

LLMs are not the intelligence. They’re the typing pool attached to a giant library.

They are prediction engines. They do much better under tight constraints than open-ended vibes.

Once I stopped treating them like wise collaborators and started treating them like fast executors that need rails, the results got a lot better.

6. Additive iterations beat heroic rewrites

Most of the progress came from boring layered passes, not giant redesigns.

Small change. Update truth. Run smoke. Commit. Repeat.

That loop is not glamorous, but it compounds. And more importantly, each pass stays survivable by the next one.

7. Distribution works better after the product is visually honest

One lesson I learned late enough to matter:

Don’t market abstractions.

A decent home UI, honest screenshots, a short working demo, and one clear download button did more for credibility than trying to talk people into the idea. Concrete product beats theory.

That also changed how I think about launch. Distribution is part of the system, but it should follow working flows, not replace them.

None of this is “secret sauce.”

It’s mostly process discipline:

• one living truth source

• no hidden assumptions

• smoke over feelings

• small iterations

• AI under constraint

That’s what got me to v1.0.

Curious how other people here keep AI-assisted projects coherent over long stretches.
What ended up being your real anti-drift mechanism?