How to Hire a Custom Software Agency in 2026
Most agency searches go wrong before the first call. The shortlist comes from a search engine that surfaces the agencies best at SEO, not the agencies best at engineering. The pitch decks all read the same — "senior team," "agile process," "transparent communication" — and by the time you realize the pod assigned to your build is three juniors and a part-time architect, you're four months and €120k into the engagement. This is what we'd look for if we were on the buying side.
Read the case studies, not the homepage
Homepages are written by marketers. Case studies are written closer to the work. Look for specifics that an outsider couldn't fake: which framework version, which database, which deployment target, what broke in production and how it was fixed. A case study that names "AngularJS 1.5 → Vue 3 migration over 14 months, kept TypeScript strict mode on the whole way" is a different signal than "we modernized the frontend stack."
If every case study reads like a press release, that's the team you'll get on your project.
Ask who actually writes the code
The single most useful question in a sales call: "Who, by name, will be writing the code? Can I talk to them before signing?"
Healthy agencies will put you on a 30-minute call with the engineer who'd lead your build. They'll be visibly senior. They'll push back on parts of your spec and explain why. They'll volunteer constraints you hadn't thought about.
Agencies that staff bait-and-switch — senior architect in the pitch, junior pod in delivery — will route around this question. They'll talk about "our team" and "our process" and offer references instead. References are gameable. A 30-minute call with the actual engineer is not.
What a real discovery phase produces
A real discovery is 2–4 weeks, billed, and produces a written artifact you can read end to end. Inside it:
- A domain model — the entities, their fields, their relationships. Drawn, not just described.
- A list of every screen or endpoint with one paragraph each on what it does.
- A stack recommendation with rationale — not just "Next.js" but why Next.js over Remix or Astro for this specific product.
- An integration map — every external system the product touches, what direction the data flows, what happens when each one is down.
- A risk register — the 5–10 things most likely to go wrong, and the mitigation for each.
If discovery is "free" and produces a Figma file and a Notion doc with bullet points, you got a pitch deck, not a plan.
Code ownership: get it in writing
Default in custom software work: you own the code, full stop. This means:
- A private repository under your organization's GitHub/GitLab account, with you as owner from day one. Not a transfer at the end of the contract — at the start.
- Every commit pushed by name, not by a shared bot account.
- Infrastructure-as-code for everything they deploy. If they configure your AWS by clicking in the console, you don't actually own the infrastructure.
- No proprietary frameworks or licensed components that lock you in. If they built their own CMS, you should be able to fork it and walk away without paying ongoing fees.
Agencies that resist any of these are protecting a business model that depends on you not leaving. That's the model. Walk.
Red flags worth treating as deal-breakers
- "We can start Monday" — for a 12-month build. Means they have no pipeline, which means they're hungry, which means they'll say yes to everything in scope and quality will pay for it.
- No tech leadership on the sales call. If you can't talk to the person who'd architect your build during the pitch, you won't see them during the build either.
- Quotes without estimates. A €180k flat quote with no breakdown by feature, week, or role is a number, not an estimate. You'll find out what they actually planned for when something costs extra.
- "Senior team" with no individual bios. Real senior engineers have public footprints — GitHub, conference talks, blog posts, OSS contributions. If the team is invisible online, they're probably not the people in the pitch.
- Template stacks for non-template work. "We always use [WordPress / Webflow / Bubble] because it's faster" — fine for a landing page, a warning sign for anything custom.
The reverse-reference check
Vendor references are filtered. Past clients who agreed to be references like the vendor enough to take a call. That tells you one thing.
What tells you more: find a past client who isn't on the reference list. LinkedIn the agency's old projects, find the CTO or product lead from two years ago, send a cold message. Ask: "Would you hire them again? What would you do differently?" The unfiltered answer is the one that matters.
What the contract should say
- Milestone-based payment, not hourly with no cap. Hourly with no cap aligns incentives toward dragging the build out.
- A defined acceptance test for every milestone. "Working signup flow" isn't an acceptance test. "User can sign up with email + password, receive verification email within 30 seconds, log in, and see empty dashboard" is one.
- IP assignment that vests on payment, not at contract end. If they go bankrupt mid-build, you keep what you've paid for.
- A specific handover clause. What do you get on day one of post-launch? Repo access, runbook, deployment credentials, incident playbook, on-call rotation handoff. Name them.
- A defined sunset clause if you stop paying. Most agencies will keep your infrastructure running for 30–90 days post-cancellation while you migrate. The contract should say so.
The two-week trial
If the engagement is over €50k, ask for a paid two-week pilot before committing to the full build. A real discovery phase, a small piece of working software, a written report. Two weeks isn't long enough to fake competence — you'll see how the team thinks, how they handle a question they don't have an answer to, how their code reads on the first PR.
The cost of two paid weeks is rounding error on a six-month build. The cost of finding out in month four that you picked wrong is the entire engagement.