How Does Technical Debt Pile Up? — Looking at “Just for Now” Examples (Structure Edition)

Hey folks!

Sometimes I think bugs love me too much — they just keep coming back no matter what I do 🐛❤️
Anyway, I’m @nyaomaru, a frontend engineer.

👉 Previous article

In that article, I introduced what technical debt is.
This time, let’s dive into how those “just for now” decisions actually accumulate — with a practical, code-based look.

Ready? Let’s go! 🚀

💸 The Process of Accumulating Debt

Very few implementations start out dirty. With reviews and decent quality gates, you can catch a lot.

But debt creeps in through small cracks, like:

• The system grows in scale
• Patches pile up during feature additions
• Old code gets misread or misused
• No one bothers to abstract or generalize

Each by itself seems harmless, but combined they cause debt to grow exponentially.

This time, let’s look at scale growth — using Vue as an example.

📦 Scale Growth

One classic case: directory structures slowly collapsing.

Take an Atomic Design–based component setup, for instance.

⚠️ Disclaimer: Atomic Design itself isn’t the villain.
It works fine if responsibilities are clearly separated.
But when you try to apply it everywhere, things go sideways.

🧱 The Good Old Days…

At first, everything was clean:
atoms had buttons, molecules had form groups, organisms had whole forms. Beautiful.

components/ ├── atoms/ │ ├── Button.vue │ ├── Input.vue │ └── Label.vue ├── molecules/ │ ├── InputGroup.vue │ └── RadioGroup.vue └── organisms/ ├── LoginForm.vue └── RegisterForm.vue 

Justice back then: “Sort by granularity!”

🧟‍♂️ But Then: Survival-Driven Compromises

• “Just for now” → a login-only button sneaks into atoms/
• “Close enough” → Input.vue overloaded with 7 props + extra hacks
• “Looks reusable” → LoginFormWithSocial.vue shoved into organisms/

components/ ├── atoms/ │ ├── Button.vue │ ├── ButtonBlue.vue │ ├── ButtonBlueSm.vue │ ├── ButtonWithLoginIcon.vue │ ├── Input.vue │ └── Label.vue ├── molecules/ │ ├── Form.vue │ ├── FormVer2.vue │ └── FormVer2Copy.vue └── organisms/ ├── LoginForm.vue ├── RegisterForm.vue └── LoginFormWithSocial.vue 

Before you know it: classification collapse

• atoms/ = “looks simple-ish” bucket
• molecules/ = graveyard of misfits
• organisms/ = pile of unrelated monsters

☠️ Root Cause of Debt: Structure Loses to Speed

• Justice (Atomic Design) wasn’t enforced, so it was broken at will
• No naming rules or classification guide → inconsistency everywhere
• Soon: “Wait, what was this file for again?” — no one dares touch it

✅ Lesson: Structure Must Be Reviewed Regularly

• Enforce rules with CI (e.g., block atoms/ from importing features/)
• Treat directory layout itself as part of the design
• Expect categories to rot within 6 months if left unchecked

🧱 When “Atoms” Absorbs Everything

Atoms were supposed to be reusable UI parts.
But gradually, generic UI and domain-heavy components got mixed together.

📌 Ideal Separation

Atomic Design focuses on UI granularity — not domain separation.
So recently, a responsibility-based split (ui/ vs features/) is becoming popular, close to Feature-Sliced Design.

components/ ├── ui/ ← Generic reusable UI (buttons, modals) │ ├── Button.vue │ └── Modal.vue ├── features/ ← Domain-specific UI (business logic included) │ └── transaction/ │ ├── TransactionStatusBadge.vue │ └── TransactionActionButton.vue 

Idea:

• ui/ = polished, reusable, domain-agnostic
• features/ = business-context-bound, with logic and constraints baked in

🧟‍♂️ But Reality: Mix at Your Own Risk

😱 Actual structure that often emerges:

components/ ├── atoms/ │ ├── Button.vue │ ├── ButtonForOrder.vue ← 🤔 domain-specific but placed here? │ ├── Modal.vue │ ├── TransactionStatusBadge.vue ← 🤔 looks generic, but logic is domain-bound │ └── ConfirmDialogWithReason.vue ← references customer IDs, business logic galore 

What happens:

• “Looks like UI” → tossed into atoms/ even if domain-bound
• Later devs assume atoms/ = safe reusable pieces → specs break
• No culture of making features/ → everything looks “common”

☠️ Root of Debt: The Illusion of Reusability

• Generic-looking code can still be domain-tied
• If atoms/ contains “customerId” or “orderStatus,” it’s already features/

✅ Lesson: “Reusable” ≠ “Put in Atoms”

• Judge by responsibility, not just looks
• Split ui/ and features/ early — or regret later
• Remember: Atomic Design = UI granularity design, not business logic design

👉 Simply being aware of the boundary between reusable UI and domain-tied UI cuts debt massively.

📦 Wrap-Up

Component architecture needs an initial plan.
But it’s not final — orgs must revisit structure as the product evolves.

Ignore this, and your “Atomic Design” turns into a monster.
Eventually, it’s either unfixable or costs a fortune to repair.

So: review structure regularly, keep it healthy, and keep development enjoyable.

Perfection isn’t possible — but recovery is! 💪

✅ Homework: check your project’s atoms/ today. If you see domain logic creeping in, fix just one thing.

This article focused on Vue, but React and other stacks face the same structural debt traps.

👉 Next time: feature additions and overlapping refactors, explored with React. Stay tuned!

✂️ That’s the gist!

Technical debt doesn’t appear out of thin air — it sneaks in through small “just for now” compromises.

This time we looked at structural drift, especially around Atomic Design gone wild.

Have you seen your own project’s atoms/ or molecules/ slowly turning into junk drawers?
Share your horror stories or survival tips in the comments — I’d love to learn how your team fights debt!