DEV Community: Binay Kumar Das

I Thought Email Verification Was Just Sending an OTP. Building It Changed My Mind.

Binay Kumar Das — Tue, 01 Sep 2026 05:14:00 +0000

A few weeks ago, I added “Email Verification” to the FindCoffeeMate 2.0 backlog.
The plan in my head was simple.
User signs up.
Send an OTP.
User enters it.
Mark the account as verified.
Move on to the next feature.
As a frontend developer, I’d integrated email verification plenty of times before. The backend always looked straightforward from the outside.
Turns out, there’s a big difference between integrating a feature and designing one.
I got the happy path working in about an hour.
Sign up.
Receive the OTP.
Enter the code.
Account verified.
Everything worked exactly as expected.
I closed my laptop that evening thinking, “Nice. I’ll polish the UI tomorrow and call this feature done.”
Then, while I was lying in bed, one question popped into my head.
“What happens if someone clicks Resend OTP five times?”
Not because they’re trying to break the system.
Just because they’re impatient.
Honestly, I’d probably do the same thing.
Then another question followed.
If five OTPs get generated…
…which one should actually work?
The first one?
The latest one?
All of them?
I realized I hadn’t made that decision at all.
Whatever happened was happening by accident, not by design.
That bothered me more than the bug itself.
So I did what every developer promises themselves they won’t do.
I got out of bed.
Opened my laptop again.
(My family was not impressed.)
Instead of writing code, I opened a notes file and started writing questions.
What happens if someone keeps requesting new OTPs?
Should older codes still be valid?
How long should an OTP live?
What if Gmail delivers an older email after the newer one?
What happens if someone clicks a verification link after they’re already verified?
Is there anything stopping someone from spamming the resend button and burning through my email quota?
At some point I looked at that list and laughed.
My “simple” feature now had more edge cases than implementation.
That’s when something clicked.
I wasn’t building an OTP feature anymore.
I was designing a system.
Once I accepted that, the implementation became much clearer.
The first rule was easy.
Only one OTP should ever be valid.
If a user requests a new one, the previous code becomes useless immediately.
No guessing.
Become a Medium member
No multiple valid codes floating around.
Then I added an expiration time.
I settled on ten minutes.
Not because I found the perfect research paper proving ten minutes is ideal.
I literally opened a few apps, timed how long it took me to get distracted, come back, find the email, and enter the code.
Sometimes engineering is data.
Sometimes it’s just common sense.
The resend button needed attention too.
At first I almost ignored rate limiting.
I remember thinking,
“Who’s going to spam OTP requests on a coffee networking app?”
Then I caught myself.
That’s exactly how technical debt starts.
It’s much easier to add guardrails while the feature is small than after thousands of people start using it.
So resend requests are now rate-limited.
Finally, I handled already-verified accounts.
If someone clicks an old verification email after they’ve already verified their account, the system simply responds that the email is already verified.
No unnecessary database updates.
No confusing errors.
Just a predictable outcome.
None of these decisions were particularly difficult.
Figuring out that they needed to exist was the difficult part.
Working on FindCoffeeMate has changed how I think about software.
When I was mostly working as a frontend developer, my focus was naturally on the user interface.
Does the form validate?
Does the loading state look good?
Does the button work?
Building the backend has forced me to think differently.
As a full stack developer, I’ve started realizing that the experience users have is shaped just as much by API design, database rules, and edge cases as it is by the UI itself.
Somewhere along the way, I also found myself asking questions that I’d normally expect a Product Owner to ask.
“What happens if users do something unexpected?”
“What experience do we actually want them to have?”
“Can we make this impossible to misuse instead of documenting how to use it correctly?”
That’s probably the biggest lesson FindCoffeeMate has taught me so far.
Product Engineering isn’t just about implementing features.
It’s about thinking through all the situations your users should never have to think about.
The funny thing is that nobody using FindCoffeeMate will ever notice any of this.
And honestly, that’s exactly the outcome I want.
If everything works, users will sign up, verify their email in a few seconds, and immediately forget the feature even exists.
They’ll never know about OTP invalidation.
Or expiration times.
Or rate limiting.
Or the evenings I spent asking myself, “Wait… what happens if…”
All of that thinking stays behind the scenes.
That’s what good software should do.
It hides complexity instead of exposing it.
Dark mode is next on my backlog.
I’m telling myself it’ll only take an afternoon.
Let’s see if future me agrees.
P.S. This email verification system will be part of FindCoffeeMate 2.0. Building this product continues to teach me that the hardest part of software engineering usually isn’t writing the code — it’s asking the questions you didn’t know you needed to ask.

The Feature Had Zero Bugs. We Removed It Anyway

Binay Kumar Das — Fri, 21 Aug 2026 04:46:57 +0000

A few week ago, I am building a feature for my Product FindCoffeeMate.

It was called “Recently Active Developers.”

The idea sounded great.

When users landed on the homepage, they’d immediately see developers who were recently active on the platform. We thought it would encourage more profile visits, connection requests, and conversations.

From an engineering perspective, everything was done.

The API worked.

The UI looked clean.

The loading states were smooth.

There were no bugs.

It was ready to be part of the next release.

Then we paused.

Before moving on to the next feature, our team decided to use the app the way a new user would.

We landed on the homepage, explored a few profiles, searched for developers with specific skills, sent connection requests, and started conversations.

Only later did we realize something.

None of us had interacted with the “Recently Active Developers” section.

Not because it was broken.

We simply didn’t need it to accomplish what we came to do.

That small observation led to a much bigger discussion.

Were we solving a real user problem, or were we just adding another section because it looked like a good idea?

The more we talked about it, the clearer the answer became.

The feature worked exactly as intended.

It just didn’t make the product better.

So we removed it.

Deleting working code isn’t easy.

As engineers, it’s natural to become attached to the things we’ve built. Every feature represents hours of planning, coding, testing, and refining.

But keeping a feature simply because we’ve already invested time in it isn’t good Product Engineering.

Every feature has a cost.

It needs to be tested, maintained, documented, and supported as the product grows.

If users don’t get value from it, that cost never goes away.

Working on FindCoffeeMate has changed how I think as both a Frontend Developer and a Full Stack Developer.

Earlier in my career, I measured success by one question:

“Does the feature work?”

Now I ask a different one:

“Does this feature make the product better?”

That shift has also given me a deeper appreciation for how a Product Ownerthinks. The best product decisions aren’t always about adding something new. Sometimes they’re about having the confidence to say, “This doesn’t add enough value, let’s keep the product simple.”

The feature never reached production.

And honestly, I’m glad it didn’t.

It reminded me that users don’t care how much effort went into building a feature.

They care whether it helps them achieve what they came to do.

Sometimes the best feature you’ll ever build is the one you decide not to ship.

Building FindCoffeeMate: A Small MVP That Taught Me Big Lessons

Binay Kumar Das — Tue, 18 Aug 2026 14:20:43 +0000

As developers, we rarely run out of ideas.

What we often run out of is the right people to build those ideas with.

Over the years, I noticed a common pattern. Many developers had startup ideas, side projects, or products they wanted to build, but they struggled to find collaborators. Some needed a frontend developer, others needed a backend engineer, designer, or even a co-founder.

Finding the right people often felt harder than finding the idea itself.

Why Existing Platforms Didn't Help

Platforms like LinkedIn are great for networking and job opportunities, but they're not really built for finding people to build side projects with.

Developer communities are amazing for discussions and learning, but most conversations end there.

I felt there was a gap between knowing people and building something together.

That's what inspired me to build a small MVP called FindCoffeeMate.

Building the MVP

Instead of trying to build a huge platform, I focused on the basics.

The first version only included:

Sending connection requests

Accepting connections

Direct messaging

Sharing startup ideas and collaboration opportunities

My goal wasn't to build every feature I could think of.

It was to answer one question:

Would people actually use a platform designed to help builders find collaborators?

Technical Challenges

I built the MVP using React, Express.js, and PostgreSQL.

A few challenges showed up quickly:

Managing authentication and user state in React

Keeping the UI updated when connection requests changed

Designing APIs for user relationships and messaging

Creating a database schema that handled users, connections, chats, and collaboration posts cleanly

One bug that took longer than expected was a connection request issue. The database was updating correctly, but the UI wasn't reflecting the latest state. It turned out to be a frontend state management problem, not a backend issue.

Moments like these reminded me that debugging is often about questioning your assumptions.

What I Learned

The biggest lesson wasn't technical.

It was learning that shipping early is more valuable than endlessly adding features.

Real users provide answers that assumptions never can.

Instead of spending months perfecting the platform, I released a simple version, started collecting feedback, and learned from how people actually used it.

Final Thoughts

Building FindCoffeeMate reminded me that an MVP doesn't need to be perfect.

It just needs to solve one problem well enough to learn from real users.

As developers, it's easy to keep building forever.

Sometimes the best thing you can do is ship, listen, and improve.

That's exactly what this MVP taught me.

findcoffeemate - https://www.findcoffeemate.com
Want to know more about me - https://binaykumardas.github.io