build decisions

What Your Developer Will Never Tell You

Imran GardeziFebruary 23, 202614 min read

Your developer is lying to you.

Not maliciously. Not even consciously. But there are things they will never volunteer. Things that are costing you months. Thousands. Sometimes your entire project.

I know because I was that developer. 15 years at Shopify, Brex, Motorola, Pfizer. I've written the status updates that said "on track" when the codebase was on fire.

Developers are translators. Not strategists. You tell them what you want. They turn it into code. But when what you told them is vague, they fill the gap with assumptions. And they build what they think you want. Not what you actually need.

This isn't a developer problem. It's an incentive problem. Baked into every project.

Today I'm telling you everything. Seven things your developer will never tell you. Each one with the question you should ask, the red flag to watch for, and what good actually looks like.

And truth number six? That's the one that makes founders angry. Rightfully so.

Truth 1: I Don't Understand What You Want

This is the most common. And the most expensive.

A founder says "I want a booking system." Developer hears booking system. Builds one. Calendar view. Time slots. Confirmation emails. Done.

What the founder actually needed: a booking system that handles recurring appointments, cancellations with partial refunds, waitlists, provider-side scheduling constraints, timezone conversions, and integration with their existing payment processor.

None of that was in the brief. Because the founder didn't know it needed to be. And the developer didn't ask. Because asking makes them look incompetent. Asking slows the project down. Asking means admitting they don't know. So they guess. The gap between "booking system" and the actual system is where tens of thousands of dollars disappear. Every unasked question becomes a feature that gets built wrong and rebuilt later.

Three months later: "Why doesn't it handle refunds?" "That wasn't in the requirements." "I didn't know I had to specify that."

Here's the question you need to ask: "Walk me through exactly what you're building, step by step, like I've never seen the product before."

If they can't explain it in plain English, they don't understand it. And if they don't understand it, they're building the wrong thing.

The developer who nods along and never pushes back? That's not confidence. That's someone guessing quietly. And you're paying for every guess.

Truth 2: The Codebase Is a Mess

This one is silently draining your budget every single month.

Every codebase has technical debt. That's normal. What's not normal is when your developers are terrified to make changes. When every feature request gets the same response: "That's going to be complicated." When a simple button takes three weeks. When bugs keep reappearing in places that were already "fixed."

That's not complexity. That's rot.

Your developers know. They've known for months. They talk about it with each other. They complain about it in Slack channels you'll never see. But they won't tell you. Because telling you means admitting it got this bad on their watch. It means admitting the shortcuts they took. It means a conversation about timelines and budgets that nobody wants to have. So they work around it. Patches on top of patches. Workarounds for workarounds. And the codebase gets worse every sprint.

I had a client. Paid $50K for the initial build. Worked fine. Six months later: "$150K to fix it." When I audited the code, I found 14 different workarounds for a single database design flaw. Fourteen. Each one introduced by a developer who was too scared to fix the root cause. Each workaround added complexity that made the next workaround necessary. It's a cascade. The first shortcut costs $500. The fourteenth costs $15,000. And by the time you're at fourteen, you're not fixing the flaw anymore. You're managing an ecosystem of workarounds that has become the system.

That's the Technical Debt Tax. You're paying interest whether you see the invoice or not.

The question to ask: "If you could rebuild any part of this system from scratch, what would it be and why?"

Watch their face. If they light up with a list, that list is your technical debt. And it's been silently compounding.

Truth 3: Auth Is a Nightmare

This is the one that keeps me up at night. Rolling your own auth is one of the most common preventable mistakes in software.

Why do developers do it? Because it's interesting engineering. Because they think it's simple. Because they want to learn how it works. None of those are good reasons to gamble with your users' data.

Auth isn't one thing. It's password storage, session management, two-factor authentication, account lockout policies, password resets, plus the security layer around all of it. Each piece has edge cases. Each piece can have vulnerabilities. A single oversight in any one of these areas can expose your entire user base. And unlike a slow page load or a broken button, a security breach doesn't give you a second chance. Users don't come back from "we leaked your credentials."

One breach and you're done. User data exposed. Trust destroyed. Legal liability with no ceiling.

Clerk. Auth0. Supabase Auth. $25 a month. Battle-tested by millions of users. Maintained by dedicated security teams.

Last auth rebuild I did? $30K. To replace something that should have been a $25-a-month service from day one. Developer built it because it was "fun." Fun cost the founder $30K and six weeks of downtime risk.

Stitch, don't build. Use proven tools for the parts that aren't your competitive advantage. Your competitive advantage is your business logic, not your login screen.

The question to ask: "Show me exactly how passwords are stored. Is this a third-party service or did we build it ourselves?"

If they built it, ask why. The answer better be compliance-driven and specific. "It seemed easier" is not a good answer. "I wanted to learn how it works"? That's a $30K experiment on your dime.

Truth 4: It Won't Handle Real Users

This is the one I've seen cost founders the most money. And they never see it coming.

At Shopify, I watched a developer build a search feature. Beautiful code. Clean. Elegant. Worked perfectly in testing. Production? 45 seconds per query. Crashed the entire database. The code worked. Just not in the real world.

Development is a controlled environment. Ten users. Clean data. No edge cases. No load. Production is the opposite. Thousands of users. Dirty data. Traffic spikes. Concurrent requests. Network failures. Every edge case you never imagined. The gap between these two environments is where most production failures live, and it's a gap that only experience can bridge.

Your developer tested with 10 fake users and a perfect internet connection. They have no idea what happens with 1,000 real users on a spotty mobile connection during a product launch.

No load testing. No stress testing. No monitoring to even tell you when things break. Flying completely blind.

Here's what that costs. I've seen a checkout flow fail for 10% of users. Some edge case with a specific card type. No monitoring. No error handling. Those users didn't call support. They didn't complain. They just left. Two months before someone mentioned it offhand. Two months. 10% of revenue. Gone. And the dashboard said everything was fine because the dashboard didn't know what it couldn't see.

The question to ask: "What happens at 10x our current users? Show me the test."

Not "can you handle it." Everyone says yes. "Show me the test." Show me the load test results. Show me the monitoring dashboard. Show me the error tracking. If the answer is vague, you're flying blind. And you won't know it until it's already cost you.

Truth 5: The Estimate Was Wrong

In my experience, developers underestimate by 3 to 5x. Not maliciously. Not because they're bad at math. Because they estimate the happy path.

"How long to build a login page?" Developer thinks: form, validation, API call. Two days. Reality: form, validation, API call, error states, loading states, forgot password flow, email verification, edge cases on mobile, accessibility, testing, code review, deployment, monitoring. Two weeks. The difference isn't scope creep. It's the iceberg that was always there, just below the waterline.

I call this the iceberg problem. The visible part, the feature, is 20% of the work. Testing, edge cases, deployment, documentation, maintenance: that's the other 80%. Most estimates you've received are weighted toward that visible 20%.

And it gets worse. Requirements change. Scope creeps. That meeting where the founder says "actually, can we also..." That's not a small change. That's a cascade through the entire system. But the original estimate never accounted for it. The estimate assumed a straight line from A to B. Real software development is a maze, and every "can we also" adds another corridor.

Three agencies. One founder. Over $100K spent. Nothing usable. Each agency estimated the happy path. Each one hit the iceberg. Each one ran out of scope.

The founder told me: "I feel stupid. Everyone else seems to get this." You're not stupid. You were given a fantasy estimate three times.

The question to ask: "Break down this estimate. What percentage is coding versus testing versus deployment versus edge cases?"

A healthy estimate is roughly a third coding, a third testing, and a third for the stuff nobody wants to think about: edge cases, deployment, buffer. If there's no buffer, it's a fantasy. And you're going to pay the difference later.

Truth 6: Learning on Your Dime

This is the one founders get angry about. Rightfully so.

A developer takes on a project using a framework they've never shipped. An architecture pattern they've never implemented. A technology stack they've been meaning to learn. Your project is their classroom. Your budget is their tuition.

Those first few weeks of "setup" and "architecture decisions"? That's learning time. They're reading documentation. Watching tutorials. Making mistakes they'd never make if they'd built this before. All on your clock. The invoices say "architecture setup" or "environment configuration." The reality is "figuring out how this technology works for the first time."

I did this once. My first day at Digisoft. My boss says "clone the repo." I had no idea what Git was. No idea. I smiled. Nodded. Went home. Studied until 3 AM. By Monday I was pushing commits like I'd been doing it for years.

A junior developer learning React on your project will take 3x longer than a senior who's built 20 React apps. On a $50K project, that's $30K in wasted learning time. That's not an exaggeration. That's the math. And you won't know it's happening. Because the junior developer doesn't say "I've never done this before." They say "this is taking longer than expected because of some technical complexity." Technical complexity. That's the polite word for "I'm figuring this out as I go."

The question to ask: "Show me three projects you've built with this exact stack. Can I talk to those clients?"

Not "are you familiar with it." Familiar means they did a tutorial once. Show me production work. Show me references. Show me proof.

The developer who says "I haven't done this before, but here's my plan to learn on my own time"? Trust them. The developer who pretends they know and charges you full rate while they figure it out? That's expensive. And it's more common than you think.

Truth 7: Nobody Can Maintain This

Bus factor of one. One person holds all the knowledge. No documentation. No tests. No runbooks. No architecture diagrams. Nothing.

When that person leaves (and they will leave) the knowledge walks out the door.

New developer comes in. Looks at the codebase. Has no idea what anything does. No comments. No README. No documentation explaining why decisions were made. They spend two months just understanding what exists before they can change anything. Two months of salary burned on archaeology. That's not onboarding. That's an excavation. And it happens because the previous developer never wrote down what they built or why they built it that way.

Or worse, they don't understand it. They make changes. Things break in ways nobody expected. Because the original developer had a mental map of every dependency, every workaround, every "don't touch this or payments break" landmine. That mental map is gone now. And no amount of code reading can fully reconstruct the reasoning behind decisions that were never documented.

I've seen companies held hostage by this. Can't fire a bad developer because nobody else understands the system. Can't hire a replacement because onboarding would take months. Stuck in what I call Dev Purgatory. Not because the software doesn't work. Because one person controls whether it keeps working.

That's not ownership. That's dependency. And dependency is a business risk with no insurance policy.

The question to ask: "If you disappeared tomorrow, how does a new developer take over? Show me the documentation. Show me the tests. Show me the deployment guide."

If the answer is "it's all in my head," you don't own your software. They do. And the moment they leave, you're starting over.

What Good Looks Like

Seven truths. Same root cause.

Developers aren't incentivized to surface uncomfortable information. Founders aren't equipped to ask for it. That's not a people problem. That's a structural problem. And structures can be fixed.

Good looks like pushback instead of guessing. Debt tracked openly instead of hidden in Slack channels. Proven tools instead of hand-rolled experiments. Load tests before launch, not after the first crash. Documentation that means any engineer can take over in a week, not two months.

That's what 15 years at Shopify and Brex taught me. Not how to type faster. How to say "stop" before the invoice hits six figures.

And here's what's changed. In 2026, one skilled engineer with AI agent-optimized workflows ships what used to take a 10-person team. The AI handles the typing: the boilerplate, the tests, the documentation, the monitoring setup. The engineer handles the judgment. The architecture decisions. The "should we even build this" conversations. The seven truths I just told you? A skilled engineer surfaces all of them before you have to ask. The AI makes them faster. The experience makes them right.

The "expensive" developer who flags problems early, pushes back on bad ideas, and builds foundations that last? That's the cheap option.

Give that developer AI agent workflows and they become unstoppable. Every founder figures this out eventually. The lucky ones figure it out from a video like this.

The Challenge

Go to your developer. Your agency. Your freelancer. Whoever is building your software right now. Ask three questions.

"What happens at 10x our current users? Show me the test."

"Show me exactly how passwords are stored."

"If you disappeared tomorrow, how does a new developer take over?"

If the answers are specific and confident, you're in good hands. If the answers are vague, defensive, or "we'll deal with that later," you have a problem. And now you know it.

The same gap that cost the Three Agency Client $100K. The same gap that turned a $50K build into a $200K rebuild. You can close it with three questions asked at the right time.

I've been the developer who didn't say it. I've been the advisor who found the damage. Now I'm telling you before either of those happens.

Key Takeaways

Developers fill gaps in vague requirements with assumptions, and they won't tell you when they're guessing. The incentive structure discourages asking clarifying questions because it makes them look incompetent and slows the project down. The result is a product built on guesses that surfaces as "that wasn't in the requirements" three months and $50K later.
Technical debt is invisible until it's expensive, and your developers have known about it for months. They talk about it in Slack channels you'll never see but won't surface it because it means admitting the shortcuts they took. A single database design flaw can spawn 14 workarounds, each one making the next one more expensive, turning a $50K build into a $200K rebuild.
"Working in development" is a completely different reality from "working in production." Ten fake users with clean data and perfect connectivity tells you nothing about what happens with 1,000 real users on mobile during a product launch. Without load testing, stress testing, and monitoring, you're flying blind, and the failures (like a 10% checkout failure rate) can bleed revenue for months before anyone notices.
Developer estimates underestimate by 3 to 5x because they price the happy path, not the iceberg. The visible feature is 20% of the work. Testing, edge cases, deployment, documentation, and maintenance are the other 80%. A healthy estimate splits roughly into thirds: coding, testing, and buffer for everything nobody wants to think about. If there's no buffer, it's a fantasy.
The structural fix is asking the right questions before writing the check, not trusting status updates after the check is cashed. "Walk me through what you're building step by step." "Show me how passwords are stored." "What happens at 10x users? Show me the test." "Show me three projects built with this exact stack." These questions test judgment, not skill, and the answers tell you everything.

Frequently Asked Questions

Why don't developers tell you when they don't understand the requirements?

The incentive structure works against transparency. Asking clarifying questions makes a developer look incompetent in front of a client who's paying them to be the expert. It slows the project down, which creates pressure on timelines and budgets. And it means admitting uncertainty, which most professionals in any field avoid. The result is that developers default to assumptions, filling in the gaps between what you said and what they heard with their best guess. This isn't malice. It's human nature combined with a project structure that punishes honesty. The fix is to build clarification into the process by requiring walkthrough demos and plain-English explanations at every milestone.

How can you tell if your codebase has dangerous levels of technical debt?

Three reliable signals: features consistently take 3x longer than they should, bugs keep reappearing in areas that were already "fixed," and your developers respond to every new feature request with "that's going to be complicated." If you ask your team "what would you rebuild from scratch?" and they light up with a list, that list is your technical debt inventory. The more specific and passionate their answers, the longer the debt has been compounding. A healthy codebase has some debt (that's normal), but the team should be able to add features without fear and deploy without dread. If deploying on a Friday feels dangerous, the debt has crossed from manageable to structural.

What is the real cost of a developer learning a new technology on your project?

A junior developer learning a framework on your project takes approximately 3x longer than a senior who has shipped 20 production projects with that same stack. On a $50K project, that translates to roughly $30K in wasted learning time, time that shows up on invoices as "architecture setup" or "technical complexity." The hidden cost goes beyond the hours. Decisions made while learning are fundamentally different from decisions made from experience. A developer learning React will structure components in ways that create technical debt a senior would never introduce. You're paying for their education and then paying again later to fix the patterns they learned wrong.

How do you prevent vendor lock-in with a single developer or small team?

Require three deliverables from day one: documentation, automated tests, and a deployment guide. Documentation means any engineer can understand the system within a week, not two months. Automated tests mean changes can be validated without the original developer's mental model. A deployment guide means anyone can ship updates without tribal knowledge. Ask your developer regularly: "If you disappeared tomorrow, how does a new developer take over? Show me." If the answer is ever "it's all in my head," you don't own your software. They do. Building these handoff artifacts into every milestone (not just at the end) prevents the hostage situation where one person controls whether your product keeps working.

What questions should non-technical founders ask their developers at every check-in?

Five questions that reveal everything: "Walk me through what you're building step by step, in plain English." (Tests whether they understand the requirements.) "Show me a working demo of what's done." (Prevents months of green status updates with nothing shippable.) "What's the riskiest part of what we're building right now?" (Forces them to surface uncomfortable information.) "What happens at 10x our current users?" (Tests whether they've thought about production reality.) "If this project needed to be handed to a new developer next week, how ready are we?" (Tests documentation and code quality.) Ask these at every milestone, not just at the end. The answers compound: good answers early prevent expensive surprises later.