5 Mistakes That Killed a Contract in 10 Days

An American company contacts me to take over a project. We negotiate the terms of the contract, my role is clear on paper, development only. They already have teams for the infrastructure and everything else. The project is 90% done, the goal is to get it live as fast as possible.

Me, I am fired up. Working with Uncle Sam, I think that is cool. A good adventure to live, even remotely. And who knows, maybe one day I would visit them on vacation. California!

The contract lasted 10 days. We stopped by mutual agreement.

I could tell this story giving myself the good role. The client this, the context that. It would be easy, and above all useless. Because the real question is why I, with my experience, did not see coming what was about to happen. Here are the 5 mistakes I made, and what I will do differently next time.

Mistake 1. I signed without clarifying roles and responsibilities

On paper, everything was simple. Me on development, them on infrastructure and the rest.

In practice, from the very first days, I needed access to the servers, the DNS, the third-party services. Nobody had defined who provides what, or when, or how. So I did what many independents do, I put on the missing hat. The devops hat got added to the contract, without full access, without a scope, without the framing being rediscussed.

It is within my skills, so I said yes. I should have said no. Not because I could not do it, but because accepting a responsibility without the means that go with it hurts the project. Every hat added along the way without renegotiating the frame is one more gray zone. And gray zones are where projects die.

What I take away. Defining roles is not a contract formality. It is deliverable number zero. If the scope moves, the framing must be rediscussed the same day, not endured in silence.

Mistake 2. I agreed to work without project tracking

At the kickoff, the message was direct. No tracking, it has to go fast. If I need information, I ask. The only expected output is the launch, bugs or no bugs, we fix them later.

I heard "less admin, more code" and found it almost comfortable. Big mistake.

Project tracking, I always try to put it in place, and in practice it does not always work well, I know that. But at the start of a collaboration, it is irreplaceable. Not to look good. To build trust by showing progress, to document the work, to create a common language between what I do and what the client perceives.

Without tracking, when the pace felt slow on the client side, I had nothing to show. No trace, no milestones, no shared reality. Just my word against an impression.

What I take away. Tracking is not negotiable at the start of a collaboration. It is precisely when the client wants to go fast that they need it most, because it is the only thing that makes speed visible.

Mistake 3. I did not lock in the client's involvement

Owning a project and delegating its execution does not mean detaching from it 100%.

The project had been vibe coded. That is not the problem, I take over vibe-coded projects, it has even become part of my job. The problem is the quantity. An enormous mass of code, documentation and versions. A few months of prompt history that, only three years ago, would have represented the work of an entire team over several quarters.

In a mass like that, decisions surface every day. Which version is the source of truth. Which feature is abandoned. Which behavior is a bug and which one is intended. Those decisions, only the client can make. And if the client is not available, or no longer has the big picture of their own project, everything stops.

I had planned nothing for that. No decision meetings, no agreed response time, no person identified as the referee.

What I take away. Before starting, I lock in the client's availability. Who decides, within what timeframe, on which channel. Delegating the execution requires more involvement from the client at the start, not less.

Mistake 4. I let the client's experience replace the audit

"The project is 90% done." In this line of work, everyone knows what that sentence is worth. Me included. Nobody believes a "90% done", it is almost a running gag among developers.

So why did I not dig deeper? Because the number came from a technical client, with long years of IT and project management behind them. I told myself they knew what "done" means, that their estimate was informed, that the framing held up. It is not the number I believed, it is the experience of the person announcing it.

The reality under the surface was dead code, outdated documentation because the initial framing had never been consolidated, features that only worked on the happy path. And edge cases impossible to reproduce, the ones that turn the remaining 10% into 90% of the work.

I did not audit before committing. No inventory, no shared definition of what "done" means. The client's credibility served as my guarantee, and I let that guarantee replace my own verification.

What I take away. The client's experience does not replace the audit. Even technical, even senior. Especially technical and senior, in fact, because the more credible the client, the more their estimates pass without control. One or two billed days to establish the real state of the project is what protects both parties. Trust does not exempt you from verifying.

Mistake 5. I did not do the pedagogy of my own work

This mistake is the mirror of the previous one. I believed their expertise without verifying it. And I assumed mine could be seen without being explained.

The terrain was known from day one. The project lived on Vercel with a serverless Supabase, and it had to move to self-hosted, in Switzerland, with a real architecture on sovereign infrastructure. I knew it when I signed. That is not the problem.

The problem is the gap between the two worlds. Deploying on Vercel is cool, it works, it goes fast. Especially when Claude does it for you. Security, backups, we will see later. Self-hosted is a different sport. Configuring a DNS, activating SSH, retrieving the right environment variables, wiring each service properly. Devops is meticulous. One bad instruction to the AI and nothing works.

That gap, I knew it. But explaining why a clean infrastructure takes two or four days to someone who just watched 95% of the work happen in one, that felt like justifying myself. So I did not do it. Not priced, not planned, not announced. I let my work become invisible, and the misunderstanding settled exactly there.

What I take away. Pedagogy is part of the job, even with an expert, because their expertise is not mine. Making invisible work visible, priced, planned, explained out loud, is not justifying yourself. It is the only thing that keeps a perception gap from turning into a breaking point.

What this contract taught me

On day 10, we talked honestly and stopped by mutual agreement. No clash, no resentment. Just the observation that the conditions did not allow good work.

I could invoke mitigating circumstances, and there are some. It would change nothing at the core. Anticipating these five points was my job. That is exactly what being independent means. Expertise does not stop at the code, it includes the frame that protects the project, and the courage to say no when that frame does not exist.

This contract gave me a checklist I now apply to every project takeover. An audit before committing. Access from day one. Non-negotiable tracking at the start. An identified and available decision maker. And the pedagogy of invisible work, priced and announced from the start, even when the client is an expert.

The American adventure will wait. Next time I will go with a better contract. And maybe still on vacation.

If you own a vibe-coded project that needs to go from prototype to product, I offer a free audit. I look at your product, I tell you honestly where it stands, and what the last "10%" really hides. No commitment, no jargon. That is exactly the purpose of my offer From Prototype to Product.