Choosing a development agency without getting trapped

What can go wrong when you hire the wrong agency

The wrong agency does more than waste money. It can slow your company for months, leave you with fragile code, and turn a simple product into a cleanup project.

The damage usually starts small. A missed milestone becomes "one more week." Then the launch slips, sales plans move, and your team starts making decisions with incomplete information. If the code is messy, every change costs more, bugs keep coming back, and each new developer needs extra time just to understand what they inherited.

The worst problems often show up after the relationship gets tense. Some agencies keep the code in their own repositories, control the cloud account, or manage releases in tools that only they can access. When you try to switch teams, you find out you do not fully control your own product.

Friendly sales calls do not prove much. A polished founder or account manager can sound sharp, answer every question smoothly, and still hand your project to a weak delivery team. Good work shows up in planning, risk reporting, testing, and documentation, not in how confident someone sounds on Zoom.

Money problems creep in the same way. A low quote turns into change requests, support fees, and surprise charges for work you assumed was included. If the contract is vague about source code, designs, infrastructure, or outside accounts, ownership disputes can follow.

Most bad agency relationships fall into the same few traps. They promise senior talent and assign junior staff. They build quickly but skip tests and documentation. They keep admin access to code, hosting, and domains. They charge extra whenever the scope gets clearer. Or they make the system so opaque that only they can maintain it.

Treat vendor lock in as a real business risk. If replacing the agency would be painful, they have more leverage than they should.

What to define before you talk to agencies

Most agency problems start before the first call. If you cannot explain the project in one plain sentence, the agency will fill the gaps with its own assumptions.

Write that sentence around the business goal, not the technology. "We need a customer portal so clients can track orders without emailing support" is clear. "We want a modern web platform" is vague and almost useless.

Then cut the first version down to what people must use on day one. Think in user actions: sign in, submit a request, pay an invoice, view a report. Put future ideas in a separate parking lot. If you mix must haves with later ideas, every proposal grows, slows down, and gets harder to compare.

Set a rough budget range before you ask for estimates. It does not need to be exact. A simple range tells agencies whether to suggest a lean first release or a broader build. Do the same with timing. Pick the date that matters and say why it matters, whether that is a sales launch, an investor update, or an internal deadline.

Choose one person who makes the final call. This saves a surprising amount of pain. When three people give separate feedback, the scope shifts every week and nobody owns the tradeoffs.

Decide how you will judge success after launch. A live product is not enough. Use a short scorecard: fewer support emails, 100 active users in the first month, or two hours less manual work each day.

With those answers in hand, agency conversations get clearer. Proposals improve, estimates tighten up, and expensive surprises become less likely.

How to screen agencies in the first calls

The first call is a filter, not a pitch meeting. You are not trying to learn everything. You are checking whether the team thinks clearly, answers directly, and has handled work close to yours.

Start with recent proof, not old claims. Ask what they shipped in the last year that resembles your project in size, pace, or risk. Useful answers sound specific: what they built, who used it, how long it took, and what happened after launch. Vague answers usually point to thin experience or a sales led process.

Then find out who will actually do the work. Many agencies send a polished seller to the call and keep the builders out of sight. Ask who runs discovery, who manages the project day to day, and who writes the code. If they cannot name roles clearly, expect confusion later.

A short set of questions works well:

• What is the closest project you shipped recently?
• Who would work on our project each week?
• How would you split discovery, build, and support?
• What risks or unknowns do you already see?

The content of the answer matters, but so does the tone. Good agencies say "we do not know yet" when needed, then explain how they would reduce that uncertainty. Weak agencies fill the gaps with broad timelines, big promises, and canned phrases.

Ask for a simple plan. It does not need polish. You want to hear how they would learn the scope, build in small steps, and handle bugs or shifting priorities after release.

One founder question often cuts through the fog: "If your lead developer quits next month, what happens to my project?" Serious teams have a real answer.

If you have a fractional CTO or technical advisor, bring them into these calls early. They can spot soft answers in minutes and save you months of cleanup later.

Interview questions that reveal how they work

A polished portfolio tells you very little about daily habits. The useful questions force an agency to explain who decides, who checks the work, and what happens when things go wrong.

You want to hear how they work on a normal Tuesday, not how they sell.

• "How do you split work into milestones, and what do you review at each stage?"
• "Who owns architecture decisions, and why does that person make them?"
• "How do you test features before release?"
• "What do you do when estimates are wrong or the scope changes?"
• "What happens if a developer leaves in the middle of the project?"

Strong answers sound concrete. They describe short phases, regular demos, one clear technical lead, a real testing process, written change approvals, and a handover plan that does not depend on one person.

Weak agencies stay vague. You will hear lines like "we are flexible" or "that rarely happens." That is not enough. Ask for a recent example. If they cannot give one, they probably do not have a steady process.

A small test works well here: ask the same question twice in different words. If the answer shifts, you found a risk. If it stays consistent, the team probably understands its own process.

Contract terms that protect your company

The contract matters more than the sales call. A friendly team can still leave you with code you cannot use, accounts you cannot access, or invoices tied to vague promises.

Start with ownership. The contract should say that your company owns the code, designs, written content, databases, and all project assets once you pay for them. It should also name every account involved: source control, cloud hosting, domains, analytics, app stores, email tools, and design files. If the agency opens an account for the project, your company should be the legal owner from day one.

Payment terms need clear checkpoints. Do not pay against phrases like "steady progress" or "ongoing development." Tie each payment to a milestone with a simple acceptance rule, such as approved designs, a working staging build, or a tested release. If a milestone is vague, expect arguments later.

A few clauses prevent a lot of pain. Your company should own all work after payment. Milestones should have written deliverables and acceptance criteria. Bug support after launch should have response times and fix expectations. Change requests should include price and timeline impact before the extra work starts. And either side should be able to end the agreement under defined conditions.

Support after launch often gets ignored until the first production issue appears. Add a bug window with response times. For example, severe bugs that block core use should get a response within one business day and a fix or workaround within a few days. Smaller issues can wait longer, but the contract should still say how long.

Change requests need their own process. Small teams often ask for "one more thing" and assume it fits inside the original budget. That is how costs drift. The agency should pause, estimate the added work, and get written approval before changing scope, price, or deadlines.

Exit terms matter even if you expect a smooth relationship. If the agency misses deadlines, produces unusable work, or stops communicating, you need a clean way out. Set the notice period, define what happens to unpaid work, and state how fast they must transfer files, code, and account access. If this feels awkward to discuss, take that as a warning.

Handover requirements to agree before work starts

A lot of people focus on price. Control matters just as much. If your team cannot access the code, hosting, or domain without asking the agency, you do not fully own the project.

Put your company on every critical account from day one. That includes the code repository, cloud hosting, domain registrar, analytics, app stores, email service, payment tools, and any outside service the product depends on. The agency can use its own working accounts if needed, but your team should keep admin access throughout the project.

This saves a lot of pain later. Founders often learn too late that the domain sits in the agency's account or that production deploys depend on one contractor's laptop. A billing dispute or missed renewal can then stop the whole business.

Ask for working notes while the project is still active, not at the end. You want setup steps, deployment instructions, environment variables, server details, backup rules, monitoring access, and a simple map of how the system fits together. If the agency says they will clean it up later, push back. Later usually means never.

Documentation should stay current during the build. Keep it short, but make it specific: how to run the app, how to deploy it, where data lives, how to add a team member, and how to recover from a failure. Simple docs beat a polished wiki that nobody updates.

Handover checklist

Before work starts, attach a dated handover checklist to the contract:

• company owner access to all repositories and services
• current credentials and permission list
• deployment steps your team can follow
• updated system and environment notes
• a handover date with a review session and fix window

Do not treat handover as a soft promise. Make it an acceptance condition. If the agency has not transferred access, documents, and working knowledge, the project is not finished.

A practical process you can actually follow

Most teams make this harder than it needs to be. A short process with the same inputs for everyone gives you better answers and fewer surprises.

1. Write a one page brief. Describe the problem, the first version you want, your budget range, your timeline, and who on your side can approve work.
2. Send that exact brief to two or three agencies. If each one gets a different story, you cannot compare them fairly.
3. Ask each agency for the same response: who would work on the project, how they would handle the first 6 to 8 weeks, how they report progress, and what they need from you.
4. Interview the people who would actually do the work. A polished salesperson can hide a weak team.
5. Score each agency before you discuss contract details or price changes.

Keep the scoring simple. Rate each agency on clarity, fit, and risk.

Clarity means they answer plainly, give real examples, and explain tradeoffs directly. Fit means they understand your stage, budget, and pace. Risk means you notice vague estimates, missing roles, unclear ownership, or promises that sound too easy.

Use a 1 to 5 score for each area and add one sentence of evidence under every score. That note matters more than people think. Memory gets biased fast after a friendly call.

Then pause. If anything still feels fuzzy, do not sign.

Ask follow up questions until the agency gives clear answers on scope, change requests, code ownership, infrastructure access, documentation, and handover. Good agencies usually tighten weak wording without much drama. Weak agencies push you to "start now" and fix details later.

That pause can save months of cleanup. A signed contract should feel boring, clear, and hard to misread.

A realistic example of a safe selection process

A small retailer with one store and a growing online business still runs stock, purchase orders, and returns in spreadsheets. The owner wants a simple web app so staff can stop chasing different versions of the same file and fixing stock mistakes by hand.

She speaks with two agencies and one freelancer.

The first agency looks polished. Their sales lead talks fast, promises a "complete custom platform," and sends a proposal full of broad phrases. The price is high, but the bigger issue is that the proposal never says who owns the code, where it will be hosted, how changes get approved, or what happens if the project stops halfway.

The freelancer is sharp and asks good product questions. His price is fair. Still, he works alone, has limited availability, and cannot offer much support if he gets sick or takes another contract.

The second agency is less charming, but much clearer. They split the work into a short paid discovery phase and a first delivery phase. They estimate only what they can explain. When the owner asks about handover, they answer in plain language.

Their proposal includes code in the retailer's own Git repository, staging and production access in the retailer's accounts, weekly demos with written decisions, a handover list with documentation and deployment steps, and a clause that lets the owner end the project and keep all completed work.

A fractional CTO reviews all three offers and points out the risk in the vague proposal. The polished agency sells confidence, but the owner would only learn later what she actually bought. The freelancer might still be useful for smaller tasks, but he is a weak fit for the full build.

She chooses the second agency. Not because they sound bigger or friendlier, but because their terms protect the company. If the relationship fails, another team can still pick up the code, the docs, and the infrastructure without starting from zero.

Mistakes that trap founders and small teams

Small teams often lose money before the first sprint starts. The trap is rarely obvious bad intent. It is vague scope, weak control, and delayed decisions about ownership.

The lowest quote is the oldest mistake in the book. A cheap proposal can hide missing work, thin testing, weak documentation, or endless change requests later. If one agency says the project costs half as much as the others, ask what they removed, what they assumed, and what happens when those assumptions break.

Technical access causes more damage than many founders expect. If the agency creates the cloud account, owns the code repository, keeps the domain login, and manages production without your team in the room, you are stuck the moment the relationship turns sour. Your company should own every account from the start, even if the agency does the setup.

Monthly retainers can go sideways fast too. A retainer without delivery rules becomes paid availability, not measurable progress. You need a clear definition of what ships, how work gets approved, what response times apply, and when you can end the agreement.

Reference checks sound dull, so many teams skip them. That is a mistake. Ask past clients a blunt question: "What became painful after month two?" You will learn more from that than from another polished sales call.

Handover is another topic founders push to the end, which is exactly why it becomes expensive. If the contract does not spell out code access, infrastructure access, documentation, deployment steps, credentials, and support during the transition, the agency keeps the leverage.

A common pattern goes like this: the quote looks cheap because support, QA, and operations are barely included. The agency uses its own accounts for speed. Work moves to a monthly retainer with no real delivery checks. Then the founder tries to switch vendors and finds out nothing is easy to transfer.

That mess is avoidable. Keep the scope specific, keep ownership with your company, talk to real past clients, and make handover part of the first deal, not the last conversation.

Quick checks before you sign

A proposal can look tidy and still leave you exposed. The safest last step is a short review that forces both sides to get specific.

Check whether you control the project from day one or only rent access to it while the agency stays in charge. That difference causes many ugly breakups later.

• Make sure your company owns every account and asset, including code repositories, cloud accounts, analytics, domains, app store access, design files, and error tracking. If the agency wants to keep anything in its own account, ask why.
• Read the milestone section line by line. Each milestone should have a date, a clear deliverable, and simple acceptance rules. If the contract says work is accepted by default after a few days, push back.
• Ask for the actual names of the people who will work on the project. Sales calls often sound great, then the work goes to a different team.
• Test the handover plan with a quick explanation. If you cannot explain how code, credentials, documents, deployment, and support transfer to your team, the plan is still fuzzy.
• Let an outside technical advisor read the proposal before you sign. A good reviewer will catch weak scope, missing handover terms, fake seniority, or delivery promises that do not match the budget.

This review does not need a week. One careful hour often saves months of stress. If you do not have senior technical help in house, a fractional CTO or advisor can do this quickly and catch problems before they get expensive.

What to do next

Once you narrow the field to one agency, pause before you send money. A lot of bad decisions happen at the end, when everyone is tired and wants to get started.

Put your brief, interview notes, scorecard, proposal versions, and contract comments in one place. If details are scattered across email threads, chat, and old documents, people miss small warnings that later turn into expensive problems.

A short final check helps more than another sales call:

• compare the final proposal against your original brief and scope
• mark anything still vague, especially ownership, access, change requests, and handover
• ask for one last review from someone who did not join every call
• do not release a deposit until those notes have clear answers

This matters most when you do not have strong technical help on your side. Founders often spot pricing issues, but they miss delivery risk, weak handover terms, or promises that sound fine and fail in practice.

If you are unsure, bring in an experienced fractional CTO for a second opinion. One careful review can catch gaps in architecture choices, team structure, timelines, and support terms before they become your problem.

If you need that outside view, Oleg Sotnikov at oleg.is can review agency proposals, handover gaps, and delivery risk before you sign. That makes sense when you want experienced technical judgment without hiring a full time CTO.

Collect the documents, do the final review, fix the weak spots, and only then commit funds. A one day pause now can save months of cleanup later.