How to choose a software development company when you can’t read the code
A framework for non-technical founders: the signals that actually predict whether your build ships, the criteria that look important and aren’t, and the four questions to ask before you sign anything.
You got on three sales calls this week. All three companies were warm, professional, and confident. All three said your project was very doable. All three sent a deck with a logo wall, a five-star Clutch rating, and a portfolio of apps that looked roughly like yours. By Friday you had three proposals on your desk, two of them within 15% of each other on price, and no real idea how to pick.
This is the hard part of choosing a software development company: the inputs you can see are the inputs every vendor has learned to polish, and the input that matters most, whether they will actually ship working software you don’t have to babysit, is invisible until you’ve already paid them. So the short answer is this. You choose a software development company on how it behaves before money changes hands, not on what it shows you. How it scopes the work, how it pushes back on your ideas, how it talks about cost and risk, and what it does when you ask a question it can’t answer cleanly. Those four behaviors predict delivery. The portfolio doesn’t.
We can say this because we are a software development company. What follows is the buyer’s guide written from inside the room, including the parts our own industry would rather not publish, because half of what passes for a sales process ends up on the red-flag list.
The trap every other guide walks you into
Search this question and you’ll get a dozen articles, almost all of them written by software companies, telling you to evaluate three things: portfolio, technical expertise, and price. That advice isn’t wrong so much as useless, because all three are easy to fake and none of them survives contact with your actual project.
A portfolio shows you the work a company is proudest of, screenshotted at its best moment, with no mention of which projects ran six months late or got rebuilt by the next vendor. “Technical expertise” is a list of logos: React, AWS, Python, Kubernetes. Every company on your shortlist has the same list, and you have no way to tell whether they use those tools well or just know how to spell them. And price, the one number you feel qualified to compare, is the most misleading input of all, for reasons we’ll get to.
The deeper problem is that this framework asks you to judge a company on artifacts. A non-technical founder cannot reliably judge a software artifact. You can’t read the code, you can’t tell a clean architecture from a fragile one, and you can’t tell whether that beautiful app in the portfolio is maintainable underneath or held together with tape. If your selection method requires you to evaluate things you can’t see, you don’t have a method. You have a coin flip with extra steps.
So stop trying to grade the software. Grade the behavior. Behavior is something a non-technical founder can read perfectly well, because it shows up in plain language, in meetings, in how questions get answered. And behavior before the contract is the single best available predictor of behavior after it.
What actually predicts whether your build ships
Four behaviors, observable in the first two conversations, tell you more than any portfolio.
How they scope your project. Hand the same loose idea to two companies. One comes back with a quote. The other comes back with questions: who’s the user, what happens on the unhappy path, what does this connect to, what’s the one feature that has to work on day one. The second company is more annoying to deal with in week one and far cheaper to work with by month six. Vague requirements are where software projects go to die, and the work of defining scope before you hire anyone is exactly what a good company insists on. A studio that takes your half-formed brief and immediately prices it is telling you it will build whatever you say and bill you for the rework. The way a studio scopes is a preview of how it will run the project. A good one treats scoping as the most important work, not a formality before the real work.
How they push back. Watch what happens when you propose something that’s a bad idea. Every founder proposes a few. You ask for a feature that doubles the timeline and serves nobody, or you describe an architecture you read about on a podcast. A vendor optimizing for the sale nods and adds it to the quote. A partner tells you it’s a bad idea and explains why, even though disagreeing with you is the higher-risk sales move. The willingness to lose a little goodwill to save you money is the most underrated signal on this list. A company that won’t say no to you before you’ve paid will never say no to you after, and a project where nobody says no is a project that balloons. This is the difference between a tech partner and a black box: a partner argues with you.
How they talk about cost and uncertainty. Ask how long it will take and how much it will cost. The honest answer involves a range, a few assumptions, and an admission that the number will move as you learn things. The answer designed to win the deal is a single confident figure with no caveats. Software estimation is genuinely hard, and a company that pretends it’s easy is either inexperienced or lying to close you. Steve McConnell, the author of Code Complete, has spent a career on a single point: early estimates carry enormous uncertainty. A studio that respects that uncertainty out loud will manage your budget honestly. One that buries it will discover it later, on your invoice.
What they do when they don’t know. Ask a question slightly outside their comfort zone. Watch whether they say “I don’t know, let me check” or whether they generate a confident answer on the spot. The phrase “I’m not sure, I’ll find out” is one of the most reassuring things a vendor can say, because it tells you they distinguish between what they know and what they’re guessing, and that distinction is the whole job. The people you’re hiring will spend years making decisions you can’t verify. You’re not betting on whether they have all the answers. You’re betting on whether they’ll be honest about which answers they don’t have.
The criteria that look important and aren’t
Some of the inputs you’ve been told to weigh heavily deserve almost no weight.
The logo wall. Big-name clients mean a company can land big-name clients. It tells you nothing about whether your project, which is smaller and less prestigious, will get their senior people or their bench. Sometimes the famous logo is actively a warning: you’ll be the account that gets the junior team while the A-players service the brand-name account.
Awards and directory badges. A top rating on a vendor directory is a function of how many happy clients a company asked to leave reviews, plus, in some cases, how much it spends with the directory. It’s a marketing output, not a quality measure. Treat it the way you’d treat a “Best of” sticker on a restaurant window: weakly positive, easily gamed, not a reason to choose.
Team size. A 200-person company is not safer than a 12-person studio. Larger shops give you process and continuity and, often, more layers between you and the people actually writing your code. Smaller ones give you direct access and senior attention and, often, more key-person risk. Neither is the right answer. The right size depends on your project, and a company that tells you bigger is always safer is selling you its own headcount.
The tech-stack pitch. If a company leads with how modern and novel its stack is, be wary. The boring, proven tools are usually the right call for an early product, and a studio reaching for the newest framework is sometimes solving for its engineers’ resumes rather than your maintainability. You want a company that picks technology based on your problem, not on what’s trending. We’ve written before about the gap between emerging tech as a tool and emerging tech as a religion; the same test applies when you’re picking who builds.
The 80/20 of choosing a software development company
There’s a version of the Pareto principle that fits this decision well: a small share of the signals carry most of the predictive weight. If you only had time to assess two things, assess these.
First, how they handle the gap between what you asked for and what you actually need. The best companies spend the first conversation narrowing your project, not expanding it. They find the version of your idea that’s half the cost and tests the same risk. A vendor that only ever adds scope is optimizing for its invoice. A partner that subtracts scope is optimizing for your outcome, and that orientation, once you see it, is hard to fake.
Second, how a real customer of theirs answers one specific question. Don’t ask their references whether they were happy. Everyone says yes. Ask: “What went wrong, and how did they handle it?” Every real project has a bad week. The reference who can describe a problem and a recovery is describing a company that tells the truth under pressure. The reference who insists nothing ever went wrong either never shipped anything hard or isn’t being candid. That single question does more work than the rest of the call combined.
The four questions to ask in the first call
Bring these to the first conversation. The answers, and the comfort with which they’re given, will separate your shortlist fast.
“Walk me through a project that went sideways and what you did about it.” You’re testing for honesty and for whether they’ve shipped anything hard enough to go sideways.
“If you had to cut my scope in half to hit the budget, what would you cut and why?” You’re testing whether they understand your product well enough to have an opinion about its core, and whether they’ll think in trade-offs instead of just selling you everything.
“Who specifically will work on this, and what happens if that person leaves?” You’re testing for key-person risk and whether you’re getting the team in the pitch or a different, cheaper one after you sign. Sole-developer dependency is a real cost, and a serious company has an answer for it.
“How will I know if the project is off track before it’s too late to fix?” You’re testing whether they’ll make the work visible to a non-technical owner, or whether you’ll be blind until a deadline slips. The answer should involve something you can actually see every week, not a status color in a tool you don’t check.
A company that answers these four cleanly, without bristling, has probably had these conversations before and survived them. That’s most of what you’re looking for.
Cheaper is a signal, not a saving
The quote that comes in 40% below the others is not a discount. It’s information. Either that company scoped your project more shallowly than the others, and the gap will reappear as change orders once you’re locked in, or it’s planning to staff your build with cheaper, less experienced people, or it doesn’t yet understand the work well enough to price it. Occasionally a low quote reflects genuine efficiency. More often it reflects a misunderstanding you’ll pay to correct.
The expensive quote isn’t automatically right either. But when prices diverge sharply, the right reaction is not to take the cheap one. It’s to ask each company to explain its number, because the explanation tells you who actually understood the project. Price is most useful as a question, least useful as an answer. We’ve laid out the deeper version of this in our piece on how outsourced projects get priced and where the surprises hide.
How to verify what you can’t read yourself
You still can’t read the code. So build verification into the engagement instead of trying to do it in the sales process.
Start with a small, paid, scoped piece of real work before you commit to the whole build. A discovery sprint, a first feature, a working slice of the actual product. One month of real collaboration teaches you more about a company than ten hours of calls, and it’s cheap insurance against a six-month mistake. How they behave inside that small engagement, whether they communicate, whether they hit what they said they’d hit, whether the working software matches the demo, is the closest thing to a guarantee you’ll get.
Then, before you scale up or at any major milestone, you can have someone independent look at what’s been built. You don’t have to read code to commission a code audit and get a plain-language read on whether the foundation is sound. A confident company welcomes that second opinion. A nervous one resists it, and the resistance is its own answer.
Choosing a software development company will never be a sure thing, because you’re buying something you can’t fully inspect from someone you’ve just met. But you can stop trying to grade the software and start grading the people, in the open, before you’ve spent a dollar. The company that scopes carefully, argues with you, prices honestly, and admits what it doesn’t know is the one that ships. Everything else is a logo wall.
Frequently asked questions
How do you choose the right software development company if you’re not technical?
Judge behavior, not artifacts. You can’t evaluate code, architecture, or a polished portfolio, but you can evaluate how a company scopes your project, whether it pushes back on bad ideas, how honestly it talks about cost and uncertainty, and what it does when it doesn’t know an answer. Those behaviors are visible in plain conversation and predict delivery better than any technical credential. Then de-risk further by starting with a small paid engagement before committing to the full build.
What is the 80/20 rule when choosing a software company?
A small set of signals carries most of the predictive weight. The two that matter most: whether the company narrows your scope (optimizing for your outcome) or only ever expands it (optimizing for its invoice), and how a real reference answers “what went wrong and how did they handle it.” Those two questions tell you more than portfolios, awards, and price combined.
What questions should I ask a software development company before hiring?
Four: walk me through a project that went sideways and what you did; if you had to cut my scope in half, what would you cut and why; who specifically will work on this and what happens if they leave; and how will I know the project is off track before it’s too late. You’re testing for honesty, for understanding of your product’s core, for key-person risk, and for whether the work will be visible to you.
Does a cheaper quote mean lower quality?
Not always, but a quote far below the others is information, not a saving. It usually means shallower scoping, cheaper staffing, or a misunderstanding of the work, and the gap tends to reappear later as change orders. When prices diverge sharply, ask each company to explain its number. The explanation reveals who actually understood the project.
How many software development companies should I talk to?
Enough to triangulate, usually three to five. One gives you no baseline. A dozen wastes everyone’s time and tends to converge on price comparison, which is the least useful axis. Three to five lets you compare how differently each one scopes the same brief, which is the comparison that matters.
Should I choose a big agency or a small studio?
Neither is safer by default. Larger shops offer process and continuity but more distance from the people writing your code; smaller studios offer senior attention and direct access but more key-person risk. The right size depends on your project’s complexity and how much hand-holding you need. Be skeptical of any company that tells you its own size is automatically the safe choice.