I Built a Tool Because I Was Tired of Overthinking Comments

I Built Commentto Because I Was Tired of Overthinking Comments

Most of the time, when I scroll through dev.to, I’m not looking for anything specific.

I read posts between tasks.

While waiting for something to build.

Sometimes when I should probably be doing something else.

And pretty often, I come across posts I genuinely like.

Good explanations.

Thoughtful write-ups.

Honest learning stories.

I want to support those writers. I want to leave a comment that actually means something.

But that’s usually where things slow down.

---

The friction I kept running into

Writing a thoughtful comment takes more energy than it seems.

Not because I don’t know what to say

but because I start overthinking how to say it.

Is this too generic?

Does this sound like something I’d actually write?

Am I repeating what others already said?

If I’m in a hurry, I’ll often do nothing instead.

Not because I don’t care but because the activation energy feels oddly high.

Over time, that started bothering me.

---

The idea that wouldn’t leave me alone

At some point, a simple question formed:

What if the hard part, phrasing, wasn’t manual every time?

Not in a “let AI comment for me” way.

But in a way that still felt like me.

I didn’t want generic praise.

I didn’t want overly polished responses.

I didn’t want something that sounded obviously automated.

I wanted something that:

• understood what I just read
• responded briefly
• matched how I usually write

That was the core idea behind Commentto.

---

What Commentto actually does (without the fluff)

At a high level, it’s simple:

• It reads the content of the page you’re on
• Summarizes what matters
• Generates a short comment in a specific writing voice
• All from inside the browser

No accounts.

No dashboards.

No long setup.

Click, generate, tweak if needed, move on.

It’s designed for moments when you want to engage, but don’t want to turn it into a task.

---

Building it felt different from most projects

I wasn’t trying to cover every case.

I wasn’t trying to make it impressive.

I was asking a quieter question:

Would I actually use this tomorrow?

That influenced a lot of decisions:

• keeping it lightweight
• avoiding unnecessary features
• focusing more on consistency than creativity
• making voice constraints explicit instead of vague

I learned quickly that “AI voice” isn’t about clever prompts.

It’s about clear boundaries.

The more opinionated the voice rules became, the more the output started to feel stable and familiar.

---

What surprised me once I started using it

The biggest surprise wasn’t speed.

It was how often it nudged me to engage when I otherwise wouldn’t have.

Not because the comments were perfect,

but because the friction was gone.

I still edit them.

I still decide whether to post.

But the blank page problem disappeared.

And that changed my behavior more than I expected.

---

A small part I didn’t expect to enjoy this much

One feature I added mostly out of curiosity was custom voices.

Instead of vague instructions like “be casual” or “be friendly,” each voice is defined by a few concrete rules: tone, sentence structure, and what it should avoid.

I started with a few defaults:

• neutral
• thoughtful
• curious
• direct
• funny
• “best friend”
• and one intentionally unhinged brainrot / gen-z mode

But once custom voices existed, I couldn’t resist experimenting.

I tried things like:

• pirate
• batman
• wizard
• master shifu

None of these are necessary.

Most of them are impractical.

But they made the project feel alive.

It reminded me that small tools don’t have to be serious all the time to be useful. Sometimes play is how you discover what actually matters.

If you try it and end up creating a voice that’s surprisingly good (or surprisingly bad (ˉ▽ˉ；)...), I’d genuinely love to hear about it.

---

A quick note on current limits

Commentto is intentionally small, but it’s built to be used.

Right now:

• it works best on long-form articles and blogs
• it doesn’t reliably handle platforms like LinkedIn yet
• and while the Chrome extension is production-ready, it isn’t listed on the Chrome Web Store

If someone is curious, it’s still plug-and-play. Load it once, and it behaves like a normal extension from there.

At the moment, the extension is loaded manually in developer mode and talks to the live API, which keeps iteration fast and avoids premature distribution decisions.

For now, that trade-off feels right.

---

What this project taught me

Building Commentto reinforced something I’ve been slowly learning:

Small tools don’t need big justification.

If they remove a specific, real annoyance, even a minor one, they earn their place.

But beyond that, this project taught me a few practical lessons I wouldn’t have picked up from a demo or tutorial.

Building across surfaces changes how you design

Because Commentto lives both as a browser extension and as a web app, I couldn’t treat the backend as an afterthought.

The API had to be:

• fast
• predictable
• tolerant of messy real-world input

That alone pushed me to think more carefully about request boundaries, truncation, and failure cases, things that don’t matter much until something is actually used.

---

Monorepos reduce friction when used intentionally

Early on, I noticed voice definitions and types starting to drift.

The fix wasn’t more discipline, it was structure.

Moving shared logic (types, voices, helpers) into a small monorepo setup made iteration calmer. Changes stopped feeling risky, and the system started behaving like one thing instead of two loosely connected apps.

It reminded me that architecture often exists to protect future clarity, not present convenience.

---

Explicit constraints beat clever prompts

One of the biggest technical surprises was how much better the output became once I stopped being vague.

Instead of asking the model to “sound casual” or “be thoughtful,” each voice was defined by concrete rules:

• sentence length
• tone boundaries
• things it should avoid saying

Reducing freedom in the right places made the system feel more consistent and more human.

---

Product friction is often architectural, not visual

None of the main problems I ran into were UI-related.

They were about:

• how data flows between extension and backend
• where logic lives
• how much responsibility each layer carries

That shifted how I think about “UX.”

Sometimes the smoothest experience comes from boring, well-defined internals.

---

Closing

I didn’t build Commentto to prove anything.

I built it because I was tired of caring and still staying silent.

Now I engage more often, with less effort, in a way that still feels like me.

That’s enough reason for me to keep using it.

Maybe it will be for you too.

Thank you for reading