Users Need to Be Able to Reply

How a “Small” Comment Feature Turned Into a 38-Hour System Design

“Users need to be able to reply.”

That was the ask.

Before that sentence, I genuinely thought this was easy.

Add a column. Link it. Done. Maybe half a day.

After that sentence?

It became a full commenting system rewrite - designed, implemented, and validated by one developer, with no QA, no business analyst, no UI/UX, and no one to bounce ideas off except my own rubber duck.

This post is the reality behind that request.

The Actual Ask (Verbatim)

Admin – Blog > Comments List Page

1. Insert a new “Blog” column between Email and Comments
2. Display the blog title
3. Blog title should be:
4. Underlined
5. Clickable
6. Opens the blog in a new tab
7. Rename column “Show Comments” → “Publish”
8. Should be able to edit comments

Public Blog Page

1. All published comments appear at the bottom with:
2. Date & Time
3. Name
4. Comment
5. Any user assigned to the blog should be able to reply
6. Replies should display in a nested UX, showing:
7. Date & Time
8. Author name

On paper, that sounds… reasonable.

In practice, it explodes.

Why This Was Never “Just Add a Column”

The moment you say “reply”, you are no longer dealing with a flat list.

You’ve introduced:

1. Parent–child relationships
2. Nesting rules
3. Ownership
4. Edit history
5. Deletion strategy
6. Public vs admin behavior
7. Validation
8. Sanitization
9. Data integrity
10. UX assumptions that were never documented

And none of that existed before.

There was no:

1. Comment hierarchy
2. Edit tracking
3. Soft delete
4. Cascade delete
5. Reply fetching
6. Nested rendering
7. Ownership validation

So before a single UI change could safely exist, the entire backend had to grow up.

What Actually Had to Be Built

I ended up writing a full implementation plan - not because I wanted to, but because without one, this turns into production debt instantly.

1. Data Model Changes

Comments needed to understand:

1. Who their parent is
2. Whether they were edited
3. Whether they were deleted
4. When those things happened

That meant new fields, defaults, indexes, and backward compatibility so existing comments didn’t break.

2. Repository Layer (Where Reality Lives)

This is where “reply” becomes expensive.

We needed:

1. Create replies
2. Fetch replies
3. Fetch comments with replies
4. Edit comments and replies
5. Delete comments with cascade
6. Soft delete everything
7. Update existing queries so deleted replies don’t magically reappear

Aggregation pipelines. $lookup. Filters everywhere.

One missed condition = ghost comments in prod.

3. Service Layer (Where Rules Live)

This is where things get political:

1. Can you reply to a deleted comment? (No.)
2. Can you edit someone else’s comment? (Depends.)
3. What happens if the email doesn’t match?
4. What if it’s admin vs public?
5. What if the content includes HTML or scripts?

Everything needed:

1. Validation
2. Ownership checks (email-based, because there’s no auth yet)
3. DOMPurify sanitization
4. Explicit error messages

This is where bugs hide if you rush.

4. Middleware & Validation

Because letting raw input through is how you end up on Hacker News for the wrong reason.

1. Email validation
2. Character limits
3. Proper Zod error handling (no more JSON.parse(error.message) hacks)
4. Consistent behavior across create, update, reply

5. Controllers (Public + Admin)

New endpoints everywhere:

1. Create reply
2. Edit comment
3. Edit reply
4. Delete comment (with replies)
5. Delete reply
6. Fetch replies
7. Fetch comments with nested replies

All with:

1. Consistent response formats
2. Blog existence checks
3. Optional ownership enforcement
4. Zero UI assumptions baked into the backend

The Irony

The original visible change?

“All published comments should appear at the bottom with replies.”

That’s the last thing that gets built.

Everything before it exists purely so that sentence doesn’t turn into:

1. Broken data
2. Security issues
3. Impossible edge cases
4. A rewrite six months later

Time Reality Check

This wasn’t a “small enhancement.”

It was 29–38 hours of work:

All planned and executed solo.

No QA safety net.

No BA clarifying edge cases.

No UX deciding nesting rules.

Just engineering judgment.

The Takeaway

When someone says:

“Users need to be able to reply.”

What they’re really asking for is:

1. A hierarchy
2. A lifecycle
3. A moderation model
4. An ownership model
5. A deletion strategy
6. A future-proof design

Replying is not a feature.

It’s a system.

And systems don’t come from “just add a column.”

They come from slowing down, thinking properly, and building it once - correctly.

That’s what this was.

And just when I thought the nightmare was over, I remembered… this isn’t even visible yet. This glorious 38-hour backend microservice masterpiece now has to be wired into two separate frontends, the customer-facing UI and the merchant-facing UI-two completely separate repositories, two separate builds, two separate sets of edge cases, and yeah, guess who’s doing it all solo. And if anyone dares say, “but you have A.I., bro”… I’ll flip a table so hard it’ll hit the next dimension. A.I. can generate code, but it can’t feel the existential terror of integrating replies and edits into multiple frontends while maintaining sanity.