A developer on the team put it plainly during a session we had on end-to-end testing.
“For me, the difficult part will be changing my mind from database tests to starting from the front end. I think that’s the only thing that my mentality needs to change.”
I recognized that immediately. I’ve been there. I’ve walked others through it. Every single time, people come out the other side saying they’d never go back to Database-First. But it does take time.
The Default Pull
Most developers I’ve worked with default to starting from the database. It makes sense on the surface. The database is where the data lives. You have tables, schemas, something concrete to build against.
The problem is that the database is at the back of the building, while your users are at the front door.
Starting Where Users Are
A long time ago, I learned to start from the outside.
The reasoning is direct. The outside is what people see. That’s what they describe to us when something is wrong or when they need something new. So we walk that same path. We might stop at the frontend component. We might stop at the API layer. We might have to trace all the way to the database. But we don’t start there.
When developing a new feature, we build the UI first. Not a polished, final UI. A working one we can put in front of stakeholders and ask: "Is this what you mean? Will this solve the problem? We validate the idea before we ever think about a database schema.
That approach also changes what the tests look like and where they live. I explored its connection to BDD specifically in Inside Out, Outside In: A New Mental Model for BDD.
What the Numbers Show
On this project, I’ve been tracking how automated tests are distributed across layers since early on. The trend tells a clear story.
In the early phases, about 70% of our automated tests lived on the front end. Back-end tests were around 20%. End-to-end tests, the kind that automate a real browser, stayed near 5%.
That ratio wasn’t arbitrary. It reflected exactly what we were doing. We were building and validating user-facing behavior before the backend was stable enough to test deeply. We hadn’t yet committed to a schema because we hadn’t yet confirmed what the feature actually needed to do.
Over time, as the domain stabilized and we understood the feature boundaries well enough to express them in code, the backend test count grew. Front-end and back-end tests are now approaching parity. End-to-end tests have ticked up recently, too — AI is making them faster to write, so we’re adding more where it makes sense.
The progression isn’t a coincidence. The ratio follows the work, and the work follows the user.
The Shift Is Real
When the developer said his mentality needs to change, he wasn’t being self-deprecating. He was being accurate.
Database-first is a deeply embedded habit. It feels grounding. You have something solid to point at. Starting from the UI can feel uncertain, like building before you know what’s underneath.
But here’s what I’ve seen every time someone makes the shift: they stop losing time to the wrong kind of rework. Instead of retrofitting a UI onto an unvalidated data model, they’re building what the user needs and letting the implementation follow.
The schema becomes a consequence of the behavior, not the other way around.
Following the Path Inward
There’s a practical side to this beyond tests and priorities.
When something goes wrong, we debug outside-in. We start at the spec, the end-to-end test description, and walk the same path the user walked. Sometimes the problem stops at the frontend. Sometimes it’s at the API. Sometimes we trace all the way to the database.
But we start where the user is, not where the data is.
The developer who named the shift in mentality understood it clearly. Naming the thing you need to change is usually how the learning actually starts.
Leave a Reply