The call went well. The agency was sharp, the portfolio looked relevant, and the founder seemed to genuinely understand your product. You left feeling like you’d found the right team.
Three months later, you’re staring at a sprint board that hasn’t moved in two weeks, a Slack channel where responses arrive every 36 hours, and a codebase that your internal engineer described, in those exact words, as “held together with hope.” The agency still sounds sharp on every call. Nothing has changed except the invoices.
This is not a failure of judgment. It is a failure of evaluation. Most founders and business leaders hire software agencies the same way they hire employees: they assess for competence and likeability on a 45-minute call, then discover culture and operating model six weeks into the engagement when reversing course is expensive. According to a 2025 study by the Software Development Association of the UK, 61% of failed software projects cite inadequate vendor evaluation as a primary contributing factor. Not technical failure. Not scope creep. The wrong partner selected through the wrong process.
The London software market has hundreds of capable agencies. The problem is not finding an agency that can build software. The problem is identifying one whose operating model, communication culture, and post-launch commitment actually match what your project requires. Those three dimensions are almost never visible on a website or in a first-call pitch.
The ten questions below are not a politeness checklist. Each one is designed to surface something the agency won’t volunteer. Ask them before you sign anything.
Question 1: How Do You Structure Your Discovery Phase Before Any Code Is Written?
The single most predictive question you can ask a software agency is not about their tech stack or their team size. It is this one.
Discovery is the structured work an agency does before development begins: mapping your users, your business logic, your edge cases, your integration constraints, and your definition of success. Agencies that treat discovery as a genuine phase rather than a formality produce dramatically different outcomes than those that don’t. According to IBM’s Systems Sciences Institute, the cost of fixing a defect found during requirements definition is between 5 and 10 times lower than the cost of fixing the same defect found in production. Discovery is where requirements are defined, tested against reality, and refined into something a development team can actually build from.
The mistake most buyers make is asking whether the agency does discovery rather than asking how. Every agency will say yes. The agency that answers with a detailed, structured explanation who is involved, how long it takes, what deliverables it produces, and what decisions it must resolve before development can begin is telling you something real about their operating model. The agency that answers with “we start with a requirements gathering session and then we kick off development” is telling you something real too.
Ask a follow-up: what deliverable comes out of the discovery phase? The best agencies produce a functional specification, an architectural decision record, or a detailed scope document that both parties sign before a sprint begins. This is not bureaucracy. It is the shared map that prevents scope disputes from becoming budget crises later.
Consider the scenario that plays out without proper discovery. A London SME pays £45,000 for a logistics management platform. The agency begins development in week two. By week eight, the client realises the data model doesn’t support multi-location inventory, which was in the brief but not in the spec because no one produced a spec. The rebuild costs £22,000 more and delays launch by eleven weeks. The agency did nothing dishonest. They just skipped the work that would have caught the problem when it was cheap to fix.
Discovery is not an agency’s preparation. It is your insurance policy.
Question 2: Who Specifically Will Be Working on My Project, and What Is Their Experience?
This question reveals one of the most persistent gaps between what agencies sell and what they deliver.
The best agencies present during a pitch with their senior team: the technical lead who has architected twelve production systems, the project manager who has navigated three complex integrations, the designer whose portfolio you recognised. What many agencies deploy on the actual project is a different team: junior developers supervised from a distance, contractors hired specifically for your engagement, or an offshore team managed by the senior person you met twice. This is not universal. It is common enough that you need to ask the question explicitly rather than assuming the team you met is the team you’ll get.
Ask for the names and LinkedIn profiles of the specific developers, designers, and project manager who will be assigned to your project. Ask how long they’ve been with the agency. Ask what percentage of their time will be dedicated to your engagement rather than split across multiple projects. A developer working at 25% allocation across four concurrent projects is not your dedicated development partner. They are a fractional resource who will context-switch your project every few days.
The best development teams are small, focused, and consistently engaged. They build institutional knowledge about your product over time and make better decisions at sprint three because they understand the constraints they established at sprint one. That compounding advantage disappears the moment the team is fragmented across six other client engagements.
If the agency can’t tell you who specifically will work on your project before you sign, that’s a London software agency red flag. It tells you something about how they manage delivery rather than sales.
Question 3: Can You Walk Me Through a Project Where Something Went Wrong Mid-Build and What You Did?
Every agency can tell you about their successes. This question reveals operating culture rather than marketing culture.
The honest answer to this question is available at every agency that has delivered enough projects: something has gone wrong. A third-party API behaved nothing like the documentation described. A key developer left mid-project. A client changed scope requirements at week ten in ways that required architectural rethinking. These things happen in software development with enough regularity that any experienced agency has a real story to tell.
An agency that can’t name a single project where something went wrong either hasn’t done enough work to have encountered real complexity, or they’ve been coached never to admit failure in sales conversations. Neither is the answer you want. The agency that describes a specific failure, explains the root cause honestly, names what they changed in their process afterward, and can show you the outcome they delivered despite the setback is giving you the clearest available evidence of their actual operating culture.
Watch for three things in the answer: specificity (vague failures suggest coached answers), accountability (agencies that blame only the client for what went wrong will blame you too), and process change (an agency that didn’t change anything after a failure hasn’t learned anything from it).
This question is the fastest shortcut to understanding whether you’re hiring a team that solves problems or a team that manages narratives.
Question 4: What Does Your Post-Launch Support Model Include, and How Is It Priced?
Post-launch support is the dimension that most buyers evaluate last and regret most. Ask about it first.
A product does not finish at deployment. It enters a feedback cycle: real users encounter edge cases no one tested, performance characteristics under production load differ from staging, security vulnerabilities surface, and the features that made sense at launch need adjustment six weeks later when your actual user behaviour contradicts your pre-launch assumptions. An agency that treats handoff as the end of their obligation has never had to maintain a product in production.
Ask specifically: what is included in your standard post-launch support model? Is bug fixing covered, and for how long? What is the response time commitment for critical production issues? Is the same team that built the product responsible for maintaining it, or does support pass to a separate team? How is ongoing feature development scoped and priced after launch?
The answers separate agencies that build products from agencies that build deliverables. A deliverable is finished when it ships. A product is never finished. The agency whose model treats launch as a handoff is structured for the former. The agency whose model treats launch as the beginning of an ongoing partnership is structured for the latter.
The commercial reality here is worth naming plainly: many agencies price post-launch support as a premium service because they’ve structured their revenue model around project delivery rather than ongoing partnership. This is not wrong. It is a choice with consequences for how they prioritise your issues at month seven when they’re deep in three new engagements. Understand the model before you commit, not after you’ve discovered it through an invoice dispute.
Already know what you need from a development partner? Start a conversation with Empyreal Infotech here or keep reading for the remaining questions that expose what most agencies won’t volunteer.
Question 5: How Do You Handle Scope Changes Mid-Project?
Scope change is not a client failure. It is the default condition of any software project that makes contact with real users, real business constraints, or real technical discovery. The question is not whether scope will change. The question is whether the agency’s change management process protects you or extracts additional revenue from you.
Ask the agency to walk you through their change request process specifically. When a scope change is identified, who decides whether it constitutes a change, how is the impact assessed, how is it priced, and what approval process governs it? Ask how they distinguish between a genuine scope change and a piece of work that should have been in the original specification but wasn’t adequately scoped.
The answer reveals the agency’s commercial culture more directly than almost any other question. An agency that treats every undocumented detail as a billable change order is incentivised to under-scope the original engagement and then charge premium rates for the work that was always going to be necessary. This is a London tech partner due diligence concern that rarely surfaces until you’re already past the point of easy exit.
The best agencies have clear change request frameworks: a defined threshold for what constitutes a scope change versus a clarification of existing scope, a structured estimation process that the client reviews before approving, and a history of absorbing minor changes within the project rather than billing every two-hour deviation as a formal change order.
Ask for a real example of a scope change they managed with a current or recent client and how it was handled. The story is more useful than the policy document.
Question 6: How Does Your Agile Development Methodology Actually Work in Practice?
Every agency in London claims to use agile development methodology. Almost none of them will agree on what that means.
Agile is not a single process. It is a set of principles that manifests differently across teams: sprint lengths vary from one to four weeks, sprint ceremonies range from daily standups to weekly check-ins, backlog management philosophies differ, and the degree to which clients are involved in sprint planning varies significantly across agencies. An agency that says “we use agile” is telling you almost nothing about how you’ll experience working with them.
Ask specifically: how long are your sprints? What happens at the end of each sprint in terms of deliverables and client review? How is the backlog prioritised, and who has authority to reprioritise? What is your sprint velocity for a project of similar scope to mine? How do you handle sprint commitments when an unexpected technical issue consumes more capacity than planned?
The best agencies treat agile as a communication structure rather than just a development structure: regular sprint reviews where the client sees working software rather than status reports, clear visibility into what is committed, what is in progress, and what is blocked, and an honest conversation when sprint capacity conflicts with feature ambition.
Watch for agencies that describe agile as “flexible and iterative” without being able to describe their actual sprint structure. Flexibility is not the same as process. An agency without a defined process is not agile. It is unstructured. The consequences of that distinction arrive at week six.
Question 7: Can You Show Me Case Studies with Measurable Outcomes for Projects Similar to Mine?
Portfolio pages look similar across the London software market. The distinguishing quality is not visual polish. It is whether the work produced measurable results.
Ask for software agency case studies and portfolio evidence that describes your specific project category in terms of business outcome rather than technical delivery. The difference: “we built a customer portal for a financial services firm” is a delivery description. “The customer portal reduced inbound support calls by 34% within 90 days of launch and cut average customer onboarding time from 12 minutes to 4” is an outcome description. One tells you what they built. The other tells you whether it worked.
Demand at least one case study where they can name the problem the client faced before the build, the specific approach they took, and the specific result they delivered after launch. If the agency can’t describe outcomes with numbers, one of two things is true: either they didn’t measure them, or the outcomes weren’t worth measuring. Both are informative.
Ask whether they can connect you with the client directly. An agency confident in their work will make that introduction. An agency that deflects to written testimonials rather than live client references is managing the narrative rather than proving the outcome.
Want to see specific, measurable case studies before starting a conversation? Talk to Empyreal Infotech we’ll walk you through the numbers before you commit to anything.
Question 8: Who Owns the Code and IP at the End of the Project?
This question is rarely asked in the first meeting and regularly produces expensive disputes after project completion.
Intellectual property ownership in software projects is not automatic. In the UK, the default legal position is that work created by an independent contractor or agency belongs to the creator unless there is a written agreement that assigns ownership to the client. Many agencies use standard contracts where IP assignment language is either absent, conditional on full payment, or limited to specific deliverables rather than the entire codebase. Discovering this at the point of dispute when you want to take your code to a different agency or when you want to raise investment and your lawyers conduct IP due diligence is significantly more costly than asking the question in conversation one.
Ask specifically: does the contract provide full IP assignment to us upon project completion? Are there any third-party components, libraries, or tools embedded in the codebase that we cannot own or that carry licensing restrictions? Will we have full source code access throughout the project or only at handoff?
The best agencies provide clean IP assignment as a standard term and can explain clearly any licensed components that carry open-source obligations. Agencies that create ambiguity around IP ownership at the proposal stage will not create clarity around it in the contract without direct negotiation.
This is not a cynical question. It is a foundational one. Your software is infrastructure. You need to own your infrastructure.
Question 9: What Is Your Approach to Security and Data Handling Throughout the Build?
Security is not a feature you add at the end of a project. It is an architectural posture you either build from day one or retrofit at significant cost.
Ask every agency on your shortlist: how do you integrate security review into your development process? At what stages does security testing occur? How do you handle sensitive data in staging environments? What is your policy on third-party access to production systems? Do you conduct code reviews with security as a specific criterion, and who performs them?
The answers reveal whether the agency treats security as a first-order concern or as a post-delivery audit. An agency that describes security review as something that happens before launch is telling you it happens at the end of the build, when the cost of addressing findings is highest. An agency that describes security considerations as part of architecture planning, sprint review, and pre-deployment testing is telling you it’s embedded in how they build.
This distinction matters more as the sensitivity of your data increases. A marketing landing page and a healthcare platform do not have equivalent security requirements. But the practice of building securely from the first commit rather than securing a completed product is better engineering regardless of the data type. The agencies that approach security as infrastructure rather than a final inspection consistently produce more defensible codebases at similar cost.
Question 10: What Does Communication Look Like Week to Week Throughout the Engagement?
Communication architecture is the dimension that destroys client-agency relationships more reliably than almost any technical failure. Bad code can be fixed. Bad communication patterns compound over time until they become irreversible.
Ask specifically: how often will we receive structured project updates? What format do those updates take? Who is my primary contact for day-to-day questions? Who is my escalation contact if I have concerns the primary contact hasn’t resolved? What is your committed response time for non-urgent questions versus production issues?
The best agencies have built communication infrastructure rather than relying on relationship management: weekly written sprint summaries that include what was completed, what is planned for the next sprint, what is blocked, and what decisions require client input. This is different from an agency that says “we’re very communicative” or “you’ll always be able to reach us.” Agreeableness is not a communication system. A communication system is a defined structure that operates whether or not the relationship is smooth.
Watch for the agency whose communication quality peaks in the sales process and drops after contract signature. The most reliable signal of post-signature communication culture is how quickly and specifically they respond to your pre-signature due diligence questions. If they’re responsive and specific now, they’ve probably built a culture of responsive communication. If they’re slow and vague before they have your money, they’ll be slower after.
What Honest Evaluation Actually Costs You in Time
Asking all ten of these questions thoroughly takes between two and three conversations per agency. That is three to six hours of evaluation time per shortlisted firm. For a project between £40,000 and £150,000, that evaluation investment represents less than 1% of the total project cost and has historically separated successful engagements from costly rebuilds with reliable frequency.
The instinct to compress evaluation time is understandable. You’re busy. The agency seemed good in the first call. You want to get started. But consider what compressed evaluation actually trades: three hours of focused questioning in exchange for the risk of discovering at week eight that your chosen partner has a communication model that doesn’t work for your team, an IP contract that requires renegotiation, or a post-launch support model that ends at handoff.
The market for affordable software development companies London includes agencies at every price point and quality tier. Price is not the discriminating variable. The agencies that routinely produce strong outcomes are not uniformly the most expensive. They are the ones whose process, communication, and post-launch commitment align with what the project actually requires. You can only identify that alignment through evaluation. There is no shortcut to that conversation.
A Pattern Worth Noting Before You Shortlist
The questions above are structured to reveal operating model, not technical capability. Most London software agencies at the credible end of the market can build what you need. The technical capability floor is higher than most buyers assume. What varies dramatically is the structure around that capability: how they manage scope, how they communicate during delivery, how they handle production issues, and whether they’re still engaged and responsive six months after launch.
When you’re working through your evaluation, the agencies that answer these questions with specificity that can name real scenarios, produce real numbers, and connect you to real clients are not trying harder to win your business. They’ve built processes that produce outcomes worth describing. The agencies that deflect to general principles and polished pitch language haven’t, or they’re managing what you learn about the ones they have.
Choosing the right software agency UK comes down to this: the relationship you’re entering is not a transaction. It is a technical partnership that will shape the architecture your business runs on. The decisions made in the first sprint influence the options available in sprint thirty. Evaluate accordingly.
FAQ: Hiring a Software Development Agency in London
What Are the Most Important Questions to Ask Before Hiring a Software Agency in London?
Ask these ten questions before signing any contract: (1) How is your discovery phase structured? (2) Who specifically will work on my project? (3) Describe a project where something went wrong mid-build. (4) What does post-launch support include? (5) How do you handle scope changes? (6) How does your agile process work in practice? (7) Can you show measurable outcomes in similar case studies? (8) Who owns the IP and code at project end? (9) How is security integrated throughout the build? (10) What does week-to-week communication look like? These questions surface operating model and culture rather than just technical capability.
How Do I Spot London Software Agency Red Flags During Evaluation?
The most reliable red flags are: an inability to describe a past project failure honestly; vague answers to specific process questions; refusal to connect you with past clients directly; IP contract language that is conditional or absent; a post-launch support model treated as a premium upsell rather than a standard service; and communication quality that is noticeably higher before contract signature than during delivery. These patterns are more predictive of a poor outcome than technical portfolio weaknesses.
What Should a Software Agency’s Discovery Phase Produce?
A proper discovery phase should produce at minimum a functional specification or detailed scope document that both parties review and sign before development begins. Strong agencies also produce an architectural decision record, a data model outline, and a risk register identifying integration dependencies and technical constraints. Any agency that begins sprints without a written, agreed specification is building without a shared map. That gap almost always generates cost and timeline disputes later.
How Important Is It to Hire Software Developers London Who Are Specifically Dedicated to My Project?
Team dedication is one of the strongest predictors of project quality. A developer working at full allocation on your project builds contextual knowledge of your codebase, your users, and your business logic over time. A developer splitting time across four concurrent engagements loses that compounding advantage with every context switch. Ask specifically what percentage allocation each team member will have on your project. Any answer below 50% for your primary developer is a meaningful quality risk.
What Should a Software Agency’s Agile Development Methodology Look Like in Practice?
Agile should produce visible progress at defined intervals: working software reviewed by the client at the end of each sprint, a clear distinction between committed sprint work and backlog items, and a structured process for raising blockers before they become missed deadlines. A sprint length of one to two weeks is standard for most London software development engagements. Longer sprints reduce visibility without improving output. Ask for a demo of the sprint reporting format before you commit to see exactly what your weekly or fortnightly update will look like.
Why Does IP Ownership Matter When Hiring a Software Agency?
Your software is operational infrastructure. If you don’t own the codebase outright, your ability to switch agencies, attract investment, or audit your own systems depends on the continued goodwill of the agency that built it. UK law does not automatically assign IP to the client in contractor relationships. Ask for explicit written IP assignment in the contract, confirm that all third-party library usage is clearly documented with licensing terms, and ensure full source code access throughout the engagement, not only at handoff.
The Question Behind All the Questions
There is a pattern to the ten questions above. They are all variations of one underlying question: does this agency build products, or does it build deliverables?
A deliverable is finished when it ships. The agency’s obligation ends at handoff. You received what was specified, the contract closes, and what happens next is your problem.
A product is never finished. It enters a feedback cycle at launch and requires a partner who is as invested in what it becomes as in what it was when it shipped. The agency that treats launch as the beginning of the relationship rather than the end of it operates differently at every stage: they scope more carefully, because they’ll maintain what they build; they communicate more consistently, because they’ll still be talking to you in month nine; they build with security and scalability from day one, because they know the code will need to grow.
Ask the ten questions. But listen for the answer to the one underneath all of them.
If you’re building custom software for a startup, SME, or growth-stage business and want a partner who stays engaged after launch, book a free 30-minute discovery call with Empyreal Infotech. No pitch deck. No pressure. Just a direct conversation about whether your project is a fit.
