How to Choose a Bespoke Software Development Company

15 questions worth asking before you trust anyone with your business's software

Choosing someone to build bespoke software is slightly different from buying most business services.

If you choose the wrong printer, you can probably use another printer next month. If you choose the wrong company to develop software that will eventually sit at the heart of your business, getting it wrong can be considerably more painful.

You're potentially trusting them with your processes. Your customer data. Your integrations. Your intellectual property. And, increasingly, something your staff or customers depend on every single day.

So I'd take the decision fairly seriously. But perhaps not in the way you'd expect.

Because the first thing I'd look for isn't a particular programming language, an enormous development team, or an impressive collection of technology logos.

I'd look for someone who asks good questions.

1. They Should Want to Understand Your Business Before They Discuss the Software

This is probably my biggest one.

If you describe your idea and five minutes later somebody is telling you which framework they're going to use, I'd be slightly nervous.

Before we discuss technology, I want to understand: what are you trying to achieve? Who currently does it, and how? What takes too long? What goes wrong? What systems are already involved, and what information moves between them? What does success actually look like?

And, importantly:

Why do you think you need bespoke software?

Sometimes you don't. I've had conversations where the sensible recommendation is to use an existing product. That's not a failed software consultation — that's a successful one.

A developer's job shouldn't be to find an excuse to develop something. It should be to find the best way of solving the problem.

2. Be Slightly Suspicious If They Agree With Everything You Say

This might sound odd — you're paying someone to build what you want, surely they should listen to you?

Absolutely. But listening and agreeing aren't the same thing.

If I think something you're proposing is unnecessarily complicated, I'll tell you. If I think there's a cheaper way of achieving the same result, I'll tell you. If you're asking me to build something that already exists for £49 a month, I'll probably just show it to you. And if a feature nobody has ever tested is going to add £20,000 to the project, we're going to have a conversation about whether it belongs in Version 1.

A good development partner shouldn't simply translate your wishlist into code. They should challenge the wishlist. You're partly paying for experience — it would be rather pointless if nobody used it.

3. Ask Them to Explain the Solution Without Technical Jargon

Here's a simple test. Ask:

"Can you explain how you think this should work?"

You shouldn't need a computer science degree to understand the answer. Something like:

"When the customer submits the form, we'll check whether they already exist in your CRM. If they don't, we'll create them. We'll then send the information to the booking system and notify the appropriate member of staff."

Fine. If the answer immediately disappears into microservices, containers, event buses, serverless architecture and whichever JavaScript framework is fashionable this week, I'd ask them to try again.

Technical architecture matters enormously. But it should exist to support the business requirement — not to impress the customer. One of the marks of someone who understands technology properly is that they can usually explain it simply.

4. Don't Choose Purely on Price

This doesn't mean choose the most expensive. It means understand what you're actually comparing.

Imagine three quotes: £12,000, £28,000, and £65,000. Those might represent three completely different things. One could be a developer working directly with you. One could be a small specialist team. One could include project managers, designers, business analysts, QA engineers, DevOps specialists and account management.

None is automatically wrong. But unless you understand what's included, the headline number doesn't tell you very much.

Ask each company: what exactly will you deliver? What's excluded? What assumptions have you made? Who will actually work on the project? What happens when something changes? What happens after launch?

Only then can you meaningfully compare the numbers.

5. Find Out Who Will Actually Build Your Software

This is surprisingly important. You might spend the sales process speaking to someone with 25 years of technology experience. Who writes the code?

Sometimes it's the person you're speaking to. Sometimes it's an experienced internal team. Sometimes it's a junior developer. Sometimes the work is outsourced, or sent overseas. None of those models is automatically bad — but you should know.

Ask:

"Who will actually be developing my system, and will I be able to speak to them?"

Personally, I'm a fan of relatively short communication paths. If somebody running the business has a question about how a process should work, being able to talk directly to the person who understands the architecture can save an extraordinary amount of time.

6. Ask How They're Using AI

In 2026, this is now a perfectly legitimate question for any software development company.

"How do you use AI within your development process?"

I'd be surprised if the answer were "We don't." AI-assisted development can now accelerate significant parts of software engineering — code generation, testing, debugging, documentation, refactoring, research, prototyping, interface development. That allows experienced developers to deliver significantly more than traditional processes alone.

But there's another answer I'd be equally wary of: "AI builds everything for us."

It shouldn't. AI is an extraordinarily capable development tool. It is not a substitute for understanding architecture, security, databases, scalability, integrations or the actual business problem. Someone still needs to know whether the code is any good.

My preferred model:

Experienced people using AI, rather than AI replacing experienced people.

And if AI is letting your developer work significantly faster, it's perfectly reasonable to ask how that efficiency shows up in your project.

7. Make Sure You Know Who Owns the Software

Ask this before development begins — not afterwards.

Who owns the source code? The intellectual property? The database? The domain? Who controls the hosting account, the cloud infrastructure, and any third-party API accounts? Where does the source code actually live, and can you access it? If you wanted to move to another developer in two years, could they take over?

Ideally, none of these answers should be surprising. I generally believe customers commissioning genuinely bespoke business software should have clear rights to the software they're paying to create — subject, obviously, to any pre-existing libraries, licensed components, or separately agreed intellectual property.

Whatever the arrangement is, get it in writing.

8. Watch Out for Technical Hostage Situations

Related to ownership is something I particularly dislike: artificial dependency.

Your developer will naturally know the system better than anyone else — that's normal. But the system shouldn't be deliberately built so that nobody else could possibly work on it.

Look for standard technologies, reasonable documentation, accessible source code, documented deployment processes, appropriately controlled credentials, and proper backups.

If your developer disappears tomorrow, it might be inconvenient. It shouldn't destroy your business. This matters particularly when you're dealing with a single freelancer or a very small development company — and I say that as somebody running a small technology company myself. Business continuity matters.

9. Ask What Happens When Things Go Wrong

Because they will. Every developer creates bugs. Every platform occasionally has problems. Every third-party API eventually does something unexpected.

The question isn't "will anything ever go wrong?" — it will. Ask instead: how will you know? Is the application monitored? Are errors logged, and who receives the alerts? Are there backups, and how quickly can data be restored? What happens if a third-party service fails? What's the support arrangement, including outside normal working hours?

Good software isn't software that has never had a problem. It's software designed with the assumption that eventually, something will.

10. Security Should Come Up Before Launch, Not During the Final Week

If the application handles personal information, customer records, financial data, health information, passwords, payment details or confidential business information, security should influence the design from the very beginning.

Ask about authentication, encryption, permissions, data storage, backups, audit logs, dependency updates, vulnerability management, GDPR and data retention.

You don't necessarily need to understand every technical answer. But your developer certainly should. And if the answer to every security question is "Don't worry, it'll be secure," I'd worry.

11. Look at What They've Built — But Ask Better Questions About It

Everyone tells you to check a developer's portfolio. Fine. But don't just look at screenshots.

Ask: what problem did this solve? How many people use it? What other systems does it connect to? What was technically difficult? What changed once real users started using it? What would you build differently today?

And, most usefully:

"Is it still running?"

A beautiful demonstration application isn't the same as production software that's been operating every day for three years. Real-world software gets messy — customers do strange things, APIs change, browsers change, businesses change their minds. A developer who has maintained production systems tends to think differently from someone who has only ever built prototypes.

12. Find Out How They Handle Changes

Your requirements will change. I can say that with reasonable confidence without knowing anything about your project.

You'll see the first version and think of something better. Staff will use it and suggest improvements. Customers will behave differently from how everyone expected. Another system will change. The business will evolve. This isn't bad project management — it's software development.

So ask: is everything fixed rigidly at the start? Is there a change-control process? Are changes estimated separately? Can priorities move between phases?

I tend to prefer developing in clearly defined stages: build something useful, test it, learn from it, then decide what deserves to be built next. It reduces the amount of money spent implementing assumptions nobody's tested yet.

13. Ask What Version 1 Doesn't Need

One of my favourite questions to ask — and to be asked.

Instead of "what else could we add?", try:

"What can we leave out?"

Good developers should be able to identify features that aren't essential to proving or solving the core problem. Every feature costs something — not just to build, but to design, test, secure, maintain, explain, support, and potentially change later.

Software naturally trends towards complexity. Someone needs to push back in the other direction.

14. Ask What Happens After Launch

Launch isn't the end of a software project — it's arguably when you finally discover whether you built the right thing.

Ask about hosting, monitoring, maintenance, security updates, bug fixes, backups, support, enhancements, costs, response times, and what happens if you eventually decide to move elsewhere.

You don't necessarily need an expensive monthly support contract. The right arrangement depends entirely on how critical the application is. But you should know what the arrangement actually is before you sign anything.

15. Do They Understand Commercial Reality?

This might be the biggest distinction between a software developer and a genuine technology partner.

A technically brilliant solution can still be a terrible business decision. Suppose I can build an incredibly sophisticated system for £50,000 — wonderful. But if the problem costs your company £3,000 a year, we probably shouldn't build it. Equally, a £30,000 system capable of removing £100,000 of annual administration deserves serious consideration.

Technology decisions should connect to commercial outcomes. Ask: what will this save? What will it improve? What will it enable? What happens if we don't build it? How will we know whether it worked?

The answer shouldn't always be measured purely in pounds — customer experience, competitive advantage, capacity and risk matter too. But there should be a reason for doing it beyond "it would be quite cool." Although, admittedly, I have built things for that reason too.

The 15 Questions Worth Asking Before You Choose Anyone

If I were appointing a software development company tomorrow, these would be high on my list:

1. What do you think we're actually trying to solve?
2. Do you think bespoke software is definitely the right answer?
3. What would you build first?
4. What would you leave until later?
5. What existing software could we use rather than rebuilding?
6. Who will actually work on the project?
7. How do you use AI in development?
8. Who owns the finished source code and intellectual property?
9. Where will the application and data be hosted?
10. How will another developer take over if necessary?
11. How do you approach security and GDPR?
12. How are changes to scope handled?
13. What happens after launch?
14. What ongoing costs should we expect?
15. How will we know whether the project has been successful?

I'd pay as much attention to the questions they ask you as the answers they give you.

Finally, Choose Someone You Can Actually Work With

This sounds rather less technical because it is.

Software projects involve conversations — lots of them. There will be decisions, disagreements, changes, things that don't work, and things that turn out better than expected. Ideas that seemed brilliant on Tuesday and ridiculous by Friday.

You need someone you can talk to. Someone prepared to say "I don't think that's a good idea" — and explain why. Someone prepared to listen when you tell them they're wrong.

You're not simply buying code. You're entering into a working relationship with someone who may become responsible for an increasingly important part of your business. Technical competence matters enormously. But so do trust, communication, curiosity and judgement.

At GeekyBee, the first conversation I want to have isn't about programming languages. It's about your business.

Show me what you're doing now. Show me what's getting in the way. Show me what you'd like to be able to do.

Then we can work out what technology — if any — belongs in the middle.

Because choosing the right bespoke software developer shouldn't begin with finding someone who can write code. There are plenty of people who can write code.

Find someone who understands why the code needs to exist in the first place.

Interviewing developers for your next project? Get in touch with GeekyBee — bring your toughest question from the list above, and we'll answer it honestly.