The Developer Who Held All the Cards

A friend of mine came to me about six months into building their product - a training app with a mobile experience for end users and a web platform where course material would be created. Solid concept, real market potential.

They'd hired a developer to bring it to life. For six months, they trusted him. I wish I could say that trust was rewarded.

---

The project was behind schedule. Way behind. But every time my friend asked about the delays, the developer had an answer.

"These bugs are really complex. I need more time to sort them out."

It was always something. Each update came with a new reason why the timeline needed to shift, new requirements the developer said were essential, and the finish line kept moving further away. My friend isn't technical - they're a businessperson with domain expertise and a vision. Without a technical background, every one of those explanations sounded plausible.

That's the trap. When you don't speak the language, you have no choice but to trust the person who does.

---

When I finally got a look at how things were set up, my stomach sank.

"Can I see the repository?"

There wasn't one. No Git, no version control of any kind. The developer had been working on his own machine with no shared access to the codebase. My friend - the person paying for this software - couldn't see the code, couldn't verify progress, and couldn't hand it to another developer if things went south.

After asking repeatedly, the developer finally pushed code to a repository. Once. A single push, and only for the mobile app. The web platform - where administrators would log in, manage users, and handle data - was never shared. This is the part of the system where security vulnerabilities like SQL injection are most likely to live. The part that most needed a second set of eyes.

When my friend pressed for more, the developer's response was to make her feel unreasonable for asking.

"None of my other clients demand this."

A business owner asking for access to code she was paying for - code that would handle her customers' data - was treated like an unreasonable demand.

On top of that, the developer had told us what the mobile app was built with but never disclosed the technology behind the web platform. That meant my friend had no way to estimate her ongoing hosting, licensing, and scaling costs. She was building a business around a product and had no idea what it would cost to run.

---

The demos were another problem. They happened over video calls - the developer would share his screen and click through features. It looked like progress. But my friend never had access to a live environment. She couldn't open the app on her phone or click around on her own time. Without live access, she couldn't verify what she was seeing, couldn't understand what had actually been built, and had no real grasp on what the final requirements even were. The goalposts weren't just moving - they were invisible.

When I started raising technical questions through my friend, the responses came back defensive. Combative, even. He framed my involvement as interference, as if having a second set of technical eyes on the project was somehow unreasonable.

That told me everything I needed to know.

---

The red flags in situations like this are almost always the same. Once you know what they look like, they're impossible to miss.

If your developer won't use version control, they're either inexperienced or deliberately making themselves irreplaceable. Every line of code written for your project should live in a repository that you own.

If you've only ever seen demos over a video call, be cautious. You should be able to open the app yourself, on your own device, on your own time. Insist on a staging environment or test build you can access independently.

If timelines keep shifting because of new requirements the developer identified, ask yourself: who's actually driving the scope of this project?

If your developer won't tell you what your product is built with, you can't plan your business. You don't need to understand every technical decision, but you need to know enough to estimate what it costs to run.

If your developer makes you feel unreasonable for asking questions, run. "None of my other clients ask for this" is a manipulation tactic designed to make you stop asking. You are not difficult for wanting access to what you're paying for.

---

Eventually, the developer did deliver something. "Something" is the operative word. What my friend received after all those months was a product that technically existed but was far from what had been promised.

I share this story not to scare anyone away from hiring developers. Most are honest, skilled professionals who want to do good work. But the information asymmetry between a non-technical founder and a technical builder is real, and it creates an environment where bad actors can thrive.

If you're a founder working with a developer, you don't need to become a programmer. You don't need to learn to read code. But you do need someone in your corner who can - someone who can look at a repository and tell you if real progress is being made, sit in on a technical call and know whether the explanations add up, and spot the red flags before they become expensive mistakes.

That's the role I played for my friend. I wish they'd had it from the beginning.