5 Red Flags Your "Developer" Is Actually Building Technical Debt

Technical debt isn’t just “messy code.”

It’s:

• Slower features
• More bugs
• Late nights
• Failed launches
• And eventually, “We have to rewrite this” conversations

If you’re a non-technical founder, you can’t see the code.
But you can see the patterns.

Here are 5 red flags that your “developer” is quietly building a future disaster.

---

Red Flag #1: “We’ll Fix It Later” Is the Default Answer

What you hear

Any time you ask:

• “Can we handle X case?”
• “What happens if Y fails?”
• “Will this work when we have more customers?”

You get some flavor of:

“Yeah, we’ll refactor that later.”
“We’ll make it scalable once we have traction.”
“Let’s not over-engineer this.”

Once or twice? Fine.
If this is the default response, you’ve got a problem.

What’s actually happening

• Corners are being cut with zero plan for paying them back.
• The dev is optimizing for:
  • speed
  • demo-ability
  • short-term dopamine

Future-you is getting handed the bill.

What to do

• Start asking:
  • “What exactly are we deferring?”
  • “What would it take to do this in a way we don’t have to rewrite immediately?”
• Bring in an architect or senior engineer to review the approach, not just the UI.

If “later” is never written down, never sized, and never scheduled,
it means “never.”

---

Red Flag #2: No One Can Explain the Data Model in Plain English

What you see

You ask:

• “Where does X live?”
• “What’s the source of truth for Y?”
• “How do we know which Z belongs to which customer?”

You get:

• A five-minute ramble full of tables, ORMs, and jargon
• Or worse:

  “It’s kind of spread around, but it works.”

Why this matters

If nobody can explain:

• What the core entities are
• How they relate
• Which system owns what

Then:

• Reporting will be a nightmare
• Integrations will be fragile
• Migrations will be hell
• Compliance/audit will be painful

Technical debt loves a fuzzy data model.

What to do

• Ask for:
  • A simple diagram of core entities and relationships
  • A clear definition of:
    • “This is the source of truth for X”
• If they resist doing this, or it turns into a mess,
  you’re not building a product — you’re building a trap.

Bring in someone senior to audit the data model before you scale.

---

Red Flag #3: Everything Is “Hard to Change”

What you notice

You ask for:

• A small tweak to a workflow
• A minor change to pricing logic
• A simple modification to a form

And the answer is always:

“That’s going to be a big change.”
“That touches a lot of places.”
“We didn’t design it to do that.”

Once in a while is normal.
Every time is a smell.

What’s going on

The system is tightly coupled:

• Logic scattered across many places
• No clear separation between:
  • UI
  • business rules
  • data access
• Changing one thing risks breaking ten others

Which means:

• Releases get slower
• Bugs increase
• Everyone becomes terrified of touching the code

What to do

• Ask:
  • “Why is this so hard?”
  • “What would have to change for this to be easier in the future?”
• If the answer is always:
  • “That’s just how it is,”
    you’re watching technical debt calcify.

Get an architectural review before “hard to change” turns into “impossible to change.”

---

Red Flag #4: No Tests, No Monitoring, No Safety Net

What you hear / see

• No automated tests
• No staging environment
• No monitoring or alerts
• “We’ll know if it’s broken because customers will email.”

Deploys feel like:

• “Everyone cross your fingers.”

Why this is lethal

Without:

• Tests
• Staging
• Monitoring

You can’t:

• Refactor safely
• Move fast without breaking things
• Detect subtle regressions

So devs start avoiding improvement and cleanup, because:

“Every change is risky.”

That’s technical debt with a bomb strapped to it.

What to do

Minimum bar you should demand:

• Some level of automated testing around core flows
• A non-production environment to test changes
• Basic monitoring:
  • errors
  • latency
  • key business metrics

If your dev resists all of this, they’re building a house of cards.

---

Red Flag #5: No Documentation, No Diagrams, No Written Decisions

What you experience

• Every explanation is verbal
• No architecture diagrams
• No README or system overview
• No record of “why we chose X over Y”

And often paired with:

“It’s all in my head.”

Why this matters

If everything lives in one person’s head:

• You’re locked in to that person
• Onboarding new devs will be slow and painful
• You can’t challenge or review past decisions
• A single departure can cripple the product

This is organisational technical debt.

What to do

• Require:
  • A short system overview document
  • A basic architecture diagram
  • Notes on key decisions (even bullet points)
• If the dev behaves like:
  • “Writing things down is a waste of time,”
    you’re not building a team or a company—
    you’re renting a wizard.

---

Why Developers Build Technical Debt (They’re Not All Villains)

Most devs building technical debt are not malicious. They’re:

• Under time pressure
• Rewarded for shipping, not for architecture
• Lacking mentorship
• Copying patterns they’ve seen elsewhere

Common root causes:

• You only ever ask “When will it be done?”
  So they cut corners.

• Nobody senior defined standards or architecture.
  So they improvise.

• They’ve never seen a long-lived system.
  So they don’t appreciate compounding pain.

You still have to fix it.
But don’t assume it’s all laziness or ego.

---

Early vs Late Detection: The Cost Curve

You want real numbers? Here’s the pattern:

• Catch a structural problem in design:
  • Maybe a few days to fix
• Catch it in initial implementation:
  • Weeks to fix
• Catch it once you have paying customers:
  • Months to fix
  • With real risk and pain

I’ve seen:

• A rushed data model that saved a few weeks up front
  turn into:
  • a 6–12 month migration
  • ugly downtime risk
  • huge engineering distraction later

That's the compounding effect of technical debt.

---

What to Do When You See These Red Flags

1. Don’t panic, but don’t ignore it

• You don’t have to fire anyone immediately.
• You absolutely should not keep pretending everything’s fine.

2. Get a code and architecture review

Bring in:

• A senior architect
• Or an external expert you trust

Ask them to:

• Review:
  • data model
  • key flows
  • deployment and testing setup
• Give you:
  • a plain-English risk assessment
  • a prioritized list of “must fix” vs “nice to fix”

3. Create a tech debt backlog

For each issue:

• What is it?
• Why does it matter?
• What’s the impact if we don’t fix it?
• Rough effort to remediate

Then dedicate real time (not scraps) to paying it down.

4. Change incentives

• Ask about:
  • safety
  • testing
  • maintainability
  • not just “is it done?”
• Praise:
  • simplifications
  • refactors
  • time spent reducing complexity

If you only reward feature output, you'll always get more debt.

---

Prevention: How to Avoid Hiring a Technical-Debt Machine

In interviews, don’t just ask:

“What stack do you use?”

Ask:

1. “Tell me about a time you had to clean up a messy system.”

   • Good answer:
     • Talks about tradeoffs
     • Mentions tests
     • Mentions migration strategies
   • Bad answer:
     • Blames previous devs exclusively
     • Flexes about rewrites without explaining risk

2. “How do you decide when to take a shortcut vs do it the right way?”

   • Good answer:
     • Mentions:
       • timelines
       • risk
       • future impact
       • communication with stakeholders
   • Bad answer:
     • “I always build it perfectly”
     • or “We can always fix it later”

3. “How would you document a system for the next person?”

   • Good answer:
     • Mentions:
       • diagrams
       • READMEs
       • inline docs where it matters
   • Bad answer:
     • “Good code is self-documenting.”

4. “How do you feel about tests?”

   • Good answer:
     • Pragmatic but serious about testing critical paths
   • Bad answer:
     • “Tests slow you down, I test manually.”

5. “What worries you about technical debt in a startup?”

   • Good answer:
     • Understands the balance between speed and survivability
   • Bad answer:
     • “We’ll deal with that once we’re big.”

---

Final Word

You don’t need to read code to know when technical debt is piling up.

You just need to pay attention to:

• How hard everything is to change
• How much is “in someone’s head”
• How often “later” is the answer
• How allergic your team is to tests, docs, and diagrams

If you see those red flags:

• Don’t wait for the rewrite crisis.
• Get an architect-level review.
• Start paying the debt before it owns you.

Because it will own you if you let it.

---

Context → Decision → Outcome → Metric

• Context: Consulting engagements where founders hired developers, saw red flags (everything hard to change, no tests, no docs), but waited too long to address structural problems.
• Decision: Developed a red-flag checklist for non-technical founders: "fix it later" as default, fuzzy data models, change resistance, no safety nets, nothing documented. Catch these early.
• Outcome: Founders who got architectural reviews before scaling avoided the worst outcomes. Those who waited faced 6-12 month migrations and near-rewrite scenarios.
• Metric: Early intervention (design phase) = days to fix. Post-launch intervention = months to fix. Multiple clients avoided $300K-$500K rewrites by catching issues in the first 6 months.

Anecdote: The "We'll Fix It Later" That Became a $400K Rewrite

In 2021, I did a code review for a startup. They had a working MVP, paying customers, and a developer who'd built the whole thing.

The data model was a disaster. Customer data was scattered across five tables with inconsistent relationships. The developer's answer to every question: "We'll fix that once we scale."

I flagged the problem. They decided it was too early to worry about.

Eighteen months later, they called me back. They'd grown 10x. The data model was now a ball of spaghetti that couldn't be untangled. Every new feature took three times longer than it should. Their developer had burned out and quit.

The rewrite estimate: $400K and 8-12 months. The "fix it later" from year one had become the defining constraint of year three.

Anecdote: The Founder Who Asked the Right Question

In 2020, a founder called me before hiring her first developer. She said: "I don't know how to read code, but I've heard horror stories. What should I watch for?"

We talked through the red flags. She started asking her developer candidates: "Tell me about a time you cleaned up a messy system. How do you decide when to take a shortcut? How would you document this for the next person?"

She hired someone who gave good answers. A year later, I did a review of their system. Clean data model. Tests on critical paths. Basic documentation. Reasonable architecture.

Was it perfect? No. But it was maintainable. The founder's ability to spot red flags early—without reading code—had saved her from hiring a technical debt machine.

Mini Checklist: Red Flag Detection for Non-Technical Founders

• [ ] Watch for "we'll fix it later" as the default answer to structural questions
• [ ] Ask for a simple data model diagram; if they can't explain it in plain English, worry
• [ ] Notice if every change is described as "hard" or "touches a lot of places"
• [ ] Require some automated tests, a staging environment, and basic monitoring
• [ ] Demand a short system overview document and architecture diagram
• [ ] Get an architectural review before you scale, not after problems emerge
• [ ] Create a tech debt backlog: what is it, why does it matter, rough effort to fix
• [ ] Change incentives: praise simplification and cleanup, not just feature output