Knowing when to decline a software project is an important decision for any software development agency. At SynthWeb, we recently turned down a potential £90,000 project after a two-hour discovery call revealed risks that could affect the client’s long-term success.
The project was real, the budget was confirmed, and the brief was well prepared. However, accepting the work without addressing the underlying problems could have created the same difficulties the client had experienced before. Here’s what happened, why we said no, and what other software businesses can learn from the experience. Understanding when to decline a software project helps an agency protect its clients, maintain delivery standards, and avoid taking on work without the right conditions for success.
The £90,000 software project on the table
A UK-based logistics business approached us to build a bespoke route optimisation and fleet management system. The proposed budget was between £85,000 and £95,000, with a six-month delivery timeline.
The founder understood the technical side of the business, and the requirements were clearly documented. On paper, it looked like the kind of project a software studio would be excited to take on.
But during discovery, we learned something important: the company already had a route optimisation system built by a previous agency.
That raised a few questions. Why replace an existing system? What wasn’t working? And what would make a new solution more successful?
When to decline a software project: Three questions that changed everything
Our discovery conversation focused on three questions.
First, what are you currently doing for route optimisation?
The client explained that they already had a working system built by another agency.
Second, what went wrong with the previous engagement?
The system still worked, but the previous agency had left without properly handing over the code. As a result, the client couldn’t maintain the software confidently.
Third, what would you want us to do differently?
After a pause, the answer was simple: build a better version.
That answer revealed the real issue. The client wanted a replacement system, but the reasons behind the previous engagement’s failure hadn’t been fully addressed.
A new development team could build better software, but that alone wouldn’t resolve problems with code ownership, documentation, handover, or ongoing maintenance.
Why we decided to turn down the project
For a software agency, knowing when to decline a software project means recognising potential delivery risks before committing time, resources, and money. Knowing when to decline a software project is not about avoiding difficult work or losing a valuable contract. It is about recognising risks early, asking the right questions, and making sure the client has a realistic path towards a successful outcome. At SynthWeb, we don’t decline projects simply because they’re complex. We decline them when the conditions needed for success aren’t in place.
In this case, immediately starting a new build could have repeated the same problems. Even a technically excellent system would create future difficulties if the client lacked a clear plan for maintaining it and managing technical ownership.
This is also why understanding existing software matters before commissioning a replacement. The UK Government’s guidance on preventing technical debt and legacy systems highlights the importance of planning for the ongoing health and ownership of digital products.
We explained our concerns and proposed a two-week technical audit of the existing system before committing to a new build. The audit would have helped us understand the codebase, identify the underlying issues, and determine whether replacement was the right decision.
The client declined the audit.
That confirmed our decision. Without first understanding the existing problems, committing to a six-month development project would have introduced risks neither side had properly assessed.
What founders should check before hiring a software agency
Learning when to decline a software project can help founders avoid repeating costly mistakes and choose a development partner who understands their long-term needs. If you’re planning a custom software project, there are a few practical steps worth taking before signing a contract.
- Understand your existing system: If you’re replacing software, establish what works, what doesn’t, and why.
- Clarify code ownership: Confirm who owns the source code, repositories, documentation, and technical decisions.
- Plan for maintenance: Decide who will manage updates, fixes, security, and future improvements after launch.
- Allow time for discovery: A technical audit or discovery phase can reveal risks before substantial development spending begins.
The UK National Cyber Security Centre’s secure development guidance also emphasises the need to plan for software flaws and ongoing security risks rather than assuming that development alone guarantees a reliable product.
If you need help deciding how to approach a new product, explore SynthWeb’s MVP Sprint and Engineering Pods services.
What this decision taught us
Turning down a £90,000 opportunity wasn’t an easy commercial decision. However, the size of a project’s budget doesn’t determine whether it is the right project to accept.
The better question is whether both sides understand the problem, agree on what success looks like, and have the foundations needed to achieve it.
Sometimes, the most responsible first step isn’t writing code. It’s understanding why the previous solution failed and making sure the next one has a better chance of succeeding. Ultimately, knowing when to decline a software project can be just as important as knowing how to deliver one successfully.
Frequently asked questions
Does SynthWeb often turn down software projects?
Not often, but we do so deliberately when important conditions for success are missing. We’d rather take on fewer projects we’re confident we can deliver well than accept work that puts the client at unnecessary risk.
What are the warning signs that a software project might fail?
Common warning signs include unresolved issues with a previous agency, unclear code ownership, unrealistic deadlines, insufficient testing budgets, and no plan for maintenance. One warning sign deserves discussion; several together may require a pause before development begins.
How can a founder evaluate whether a software agency is the right fit?
Ask the agency about projects it has declined, how it handles problems during development, and how it supports clients after launch. You can also request a reference from a client who faced a difficult situation during an engagement. These conversations can reveal more about the agency’s working approach than a portfolio alone.
The project on the table
A UK-based logistics business wanted a bespoke route optimisation and fleet management system. Scope was clear, budget was confirmed at £85,000–£95,000, timeline was 6 months. The founder was technically informed and the brief was well-prepared. On paper, this looked like the kind of project we should be excited about.
What the questions revealed
Three questions surfaced the problem. First: what are you doing with route optimisation today? Answer: we have a system already — built by a previous agency. Second: what went wrong with it? Answer: it works but the previous agency left without handing over the code properly and we can’t maintain it. Third: what would you want from us that was different? Silence, then: just build us a better version. The pattern was clear — the client hadn’t resolved what went wrong with the last engagement, and the risk of the same outcome was high enough that taking the work would have been the wrong decision for both sides.
Why we said no — and how
We decline work when the success conditions aren’t in place, not when the project is hard. In this case, the success condition was missing: the client needed to understand and resolve what had gone wrong with the previous agency before commissioning a replacement. Taking the project without addressing that would have put us in the same position — delivering a system into an environment that wasn’t ready to receive it. We said no, explained why, and suggested a two-week technical audit of the existing system as a first step before any new commission. They declined the audit. That confirmed the decision was right.
FAQ
Does SynthWeb often turn down projects?
Not often — but deliberately. When we do, it’s because we’ve identified a condition for success that isn’t in place, and taking the work without addressing it would produce a bad outcome for the client and damage our reputation. We’d rather have fewer projects we’re proud of than more projects we’re uncomfortable with.
What are the warning signs that a software project is likely to fail?
Unresolved history with a previous agency, unclear ownership of technical decisions on the client side, budget pressure that requires cutting corners on architecture or testing, and timeline pressure that leaves no margin for the unexpected. Any one of these requires a conversation. More than one requires a decision.
How should a founder evaluate whether a software agency is the right fit?
Ask them about the projects they’ve declined and why. Ask what happens when a project hits problems mid-sprint. Ask to speak with a previous client who had a difficult moment in the engagement. The answers reveal more than a portfolio.
