How to Choose a Software Consultancy That Won't Waste Your Time

To choose a software consultancy that won't waste your time, focus on four things: whether they can show you working software they have shipped, how they handle scope uncertainty, whether their team structure matches your problem size, and whether you can actually understand how they think. Everything else, credentials, case study PDFs, agency awards, is noise until those four pass.

I'm writing this because I run a small consultancy myself, BedrockTeam, and I've spoken to enough founders who've been burned to know the patterns. This isn't a sales pitch. If you read this and decide a different consultancy fits better, good: you made a better decision. That's the point.

Why most consultancy vetting goes wrong

Most founders evaluate consultancies the wrong way because consultancies have learned to present well. A polished deck, a discovery call with a senior person, a few recognisable logos in the footer: these are easy to produce and they are optimised for the sales process, not for actual delivery. The things that predict whether your project lands well are much harder to surface in a pitch.

The other failure mode is evaluating on price too early. A cheaper day rate from a larger agency often hides a bait-and-switch: the senior people who pitched you hand off to juniors once the contract is signed. Understanding who will actually work on your project is more important than the headline number.

A practical process for evaluating any software consultancy

1. Ask to see working software, not case studies. Any consultancy worth hiring can point you to something live that they built. Screenshots age. A URL you can click does not. If the answer is 'we're under NDA for everything', push back: most clients allow a demo under NDA, and a consultancy with nothing to show you is a red flag.
2. Find out who is actually doing the work. In larger agencies, project delivery often sits with mid-level developers while senior staff stay in the account management lane. Ask directly: 'Who will write the code? Will they be on every call, or handed a spec?' The answer tells you more than any credentials page.
3. Test how they handle not knowing something. Give them a real problem from your context, ideally one with some ambiguity, and watch what they do. Good consultancies ask clarifying questions and surface tradeoffs. Average ones give you a confident answer that glosses over the hard parts. You want the former.
4. Understand their default way of working. Do they work in short, visible cycles where you can see progress weekly, or in long stretches where you get updates at milestones? The former is almost always better for founder-led businesses because it means you can course-correct before costs compound.
5. Check whether they will push back on you. A consultancy that agrees with everything you say is not saving you trouble; it's deferring problems. The ones worth hiring will tell you when your instinct is wrong or when a feature you want is going to make the architecture worse. If they never disagree with you in the sales process, they won't in delivery either.
6. Ask a specific question about team size and availability. A solo contractor moonlighting as a 'consultancy', a two-person outfit, and a 40-person agency have completely different risk profiles. Neither is automatically better, but you need to know which you're buying and whether it matches the scale and pace you need.
7. Get clear on what happens when things slip. Scope creep, delayed decisions, third-party integrations that behave unexpectedly: these are routine, not exceptional. Ask how they've handled them before. The answer should include a specific example, not a process diagram.

Software consultancy vs agency: what the distinction actually means

The terms 'software consultancy' and 'software agency' get used interchangeably, but the working model is often different. Agencies tend to run projects with defined deliverables, fixed timelines and a handoff at the end. Consultancies, at least good ones, stay closer to the problem and treat the engagement as iterative: the scope evolves as you learn more.

For most lean founder-led businesses, the consultancy model fits better. You rarely have a perfectly specified problem at the start. What you have is a direction and a budget, and you need someone who can think alongside you, not just execute against a spec.

What to look for in a small team consultancy specifically

If you're a founder or operator running a lean business, a small consultancy is often the right fit, but it comes with its own risks. Capacity is the main one. A two-person outfit can only run so many projects in parallel, and if you need them to move fast or scale up quickly, you need to understand their limits before you start.

The upside is real though. Small consultancies tend to have lower overhead, which means more of your budget goes into the actual work. The people you speak to in the sales conversation are usually the people doing the delivery. And they tend to be more honest about what they can and can't do, because their reputation depends on it directly.

• Ask about current client commitments so you understand availability honestly.
• Clarify what happens if a key person gets sick or leaves: small teams are more exposed to single points of failure.
• Check that their previous work includes projects close to your domain or technical stack, not just vaguely similar problems.
• Look for evidence of long-term client relationships, not just a stream of short engagements: it usually signals that the working experience was good.

The questions most people forget to ask

Most founders ask about process, tech stack and timeline. Fewer ask the questions that actually predict whether things go well:

• 'What's the most recent project that didn't go as planned, and what happened?' A good consultancy will answer this without deflecting.
• 'What do you think is missing or unclear in the brief I've given you?' This surfaces how carefully they've read it and whether they think in problems or features.
• 'If our budget ran out halfway through, what would you prioritise?' This tells you whether they understand what actually matters to your business.
• 'What do you need from us to do your best work?' Delivery quality depends on both sides. A consultancy that articulates this clearly is one that's thought about it.

Red flags that are easy to miss

• They talk a lot about their process but show you nothing they've shipped.
• Every answer comes back to the tech stack they prefer rather than your actual problem.
• They're reluctant to do a small paid scoping engagement before a full contract.
• The senior people disappear after the pitch and you start dealing with account managers.
• They've never worked with a business at your stage or scale before and can't articulate why that doesn't matter.
• Their contract is heavily weighted towards protecting them from scope changes rather than helping you manage them.

None of these alone is necessarily disqualifying. But a pattern of them, even if each item feels minor, usually signals a consultancy built around closing deals rather than delivering well.

A note on evaluating BedrockTeam specifically

If you're reading this and considering working with me through BedrockTeam, I'd expect you to apply exactly this framework. I can show you working software. I'll tell you clearly who does the work and what the limits of my capacity are at any given time. I'll push back when I think you're going in the wrong direction, and I'll ask more questions than you expect in the early stages. If that sounds like the working relationship you want, get in touch and we can figure out whether it's a good fit.