How to hire a software development agency in 2026: the questions that actually matter

You've decided to build something — an MVP, an internal tool, a whole product — and you're going to hire an agency to do it. Good. But the way you choose that agency will matter more than almost any decision you make this year, and most founders pick badly. Not because they're careless, but because they judge agencies on the wrong things: a shiny portfolio, a confident sales call, a price that felt reasonable in the moment.

In 2026 this is harder, not easier. AI tooling means anyone can spin up a slick landing page and a demo that looks like a real product. There are more studios than ever, and the surface signals — nice website, fast reply, "we've done this before" — no longer tell you much. What tells you something is the set of questions you ask before you sign, and how the agency answers them.

Here's the list I'd bring to every first call.

Start with your needs, not their portfolio

Before you evaluate a single agency, get clear on what you're actually buying. Not "an app" — the outcome. Are you validating an idea with real users in six weeks? Replacing a spreadsheet that's holding your operations together? Building something you'll raise money on? These are completely different jobs, and the agency that's brilliant at one can be wrong for another.

Write down, in a paragraph, what "success" looks like six months from now. Then judge every agency against that, not against how impressive their case studies are. A team that has built exactly your kind of thing three times is worth more than a bigger name that would be doing it for the first time on your budget.

The question to ask: "Tell me about a project like mine — what went wrong on it, and how did you handle it?" Anyone can describe a success. How they talk about the messy parts tells you who you'll actually be working with.

Can you actually work together?

This is the one founders underweight the most, and it's the one that sinks the most projects. You are not hiring code. You are hiring a team of humans you'll be talking to, several times a week, for months. If that communication is bad, no amount of technical skill saves you.

Pay attention to how they behave before you've signed anything, because that's the best version of them you'll ever see. Do they reply clearly and on time? Do they ask about your business and your users, or only about features? When you ask a technical question, do you get a plain-English answer or a wall of jargon designed to make you feel like you shouldn't have asked?

The questions to ask: Who exactly will I be talking to day to day — the person on this call, or someone I haven't met? How often will we speak, and on what channel? What happens when I have a question at 6pm on a Tuesday? What's your typical response time? You want specific answers, not "we're very communicative."

A green flag is a named point of contact, a regular cadence (a weekly call, a shared channel), and someone who can translate between "what the business needs" and "what the code does." A red flag is vagueness, or a salesperson who vanishes the moment the contract is signed and hands you to a team you never met.

The money conversation — and the numbers not on the quote

Ask about price directly. Any agency worth hiring is comfortable talking about money, and evasiveness here is itself an answer.

But the number on the quote is the easy part. What you actually want to understand is how the price behaves when reality hits. Is this fixed-price for a defined scope, or time-and-materials where the meter runs? Fixed-price protects your budget but makes every change a negotiation; time-and-materials is flexible but can drift. Neither is wrong — but you need to know which one you're signing.

The questions to ask: What does a change request cost, and how is it agreed? What happens if the project runs over the estimate — who absorbs that? And the big one: what are the recurring costs I'll inherit? Almost every modern app comes with a tail of monthly bills — hosting, a database, authentication, email sending, monitoring, error tracking, sometimes per-seat tools the agency likes to work with. Some of these are unavoidable and cheap. Some are expensive and chosen for the agency's convenience, not yours.

Ask for a written list of every recurring fee the build will commit you to, and who pays for it. The OWASP guidance on unbounded cost and resource use is a good reminder that, especially with anything AI-powered, costs can scale with usage in ways nobody mentioned on the sales call. Get the full picture before you sign, not in month three.

What will they build it with — and what does it cost you forever?

Ask what technology they'll use and, more importantly, why. You don't need to understand the answer at an engineering level. You need to understand two things: is this a mainstream, well-supported stack that any future developer can pick up, and does anything in it lock you in?

Some agencies build on proprietary frameworks or platforms they control. It's faster for them and it feels fine — until you want to leave, or hire someone else, and discover your product can't easily live anywhere but their house. Others reach for niche paid tools that carry a licence fee forever.

The questions to ask: Is everything you'll use open, standard, and widely known? Is there anything in the stack I'll be paying a licence for after we're done? If I hired a different developer next year, would they recognise this codebase and be able to run with it? Popular, boring, well-documented technology is usually the right answer — it's the difference between owning a car any mechanic can service and owning one only the original dealer can touch.

Whose code is it, really?

This is where founders get burned quietly, and often don't find out until it's expensive.

You are paying to have software built. You should own that software — completely, forever — the moment you've paid for it. That sounds obvious, but it is not the default unless your contract says so, and plenty of agencies keep more than you'd expect.

The questions to ask: Who owns the intellectual property when the project ends? (The answer you want: "you do, on final payment, in writing.") Where does the code live — in a repository I own, or on your accounts? Can I have access from day one? How is the finished product delivered?

The healthiest setup is simple: your code sits in a GitHub, GitLab, or Bitbucket organisation that you own from the first week, with the agency added as collaborators. That way you can watch progress in real time, you're never locked out, and if you ever change agencies it's a clean handover instead of a hostage negotiation. If an agency wants to keep the code on their side and hand it over "at the end," ask yourself what happens if the relationship sours in the middle. The answer is usually: you have nothing.

How they design and decide

Ask how they get from "your idea" to "a thing on the screen." A team that starts coding on day one, before anyone has agreed what they're building, will build the wrong thing quickly.

You're looking for a discovery step — questions about your users and your goals — followed by something you can react to before it's expensive to change: a prototype, a clickable mockup, wireframes, something visual. Good teams show you the shape of the thing early and cheaply, when your feedback still costs them an afternoon instead of a rebuild.

The questions to ask: How do you decide what to build first? Will I see designs or a prototype before you write the real code? Who signs off on scope, and what happens when I want to change something halfway through? You want a process that expects change, because you will change your mind — that's normal — and the question is whether their process bends or breaks when you do.

Who's watching security?

Security is the thing nobody asks about until it's a headline. Ask about it.

You don't need to audit their practices yourself. You need to know that security is something they do on purpose, not something they hope is fine. The gap between "we build securely by default" and "we'll look at security if you want to pay for it" is enormous, and it maps almost exactly onto the gap between a product you can put a paying customer's name on and one that leaks their data.

The questions to ask: How do you handle secrets and API keys? Who has access to my production data, and how is that controlled? Do you follow any recognised security baseline, like the OWASP Top Ten? If my app handles EU users, how do you approach data protection? You're not grading the answer like an expert — you're checking whether they have an answer at all, and whether it sounds like a habit or an afterthought.

After launch: maintenance and how fast they move

Software is never finished. Dependencies need updating, bugs surface, browsers change, and you'll always want "one small thing." So ask what happens after launch before you sign for the build.

The questions to ask: Do you offer maintenance, and what does it cost? What's your response time when something breaks in production? How quickly can you turn around a small change once we're live — days, weeks? And, tied back to code ownership: if I outgrow you and want to take the code elsewhere, am I free to do that?

Iteration speed is a real signal of how a team works. An agency that can ship a small, safe change in a day or two has good habits — version control, previews, a way to roll back a mistake. One that treats every tweak as a mini-project, quoted and scheduled weeks out, is telling you something about how it's built underneath.

The one-page checklist to bring to your first call

Print this. Ask all of it. Watch how they answer, not just what they say.

• Fit: Have you built something like this? What went wrong on it?
• Communication: Who will I talk to, how often, and how fast do you reply?
• Price: Fixed or time-and-materials? What does a change cost?
• Hidden costs: List every recurring fee I'll inherit, and who pays it.
• Tech stack: Is it standard and portable? Any licences I'll owe forever?
• Ownership: Do I own the IP and the repository, in writing, from day one?
• Delivery: Where does the code live, and can I access it now?
• Design: Will I see a prototype before you write real code?
• Security: How do you handle secrets, data access, and a security baseline?
• Maintenance: What does post-launch support cost, and what's your response time?
• Speed: How fast can you ship a small change once we're live?

Any single vague answer isn't a dealbreaker. A pattern of them is.

How we answer these questions

We built QwertyBit to pass this checklist, because we've watched founders get burned on every item in it. Short version: you own the code and the repository from day one, in writing; we build on standard, portable technology; every recurring cost is on the table before you sign; and we'd rather show you a prototype than hand you a surprise. If you're weighing us against other studios, ask us all of the above — we'd expect nothing less.

If you're at the "who do I actually hire" stage, book a free discovery call and bring the checklist. We'll walk through your project against it honestly, whether you end up working with us or not. And if you want the wider picture, our step-by-step approach to MVP development covers what to nail down before you start, and our 8-point launch checklist for vibecoded apps is the perfect companion if you've already built something yourself and want an agency to make it safe to ship.

Hiring well isn't about finding the cheapest team or the most impressive one. It's about finding the team whose answers to these questions you can live with for the next year. Ask them out loud. The right agency will be glad you did.