How to choose a software development partner when you can't read the code

Two applications can look identical in a demo and be completely different underneath. Same screens, same buttons, same click-through. One will still be running in three years and cost a sensible amount to change. The other falls over the first time four hundred people use it at once, and by then the person who wrote it has stopped answering emails.

That's the real problem with commissioning software when you're not technical. Not the cost, although a product can genuinely be £500 or £500,000 and look much the same on day one. It's that you're being asked to judge something you can't inspect. 

It’s a bit like buying a car without knowing how an engine works. Most of us do that perfectly happily, because there are other ways to judge what we’re buying: reviews, service history, warranties, inspections. With custom software, those signals are much harder to see.

The good news is you don't need to read code to make a good decision. A lot of the signals you need are behavioural, and you can spot them before anyone starts developing anything: how a partner reacts to your idea, who they put in the room, what they try to talk you out of. Six years and sixty-odd builds later, here are the five I'd watch for.

1. Be wary of anyone who says yes too quickly

When you pitch your idea, you want to hear yes. Someone nods along, says they can build exactly what you've described, and you leave feeling rather good about it. That's the moment to worry, because a fast yes almost always means they haven't understood the problem yet.

Lucy Woodhead runs operations at US Jetting. She hired us to build their eCommerce site, in our conversation about tech development she said:

"It feels quite complicated what I'm asking. When you answer so quickly, “we can do it”, I worry you're not understanding what I'm saying."

Lucy isn't technical. She knew her own business inside out, and from the speed of the answer alone she could tell nobody was listening. You don't need to be technical to spot that.

The hardest part of any build is turning a business idea into structured logic, and founders rarely manage it alone. That's the reason you're hiring someone. But if your partner doesn't do that work with you before they start, you'll find the gaps four months in, when fixing them costs most. Nick Sales, a fractional CTO who has led engineering teams since the late eighties, describes builds that start from back-of-envelope conversations as a very efficient way of getting rid of all your excess money. Look for the partner who spends your first sessions asking tough questions rather than comfortable ones.

2. Don't choose on technical credentials alone

When you're out of your depth, the instinct is to hand the decision to the most technical person you know. But technical quality is only one part of it, and someone also needs to judge whether the product makes sense for the people who'll end up using it.

Kath Hipwell, CEO of the Association of British Climbing Walls, ran a proper selection process when ABC commissioned a new incident reporting system for its 250 member walls. Her advice is to get both kinds of thinking into the pitch review team, and to "look widely and interview deeply". What she brought to the project herself is the best argument for it. Kath isn't technical, and her contribution was the interactive human form: the visual body diagram a wall manager clicks to record where somebody got hurt, instead of typing "left ankle twisted" into a text box the way the old system required.

"My main thing I brought to the whole process was making the human form sort of bang on for what was needed and interactive."

For a safety system, whether people fill it in properly is more or less the whole point. So it's worth checking that somebody in the process is thinking about that, and not only about the technical architecture.

3. Make sure you can talk to the people building it

The biggest single failure point in a custom build is the gap between what's in your head and what ends up in the code. Some agencies insulate their developers behind account managers, project managers and business analysts. It looks reassuring on an org chart and it's an expensive game of Chinese whispers: by the time your requirement reaches the person writing the code it has been through four translations, losing something each time.

There's a quality problem underneath the efficiency one. Ben Burch, who founded Allegr, puts it plainly:

"If you don't really know why you're writing it, you are going to make assumptions. Minor they may be, but you're going to make assumptions and you're going to create a less good product at the end of the day, because fundamentally you don't know what it's going to do when it gets out into the wild."

Cut a developer off from the commercial reason a feature exists and they'll still build it, but they'll fill the gaps with guesses and won't flag them, because they don't know they're guessing. So ask directly in the pitch: will I be speaking to the people writing this? 

4. Find someone willing to shrink your idea

Founders tend to arrive with a grand vision. One platform, every problem solved. It's a lovely instinct and it's how budgets balloon. A good partner takes the vision seriously and then helps you cut it down to the smallest thing worth proving, which is uncomfortable and is probably the most valuable thing they'll do for you.

Craig Brown, who founded the product marketing consultancy Troubadour, watches founders try to launch as the mature version of the company they intend to become:

"A lot of companies want to get to the version of how Stripe positions itself today, but that isn't how Stripe started."

Stripe began by making online payments easier for engineers at e-commerce companies. Craig's test for a starting point is whether you're solving "a problem that people feel today and this week and next week", which is a better question than whether the idea is exciting.

Nick Sales calls the worst mistake founders make "build it and they will come". The ideas that trigger it remind him of the Innovations catalogue, the little A5 booklet that used to flop out of magazines in the eighties and early nineties, full of what he describes as "all kinds of weird slamming together of technologies that really weren't meant to ever meet in daylight":

"There were things like slippers with torches for elderly people."

Somebody, somewhere, looked at that and thought it was a great idea. You want a partner asking early: is this a real problem somebody feels, or is it a light bulb on a slipper? A partner who accepts your feature list without argument isn't being agreeable, they're being expensive. 

5. Work out what the price difference is actually buying

Quotes for the same brief can differ by a factor of ten, and on day one the screens will look much the same. What's interesting is that the reasons behind that gap have shifted quite a bit in the last couple of years.

The old answer was breadth. A production system needs front-end, architecture, database design, UX, QA, infrastructure and security, and the argument went that one person would be genuinely strong at two or three of those and improvising the rest. That's much less true than it was. A good individual developer with AI tooling now covers ground that would have taken three or four people in 2020, and covers it fast. Dave down the road has had a serious upgrade, and anybody still selling purely on headcount is selling something you can increasingly get elsewhere.

What AI hasn't handed anyone is more judgement. It will write you an authentication flow in four minutes. It won't tell you that the flow is wrong for the way your business actually works, because it has no idea how your business actually works. That gap gets filled by experience rather than tooling, and it's the thing you're really paying for. A very good freelancer has it. A junior-heavy agency might not. So the real question still isn't agency versus individual, it's whether the people involved have enough experience to know when the output is wrong, and whether anybody is looking at it with fresh eyes. One person reviewing their own work, AI-assisted or not, has nobody checking their assumptions. A team has that built in. If you're hiring an individual, buy it separately: a fractional CTO for a few hours a month costs a great deal less than finding out later.

Nick Sales' case for a team still holds on the commercial side:

"Maybe a development agency is the best way of doing this because the costs will be explicit. They can ramp up, can ramp down. They'll get the skills you don't know you need, because we don't know we need them yet... As opposed to Dave down the road, who works in his garage."

The other thing a team buys is speed. Design, front-end, back-end and testing moving at once compresses a timeline in a way one very fast person can't, however good their tooling. Plus continuity, which nobody thinks about until it matters: individuals get ill, get busy, and occasionally stop replying.

Then there's geography. Day rates vary enormously between countries, and a lower rate isn't by itself a warning sign. Our own team is in the Philippines, so I would say that. But the point holds whoever you're talking to: where people sit matters far less than whether you can speak to them directly, how many hours a day your working times overlap, and who picks up the phone when something breaks. 

6. Ask how they use AI, not whether they use it

Everybody uses it now. Don’t ask if they are using it but ask how they are making sure they aren’t producing sloppy code.

Veracode has spent three years testing AI-generated code across a hundred-odd models, and the share that does what was asked has risen from around 50% in 2023 to about 95%. That is an enormous improvement in three years and it's why everybody's timelines have shortened. But over the same period, the share that passes their security tests has stayed close to 55%. The tools have gotten dramatically better at producing code that works, and not much better at producing code that's safe. The Cloud Security Alliance found the other half of the problem: around 80% of developers believe AI writes more secure code than they do.

There's a second limitation worth understanding, which is that these tools are very good at the task in front of them and largely blind to the system around it. Jason Margolin puts it well:

"The value adds where you have someone technical is that they can understand the overall architecture, how all the systems are running, how they're all speaking to each other. The AI can't see any of that... you tell it to do something and it will just try to do it to the best of its ability but it doesn't understand the business and how it operates."

Ask it to add a feature and it will add the feature. Whether that feature is now duplicating something you already had, or quietly breaking an assumption three parts of the system away, is not a question it is in a position to answer.

None of which is an argument against using these tools. We use them heavily, and the productivity difference is real. It's an argument for asking what the process around them is. Is there a written policy on what AI can and can't be used for. Who reviews AI-generated code before it merges, and is that person different from whoever prompted it. What's the rule about client data and credentials going into these tools. Who's responsible for the security of what goes live in a product?

‍

If you get vague answers to any of that, it usually means there isn't a process. 

What if I've already built something?

Quite a few people now arrive having built a working prototype in Lovable, Replit, Cursor etc, with a slightly nervous sense that they are almost all the way there.

Helpfully a working prototype is the best brief you can hand a development team, better than any specification document, because everyone can click on it and play with something real. It's also a cheap way to find out whether anybody wants the thing, which is why we encourage founders to build one.

The distinction that matters is between a prototype and production software. Jason Margolin, a fractional CTO who spent time at Meta and BP, draws it clearly:

"It's really great for prototypes. But in my mind, it is just that. It is a prototype. It's throw away. And if you are building a serious tech product, you should be investing in hiring someone who... at least can get the building blocks in correctly."

His analogy for what to do next is the one I'd give anybody:

"I wouldn't draft up a contract and send it to someone as a legal document without having shown a lawyer first."

You don't need to read the code

I've spent the last six years building software with people who, in a lot of cases, couldn't read a line of the code we were writing for them, and they shouldn't have to. Their job is to understand their customers better than anyone else in the room, and mine is to make sure my team understands clearly what's needed, and clearly explain any technical decisions to my clients so they are making informed decisions.

The important thing isn't learning to assess the code. It's knowing what to look for in the people who can.

If you've got an idea you're circling, or a prototype you're not sure about, we're happy to have a look and tell you what we think.

Explore our services, or book a call with Old.St Labs to talk through your idea.