How Do You Know if a Developer Understands Your Business?
A pet care startup spent £80,000 building a gorgeous app that let users book dog walkers with the tap of a button. It had video profiles of the walkers, real-time GPS tracking, and a sleek payment system. The problem? The developer never asked about the actual business model—turns out pet owners in that area preferred regular weekly walkers they could build relationships with, not on-demand bookings. The app was technically perfect but commercially useless, and honestly, it could have been avoided if the developer had asked a few basic questions about how the business actually worked.
Here's the thing—building an app isn't just about writing code and making things look pretty. Its about understanding what you're trying to achieve as a business and who you're serving. I've seen this mistake play out dozens of times; a business hires a developer based purely on their technical portfolio or their price, without checking if they actually understand how businesses operate in the real world.
The best developers don't just build what you ask for—they help you figure out what you actually need.
When you're vetting app developers, you need to look beyond their GitHub repositories and their list of technologies they work with. Sure, technical skills matter, but if a developer cant grasp your business model or doesn't understand your users' behaviour patterns, you're setting yourself up for expensive mistakes. I mean, what's the point of building something fast and efficient if it doesn't solve the right problem?
The difference between a developer who gets your business and one who doesn't can mean the difference between an app that drives revenue and one that sits unused on peoples phones. And let me tell you, that distinction becomes obvious pretty quickly once you know what to look for in those early conversations.
They Ask About Your Users First, Not Features
When you first sit down with a developer to discuss your app idea, pay close attention to what they ask you about. A developer who truly understands business will want to know who your users are before they even think about what features you want to build. I mean, it sounds obvious when you say it out loud—but you'd be surprised how many developers jump straight into talking about tech stacks and API integrations without ever asking "who is this actually for?"
The best developers I've worked alongside over the years all have this same habit; they start every project by getting inside the heads of the people who'll actually use the app. They'll ask questions like: What problem are your users facing right now? How are they currently solving this problem? What makes them frustrated about existing solutions? These aren't just polite conversation starters—they're the foundation of building something people will actually want to use.
Here's the thing—features are easy to list, but understanding user behaviour is what separates apps that succeed from the ones that get deleted after a single use. A developer who gets this will push back if your feature list doesn't match what your users actually need. They might say something like "that's a nice feature, but will your users understand how to use it?" or "I'm not sure that solves the core problem you described." And honestly? That's exactly what you want to hear.
Questions That Show They're Thinking About Users
A developer who understands business will ask questions that dig into the reality of how people will interact with your app. They want to understand the context—where are people when they use this? Are they stressed? In a hurry? Sitting on the sofa? All of this matters because it affects every design and technical decision that follows. Its not just about making something that works; it's about making something that works for real people in real situations.
Look for developers who ask about:
- Who your primary users are and what their daily routine looks like
- What devices they use and how tech-savvy they are
- What would make them choose your app over doing nothing at all
- How often they'd realistically use the app and in what situations
- What would cause them to stop using it or leave a bad review
- Whether you've actually spoken to potential users about this idea
If a developer spends the first meeting talking about all the cool things they can build without asking these questions? That's a warning sign. They might be technically brilliant, but they're approaching your project as a coding challenge rather than a business solution. And that difference matters more than you might think—because at the end of the day, your app needs to serve users, not just showcase technical skills.
The Questions They Ask During Discovery Tell You Everything
You know what's funny? The best developers I know spend most of the first meeting asking questions rather than talking about themselves. They dig deep. They want to understand everything.
When I sit down with a potential client, I'm not thinking about tech stacks or frameworks—I'm thinking about their business, their users, and what actually needs to happen for this app to succeed. And that's exactly what you should be looking for when you're vetting developers. The questions they ask during discovery tell you everything about whether they understand business or if they're just code monkeys looking for another project to build.
Good developers ask about your customers pain points, your revenue model, your biggest operational challenges. They ask what happens after the app launches, how you'll measure success, what keeps you up worrying about this project. They want to know about your team structure, who'll be managing the app long-term, what your budget constraints really are (not just the number, but why). These arent just nice-to-have questions—they're essential for building something that actually works for your business.
Bad developers? They jump straight to asking about design preferences, colour schemes, whether you want iOS or Android first. Sure, those platform decisions matter eventually, but they shouldn't be leading the conversation. If someone's more interested in what animations you like than who your customers are and what problems they're facing, that's a red flag the size of a house.
What Discovery Questions Should Sound Like
Here's what I typically ask clients during discovery, and what you should expect from any developer who actually gets business:
- Who are your users and what problems are they trying to solve?
- What happens if this app fails—what's the business impact?
- How does this app connect to your existing revenue streams?
- What are your competitors doing and why isn't that working?
- Who needs to approve decisions and what are their priorities?
- What's your timeline based on—market opportunity, funding, something else?
- How will you acquire users and what's retention strategy?
- What metrics actually matter to your business stakeholders?
If a developer spends the first meeting showing you their portfolio instead of asking about your business, walk away. Discovery is about understanding your needs, not showcasing their past work.
The Depth of Questions Matters Too
It's not just about asking the right questions—its about how deep they go. When I ask about users, I don't stop at "small business owners." I want to know: how tech-savvy are they, where are they when they'd use this app, what devices do they typically have, what's their biggest frustration with current solutions? That level of detail shows a developer is thinking about real-world usage, not just building features in isolation.
I mean, anyone can read a list of discovery questions online and parrot them back. But developers who genuinely understand business will naturally drill down because they know the devil's in the details. They'll push back when your answers are too vague. They'll ask follow-up questions that you hadn't even considered. That's what you want—someone who's genuinely trying to understand, not just ticking boxes on a discovery checklist.
And here's the thing—if they're not asking these questions, they're making assumptions. And assumptions in app development are bloody expensive. I've seen projects go tens of thousands over budget because developers built what they thought was needed rather than what the business actually required. The questions they ask (or don't ask) during discovery will determine whether your app succeeds or becomes another expensive lesson learned.
How They Talk About Your Competition Matters
A developer who truly understands your business won't just nod along when you mention your competitors—they'll want to dig deeper. I mean, really dig. They should be asking about what your competitors do well, where they fall short, and most importantly, how your app can position itself differently. If a developer doesn't show genuine curiosity about your competitive landscape, that's a warning sign they're more focused on building features than building a business solution.
Here's the thing—good developers will actually download and use your competitors' apps before your first meeting. They'll have noticed things. Maybe the onboarding is clunky, or the navigation doesn't make sense, or there's a gap in functionality that users clearly want. When they start pointing out these observations without you having to prompt them, you know they're thinking like a business partner rather than just a code writer.
But its not just about finding flaws in other apps; the best developers will also highlight what your competition does brilliantly and whether those patterns should inform your own approach. Sometimes the smartest move isn't to be completely different—sometimes it's about meeting user expectations that have already been set by market leaders. A developer who gets this balance understands that users carry learned behaviours from other apps they use daily.
What to Listen For
Pay attention to how they frame competitive analysis. Do they talk about user needs or just feature lists? Do they ask about market positioning and your unique value proposition? The conversation should feel strategic, not technical. If they're suggesting you copy features without understanding why those features exist or whether they actually serve your users, that's superficial thinking that won't serve your business goals in the long run.
- They research your competitors before meeting with you
- They identify gaps and opportunities in the market
- They discuss user expectations based on competitor apps
- They help you understand when to follow patterns vs when to differentiate
- They ask about your competitive advantages beyond just app features
Do They Understand Your Business Model and Revenue Goals
Here's something I've noticed over the years—most developers can build features, but not all of them think about how those features actually make you money. And that's a problem, right? Because at the end of the day, your app needs to support your business goals, not just exist as a nice piece of software that doesn't really do anything for your bottom line.
When I'm speaking with potential clients, I always want to understand how they plan to generate revenue. Is it subscriptions? In-app purchases? Advertising? A combination of things? Because the way you monetise completely changes how we approach the design and development. A subscription app needs a totally different onboarding flow than one that relies on ad revenue—the user psychology is different, the metrics we track are different, everything shifts based on that business model.
A developer who understands business will ask you about your unit economics. They'll want to know your customer acquisition cost and what kind of lifetime value you're targeting. I mean, if it costs you £8 to acquire a user but your average user only generates £5 in revenue, we've got a serious problem to solve. Maybe we need to focus on retention features that keep people engaged longer, or maybe the onboarding needs work to convert more free users to paid.
The best developers dont just build what you ask for—they help you figure out what will actually move the needle for your business
If a developer never asks about your revenue model or how you measure success, that's a red flag. They're probably just order-takers who'll build whatever you specify without thinking about whether it actually serves your goals. You want someone who connects the technical decisions to business outcomes, who can say "if we build it this way, it'll help increase conversion by making the upgrade path clearer" or "this feature might be fun but it wont help with retention based on what we know about your users."
Can They Explain Technical Decisions in Business Terms
Here's something I've noticed over the years—good developers can talk about code all day long, but great developers can tell you exactly why that code matters to your bottom line. There's a massive difference between the two, honestly.
When I'm proposing a technical solution to a client, I don't start with "We'll use React Native with a Node.js backend and integrate GraphQL APIs." I mean, sure, that might be what we do, but thats not what the client needs to hear first. What they need to know is that this approach will let us launch on both iOS and Android simultaneously—saving them about £30,000 and three months of development time. See the difference?
A developer who understands your business will connect every technical choice back to your goals. If they're recommending serverless architecture, they should be telling you it means lower hosting costs when you're starting out and the ability to scale up quickly when your user base grows. If they want to implement biometric authentication, they should explain how it'll reduce abandoned sign-ups by making login friction nearly disappear.
Its a bit mad really, but I've seen developers recommend complex solutions simply because they're interesting to build—not because they serve the business need. A client doesn't care if something is technically clever; they care if it helps them acquire customers, reduce costs, or improve user retention. The best developers I've worked with can translate "we need to optimise database queries" into "your app will load 3 seconds faster, which typically improves conversion rates by 15-20%." Thats the language that actually matters when you're trying to build a successful business.
They Challenge Your Assumptions (The Good Ones Do)
Here's something I've noticed over the years—clients who've had the best results are the ones who worked with developers willing to push back on their ideas. Not in an arrogant way, mind you, but in that respectful "have you considered this?" kind of way that makes you think twice about what you're planning to build.
A developer who understands your business won't just nod along and say yes to everything you want. They'll question why you think certain features are necessary; they'll point out when your assumptions about user behaviour might be wrong. I mean, its uncomfortable sometimes, but that discomfort is actually a good sign. It means they're thinking about your project as more than just a technical brief they need to execute.
The best conversations I've had with clients involve a bit of healthy debate. When someone tells me they want fifteen features in version one, I'll challenge that—not because I cant build it, but because I know from experience that bloated first releases rarely succeed. When they insist users will behave a certain way, I'll ask what evidence supports that assumption. These questions aren't meant to be difficult, they're meant to protect the project from costly mistakes.
Here are the kinds of challenges a good developer should raise:
- Questioning feature priorities based on what users actually need vs what you think they want
- Pushing back on timeline expectations that would compromise quality
- Suggesting simpler solutions when you're overcomplicating things
- Challenging assumptions about your target market or user behaviour
- Raising concerns about monetisation strategies that might not work in practice
If a developer agrees with everything you say without question, that's actually a red flag. You want someone who brings their expertise to the table and isn't afraid to have honest conversations about what will and won't work for your business.
The difference between challenging your assumptions and being difficult is intent. A developer who understands your business challenges you because they want your app to succeed—they're invested in the outcome, not just completing their to-do list. They've seen what works and what doesn't, and they're trying to save you time, money, and headaches down the line.
Industry Experience vs Business Understanding
Here's something I've noticed over the years—there's a massive difference between a developer who's built 20 healthcare apps and one who actually understands healthcare as a business. Sure, industry experience is valuable (I'm not going to pretend it isn't) but its not the golden ticket most people think it is.
I mean, you can build apps for restaurants your entire career and still not understand why some restaurant businesses succeed whilst others fail. You might know every food delivery API inside out, you might have integrated with dozens of POS systems, but do you understand the economics of a restaurant? The margins? The customer acquisition challenges? The seasonal fluctuations that keep owners up worrying about cash flow?
Actually, I've found that developers with strong business understanding but less industry-specific experience often deliver better results than those who've "seen it all before" in your sector. Why? Because they ask better questions. They don't make assumptions based on what worked for your competitor three years ago; they actually try to understand your specific situation, your unique challenges, your particular customers.
The best developers I know—and the approach we take at Glance—combine a bit of both. We want to understand your industry enough to speak your language and know the common pain points, but we also want to approach your project with fresh eyes and genuine curiosity about your business model. Because here's the thing: every business is different, even within the same industry. A budget hotel chain has completely different needs than a boutique luxury hotel, even though they're both "in hospitality"...and a developer who treats them the same is missing the point entirely.
Red Flags That Show They Don't Get It
Right, lets talk about the warning signs—because honestly, spotting these early can save you months of headaches and thousands of pounds. I've seen enough projects go sideways to know exactly what to look for when a developer just doesn't understand your business.
The biggest red flag? They jump straight into talking about technology. I mean, if the first thing out of their mouth is "we'll build this in React Native" or "we use Firebase for everything", thats a problem. They're thinking about tools before they understand what needs building. Its like a builder telling you what bricks they'll use before asking what kind of house you need.
Another one that drives me mad—they agree with everything you say. Sure, it feels nice at first, but good developers push back when something doesn't make sense. If you suggest a feature that'll cost a fortune but only serve 2% of your users, they should tell you. If they're just nodding and saying "yes we can do that", they either don't understand your business constraints or they don't care...and neither option is good.
When a developer cant explain why something matters to your users, they're just building features in a vacuum—and that's expensive.
Watch out for developers who talk about timelines without asking questions first. How can they possibly estimate how long something takes if they haven't understood the scope properly? And if they can't explain their technical choices in terms you understand (without making you feel stupid), that's a massive red flag too. You know what? The best developers I know can explain complex stuff simply because they actually understand it—the ones who hide behind jargon usually don't.
Finally, if they've never worked in your industry and show no curiosity about learning it, run. Fast. You need someone whos going to invest time understanding your world, not just treat your app like every other project thats crossed their desk.
Conclusion
Look, finding a developer who truly understands your business isn't easy—there are thousands of agencies out there who can write code, but far fewer who can think like a business partner. And that's really what you're looking for here, isn't it? Someone who gets why your app needs to exist in the first place, not just someone who can make buttons work and screens look pretty.
The developers who understand your business are the ones asking uncomfortable questions during discovery; they're pushing back on your assumptions (politely, mind you), and they're talking about users before they talk about tech stacks. They know your competitors as well as you do—sometimes better—and they can explain why certain technical decisions will help you hit your revenue goals. Its not rocket science, but it does require experience and a genuine interest in solving business problems rather than just building apps.
Here's the thing—you'll know within the first few conversations whether a developer gets it or not. Trust your instincts on this one. If they're jumping straight into design mockups without understanding your market position, or if they cant explain technical trade-offs in terms that relate to your business outcomes, that's your sign to keep looking. The right developer will feel more like a business consultant who happens to build apps, rather than a coder who's just waiting for you to hand over a specification document.
I've seen too many projects fail not because of bad code, but because the developer never understood what the app was meant to achieve for the business. Don't let that happen to you. Take your time, ask the right questions, and wait until you find someone who genuinely understands what you're trying to build and why it matters.
Share this
Subscribe To Our Learning Centre
You May Also Like
These Related Guides

How Can You Structure Developer Trial Periods Effectively?

What Happens to Your IP When Developers Leave Your Project?
