How do I know if a software development team is genuinely technical or just a sales-led agency?

Ask to speak with the person who will actually write the code, not just the account manager or project lead. A technically credible team will be able to discuss your specific problem in concrete terms, propose options with real trade-offs, and explain why they would choose one approach over another for your situation. If every answer sounds like it came from a brochure, the technical depth may not be there.

Should I choose a larger team or a smaller, specialist team for a custom internal tool?

For most UK SMEs and scale-ups building internal tools or bespoke operational software, a smaller specialist team typically delivers better results than a large generalist agency. Smaller teams have lower overhead, more direct communication with the people doing the work, and a stronger incentive to get the problem right rather than bill hours. The risk with smaller teams is capacity, so ask directly about their current workload and how they manage concurrent projects.

What should I look for in a software team's portfolio?

Look for projects that share characteristics with yours: similar business context, similar user types, and similar integration complexity. Logos and headline results are less useful than detailed case studies that describe the problem, the constraints, what went wrong, and how it was resolved. If a team cannot provide this level of detail for at least a couple of projects, that is a signal worth probing.

How important is it that the development team is based in the UK?

Location matters less than communication quality and time-zone overlap, but UK-based teams do offer some practical advantages: easier in-person discovery sessions, familiarity with UK GDPR and sector-specific regulation, and simpler commercial arrangements (VAT, contracts under English law). If you are considering an offshore or nearshore team, factor in the cost of managing the additional communication overhead, which is often underestimated.

What is a reasonable timeline to expect for a custom internal tool?

Timelines depend heavily on scope, and any team that gives you a confident deadline without a scoping phase first should be treated with scepticism. That said, a well-scoped internal tool of moderate complexity (replacing a manual spreadsheet-based process, for example) can typically reach a usable first version in a matter of weeks rather than months, if scope is kept tight and feedback is rapid. Be cautious of projects that do not have a testable milestone early in the timeline.

What to Look for When Choosing a Custom Software Development Team

When choosing a custom software development team, the criteria that actually predict a good outcome are: proven delivery on similar problems, a clear process for scoping and managing scope creep, honest communication about what they will not build, and evidence that the code they write can be maintained by someone else after the engagement ends. Most UK businesses that have been burned by a previous team trace the failure back to one of these four areas, not to technical skill alone.

Why Choosing the Right Team Is Harder Than It Looks

Every development team looks credible on a discovery call. They have a polished deck, a portfolio of logos, and reassuring language about agile processes. The problem is that most of these signals tell you very little about whether the team will ship something useful, on a realistic budget, that your internal people can actually use and maintain. The UK market for custom software is large enough that bad actors and genuinely good teams can look identical until you are three months into a contract.

The checklist below is built around the failure modes we see most often, not around what teams want to show you during the sales process.

The Core Selection Criteria

1. Scoping Rigour Before Any Code Is Written

A good team will want to understand your problem deeply before they quote. If a team sends a fixed-price proposal within 24 hours of a first conversation, treat that as a warning sign rather than efficiency. Proper scoping takes time and involves uncomfortable questions: What does your current process actually look like step by step? What are the edge cases? Who are the real end users and how technically confident are they? A team that skips this phase will compensate later with change requests or by shipping something that solves the wrong problem.

Tip

Ask any prospective team: 'Walk me through what happens when requirements change mid-build.' A vague answer about 'agile flexibility' is not the same as a concrete process for logging, pricing, and agreeing scope changes.

2. Relevant Delivery Experience, Not Just Relevant Technology

Many teams will tell you they have built CRMs, internal tools, or workflow automation. What matters more is whether they have solved a problem with a similar business context to yours. An ops-heavy SME replacing spreadsheets has very different constraints to a scale-up needing an internal tool that integrates with five existing systems. Ask to see a case study that is close to your situation, and ask specifically what went wrong and how they handled it. Teams that can only talk about successes have not done enough work, or are not being honest with you.

3. Ownership and Handover From Day One

One of the most common sources of long-term pain in UK software engagements is dependency. A team builds your tool, and then you cannot touch it without going back to them. Ask directly: Who owns the code repository? Is it in your organisation's version control account or theirs? What documentation will be produced, and for whom? If your internal team (or a future team) needs to pick this up in 18 months, what will they find? A team confident in the quality of their work will welcome these questions.

4. Communication Cadence and Honesty About Blockers

Bad news delivered early is manageable. Bad news delivered at the deadline is a crisis. Find out how the team communicates when something is not going to plan. Do they have a regular rhythm of updates (weekly demos, async video updates, shared project boards)? More importantly, can they give you an example of a project where they had to tell a client something they did not want to hear, and what happened next? Teams that only surface problems when they are already critical are a liability regardless of their technical skill.

5. Honest Advice on Build vs Buy

A trustworthy custom software team will sometimes tell you that you do not need custom software. If a team never suggests that an off-the-shelf tool, a configured SaaS product, or a simple automation might solve your problem adequately, ask yourself why. Teams with integrity will be direct about when the economics of custom build do not make sense. This honesty costs them work in the short term but is a reliable signal of a team that prioritises your outcome over their billing.

6. Technical Choices That Reduce Risk, Not Maximise Interest

Be cautious of teams that default to the newest or most complex technology for every problem. The right technical choices depend on your constraints: the skills of anyone who will maintain the tool, the scale of the problem, and how likely requirements are to change. A tool built in a niche framework that only the original team understands is a liability. Ask what stack they are proposing and why, specifically for your situation. A good answer will reference your context, not a generic preference.

Selection Criteria at a Glance

Criterion	What Good Looks Like	Warning Sign
Scoping process	Structured discovery before any quote	Fixed-price proposal within 24 hours
Delivery experience	Case studies close to your business context, including what went wrong	Only polished success stories
Code ownership	Code in your repo, documented for future maintainers	Vague answers or team-owned repositories
Communication	Regular demos, shared tracking, proactive bad news	Updates only when chased
Build vs buy honesty	Willing to recommend not building custom	Never questions whether custom is the right answer
Technology choices	Stack chosen for your constraints and maintainability	Latest framework regardless of context

Questions to Ask During the Evaluation Process

Can you walk me through a project that was similar to ours, including what did not go to plan and how you handled it?
What does your scoping process look like before you write a line of code?
Who will own the code repository and what documentation will you produce for a future maintainer?
How do you handle scope changes, and can you show me an example of how that was communicated to a client?
What would make you advise us not to build this as custom software?
Why are you recommending this particular technology stack for our situation specifically?
Who on your team will actually be doing the work day to day, and can I speak with them before we sign?
What does a handover look like at the end of the engagement?

A Note on UK-Specific Context

UK businesses face some specific considerations that are worth raising explicitly. If your tool will process personal data, UK GDPR compliance needs to be a first-class consideration in the build, not an afterthought. Ask how the team handles data residency (particularly relevant if you are in financial services or healthcare) and whether they have experience with the ICO's guidance on privacy by design. Separately, if you are using a contractor-model team rather than an agency, check whether IR35 status has been correctly assessed for each individual involved, as this can create unexpected tax liability for your business.

Warning

If your business operates in a regulated sector (financial services, healthcare, legal), ask prospective teams specifically about their experience with compliance requirements in your industry. A generic answer about 'following best practices' is not sufficient.

What a Good Engagement Looks Like in Practice

The best custom software engagements tend to follow a similar pattern: a structured scoping phase produces a clear picture of the problem before any commitment to a full build; the first milestone is something small and testable that real users can interact with; feedback from that test informs the next phase rather than being ignored; and by the end of the engagement, your internal team understands what has been built and why, even if they did not write it. If a team cannot describe their process in these terms, ask them to try.

At Bedrock Team, we work exactly this way. We do structured discovery before we quote, we ship working software in stages so you can validate early, and we build with the assumption that someone else will need to read and maintain the code after us. If you are currently evaluating teams and want a direct conversation about whether your problem is a good fit for custom build, get in touch and we will give you an honest answer.