"This Is Mine" - The Most Honest Thing Your Contractor Ever Said

We were in the middle of a crisis call - me, a founder I coach, his co-founder, and a developer who had just been caught with the entire product codebase published publicly on GitHub.

Not a snippet. Not a test file. The whole thing. Backend, API integrations, the core IP the team had been building for months - sitting in a public repository under this contractor's personal account, indexed by the internet, accessible to anyone who knew where to look.

The founder's co-founder had spotted it by accident. An AWS alert about exposed API keys led her down a thread, and there it was. She was shaking when she got on the call.

When the contractor finally joined - driving, half-distracted, defensive from the first word - the founder's co-founder pushed hard. She demanded to know why. She named the file. She pointed to the commit dates. She said, clearly and loudly, that this was their code, their IP, their product.

And then the contractor said the most honest thing he'd said in six months:

"Shut up. Shut up. Shut up. This is mine. None of yours."

Everyone on the call reacted like it was a meltdown. Like he'd finally snapped under pressure and said something he didn't mean.

I think it was the only thing he said the entire call that he actually meant.

The Confession Hidden Inside the Outburst

Let me tell you what I saw when I looked at this situation clearly.

This contractor had been working on the product for months - way past the original timeline. Every time the team asked for code, they got pieces. Every time they needed a file, there was a reason it wasn't ready. Every time a deadline came, there was a new delay. Six hours of work somehow stretched into two, three months of excuses.

Meanwhile, the contractor had been committing to a public GitHub repo. Not once - the most recent commit was two days before the call. He wasn't sharing the code with the people who paid for it, but he was keeping it current under his own account. That's not an accident. That's a filing system.

When his co-founder on the call asked him to explain, his first move was to call it a mistake - he'd committed "one directory level too deep." That's technically possible. It's also the kind of explanation that sounds just plausible enough to let everyone back down from the confrontation. The classic contractor de-escalation play.

But then he dropped the mask for four seconds. This is mine. None of yours.

That wasn't stress talking. That was his actual operating psychology, finally visible.

Ownership Psychology: What It Is and How It Forms

Every contractor who builds something starts with some version of pride in their work. That's fine - it usually means they'll do good work. The problem starts when that pride calcifies into something else: a quiet, private belief that because they built it, they own it.

This doesn't happen overnight. It forms gradually, over weeks and months, usually accelerated by a few specific conditions:

• They feel underpaid for the complexity of what they're building. Every time the scope expands and the contract doesn't, they mentally rebalance the ledger. The code starts feeling like the compensation they didn't get.
• They have more technical understanding than the client. When you don't fully understand what's being built, it's easy for the contractor to interpret confusion as incompetence - and from there it's a short step to "they don't deserve this."
• The client keeps accepting delays without consequences. Every time a missed deadline passes without a hard conversation, the contractor learns that ownership isn't really being enforced. Why would he think anyone else actually owned it?
• The work becomes part of their portfolio psychology. At some point, they stop thinking "I'm building this for them" and start thinking "I'm building this, and they're funding it."

None of these thoughts get said out loud. The contractor keeps showing up to calls, keeps giving status updates, keeps saying the work is almost done. But underneath, the ownership psychology has already taken root. By the time you get the outburst, it's been there for months.

The Signals That Were There the Whole Time

The thing that got to me on this call was how clearly I could see the signals in retrospect. Not because I'm a genius - because the founder had told me about all of them, one by one, and every time we'd rationalized them away.

Code delivered in pieces, never in full. The contractor would share individual files when asked, but never hand over the full repository in a working state. There was always a reason - it wasn't ready, there were dependencies, Rohit (the replacement dev they were onboarding) didn't have the right access. This is one of the clearest ownership signals there is. When someone controls information asymmetry on purpose, they're protecting leverage.

Commits to his own account, not the client's repo. The contractor's most recent commit to the public repo was two days before the call. The code the team had seen from him was weeks old. He was doing active development work - just not sharing it. He had a private version and a shared version. That's not a workflow issue. That's a strategy.

Unavailability that was selective, not general. The contractor wouldn't answer calls from the co-founder who was tracking his work most closely. He'd respond to Slack sometimes, go dark other times. But he was reachable when he wanted to be. Selective unavailability is a power move - it trains clients to be grateful when they do get access to you, and to back off when they push too hard.

Blaming everyone else for the delays. On the call, the contractor's explanation for the months-long delays was the frontend. The frontend wasn't done, so he couldn't complete his work. But the co-founder pushed back: Vishal had completed his tasks. The contractor then pivoted - it was QA, it was communication gaps, it was everyone. When a contractor has an explanation for every delay that puts responsibility elsewhere, that's not a guy trying to solve problems. That's a guy protecting his position.

"That's outdated" as a deflection. When the team first noticed a version of the code online, the contractor's initial response was to say it was old, outdated, not the real version. This is the contractor version of "those are just rumors." It's designed to create doubt about whether what you're seeing is real. By the time you confirm it's real, the emotional momentum of the confrontation has dissipated.

The "It Was a Mistake" Play

I want to spend a minute on this because I've seen it a dozen times in different forms.

When someone gets caught doing something they shouldn't, the first move is almost always "it was a mistake." Not because it's true, but because it's the fastest path to de-escalation. It hands the other person a way out of the confrontation without losing face. It turns a betrayal into an accident, and accidents are forgivable.

In this case: he committed "one directory level too deep." Could that happen? Sure, technically. Does it explain why the repo was still public two days before the call, with active commits, with a file the team had never seen before? No. Does it explain why he hadn't mentioned it? No. Does it explain why the team's API keys were embedded in the exposed code and they were getting alerts about it? No.

The "mistake" framing collapses the moment you hold it up against the full picture. But in the moment, under pressure, on a call where everyone wants the tension to end - it works. People want to believe it. It's less frightening than the alternative.

Don't let them use it. When you hear "it was a mistake," that's when you slow down, not speed up. Ask for specific answers to specific questions. The co-founder on this call did exactly the right thing: she asked him to walk through the files on screen, to point to the specific files the team didn't have access to, to explain exactly how a one-level commit error resulted in the entire backend being public. He couldn't do it cleanly. He kept redirecting.

What to Do When You're Already In This Situation

By the time this call happened, the team was in a genuinely difficult spot. They needed the contractor to take the repo private - and he was the only one who could do it. They were also mid-transition, trying to onboard a replacement developer who was already struggling because he didn't have access to the full codebase. Firing the contractor immediately felt risky.

Here's the move the co-founder landed on during the call, and I think it was right: hold the cards. Don't fire him yet. Give him a specific task with a specific deadline - take the repo private, do it within the hour, text when it's done. Make it non-negotiable and visible. While that's happening, extract everything possible: all files, all credentials, all documentation. Get the replacement developer up to speed as fast as you can. Then, when you're no longer dependent on the contractor for anything critical, make the decision.

The co-founder put it well: "We'll have a celebration of his fire." Which sounds harsh, but it's actually the correct contractor management instinct. Don't blow up the relationship in a moment of anger and lose access to things you still need. Get what you need first. Maintain leverage. Then end it cleanly.

If you find yourself in this situation - contractor who's been withholding, possible IP exposure, a team that's partially dependent on someone you can no longer trust - the sequence is:

• Get the exposure fixed first. Make it private, revoke keys, change credentials.
• Download everything immediately. If the code is public even for an hour, you now have it.
• Start the parallel track. Get the replacement up to speed while maintaining the illusion of continuity with the original contractor.
• Document everything. The commits, the dates, the conversations. If this turns into a legal dispute, you'll want the paper trail.
• Exit when you're ready, not when you're angry.

How to Prevent This from Month One

All of this is recoverable. Painful, expensive in time and energy, but recoverable. What's actually costly is when it happens three or four times because you haven't built the systems to catch it early.

The ownership psychology I described earlier has tells. You can see it forming if you know what to look for. Here's how I run contractor relationships now:

Code lives in your repo, not theirs. Day one. The contractor has access to a repo you control. They commit there. Their personal account doesn't enter the picture. If they push back on this, that's your answer right there - the pushback on repo ownership is the ownership psychology speaking before anything has gone wrong.

You own all credentials from the start. Every API key, every service account, every login - registered to company email addresses you control. The contractor has access; they don't have ownership. There's a difference, and setting it up correctly at the start costs nothing.

Regular full-state code reviews, not just progress demos. A progress demo shows you a running product. A code review shows you what you actually have. These are different. A contractor can show you a beautiful UI while withholding backend logic. Ask to see the repository directly, regularly, with someone on your side who can verify it's complete.

Watch for the "I'll share it when it's ready" pattern. Legitimate developers share incomplete work. They commit in-progress code. They push to a shared repo even when things are broken, because that's how version control works. A contractor who never commits until they're "done" is either very unusual in their workflow or maintaining a private version. Ask why. Push on it.

The six-hours-to-six-months gap is your signal. In this case, the team estimated the work at roughly six hours. It took months. That gap is where the ownership psychology lives. When something takes ten times as long as it should, the contractor has either lost interest, lost ability, or - in the worst case - stopped wanting to finish because finishing means handing it over.

The Part Everyone Glosses Over

There's something uncomfortable underneath all of this that I want to say directly.

The contractor did build something. He wasn't faking the work. The code was real, the commits were real, the product was real. At some point, he probably started on this with genuine energy and genuine skill. The ownership psychology didn't replace his competence - it ran alongside it.

That's what makes these situations so hard to catch. The guy doing good work and the guy building something he intends to keep can look identical from the outside for a very long time. You're watching the commits go up, seeing the features come together, and trusting that the person who built it is building it for you.

The signal isn't in the quality of the work. It's in the patterns around the work - the access, the transparency, the communication, the delays, the deflections. Those patterns are where ownership psychology shows itself, months before anyone says a word about it out loud.

And if you're running a startup, an agency, or any kind of product business, this is probably the single most important contractor management skill you can develop. Not how to write a great contract (though you should). Not how to structure payment milestones (though you should do that too). It's how to read the psychological tells that tell you whether someone is building something for your company or building something they think belongs to them.

Because most of the time, they'll never say it out loud.

Except when they do. And when they do, it sounds like: This is mine. None of yours.

And at that point, they've been thinking it for a long time.

Build the Systems Before You Need Them

If you're actively managing contractors right now - developers, designers, anyone building something with your IP - go check your repo access, your credential ownership, and your code review cadence today. Not next week.

If you're scaling an outbound operation and trying to build a team around it, the same ownership psychology shows up in sales teams, in appointment setters, in anyone who's building a book of relationships or a skillset on your dime. The 7-Figure Agency Blueprint goes into how I structure those relationships so the leverage stays with the company, not the individual.

And if you want to work through your specific contractor situation - or build the kind of hiring and management systems that catch this early - that's exactly what we dig into at Galadon Gold. Real problems, live calls, people who've been through it.

The lesson from this call isn't that contractors are bad. It's that ownership is psychological before it's legal, and the founders who catch it early are the ones who know what they're watching for.

Watch for it.