What Your Developer Isn't Telling You (And What You Should Ask)

You trust your developer, and that's normal

You've found a developer. Freelancer, agency, or in-house. They're competent, responsive, they deliver what you ask for. You trust them. And that's perfectly normal.

But trust doesn't replace visibility.

I've seen too many projects where the PM discovers after six months that the application has zero automated tests. That the database has never been backed up. That the code isn't documented anywhere and nobody other than the current developer can understand it. Six months of development, tens of thousands of francs invested, and one day the dev is no longer available. Or the project needs to evolve. And then comes the cold shower.

This isn't a matter of bad faith. It's a matter of communication. And in the client/developer relationship, there are things that almost never surface on their own.

"Everything's going well"

This is probably the most dangerous sentence in a tech project.

When your developer tells you everything's going well, in most cases, it's true. But sometimes, it means something else. It means: "I have a problem, but I think I can solve it." Or: "There's technical debt piling up, but now's not the time to talk about it." Or: "I've been stuck on something for two days, but I don't want to look incompetent."

Developers don't hide problems out of malice. They do it out of habit, out of optimism, or because they figure the client wouldn't understand the technical details. And honestly, they're often right on that last point. But that doesn't mean you should stay in the dark.

The real challenge isn't understanding every line of code. It's asking the right questions to get real visibility into the state of your project.

The questions you should be asking regularly

These questions don't require any technical skills. They just require the reflex to ask them. And the answers, even if you don't understand every detail, will give you very clear signals about the health of your project.

"Does the project have automated tests? How many?"

A project without tests is a project where every change is a gamble. You change something here, it breaks over there, and nobody notices until a user reports the bug in production. Automated tests are the safety net. If your dev tells you there aren't any, or that they "didn't have time," that's a warning sign. Not because it's critical today, but because it will be.

"If you disappeared tomorrow, how long would it take another dev to pick things up?"

This question often makes people uncomfortable, and that's exactly why you need to ask it. The honest answer is usually "a few weeks." If it's "a few days," you're in good shape. If it's "a few months" or an awkward silence, you have a dependency problem that's going to cost you sooner or later.

"What's the current technical debt?"

Technical debt is the sum of all the shortcuts taken to move fast. Every project has some. That's not a problem in itself. The problem is when nobody measures it and nobody pays it down. Ask your dev to describe it in simple terms. If the answer is "there isn't any," either your dev is a genius or they don't want to talk about it.

"Is the code version-controlled and automatically deployable?"

Version control (Git) is the bare minimum. It lets you roll back if something breaks, collaborate on the same codebase, and keep a history of every change. Automated deployment (CI/CD) is the ability to ship a new version in minutes, reliably and reproducibly. If your dev deploys by copy-pasting files to a server, you're stuck in 2010.

"What's blocking or slowing you down right now?"

This question is a gift you give your developer. It gives them permission to talk about real problems. Maybe they're struggling with a poorly documented external API. Maybe the specs aren't clear and they're improvising. Maybe they're spending 30% of their time working around a technical decision made six months ago. You can't help if you don't know.

"Is user data secure?"

This is the question nobody asks until the day there's a breach. Are passwords hashed? Is sensitive data encrypted? Are API endpoints protected? Are backups in place? If your dev can't clearly answer these questions, you have a problem. And in Switzerland, with the FADP (Federal Act on Data Protection), that problem is also a legal one.

"What's the one thing you'd do differently if you started over?"

My favourite question. Because the answer reveals everything. If your dev has a precise, thoughtful answer, it means they have perspective on their work, they see the trade-offs, and they're capable of self-criticism. That's the sign of a good professional. If the answer is "nothing, everything is perfect," be wary. No project is perfect. Anyone who claims otherwise either doesn't see the problems or doesn't want to see them.

Warning signs you can spot without writing code

You don't need to read code to sense that a project is heading for a wall. There are observable, concrete signs that don't lie.

Estimates are always blown. Not occasionally — systematically. "It'll take two days" turns into a week. "It's almost done" drags on for three weeks. It's not necessarily incompetence. It's often a symptom of code that's become too complex to evolve. Every change takes longer because the project is accumulating unmanaged technical debt.

"Small changes" take days. When changing a button colour or adding a field to a form becomes a two-day operation, the architecture is no longer holding up. A well-structured project allows simple changes to be made simply.

Your dev is afraid to touch certain parts of the code. "It works, let's not touch it." That sentence should set off alarm bells. Code that nobody dares to modify is code that nobody understands anymore. And code that nobody understands is a ticking time bomb.

There are no regular demos. If you only see the product when it's "finished," you discover problems too late. A good cadence is a demo every one to two weeks, even if it's incomplete. It lets you course-correct before the project goes off in the wrong direction.

You can't access the source code. This is the ultimate red flag. The code is what you're paying for. You should have access to it at all times, in a repository you control. If your provider refuses, or tells you "it's on their computer," you have an intellectual property problem on top of a technical one.

How to become a better tech client

Asking these questions isn't micro-management. It's the opposite. It's giving your developer the framework to be transparent, to surface problems early, and to make the right technical choices without having to hide them.

The best projects I've worked on were with clients who asked questions, who were willing to hear bad news early, and who invested in quality even when it wasn't visible on screen. Clients who understood that security, testing, and documentation aren't wasted time — they're invested time.

You don't need to become technical. You need to become demanding about transparency. To ask for evidence, not promises. To prefer a dev who tells you "it's more complicated than expected, here's why" over a dev who tells you "everything's fine" for six months before announcing the project needs to be rebuilt.

What if your dev is an AI?

If you've read my previous article on vibe-coded projects, you know that more and more people are building their products with AI. And everything I've just said applies in that case too. Perhaps even more so.

And if your dev is Claude, ChatGPT, or Gemini, don't hesitate to ask it these very questions. You might discover some interesting things. Ask if there are tests. Ask about the technical debt. Ask what it would do differently if it started over. The answers might surprise you.

Because the problem is never the tool. The problem is not asking the right questions.

And if the answers leave you puzzled — whether they come from a human or an AI — a few hours of outside perspective can make all the difference.