The Lean Architect’s Guide to Shipping | Blog

Most engineering advice is focused on writing better code. But if you’re building for a market, “better code” is a secondary concern. The world is full of perfectly unit-tested repositories that never saw a single user because the deployment was too complex, the architecture was too rigid, or the developer was too busy building “features” instead of solving problems.

In my time moving across data science, venture capital, and founder roles, I’ve realized that the most successful products aren’t necessarily the most technically complex. They are the ones that prioritize momentum over perfection. Being a generalist means understanding that your job isn’t to write lines of code—it’s to deliver value. If you want to move from “coder” to “builder,” you need to stop falling in love with your functions and start obsessing over your system.

Here is the manifesto for shipping fast, staying lean, and building things that actually work.

Deploy on Day 1

There is no greater heartbreak than spending three weeks perfecting a local environment only to find your architecture isn’t built for the cloud.

Infrastructure first: If it doesn’t run in production, it doesn’t exist.

The Python Tax: Be warned—deploying JavaScript is a breeze, but deploying Python (FastAPI, Django, Flask) can be a soul-crushing endeavor. Choose your stack based on the “Deployment-to-Pain” ratio. A comic showing the difference between building features and solving problems. Avoid the Server Trap: Server maintenance is a distraction. Aim for serverless or managed environments so you can focus on the product, not the patches.

Customers Own the Problems, You Own the Solutions

When a client or PM asks for a specific button or feature, they are handing you a solution, not a requirement. A comic showing the difference between building features and solving problems.

The “Why” Filter: Stop and ask why they want it. What is the friction point?

Brainstorming > Building: Once you understand the underlying problem, you can usually find a path that is 10x easier to build and 2x more effective than what was originally requested.

Architecture is the Strategy; Code is the Tactic

Elegant code in a flawed architecture is just a well-painted room in a house that’s sinking.

Diagram First: Never open an IDE without a schema. Visualizing the flow of data prevents “spaghetti logic” before it starts.

Leverage AI: In 2026, writing individual functions is a low-leverage task. Let AI handle the boilerplate and the logic blocks while you focus on the high-level framework and library choices.

The “Postgres Thesis”: Business Logic Lives in the DB

The most robust applications treat the codebase as a thin layer for running queries and rendering UI. A comic showing the difference between building features and solving problems. RLS is King: Move your access control and security rules into Postgres Row Level Security (RLS).

The Single Source of Truth: When business logic lives in the database, it remains consistent regardless of which frontend or API layer you swap in later. Your codebase should simply be the messenger.

UX over Everything

Nobody cares about your blazingly fast Rust core if the JavaScript UI is lagging or the user flow is confusing.

Design as a Moat: In a world of commoditized code, superior design is a competitive advantage.

The “Microsoft” Trap: It is a rare and vital skill to add features without cluttering the UI. A comic showing the difference between building features and solving problems. Simplicity Wins: If a user has to think about how to use your tool, you’ve already lost.