Engineered, not generated
Anyone can generate a CRUD app this year. Type a prompt, get a screen, wire it to a table. The demo looks fine. The trouble starts in month four, when someone has to change it — and nobody, including the person who generated it, can say why it works the way it does.
That is the difference between software that exists and software a team can rely on.
Anyone can generate an app this year. In the demo, both look fine.
Our rule
We use AI heavily while building Usable. What we don't do is ship code that no human has understood. Every module we release has to pass a plain test:
Could a competent developer who has never seen this code maintain it — without asking an AI what it does?
If the answer is no, it isn't finished. Not because generated code is bad by definition, but because software you can't reason about is software you can't fix under pressure. And business software is exactly the kind that breaks under pressure: on a Monday morning, in the middle of a shift, when a customer is waiting.
Why you cannot see the difference when you buy
The uncomfortable part about this line: it is invisible at purchase. In a demo, carefully built software looks exactly like quickly generated software — sometimes worse, because it has fewer effects.
| Visible in the demo | Visible when it snags | |
|---|---|---|
| Interface | Looks finished in both cases. | Can one screen change without breaking three others? |
| Data model | Not visible. | Does the schema say what it means — or is everything called `data1`, `data2`? |
| Permissions | You are signed in as an administrator. | Are they readable in one place, or spread over 40 files? |
| Changes | Does not come up. | Can somebody who did not write the code touch it safely? |
| Debugging | Does not come up. | Is the cause found in minutes or in days? |
Everything in the right-hand column is decided long before you buy and becomes visible long after. That's why it is fair to expect vendors to say something about it — and why we say it here.
What that looks like in practice
- Every module carries its own documentation — written to be read by the people using it, and by whoever maintains it next.
- Boring, explicit code beats clever code. The database schema says what it means. The permissions are readable in one file.
- We delete more than we generate. Most of the work is deciding what not to build.
- Every data change leaves a trace. Not as an add-on, but because a system without a trace proves nothing in a dispute.
What we use AI for, and what we don't
So that "we use AI" doesn't stay a slogan, here is the split as it actually runs:
| For what | Why it fits there |
|---|---|
| First drafts, trying out variants | Discarding fast is cheaper than deliberating long |
| Repetitive rewrites across many files | Mechanical, easy to check, boring for humans |
| Tests and sample data | Broad coverage, low risk |
| Research into regulation and deadlines | It finds sources — we do the judging |
| Not: deciding the data model | The cut is the decision, not the typing |
| Not: permission and role logic | Has to be readable and owned by a human |
| Not: migrations, unread | One wrong step hits real data in real businesses |
The line doesn't run between "hard" and "easy" but between "checkable" and "answerable for". What a human can verify in minutes, a machine may write. What could stay quietly wrong for weeks, it may not.
None of this is visible in a demo. All of it is visible the day something goes wrong — which is, honestly, the only day that counts.
The connection to the product isn't obvious, but it's direct: maintainable code is the reason a module that snags in one place can be a job for us instead of a problem for you. It's the same idea as cutting software into modules, one level down — a piece of software only stays negotiable as long as somebody still understands it.
- Engineering
- Craft