There’s a question I think every founder should ask before hiring a developer. Not about the tech stack. Not about the rate. Not about availability.
“Walk me through how you’d approach building this.”
Not “what would you build it with.” How would you approach it.
- The tool-first developer: Starts with frameworks. “I’d use React for the frontend, Node for the backend, PostgreSQL for the database.” They’re thinking in tools and answering a different question than the one you asked.
- The business-first developer: Starts with questions. “Who are the primary users? What’s the workflow they’ll go through daily? Where’s the money flowing? What does this look like in 6 months when you’ve scaled?”
Both developers might build the same product. But the second one will make different decisions along the way.
Decisions about architecture, data modeling, payment flows, and feature scoping that account for where the product is going, not just where it is today.
This is the difference between code that works and code that lasts.
I’ve taken over codebases built by developers who never asked about the business model. You can tell within an hour:
- The database schema reflects the first feature that was built, not the product vision.
- The payment integration assumes one pricing tier, adding a second tier means restructuring half the billing logic.
- The user roles are hardcoded because nobody anticipated that the product would serve more than one type of user.
None of these were bugs when the code was written. They became bugs when the business grew beyond the developer’s assumptions. And the developer’s assumptions were narrow because they never asked the questions that would have expanded them.
When you’re evaluating a developer, whether it’s me or anyone else, look closely at their starting point.
If they ask about frameworks first, they’re thinking about the next sprint. If they ask about your business first, they’re thinking about the next year.
Hire accordingly.