5 Pillars of Production Software:The AI Framework

The 5 pillars of production software separate code that runs from software that works from products that scale: architecture and database thinking, system design, security and trust, product thinking, and knowing how to work with AI itself. AI writes the code in seconds. The pillars are the twenty years of judgment it cannot supply — condensed so a non-technical founder can apply them from day one.

This is the framework underneath everything I teach about building with AI. AI can generate thousands of lines of code, but it cannot understand the business consequences of architectural decisions, predict how technical debt compounds, know when to break its own rules, think through edge cases nobody described, or balance speed against correctness in context. The code is free. This is what you actually need to know.

Pillar 1: Architecture and database thinking

The foundation — get this wrong and everything else is building on sand. The core rules: keep your data organised so nothing is stored twice (stay 90%+ normalised, and denormalise deliberately, never accidentally). Put an organisation column on every table from day one — adding multi-tenancy later means touching 964 tables; ask me how I know. Enable row-level security so the database itself refuses to show one customer another customer's data, even when your code has bugs. Never truly delete anything — mark it deleted so users can undo. Track who created and changed every record. Index everything you query, because your app is fast with 100 records and unusable at 100,000 without indexes.

Every one of those rules is invisible in a demo and existential in production. And AI will skip essentially all of them unless you explicitly ask.

Pillar 2: System design and scalability

How your code is organised determines how fast you can move. The spine is separation of concerns: the screen talks to a hook, the hook talks to a service, only the service talks to the database — never skip layers (I dedicated a full article to this 3-layer pattern). Around that spine: every screen handles loading, error, and empty states, not just success; anything slow runs in the background instead of making users wait; data loads in pages of 20–50 items instead of all at once; results that rarely change get cached; and operations behave the same whether a user clicks once or, impatiently, five times.

None of this is exotic. It is the difference between an app that impresses in a screen recording and an app that survives its hundredth customer.

12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →

Pillar 3: Security and trust

Users trust you with their data; the third pillar is not breaking that trust. Authentication answers who someone is — authorisation answers what they may do, and they are not the same check. Defence runs in layers: the database enforces row-level security, the service checks business permissions, the API validates every request, and the UI hides what a user cannot touch — so when one layer fails, the others hold. Every piece of user input gets validated before it is used. Every secret lives in configuration, never in code. And user input never gets glued directly into database queries, which is how attackers delete your tables.

AI is at its most dangerous here, because insecure code looks identical to secure code when it runs. It works, it demos, and it leaks.

Pillar 4: Product thinking

Code works; products ship. The fourth pillar is everything users feel: significant features go behind flags you can switch off without redeploying, so a broken launch is a toggle rather than an emergency. When a third-party service dies, the feature degrades gracefully instead of taking the whole app down. Every user action gets feedback — a spinner, a confirmation, an error with a retry. And when speed and correctness conflict, correctness wins: fast but wrong is worse than slow but right, because corrupted data is the one bug you cannot patch away.

The habit that powers this pillar is a question: what if? What if this record has children? What if two users delete it simultaneously? What if the payment succeeds but the confirmation fails? Edge cases are where bugs hide, and AI will not hunt them for you.

Pillar 5: Working with AI

The meta-skill: AI is the tool, you are the craftsman. Five disciplines. Verify everything — AI is reliably wrong about security, edge cases, and performance, and reads as confident either way. Manage context — give it your architecture rules and one or two examples, not your whole codebase. Be specific — two minutes writing a precise prompt saves twenty minutes fixing a vague one, and structured prompts are exactly what the PRP method systematises. Validate in loops — type checks, tests, then manual testing, before anything is committed. Build incrementally — the smallest working version first, then enhance, so you always have a working app.

And when AI proposes something that violates your rules: push back. You are the architect; AI is the builder — that role division is the whole game. Fight over architecture, security, and data integrity. Let go of naming preferences and minor style. Direction is yours; execution is its.

The 5 pillars of production software at a glance

This framework is not theoretical. It is how a platform with 964 database tables got built by one person with AI — and why the honest summary of the whole approach is one sentence: you provide the direction, AI provides the execution. The code is free. The pillars are what make it production-ready. That is how a €2M platform got built for €3,250.

The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →

Frequently asked questions

Do I need to master all five pillars before building anything?

No. Start building immediately, but apply pillar 1 from the first prompt — the database decisions (organisation column, row-level security, soft deletes) are the ones that are brutal to retrofit. The other pillars can be layered in feature by feature as you go.

Is this not just software engineering — why frame it for AI?

It is software engineering, distilled to what changed. Before AI, these principles were useless to you without the years needed to write the code. Now the code is free, so the principles are the entire job — and unlike syntax, judgment does not take twenty years to apply when someone hands you the checklist.

How do I make AI follow the pillars without repeating them every prompt?

Put them in a standing instruction file that your AI tool reads every session, and reference them when you review output. The most common corrections — every table gets an organisation column, every component handles all four states, no hard deletes — become rules written once. The top ten AI production mistakes post has the ready-made rules block.

Which pillar do beginners get wrong most?

Pillar 5 — they trust AI output because it runs. Code that runs is the lowest bar there is; the demo hides everything the other four pillars exist to catch. The founders who succeed read what AI generates, ask "what could go wrong here?", and verify before they ship. Trust, but verify.