How to Vet a Custom Software Developer in 2026

A bad custom software engagement rarely fails loudly at the start. It fails quietly, six months in, when the demos stop matching reality and you realize you cannot get the code out. The way you avoid that is not a better contract. It is better vetting before you sign.

This guide is for the operator who is about to spend real money on a custom build and wants to know, concretely, how to separate a serious partner from a risky one. You will get the signals that actually matter, the questions that surface the truth, the red flags worth walking away over, the ownership terms to nail down before work starts, and a way to test a firm cheaply before you commit to the whole project. The AI-era complications are real, and this guide treats them honestly rather than pretending nothing changed.

Why Vetting Is Harder in 2026

The fundamentals of choosing a software development company have not changed. You still want competence, judgment, and integrity. What has changed is that the surface signals people used to rely on are now cheap to fake.

AI-Generated Portfolios and Case Studies

A convincing portfolio page, a polished case study with invented metrics, a fluent proposal that mirrors your exact language back at you: all of these can be produced in minutes now. That does not make every polished firm a fraud. It means polish is no longer evidence. A beautiful website and a tight pitch deck used to suggest a firm had its act together. In 2026 they suggest a firm has access to the same tools everyone else has. You have to look at things that are expensive to fake, not things that are cheap to generate.

The Low-Code and Resale Shop Problem

A growing number of firms marketing themselves as custom software developers are assembling low-code platforms, white-labeling someone else's SaaS, or wiring together no-code tools and calling it custom. Sometimes that is genuinely the right answer for your problem, and an honest firm will tell you so. The risk is the shop that sells you a low-code build at custom-software prices, hands you a system you cannot modify or export, and locks you into a platform you did not choose. You are not necessarily against low-code. You are against paying for ownership you do not actually receive.

AI in the Build Itself

Most competent developers now use AI coding assistants, and that is fine. The concern is not that a firm uses AI. The concern is whether anyone on the team understands the code well enough to maintain it, debug it under pressure, and explain why it was built the way it was. AI can produce a working prototype fast. It cannot, on its own, own the architecture of a system that has to run your business for the next five years. Your vetting needs to confirm there is real engineering judgment behind the output, not just generated code nobody fully understands.

What to Actually Evaluate

Forget the marketing layer for a moment. When you choose a software development company, four things determine whether the engagement succeeds, and none of them are visible on a homepage.

• Production systems that still run: Anyone can show you screenshots. The real signal is software they built that is live, in daily use, and that someone other than them depends on. Ask to see it working and ask who relies on it.
• References you can actually reach: Not a logo wall. A name and a phone number of someone who paid this firm to build something and will talk candidly about how it went, including what was hard.
• How they reason about your problem: The quality of the questions they ask you is the single best predictor of the quality of what they will build. A firm that starts scoping before it understands your operation is guessing.
• Communication under ambiguity: Most of a custom build is navigating things nobody specified clearly at the start. You are hiring a firm to think with you, not just type for you. Watch how they handle a vague or contradictory requirement.

These are the same fundamentals whether you are weighing whether to build internal tools versus buying SaaS or commissioning a full operational platform. The decision about what to build comes first, but once you have decided to build, who builds it is the decision that carries the most risk.

The Questions to Ask

Vetting happens in conversation, and the right questions do most of the work. These are the ones that consistently separate serious firms from the rest.

"Walk me through a system you built and the hardest decision you had to make."

You are not testing whether they can describe a project. You are testing whether they own the engineering decisions. A real builder will light up here, explain a genuine tradeoff, and tell you what they would do differently now. A reseller or a thin shop will stay at the level of features and screenshots because there was no hard decision, only configuration.

"What would you tell me not to build?"

The most valuable thing a custom software partner does is talk you out of the wrong work. A firm that says yes to everything is optimizing for your signature, not your outcome. The ability to say "you do not need custom software for that, here is the cheaper path" is a strong signal of integrity, even though it costs them revenue in the moment.

"How do you handle a requirement you think is a mistake?"

You want a partner who will push back, explain why, and then either change your mind or build it your way once you have both understood the tradeoff. The wrong answer is "we just build whatever the client asks." That is not deference. That is a firm that will let you walk into a wall it could see coming.

"Who, specifically, will write the code, and will they still be here in a year?"

Plenty of firms sell with their best people and deliver with their least experienced. Ask who is actually assigned, ask about turnover, and ask what happens to your project if that person leaves. The answer tells you whether you are buying a relationship or a sales motion.

"Show me how a past client got their code and kept running it after the engagement ended."

This question previews the ending at the beginning. A confident firm has a clean story here because handoff is part of how they work. A firm that gets evasive is telling you the relationship is designed to be hard to leave.

Red Flags Worth Walking Away Over

Some signals are strong enough that a single one justifies slowing down, and a cluster of them justifies walking away entirely.

• A fixed price before any real scoping: A firm that quotes a number before understanding your operation is either guessing or planning to make the money back on change orders. Real estimates follow real discovery.
• Evasiveness about code ownership: If you ask "do I own the code" and get anything other than a clear yes in writing, treat the rest of the conversation with suspicion.
• No source-control access: If you will not get direct access to the repository where your software lives, you do not own your software. You are renting it from people who can hold it hostage.
• A portfolio with no live systems behind it: Polished case studies and zero reachable references is the signature pattern of a firm whose best work is its marketing.
• No questions about your existing process: A firm that is ready to start building without understanding how you operate today is going to build something that does not fit how you operate.
• Pressure to sign fast: Urgency is a sales tactic, not an engineering necessity. A serious firm wants you to understand what you are buying, because misaligned expectations hurt them too.
• Cannot explain their own architecture in plain language: If they cannot describe how a past system works without retreating into jargon, either they do not understand it or they are hiding that someone else built it.

None of these are about a firm being small or new. A two-person shop founded recently can be an excellent partner. These flags are about whether a firm is optimizing for the signed contract or for the working system. Those are different businesses wearing the same logo.

Code and IP Ownership, and the Handoff

This is the part most buyers underweight, and it is the part that determines whether you are free or trapped at the end. Get it right in writing before any work begins.

Ownership

Your contract should assign all custom code, designs, and documentation produced for you to your company. The phrase to look for is a clear work-product assignment, not a license. A license means they own it and let you use it. Assignment means it is yours. Watch for retained-IP clauses that quietly carve out "reusable components" or "frameworks" in a way that leaves the part you actually need under their control.

Repository Access From Day One

You should have access to the source-control repository, in your own organization's account where possible, from the first commit. Not at the end. Not on request. From the start. This single arrangement prevents the most common hostage scenario in custom software, where everything is fine until the relationship sours and suddenly the code you paid for is somewhere you cannot reach.

The Handoff Standard

A real handoff is not a zip file emailed on the last day. It is the repository, the deployment configuration, the credentials and environment details, and documentation good enough for a different developer to pick up the system and keep it running. The test question is simple: if this firm disappeared tomorrow, could another competent developer take over without reverse-engineering everything from scratch? If the answer is no, you do not own a system. You own a dependency.

These ownership terms matter just as much when you hire a software developer in Louisiana as they do with a nearshore or offshore team, and they are part of how an honest firm prices and scopes work. They also shape the true cost of custom business software, because a clean handoff is cheaper over five years than a cheap build you can never leave.

Run a Paid Discovery as a Test

The single best vetting tool is not a question. It is a small, paid engagement before the full build. A discovery, sometimes called a scoping or design sprint, is typically a few weeks of work that produces a defined scope, an architecture outline, a realistic estimate, and a recommendation on what to build and what to skip.

It works as a test for a specific reason: you are evaluating the firm and getting a real deliverable at the same time. You see how they run a project at small scale before you bet the full budget on them. You see whether they communicate clearly, whether they push back when they should, whether they hit a short deadline, and whether the document they produce reflects your operation or a generic template.

What works: A paid discovery aligns incentives honestly. The firm is paid for real thinking, so you get their real thinking. You leave with a scope you own regardless of whether you continue, which means you can take it to another firm if this one underwhelms. For a fraction of the project cost, you de-risk the largest decision.

What breaks down: A discovery is only as good as the firm running it. A weak shop will use it to produce a vague document that mostly justifies a large estimate. Watch for that. The discovery should make your decision clearer and your scope tighter, not just bigger. And a discovery cannot fix a relationship that is wrong on fundamentals. If the ownership terms are bad, no amount of good discovery work makes the engagement safe.

This is how we prefer to start, and it is visible in how systems like SubVerify, our subcontractor compliance platform, were scoped before they were built. You can see the broader approach across our custom business software work and the related guide on building custom software for trades and construction firms, where discovery-first scoping prevents exactly the kind of expensive surprises this article is about.

The Vetting Checklist

If you are about to choose a software development company, work through this before you sign anything.

• Get at least two references you can actually call, and call them. Ask what was hard, not just whether they were happy.
• See a live system the firm built that is in daily production use, and confirm someone other than the firm depends on it.
• Ask them to walk you through a real architectural decision in plain language. Confirm they own it.
• Describe a deliberately vague requirement and watch whether they ask good questions or just agree.
• Get code ownership in writing as an assignment, not a license, before work starts.
• Confirm direct source-control access from day one, ideally in your own organization's account.
• Define the handoff standard in the contract: repository, deployment, credentials, and documentation sufficient for another developer to take over.
• Run a small paid discovery and treat the experience itself as the most important data point.
• Treat any single hard red flag as a reason to slow down, and a cluster of them as a reason to walk.

Vetting a custom software developer in 2026 is not about decoding technical jargon or trusting a slick pitch. It is about weighting verifiable evidence over polished artifacts, watching how someone reasons through your real problem, and nailing down ownership before the work begins. The firms worth hiring make all of this easy, because transparency is how they already operate. If you want to talk through a project, Warren & Sabb starts every engagement the way this article recommends: with honest scoping and a clear answer to who owns what.