I’ve been a fan of outside-in development for years. Start from the UI, work your way back to the database. It made sense: build what users see first, then fill in the layers beneath.
But lately I’ve been thinking about this differently. Maybe I’m doing inside-out and outside-in, just in sequence.
The Old Inside-Out vs. Outside-In Debate
When I first started developing, I worked outside-in without really naming it. I’d sketch out the interface, think through the user experience, then build backward into the system.
A lot of developers I worked with did the opposite. They started inside-out: database schema first, then stored procedures, data access layer, business logic, and finally the UI. Build the foundation, then the walls, then the roof.
I moved away from that approach because it felt like building a house without knowing who would live in it. The UI often ended up shaped by the database, not by what people actually needed to do.
A Few Steps Further Back
But here’s what I’ve been noticing: even starting from the UI might not be far enough out.
Before I think about the interface, I ask different questions. What do people actually need? What are they trying to accomplish? What do they value?
Those questions aren’t about the outside of the application. They’re about the person’s inner self.
People say what they want, but that’s not always what they need. What they need usually comes from somewhere deeper: their values, their aspirations, the problems they’re trying to solve in their work or their life.
So what I’m describing is this: first, go inside-out, from the person’s inside outward to what they express. Once we’ve drawn that out, then we go outside-in, starting from the outside of the application and working our way into the system.
How This Maps to BDD
This actually fits well with how I’ve been thinking about behavior-driven development.
BDD is supposed to be about behavior, not just system behavior (or at least that’s how I see it). It’s about the real world, the people, the context. But it’s easy to slip into thinking about behavior purely through the lens of the system: “When the user clicks this button, the system does that.”
What I want to do is look outward first, to the people and the real world, and then flip around to look at the system.
We start by listening to what people say they want (the outside). Then we go inward to understand the motivations, the values, the real needs (the inside). That’s inside-out.
Then we turn around. We take those needs and translate them into system behavior, starting from the interface and working our way into the implementation. That’s outside-in.
Inside-out, then outside-in.
Why This Matters
I like this mental model because it keeps me honest about where I’m starting.
If I jump straight to “outside-in development,” I might start with the UI, but I’m still making assumptions about what people need. I’m designing based on what I think they want, not what they’ve told me or what I’ve observed.
Going inside-out first means I’m grounding the work in something real: actual human needs, not my best guess about them.
And then the outside-in approach becomes more effective because I’m building an interface and a system that actually serve those needs.
What I’m Working On
I’m still refining how I explain this. I want it to be crisp enough to describe clearly in a conversation or workshop.
And I want to visualize it. I think there’s a diagram here that would make the whole thing click: the person at the center, their needs radiating outward, then the system wrapping around that. Inside-out, then outside-in.
If you’ve thought about this kind of thing, I’d be curious to hear how you approach it. Where do you start when you’re trying to understand what to build?
Leave a Reply