--- title: What due diligence steps matter most in developer selection description: Learn which due diligence steps actually matter when choosing a developer, from reading past work critically to spotting red flags before you sign. image: https://weareaffective.com/hubfs/learning-centre-images/what-due-diligence-steps-matter-most-in-developer-selection.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-due-diligence-steps-matter-most-in-developer-selection#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What due diligence steps matter most in developer selection Table of Contents Choosing a developer is one of the most consequential decisions a founder makes, and the process most people use to make it is barely adequate. They look at a portfolio, have a call that feels positive, and sign a contract. The portfolio shows the developer can produce something that looks good. The call confirms they seem reasonable to talk to. Neither of these things tells you whether they will ask the right questions before building, whether they will push back when your brief has a gap in it, or whether they will tell you something you do not want to hear before it costs you money to ignore it. > The decisions made before a line of code is written are the ones that determine whether a project reaches launch or burns through its budget. The work of due diligence is not glamorous, and it does not feel like progress the way signing a contract does. But the decisions made before a line of code is written are the ones that determine whether a project reaches launch or burns through its budget in design and build without ever getting there. We have seen both outcomes. The difference, more often than not, comes down to how carefully a team was chosen and how honestly the relationship started. What follows is the due diligence process we think actually matters, drawn from the projects where it went well and the ones where it did not. ## Why Most Due Diligence Stops at the Portfolio A portfolio is evidence that a developer has shipped products. It is not evidence of how they got there. It does not show you the conversations that happened before the first wireframe, whether the original scope held, how they responded when the client changed direction, or what the project cost relative to what was budgeted. All of those things matter more to your project than whether the home screen looks clean. The reason most due diligence stops at the portfolio is that going deeper is uncomfortable. It requires asking questions that feel confrontational, like whether they have ever walked away from a client or whether they have ever told a client their brief was wrong. Most founders are in a positive frame of mind at the point of selection, they want this person to be the right choice, and that optimism shapes the questions they ask. There is also a skills gap. Most founders commissioning their first or second product do not yet know what good looks like in [app development](https://weareaffective.com/app-development). They can evaluate a visual design. They cannot easily evaluate a discovery methodology or a security architecture decision. So they default to what they can assess, which is the surface. The job of due diligence is to go past the surface before you are committed, not after. ## How to Read a Developer's Past Work Critically When you look at a portfolio, the right question is not whether the products look good. The question is what decisions the developer made during those projects and why. Ask them to walk you through one case, not the highlights reel version, but the actual process from brief to launch. Where did the scope change? What did they build first and why? What did they recommend cutting? If they cannot answer those questions with specifics, the portfolio is telling you less than you think. A developer who built a beautiful product under perfect conditions is a different thing from a developer who made good calls when the conditions were difficult. #### Ask About What Did Not Ship One of the most revealing questions you can ask is what got cut from a project and whose decision that was. A developer who has never recommended cutting a feature, or who hands that decision entirely to the client every time, is not doing the strategic part of the work. The best developers treat scope as something to manage actively, not just to document. #### Ask About the Budget Ask whether projects came in on budget and, if not, why. Not as a gotcha, but as a genuine probe into how they handle scope creep and cost transparency. A developer who has always hit budget on every project may not be telling you the full story. One who can explain specifically what caused overruns on a past project and what they changed as a result is showing you something real. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The Discovery Process as a Screening Tool The most reliable signal a developer will give you about how they work is how they approach discovery. A team that wants to move straight to design and build before the problem is properly understood will cause you problems. Not because they are bad developers, but because you will spend budget building the wrong thing. We worked with a property developer building a concierge app for high-rise properties who came in with a suggested budget and a pre-formed idea of what they wanted. They were looking for a validation rather than a full scoping exercise. We convinced them to run a proper discovery phase, including focus groups and user workshops. What we found was that the product needed to be far simpler than they had planned. A lot of the features they wanted to include were dropped, and the focus shifted to creating a human connection with the product rather than replacing the systems already in the building. The result was a better product at a lower cost. That kind of outcome is only possible if the developer insists on doing the work to understand the problem first. When you are evaluating a developer, ask them [what their discovery process looks like](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo) and what happens if the findings contradict the original brief. A team that has a real answer to that second question is one that treats discovery as genuine inquiry, not as a formality before the build starts. Ask every developer you are considering: "Can you describe a discovery process where the findings changed the product significantly?" If they cannot give you a specific answer, they are treating discovery as a box to tick rather than a genuine phase of work. According to [Devtimate](https://devtimate.com/glossary/discovery-phase/), projects that skip discovery are 3 to 5 times more likely to fail or exceed budget. That figure matches what we have seen on our own work, particularly on projects where a client arrived with certainty about what they wanted and a resistance to questioning it. ## What Happens When Founders Skip Scoping On a dating app project focused on verified profiles and preventing bots, the client chose to skip discovery for the messaging component and focus purely on the onboarding process. The reasoning was that messaging was straightforward and did not need the same scrutiny as verification. That turned out to be wrong in a way that was expensive to fix. Because we skipped discovery for messaging, what we built was a generic messaging feature that contradicted the core premise of the product. The onboarding process verified every user carefully. The messaging system then allowed automated and fake messages, which undermined the entire point of the verification work. The mismatch meant the whole messaging section had to be rewritten. That cost approximately £15,000 in additional budget and two months of extra work. The lesson is not that the client made a bad decision in isolation. The lesson is that [every component of a product connects](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-) to every other component, and scoping decisions made for one part have consequences for the rest. A developer who lets a client skip scoping for part of a product without flagging those consequences is not doing their job. Before signing any contract, ask the developer how they handle it when a client wants to skip or abbreviate the scoping phase for a specific component. Their answer will tell you a lot about how much of the risk they are willing to carry on your behalf. When you are evaluating developers, ask specifically how they document scope and what happens when a client wants to deprioritise a discovery exercise for part of the product. A developer who has no framework for that conversation is one who will let you make expensive decisions without the information you need. ## Checking Whether a Developer Will Challenge You Most developers will tell you what you want to hear in an early conversation. The economic incentive is clear: push back too hard and you lose the work. This is rational behaviour for them, but it is [a problem for you](https://weareaffective.com/learning-centre/how-to-tell-whether-your-digital-problem-is-a-format-problem-or-a-brief-problem). A developer who agrees with everything you say before the contract is signed is training you to expect agreement throughout the project, and that habit becomes costly when your brief has a real problem in it. We see this most clearly in the early conversations with founders. A pre-launch founder in the football industry came to us with a colour-coded spreadsheet mapping out competitor products, aiming to merge several of them into one. They were visibly pleased with the analysis. When we started asking questions about [why a user would choose](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) an all-in-one product over the specialised apps they already used, and whether consolidation risked making individual features weaker, the founder became deflated. Our view is that being honest about what will make a product succeed is the job, and a developer who does not do that in the early conversations will not do it during the build either. When you are talking to a prospective developer, present them with something in your brief that is genuinely questionable and see how they respond. Not a trap, just a decision that has a real alternative. If they validate it without question, that is information. ## Budget Transparency and Scope Control The most consistent cause of project failure is [scope creep that goes unmanaged](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi) until the budget is gone. On the sports club app project, we warned the client early on that the budget would spiral out of control and that they were at risk of running out of money before publishing anything. Despite those warnings being recorded and acknowledged, the client continued adding features. The project ended with the entire budget exhausted, nothing on the app store, and the client and agency parting ways. That outcome was preventable. But preventing it required a developer willing to be firm about scope, not just to document the warnings and carry on building. When you are evaluating developers, ask them how they handle scope creep and what their process is when a client wants to add features mid-project. Ask whether they have ever pushed back hard enough on a client to risk losing them. A developer who has never had that experience either has not worked on enough projects or has not been honest enough with the ones they have worked on. | Budget question to ask | What a good answer looks like | What a weak answer looks like | | --- | --- | --- | | How do you handle scope additions mid-project? | A clear change-control process with cost and timeline impact assessed before any work starts | "We try to be flexible" or "we work it out as we go" | | Have you ever told a client they could not have a feature? | A specific example with the reasoning behind the decision | A general statement about always putting the client first | | What happens if we run out of budget before everything is built? | A prioritisation framework and a clear conversation about MVP scope from the start | Reassurance that it will not happen | ## How Developers Handle Disagreement and Bad News A developer who cannot tell you something is wrong until it is too late to fix it is a vendor, full stop. The distinction matters. A vendor delivers what was ordered. A partner tells you when what was ordered is not what you need, and they do it early enough to change course. The test for this is not asking a developer how they handle conflict, because everyone will give you a good answer to that question. The test is watching how they behave when you give them an instruction in an early meeting that you know is suboptimal. Do they follow it without comment, or do they ask why and offer an alternative? Do they frame disagreement as something that happens to the project, or as part of their service? #### The Difference Between Pushback and Capitulation There is a difference between a developer who disagrees, explains their reasoning clearly, and then respects your decision, and one who either says nothing or who continues to resist after you have made a call. You want the first type. The second and third are both signs of a relationship that will cause friction at the wrong moments. Good disagreement is quick, specific, and resolved without drama. #### How They Deliver Bad News Ask a prospective developer to describe a time they had to tell a client something that significantly changed the project. What was the news, when did they raise it, and how? A developer who raises problems early and directly is managing your risk. One who surfaces problems late, or who frames bad news as the client's fault, is telling you something about how they operate under pressure. ## Technical Decision-Making Under Constraints Every project involves constraints, whether budget, timeline, or technical limitations in existing systems. How a developer makes decisions within those constraints is one of the most important things to understand before you hire them, and it is rarely discussed in early conversations. On the performance coaching survey app, one of the biggest technical challenges was locking down Firebase security rules without the protection of a dedicated API layer. We made a deliberate early decision to skip a traditional API for the MVP, which kept the build lean and fast. But that decision had a consequence: with no API acting as a controlled intermediary between the client and the database, we had to scrutinise every security rule very carefully to ensure neither the app nor the web response page could be exploited. That is the kind of trade-off that a developer needs to flag clearly before the build starts, not discover halfway through it. When you are evaluating a developer, ask them to describe a technical decision they made under budget or time constraints and what the downstream consequences were. A developer who can answer that question with specifics understands the relationship between early decisions and later costs. One who cannot is either inexperienced or not being honest about their process. Ask developers directly: "What technical shortcuts have you taken on past projects to hit a budget, and what did those shortcuts cost later?" The answer reveals how transparent they are about trade-offs and whether they flag consequences before committing to an approach. ## Red Flags in Early Conversations The early conversations with a developer are the best data you will get about how they work, because they have not yet adapted to your specific preferences. Before they know what you want to hear, they will show you who they are. Pay attention to what they say and, more usefully, what they do not say. The most reliable red flags are not dramatic. They tend to be small signals that become patterns. - They validate everything you say without asking a clarifying question - They [talk about features before they have asked about users](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) - They give you a budget estimate before understanding the full scope - They do not ask what success looks like after launch - They refer to discovery as something that happens alongside design rather than before it - They have no answer to what happens if their estimates are wrong None of these signals alone is conclusive. But two or three of them together, in a first conversation, suggest a developer who is focused on winning the work rather than on doing it well. The pitch phase and the project phase require very different skills, and a developer who is very good at one is not necessarily good at the other. ## When to Walk Away From a Developer There are situations where the right decision is to decline a developer, even when the portfolio is good, the price is right, and the conversation has been positive. The clearest of those situations is when a developer resists the discovery process, because that resistance tends to compound as the project progresses. We walked away from a project involving a fairly standard social product because the client wanted to go straight into redesigns without any discovery work. They were not willing to engage with the [user-centred discovery phase](https://weareaffective.com/learning-centre/why-your-social-media-app-needs-more-than-just-pretty-design) that we treat as non-negotiable. Rather than compromise the process, we declined the work. That is a difficult decision commercially, but the alternative is carrying responsibility for a product whose foundational assumptions were never tested. The same logic applies in reverse when you are the one choosing a developer. If a developer resists your questions about their process, if they are vague about how they handle scope or budget, or if they seem more interested in starting than in understanding, those are reasons to keep looking. A developer who is uncomfortable being scrutinised before the contract is signed will be harder to hold accountable once the project is running. According to [arXiv research into large IT projects](https://arxiv.org/abs/1304.4525), most run roughly 24% longer than expected, and 18% are extreme outliers with cost overruns exceeding 25%. The selection decision is one of the few points at which you can materially reduce that risk before it materialises. ## Conclusion The portfolio is the beginning of due diligence, not the end of it. The questions that matter come after it: how a developer runs discovery, how they handle disagreement, what they do when a client's brief has a problem, and how transparent they are about budget and scope. Those things are harder to evaluate than visual design, but they are the things that actually determine whether a project launches. The pattern we see in projects that fail is usually a relationship that was never built on honest terms. The client did not know what to ask before signing, and the developer did not volunteer what the client needed to hear. The due diligence process is how you change that dynamic before it costs you. Ask harder questions earlier. Watch for what a developer does not say. Treat their response to your brief as data. And if a developer cannot tell you clearly how they handle the difficult parts of a project, assume that their approach is to avoid those conversations rather than to have them well. The founders who end up with products they are proud of are the ones who chose partners rather than vendors. That distinction starts with how you select, not with how you build. [Let's talk about your developer selection process](https://weareaffective.com/get-started). ## Frequently Asked Questions Why is looking at a developer's portfolio not enough during due diligence? A portfolio shows that a developer has shipped products, but it does not reveal how they got there. It tells you nothing about whether the original scope held, how they handled difficult decisions, or what the project cost relative to the budget. What questions should I ask a developer about their past projects? Ask them to walk you through a real project from brief to launch, including where the scope changed and what they recommended cutting. If they cannot answer with specifics, the portfolio is giving you far less information than you might assume. Why do so many founders stop their due diligence at the portfolio stage? Going deeper requires asking questions that can feel confrontational, and most founders are in an optimistic frame of mind when selecting a developer. There is also a skills gap, as many founders commissioning their first or second product do not yet know what good looks like beneath the surface. What does it mean for a developer to manage scope actively? A developer who manages scope actively treats it as something to shape and challenge, not simply accept. The best developers will recommend cutting features when necessary, rather than leaving every such decision entirely to the client. How can I tell whether a developer will push back on a flawed brief? Ask them directly whether they have ever told a client their brief was wrong, and listen carefully to how they answer. A developer who cannot recall a specific example may not be doing the strategic part of the work. Why do decisions made before coding begins matter so much? The decisions made before a line of code is written largely determine whether a project reaches launch or burns through its budget without getting there. Poor choices at the selection and briefing stage are very difficult and expensive to correct later. What should I look for when a developer walks me through a past case study? Look for honest, specific answers about what went wrong, what changed, and what trade-offs were made. A developer who only presents a highlights reel, without acknowledging difficulty or hard calls, is not giving you a useful picture of how they actually work. Is it reasonable to ask a developer whether they have ever walked away from a client? Yes, and the article suggests this is exactly the kind of question that matters. It can feel uncomfortable to ask, but a developer's answer will tell you a great deal about how honestly they approach client relationships. ## Related Articles [![Should my dating app include video chat and how much does it cost?](https://weareaffective.com/hubfs/learning-centre-images/should-my-dating-app-include-video-chat-and-how-much-does-it-cost.webp)](https://weareaffective.com/learning-centre/should-my-dating-app-include-video-chat-and-how-much-does-it-cost) ### [Should my dating app include video chat and how much does it cost?](https://weareaffective.com/learning-centre/should-my-dating-app-include-video-chat-and-how-much-does-it-cost) Only [0.6% of Tinder swipes lead to dates](https://wifitalents.com/dating-app-swipe-statistics/), according to WifiTalents, 2026. That number tells you... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How Do I Know if My App Update Schedule Is Too Slow?](https://weareaffective.com/hubfs/learning-centre-images/how-do-i-know-if-my-app-update-schedule-is-too-slow.webp)](https://weareaffective.com/learning-centre/how-do-i-know-if-my-app-update-schedule-is-too-slow) ### [How Do I Know if My App Update Schedule Is Too Slow?](https://weareaffective.com/learning-centre/how-do-i-know-if-my-app-update-schedule-is-too-slow) An app that ships infrequently feels stagnant to users, even when the team behind it feels busy.... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How do I stop my app disappearing in search results?](https://weareaffective.com/hubfs/learning-centre-images/how-do-i-stop-my-app-disappearing-in-search-results.webp)](https://weareaffective.com/learning-centre/how-do-i-stop-my-app-disappearing-in-search-results) ### [How do I stop my app disappearing in search results?](https://weareaffective.com/learning-centre/how-do-i-stop-my-app-disappearing-in-search-results) There is a version of this problem that looks like a marketing failure and a version that looks... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.