DEV Community: superkacper4

How we created more tech debt in 6 months than in a 10-year-old system

superkacper4 — Wed, 28 Jan 2026 19:28:32 +0000

The original post

Table of contents

Introduction
The bad table
A little bit of context
Contrast
Summary

Introduction

Six months ago, we made a small, reasonable decision: we decided not to create a new database table.

Two entities in our system “looked similar enough”, so we put them into the same one.

Today, this single decision has created more technical debt than the 10-year-old system I work with every day.

This is the story of how that happened.

The bad table

Initially, our app had a simple concept of adding opinions to it. The schema looked more or less like this:

model Opinion {
  id         String    @id @default(cuid())
  building   Building? @relation(fields: [buildingId], references: [id])
  buildingId String?
  pricePerSquareMeter Int
  rating  Int?
  message String?
  area    Float
  opinionDate DateTime @default(now())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

As you can see, there are already properties that are clearly meant to be shared between apartments and opinions, like area, buildingId, or pricePerSquareMeter.

All was fine until we realized we lacked a few properties that are essential for the apartment entity. Since opinions and apartments could now also be added by registered users, we added a new relation for it. It was still great — we still had full coverage.

So we kept going. After a while, we realized that we lacked such a basic field as numberOfRooms.

So we added that. Then we added floor. Then height. It's not like they can't exist in the opinion entity. It's just something that wouldn't make any sense from the business perspective.

After a while, we ended up with many ?. across the whole app, as half of our table had optional properties.

From the data perspective, it was such a mess that we ended up with an isApartment flag inside the Opinion table. 🙃

What was also very bad, from the code perspective, was that it was not that clear when an Opinion was actually an apartment and when it was just an opinion.

This created huge tech debt, but the sad part is that for a very long time it seemed like this decision was reasonable. But as time passed, it became more and more clear that this was a bad decision.

A little bit of context

The app I am referring to is a Next.js monolith app. It's only around 6 months old, but it's a ready product, with even external integrations with payments. It's not a super complex app, but it's definitely not a trivial one either.

The idea was to create a place for people to exchange their opinions and prices related to the real estate market, so it would help with decision-making. Something like Glassdoor, but for real estate. That's why we already had the Opinion table when we decided to add the ads part.

Contrast

Recently, we were working on a new feature in a 10-year-old app - vouchers. We started, as usual, with the monolith app, so everything was packed into the app's database.

But then we realized that sooner or later this would require external integrations handled by our Marketplace (a set of microservices). So instead of continuing, we stopped. We took a step back and moved the whole logic to a dedicated service.

It was more work. It delayed us. But now we have a single source of truth.

What was learnt

I realized that tech debt is not something that just appears out of nowhere. It's something that we create every single day.

It's not about being lazy, not having time to refactor, or choosing some exotic stack. It's about making decisions that seem reasonable, but then snowball into something much worse.

Every single TODO: Will refactor it later., or "These two look similar enough, let's make them share logic" (and you end up with many ifs).

Summary

I just want to encourage you to think more about technical debt and realize that it's something you (and I) bring into the project every single day.

It's not just something left behind by people who no longer work there. It's on me. It's on you.

One day, you may find that the 💩 code you are trying to debug was written by you.

Stay strong and be positive! 💪

To comment, you can use the Issues tab on my project, or comment in the thread (if this post was posted on Reddit, X, or anywhere).

Developers VS Product Sense

superkacper4 — Tue, 30 Dec 2025 13:29:37 +0000

(The original post)

Table of content

Intro
What is product sense interview about?
Why they struggle there?
Is it even an actual issue?
How to start your "workout"?
Summary

Intro

We are a small product company in the process of hiring developers. The idea was not only to hire people who can code but also those who can bring a deeper look at the product, not just the "It was like that on Figma" approach.

So we are trying to hire some devs. Many of them are really strong when it comes to technical stuff. Some of them are so good, I feel dumb 😐

But from what I’ve noticed, many devs have a problem with the last interview — the product sense interview.

Before we go further, I don’t think every single dev should have this skill — it’s about what we need and what I noticed across a few hiring processes.

What is product sense interview about?

Mostly, it focuses on how you see web apps and websites around you. It’s really not that complicated, as we are not forcing you to create some product strategy from scratch. It’s more about naming what you like in your favourite app, what you dislike, and how you would improve it. Doesn’t sound that bad, right?

Turns out differently, though. Many devs fail in the last stretch, and here I’d love to dive deeper into that.

Why they struggle there?

I guess there isn’t any easy answer for that. But from what I’ve noticed, many devs are really focused on the technical side of things. They love coding, and they love solving problems with code. But when it comes to thinking about the product as a whole, they often struggle to see the bigger picture.

Obviously, in bigger tech companies, it doesn’t have to be a problem. They are really good at what they do, and there are plenty of other people taking care of designing, planning, etc. In our case, it’s a little bit more complicated, as we are a small team and everyone needs to wear multiple hats.

Even in my example, as a Fullstack dev, I have to take care of Jira tickets, GitHub CI, or sometimes even participate in customer interviews.

Is it even an actual issue?

It depends 😜 Obviously, I wouldn’t be surprised if you’ve already been working for X years and have never bumped into this problem. Definitely, there is — and for quite some time there will be — a place for coders (we can argue about what AI will do here, but I don’t like to play magician, so 🤷‍♀️).

But if you would ever consider moving into management roles, you should start thinking more about the product. That doesn’t mean you have to think less about code.

Even if you don’t care about management and just want to write code, I think it may still help you to start training this muscle — it won’t hurt you.

And here I’ll try to quickly convince you why:

Bigger input to your team — If you can think about the product, you can bring more value to your team. You can suggest improvements, help with prioritization, or even just throw ideas. This will make you a more valuable team member and may open up new opportunities for you.
Growing inside your team — It obviously connects with the first point. The more you do beyond coding, the more valuable you become to your company — and the better your chances for a raise or avoiding layoffs.
Better ideas and execution of your side projects — To be honest, this is the most important one for me. I love working on my side projects, and I guess we all do. If you can think about the product, you can create something that people actually want to use and execute it better.

How to start your "workout"?

Just take a look around you. You certainly use many apps every single day. Look at them, think about what you like in them, and what annoys you. So right after saying “I hate this app”, add one more step and think why. Is it slow? Or maybe the UI is trash (what exactly in the UI pisses you off)?

I wouldn’t say it’s much, is it? And maybe it will even inspire you to create a great new side project — just because you noticed how bad the current one you use is.

Think about it as just a different set of problems to solve, with different tools. Now you’re not solving an algorithmic problem with code. Instead you’re trying to figure out how to make the UX better, within the technical limitations you have. It’s still the good old problem-solving we all love, just with different tools.

Summary

I want to add a final thought here. I highly recommend starting the "workout," as it’s really for free. Now, when the whole AI thing is happening, it won’t hurt. It may even help you gain a new advantage on the market or open up new possibilities for you.

Stay strong and be positive! 💪

To comment, you can use the Issues tab on my project, or comment in the thread (if this post was posted on Reddit, X, or anywhere).