How I built a real app with LLMs without letting it turn into slop

I think a lot of “AI-built app” talk collapses because people are really talking about one of two bad extremes:

1. prompt-gambling until something vaguely works

2. rejecting the whole thing because most of the output is unstable junk

What worked for me was neither.

I’ve been building BUS Core, a local-first ERP / workshop OS for small makers and micro-shops. Think: the point where a spreadsheet used to be enough, but now inventory, receiving, manufacturing runs, and costing start drifting apart.

The useful part is not “I used AI.”

The useful part is the control system I had to build around it.

What actually worked

I treated the LLM like a junior dev, not an oracle.

That meant a few hard rules:

• Source of Truth first
  The model was not allowed to just spit out code. It had to update the living SoT first so naming, structure, and intent stayed coherent.

• Smoke test over feelings
  If the app booted, hit the endpoints, and basic flows stayed green, the iteration lived. If smoke was red, nothing else mattered.

• Small passes, constantly
  No giant rewrites. No “perfect architecture.” Just additive changes that survived the next pass.

• Code is fact
  If the code and docs disagreed, code won. Then the SoT got fixed.

That sounds obvious in hindsight, but it is not how most people use these tools.

Most AI-assisted projects fail from drift.

Not because the models are useless.
Because the process is loose.

What I think people miss

The model is not the intelligence.

The human is.

The model is the typing pool with a giant library behind it. Good when constrained. Bad when left to improvise architecture while everyone pretends it’s magic.

That shift mattered a lot.

Once I stopped asking for brilliance and started demanding obedience to a real process, the whole thing got more reliable.

What I’m building toward

BUS Core is aimed at shops that are too real for toy tools and too small to want enterprise ERP baggage.

The thesis is simple:

• local-first

• boring on purpose

• useful before pretty

• no rent-seeking cloud dependency

• honest operator workflows

What I’m seeing now

The early traction is still small, but it’s real enough to respect:

• people are finding it

• some are downloading it

• update checks are happening

• the quiet signal is stronger than the social signal

That actually fits the product.

Nobody gets excited to publicly gush about shop software.

They just test it if it might stop their stock from lying to them.

My current takeaway

AI didn’t remove the need for process.

It made process more important.

If you want these tools to build something real, the question is not “which model is best?”

It’s:

What rails do you force it to stay inside?

For me, the rails were:

• Source of Truth

• smoke tests

• small iterations

• code as ground truth

• no hidden assumptions

That’s the part I think is portable to other products, not just BUS Core.

If you’ve built with AI and managed to avoid the usual spaghetti explosion, I’m curious what your equivalent rails were.