Build Features from the Outside In

Depending on how much of a developer you (think) you are, this process describe might be the only logical one to you. But it happens often enough, when I explain how I build features (from the outside-in), I get weird looks and questions what it is. So here I am doing the only logical thing when things like this happen too much; I write it down in this short article.

This process, sometimes referred to as Outside-In Development or Frontend-First Development, is nothing more than starting with the user perspective: the HTML (a UI component or HTML form). Then from here, you go up the chain: to the router, controller and then the model (or some class).

Why work from the outside-in?

To me it helps to develop quicker. You start with what the user interacts with or with the data they enter. And never more. You don’t need the full production-ready UI, but the bare minimum HTML works well enough (Tailwind CSS is great for this).

This means the requirements are clearer: you know exactly what data you need to handle. And it shows any UX issue early on. But the biggest plus to me is limiting over-engineering: you only build what’s necessary for the UI. It happened too often to me that I made a great and smart API (fully OO, Solid, etc.), only to discover it missed certain attributes or, the opposite, it wanted too much.

This is why static mockups might seem like a time waster, but they are the Outside-In Development process in overdrive.

When I build a SaaS for others this is the process I follow for every feature.