That Time I Gave Away £50k Worth of Consulting for Free (And What It Taught Me About the Industry)

I was naive. Let me just get that out of the way.

Early in my contracting career, I took a short engagement with a company - let’s call them Acme Corp. The work was straightforward: review their AWS infrastructure, identify issues, help stabilise their systems. A month or two of work, decent rate, seemed like a good fit.

Then the budget “ran out.”

Fair enough. Contracts end. But before I left, they asked if I could put together a proposal outlining everything that needed fixing and how long it would take. You know, just so they had a roadmap for when budget freed up.

So I did. I spent hours writing a detailed document covering:

• Server stability issues (JVM memory problems from running Tomcat, Apache and the application on the same box)
• Load handling problems (a specific user uploading 60 images would crash the upload server)
• Unnecessary costs from unused public IPs
• Email deliverability issues (SPF, DKIM, MX records needing audit)
• Security concerns (open security groups, no NACLs, shared access keys)
• Recommendations for SSM access, containerisation, Infrastructure as Code, immutable AMIs, proper IAM and SSO

I estimated timelines. Quick wins in 10-12 days. Long-term improvements over 3-4 months. I gave them a genuine, honest assessment of their environment and a roadmap to fix it.

Then I sent it.

And got ghosted.

No response. No “thanks but we’re going a different direction.” Nothing.

They almost certainly took that document, handed it to someone cheaper (or did it themselves), and implemented everything I’d outlined. For free. My consulting, my expertise, my time – all given away because I was too eager to be helpful.

The Interview Version of This

Here’s the thing: this doesn’t just happen to contractors. It happens to candidates in interviews all the time.

You know the pattern:

“For the technical assessment, we’d like you to design a system for [suspiciously specific business problem].”

“Please write a solution for handling [exact scenario our production system faces].”

“Create a proof-of-concept for [feature we’ve been meaning to build].”

Sometimes these are legitimate assessments. Often, they’re not.

I’ve seen take-home tests that:

• Ask candidates to design the exact architecture the company is currently struggling with
• Request working code for features that mysteriously appear in the product weeks later
• Demand detailed proposals for solving problems that read like internal tickets

The candidate spends 8-20 hours on a “test,” submits it, gets rejected (or ghosted), and never knows that their work is now being discussed in sprint planning.

Is it illegal? Probably not, in most cases. Is it ethical? Absolutely not.

Why Companies Do This

Let’s be honest about the incentives:

It’s free. Consulting rates for senior engineers are £500-1000/day. A detailed architecture proposal might cost £5-10k if you hired someone properly. A “take-home test” costs nothing.

There’s no accountability. Candidates are desperate for jobs. They’ll do the work hoping it leads somewhere. When it doesn’t, they blame themselves, not the company.

It’s easy to justify internally. “We’re just assessing their skills.” “It’s based on real problems so we can see how they think.” “Everyone does take-home tests.”

The power dynamic is completely one-sided. The company holds all the cards. The candidate needs the job. Even if they suspect something’s off, what are they going to do – refuse and lose the opportunity?

How to Spot It

Some red flags:

The problem is too specific. Generic assessments ask you to design “a URL shortener” or “a rate limiter.” Fishing expeditions ask you to design “a ticket routing system that handles peak loads on Friday afternoons in the travel industry.”

They want production-ready code. Real assessments want to see your thinking. Exploitation wants working features.

The scope keeps expanding. “Could you also add…” is a sign they’re treating you as unpaid labour.

You never meet the team. If no engineers are involved in evaluating your work, it’s probably going straight into their backlog.

The feedback is suspiciously vague. “We decided to go with another candidate” with no technical feedback usually means your solution was useful but you weren’t.

What I Do Now

I still do take-home tests when required. But I’ve changed my approach:

Time-box ruthlessly. If they say 4 hours, I spend 4 hours or even less. Not 8. Not 12. If the test can’t be completed in the stated time, that’s their problem, not mine. Or i’ll decline the test and move on (unless its a role I want badly)

Keep it conceptual. Architecture diagrams, pseudocode, bullet points. Not production-ready implementations. If they want working code, that’s what the job is for.

Ask questions first. “Is this based on a real problem you’re facing?” Sometimes the honesty of their answer tells you everything.

Protect your IP. I’ve started adding a simple header to documents: “This document is provided for interview evaluation purposes only. Redistribution or commercial use without written consent is prohibited.” Does it have legal teeth? Probably not. Does it make a point? Yes.

Walk away from obvious exploitation. A company once asked me to build a fully functional microservice as a “test.” I declined. They were annoyed. I don’t care.

The Contractor Lesson

Back to my Acme Corp story.

I was naive, but I’m not bitter. Because:

That experience taught me something important: your expertise has value and you should never give it away for free unless it’s a deliberate choice.

When I send proposals now, they’re paid engagements. Discovery sessions have day rates. Detailed roadmaps come after contracts are signed. I’ve learned to separate “being helpful” from “being taken advantage of.”

And look – Acme Corp probably did implement my suggestions. They probably saved themselves months of fumbling by using my roadmap. Good for them, genuinely. But I won’t make that mistake again.

The Politics Reality

Here’s the part nobody wants to say out loud: the tech industry has politics and pretending otherwise is a fast track to getting exploited.

“Just do good work and you’ll be recognised” is a lie told by people who’ve never had their work stolen.

“Meritocracy” is a fairy tale companies tell candidates while they’re extracting free labour through interview tests.

You don’t have to become cynical. But you do have to be aware. Protect yourself. Value your time. Understand that companies will take whatever you give them, so be intentional about what you give.

Don’t hate the player, hate the game. Or better yet – understand the game well enough to play it on your terms.

Practical Takeaways

If you’re interviewing:

1. Time-box take-home tests. Respect the stated limit, not the implicit expectation.
2. Ask if the problem is real. Their answer will be revealing.
3. Keep solutions conceptual. Show your thinking, not a finished product.
4. Trust your gut. If something feels exploitative, it probably is.
5. It’s okay to decline. Companies that won’t hire you without free labour aren’t companies you want to work for.

If you’re contracting:

1. Never send detailed proposals before contracts are signed. High-level summaries only.
2. Discovery is paid work. If they want you to audit their systems, that’s a billable engagement.
3. Get everything in writing. Verbal agreements mean nothing when budget “runs out.”
4. Maintain relationships, but protect yourself. Being helpful and being a pushover are different things.

Final Thought

I don’t regret the Acme Corp experience. It was tuition. Expensive tuition, but I learned.

Now when someone asks for detailed proposals before signing a contract, I politely decline and explain why. Some understand. Some get offended. The ones who get offended are exactly the ones who would have exploited me anyway.

Your expertise took years to build. Your time is finite. Your work has value.

Act accordingly.

---

Had similar experiences with interviews or contracting? I’d like to hear your stories – find me on LinkedIn.