I Think My Developer Is Lying to Me

You’re paying someone to build software and you can’t read what they’re building. For a while that was fine. Lately the dates keep moving, the explanations have gotten more technical, and the last invoice was bigger than you expected. You’ve started to wonder whether your developer is lying to you, and you have no way to find out.

You can find out. It doesn’t require learning to code, and most of it can be done this week. Here is how to tell if your developer is lying, how to tell when they aren’t, and what to do in either case.

Why you can’t tell from where you sit

You take your car to a shop and they tell you it’s low on blinker fluid. If you know cars, you laugh and leave. If you don’t, you pay for the blinker fluid.

That is the position you’re in with software, and it has nothing to do with how smart you are. Your developer knows things you don’t, describes them in words nobody taught you, and you are expected to approve the spending anyway.

The uncomfortable part is that an honest developer and a dishonest one sound almost identical from the outside. Both will tell you something took longer than planned. Both will mention a problem you’ve never heard of. One of them is describing reality and the other is describing an invoice, and the words are the same.

So I’d stop trying to judge the explanations. You will lose that contest every time, including against people who are telling you the truth. Judge the things you can see.

Things that sound like lies and usually aren’t

Most developers are honest, and a lot of what makes founders suspicious is ordinary software behaving the way software behaves. Before you accuse anyone, know which of these are normal.

The estimate was wrong. Every estimate is a guess. With custom software, the thing being built has never existed before, so the guess is made with missing information. A date that slips once or twice, with a reason you can follow, is the normal case.

Fixing one thing turned into fixing five. You ask for a small change and it takes a week, because the small change depended on something else that was broken, which depended on something else again. This happens to careful developers constantly. It feels like padding and usually isn’t.

It was fast at the start and now everything is slow. This is the one that makes people most suspicious, and it is nearly always real. The first version took weeks. Now a feature that sounds simple takes weeks on its own. Early on there is nothing for new work to collide with. Later every change has to fit around everything already built. A service you depend on changes how it works, or you hit the ceiling of a tool that was fine at the start, and the fix is to replace it and then adjust everything that touched it. Sometimes the developer has to stop and reorganize code that has gotten tangled, which produces nothing new for you to look at. Software slows down as it grows, on good projects as well as bad ones.

A lot of the work is invisible. Security, backups, error handling and the plumbing that keeps two customers from seeing each other’s data produce nothing you can click. A good developer spends real time there, and a week of it looks from your chair exactly like a week of nothing.

They told you no. A developer who pushes back on a feature, or says something will cost more than you hoped, is more likely to be honest than one who agrees with everything.

None of these prove honesty. They are only weak evidence of lying, and they show up on good projects all the time.

Signs that should worry you

These are different, because every one of them is something you can check without understanding the code.

You can’t get into your own accounts. The code, the hosting or the domain is registered in the developer’s name, and when you ask for access there’s a reason it isn’t convenient right now. This is the most serious sign on the list. I covered why every account should be in your name from day one in an earlier post, and it matters more here than anywhere.

There is nothing to click. You hear “about 80 percent done” for weeks and have never been sent a working link. Real progress on software can almost always be shown, even when it’s rough.

The answers get more technical when your questions get simpler. You ask “can a customer sign up yet?” and get a paragraph about infrastructure. Someone who understands their own work can answer a yes-or-no question with yes or no.

Payment keeps arriving before proof. Each invoice is for work you’re told is finished and can’t see, and the next phase can’t start until it’s paid.

They don’t want anyone else looking. You mention having another developer review the code and the mood changes. An honest developer may not enjoy being checked. They don’t try to prevent it.

Stop judging the explanations. Judge the things you can see.

Five checks you can run this week

None of these need technical knowledge, and none of them are an accusation. They are what any owner is entitled to ask. Run them in order, because each one is a little more pointed than the last.

A caution on that last step. Some reviewers will tell you everything is garbage and has to be rebuilt, because the rebuild is what they’re selling. Sometimes that verdict is true. Ask for the specific problems in writing, with examples, before you believe it from anyone.

How an honest developer reacts

The checks are useful twice. You learn something from the results and you learn something from the reaction.

An honest developer sends the link the same day, or tells you plainly why there isn’t one yet and when there will be. They fix the account ownership without an argument, and often apologize for not having set it up that way. They’re fine with the weekly walkthrough, because it saves them writing long emails.

I record a video nearly every time I finish something a client should know about. I click through it and explain what I did, what I chose not to do, and why. Clients can comment and ask questions on the video. I started doing it because explaining software in writing is slow and showing it is fast. It turned out to do something more useful, which is that nobody I work with has to wonder what I’ve been doing.

A developer with something to hide reacts differently. The requests are treated as insults. The link is always a few days away. The second opinion becomes a reason to threaten to quit.

If your developer is overseas, don’t count on the contract to help. A contract with someone on the other side of the world is very hard to enforce, which I wrote about in what happens after an offshore MVP is “done”. Your accounts are the protection you have.

The part that is yours

I say this carefully, because it’s the piece people least want to hear.

A lot of founders in this spot handed the technical side to “the tech person” and stopped thinking about it. That is an understandable thing to do. It is also how a small problem goes unseen for six months.

If your product is software, you are running a technology business. You don’t have to write the code. You do have to understand it well enough to manage the person who does, which means knowing what was built this week, what is next, and why. The five checks above are that job, done once in a hurry. Done every week, they are how a software business gets managed.

Some people don’t have the time or the background for that, and there’s nothing wrong with saying so. The answer then is to have someone on your side of the table who does. That’s the work I do as a fractional CTO, and it is a reasonable thing to hire for whether or not you hire me.

Frequently Asked Questions

How do I know if my developer is lying to me?

Don't try to judge the technical explanations. Check what you can see instead. Ask for a working link you can click through, confirm that the code, hosting and domain are in your name, and look at whether changes were made on the days you were billed for. Then watch how they react to being asked. Honest developers answer quickly and plainly.

The first version was built in weeks. Why do simple features take weeks now?

Usually because the software has grown. Early on there is nothing for new work to collide with. Later every change has to fit around what already exists, a service you depend on changes, or an early tool hits its limit and has to be replaced. That slowdown is normal. Ask your developer to show you what the time went into. A plain answer you can follow is a good sign.

How do I know the outsourced team I hired isn't lying to me?

Use the same checks, and weight account ownership most heavily. With an overseas team a contract is very hard to enforce, so owning the code, hosting and domain yourself is your real protection. Ask for a weekly walkthrough of what changed. What Happens After Your Offshore MVP Is "Done" covers the pattern in detail.

How do I know if I'm being taken advantage of?

The clearest signs are ones you can verify without reading code: you can't get into your own accounts, you have never been sent a working link, invoices arrive for work you can't see, and the developer resists having anyone else look. One of these is a question to ask. Several together are a pattern.

Who should own the code and the accounts?

You should, from the first day. Your AI Prototype Stalled. How to Hire Someone to Finish It explains how to set that up and why good developers suggest it before you ask.