Founders Burned by an Agency? Secure Code Access Before Spending More

Secure repository access today, then run a triage audit, or commission a short Prototype Audit, before you spend another euro. The UIDP software contract guidance shows why control of code and accounts must come before delivery. I'm Hanad Kubat, a senior software engineer, and I run these audits for founders who need a clear picture fast.

Key Takeaways

Controlling code and accounts before delivery, combined with structured audits and clear ownership, reduces typical startup risks and prevents costly project failures.

Table of Contents

• Why agencies burn founders: common, research-backed failure patterns
• Pre-engagement checklist: discovery, contract, and SOW items to insist on
• Estimates, staged acceptance, and stopping rules to limit tail risk
• Handover and ownership: concrete items to secure before final payment
• If you're already burned: a prioritized 90-day recovery playbook
• Author perspective: how my fixed-scope, fixed-price deliveries reduce these risks
• Direct option: auditing, rescue, and fixed-price MVP builds I offer
• FAQ
• Sources

Why agencies burn founders: common, research-backed failure patterns

Most bad outcomes are set up before anyone writes code. An ACM analysis of failed projects found that requirements were inadequate when delivery decisions were made in 73% of cases, and estimates were badly done in 81%. A provider who treats your clarifying questions as delay is a risk.

Cost surprises are also heavier than most founders expect. A 2022 empirical study of IT overruns found they follow a power-law distribution, which means extreme overruns are possible, not freak events.

Communication matters as much as code. A PLOS One study of outsourcing failures identified requirements-engineering problems as a leading cause and grouped 43 recurring issues, including communication, knowledge management and coordination. In real projects this looks familiar: defects that surface late, bills that grow without a change you approved, and hosting or app-store accounts registered to the agency, not you.

Pre-engagement checklist: discovery, contract, and SOW items to insist on

Treat discovery, acceptance criteria and change control as engineering work, not paperwork. Before you sign anything:

• Run a timeboxed discovery or audit, and keep a written record of the outcomes, assumptions and acceptance criteria.
• Make the statement of work name repository access, documentation, deployment steps, maintenance expectations, security, validation, and third-party and open-source licensing. The UIDP guidance recommends listing these in the contract instead of relying on a vague promise to "deliver the app."
• Ask for early transfer or shared control of operational accounts. If that is impossible, add a continuity mechanism such as escrow, which the same guidance describes as an optional fallback.
• Define change control: who signs off, what triggers re-estimation, and how changes are priced.
• Validate the idea itself before paying for build work. Our guide on validating a SaaS idea before development covers that step.

Pro Tip: Ask the agency to describe, in writing, what happens if you decide to leave. Their answer shows how much control you really have.

Estimates, staged acceptance, and stopping rules to limit tail risk

A 10% contingency does not fix power-law risk. When overruns can be extreme, padding the budget slightly changes little. What changes your exposure is structure.

The 2022 power-law study of IT cost overruns recommends a narrow first release, explicit assumptions, staged acceptance, and stop/go decisions. Small contingencies do not protect you from the rare, very large overrun.

In practice, I would structure an engagement like this:

1. Scope the first release to one core workflow, nothing more.
2. Attach written assumptions to every estimate, so you can see what the number depends on.
3. Split delivery into stages, each with acceptance criteria you can verify yourself.
4. Decide at each gate whether to continue, adjust or stop, before the next payment.

If a provider quotes a single fixed price with no assumptions, ask what it includes, what would change it, and who pays when an assumption turns out wrong. Ask which requirements are still unclear and how that unclarity is priced. Vague answers mean the risk has been moved onto you. Realistic scheduling matters here too, and this short piece on setting reasonable deadlines is a useful companion when you define your gates.

Handover and ownership: concrete items to secure before final payment

A handover is more than a ZIP file of source code. Put the repository and operational accounts under your control early, not only at the end, and require these items:

• Documentation, automated tests and deployment scripts.
• A list of third-party dependencies with their licenses.
• Clear notes on hosting, domains, payment providers and API keys, all registered to you.
• Contract wording that states who owns the code and how licensing transfers.

Then run one test: can an independent developer clone the repository, run the app locally, and deploy it to production without calling the agency? If not, the handover is incomplete. A phase-by-phase audit checklist can help you structure that verification.

Pro Tip: Hold the final payment until a developer who did not build the product has completed that local run and deploy.

If you're already burned: a prioritized 90-day recovery playbook

Start with facts, then spend carefully.

1. Run a triage audit as soon as possible: repository access, deployment health, billing risks and open security issues.
2. Find the one smallest change that materially reduces risk or cost, and budget that work strictly.
3. Pause non-essential work and freeze any change you did not explicitly approve. Ask for a written statement of outstanding assumptions.
4. Choose a path. A targeted patch fits when the architecture is sound and the problems are contained. A rescue rebuild fits when the product works but the code cannot be extended or reviewed. A full rebuild fits when the foundation is wrongrong and patching costs more than starting clean.

Our article on why startups fail at technical delivery goes deeper on the causes, and the two-week due diligence checklist maps well onto step one.

Author perspective: how my fixed-scope, fixed-price deliveries reduce these risks

I work alone, and the person you talk to is the senior engineer who writes the code. My builds are short, fixed in price and scope, and you own the code from the first commit, so discovery gaps, acceptance disputes and handover surprises have little room to grow. I make no promises about funding, growth or users. I deliver a working first version, and what you do with it is your business.

— Hanad Kubat

Direct option: auditing, rescue, and fixed-price MVP builds I offer

I take on several kinds of work, all fixed price, with code ownership from the first commit:

• Rescue or rebuild of a prototype that has hit a wall.
• First real version of a product that exists only as a document or design file.
• Internal tool that replaces one painful manual workflow.

A Prototype Audit is the lowest-risk way in. It gives you a clear view of assumptions and risks before committing further. Builds start from €12,000. See the details on my main service page and ask for the audit there.

FAQ

What should I do first after a bad agency experience?

Secure access to your repository, hosting and operational accounts before anything else. Then run a triage audit soon to learn what you actually own, what is at risk and what it costs to keep running.

How do I know if an agency's estimate is trustworthy?

Ask to see the assumptions behind the number. ACM research links unreliable estimates to delivery dates set before requirements were adequate. A trustworthy provider documents clarifications and explains what would change the price.

Should I fix the existing code or rebuild it?

It depends on the foundation. Patch when the architecture is sound and the problems are contained, and rebuild when the code cannot be extended, reviewed or deployed by an independent developer. A short audit gives you the evidence to decide.

Do headline software failure statistics mean most projects fail?

Be careful with them. IEEE Software cautions that failure figures like the CHAOS report depend on definitions and sampling. Check how success is defined before trusting any single percentage.

Sources

• Contract Accord 16: Software - UIDP
• Full article: The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution
• ACM: Digital Library: Communications of the ACM

Recommended

• Own Code from First Commit: What Founders Must Insist On in Contracts
• Bubble App Security for Founders: 5 Checks Before Rebuilding
• Founders: 6 Point Lovable to Production Handoff to Own the Code