Forem: Suhas Sunder

Why I Built 70+ Focused Timers Instead of One Big Timer

Suhas Sunder — Fri, 20 Feb 2026 18:42:20 +0000

I Built a Timer Site Because I Kept Needing Slightly Different Timers

I did not wake up one day thinking, “The world needs another timer website.”

I kept building timers because I kept needing them.

A clean countdown for presentations.

A fullscreen timer for workouts.

A silent timer that would not blast a notification.

A meeting timer that counts up instead of down.

A Pomodoro timer without clutter.

Every time I searched for one, it almost did what I wanted. Almost.

So I started building them myself.

That collection eventually became ilovetimers.com.

The Real Problem With “Just a Timer”

Timers sound simple.

Set duration.

Start.

End.

But real use cases are very different:

A classroom timer needs to be large and readable from across the room
A presentation timer must not make sound unexpectedly
A workout timer needs intervals and repeat cycles
A meeting timer often needs to count up, not down
A study timer should feel minimal, not distracting
A cooking timer needs presets and fast adjustments

One generic timer cannot serve all of those well.

So instead of building one bloated “super timer,” I built focused routes.

Each one solves a specific use case cleanly.

Focused Timers Instead of One Complicated Tool

The site now includes:

Countdown timer
Stopwatch
Pomodoro timer
HIIT timer
Tabata timer
EMOM and AMRAP timers
Presentation and classroom timers
Silent timer
Study and focus timers
Cooking, tea, and egg timers
Meditation and breathing timers
Speedrun and reaction time tools

Each page is intentionally simple and purpose-built.

No feature overload. No unnecessary UI.

Fullscreen Matters More Than You Think

One thing I learned quickly is that fullscreen support changes everything.

For workouts.

For classrooms.

For meetings projected on a screen.

A clean, distraction-free display is often more important than extra features.

So fullscreen behavior became a first-class concern instead of an afterthought.

Count Up vs Count Down

Another detail that kept coming up: people track time differently.

Some want:

“How much time is left?”

Others want:

“How long have we been going?”

That difference sounds small, but it completely changes the mental model.

So I built both countdown and count-up tools, including meeting-specific versions.

Timers Are Really About Context

The deeper I went, the more I realized timers are not about time.

They are about context:

Productivity
Focus
Rest
Training
Cooking
Study
Sleep
Presentations
Exams

That is why there are separate routes instead of one universal tool.

A workout timer should not look like a meditation timer.

A classroom timer should not behave like a chaos timer.

Beyond Timers: Clocks and Time Tools

Eventually it expanded beyond timers:

World clock
UTC clock
Analog and digital clocks
Binary and hexadecimal clocks
Fibonacci clock
Atomic clock
Golden hour and moon phase clocks
Time zone converter
Work hours and billable hours calculators
Military time converter

Because once you are working with time as a concept, the ecosystem grows naturally.

What Building This Taught Me

A few things surprised me:

Small UX details matter more than complex features.
Large readable typography beats decorative UI.
Silent mode is more important than people think.
Repetition patterns in workout timers require careful state handling.
Precision timing in the browser is not as trivial as it looks.

Timers are simple conceptually, but state management, edge cases, and real-world expectations make them interesting to build.

Why Build Instead of Just Use Existing Ones?

Because I wanted control over behavior.

When does it auto-reset?

Does it keep state if the tab refreshes?

Does it drift over time?

Does it behave consistently across devices?

Building my own forced me to define those answers.

And once you start defining behavior explicitly, you understand the problem space much better.

The Pattern Again

I keep noticing the same pattern in my projects:

I build small, focused tools around things I want to understand deeply.

MorseWords helped me understand parsing and boundaries.

ilovesvg helped me understand structured vector data.

ilovetimers helped me understand time handling, state, UX minimalism, and precision in the browser.

Building tools is how I explore systems.

If you build small utilities like this, what have you learned from them that you would not have learned just using someone else’s tool?

If you are curious, you can check it out here:

https://www.ilovetimers.com

I Built an SVG Toolkit Because I Needed to Actually Parse SVG Properly

Suhas Sunder — Fri, 20 Feb 2026 18:38:28 +0000

I Built an SVG Toolkit Because I Needed to Parse SVG Properly

SVG looks simple.

It is just XML.

It is just paths and shapes.

It is just vectors.

Until you actually try to manipulate it.

I built ilovesvg.com because I kept running into real SVG parsing problems while working on projects. Not theoretical ones. Practical, annoying edge cases.

I needed reliable SVG tooling. So I built it.

The Problem: SVG Is Simple Until It Isn’t

The moment you try to do anything beyond display an SVG, things get complicated:

viewBox does not match width and height
Inline styles override attributes
Paths contain transforms
Colors are defined in multiple places
Stroke widths behave differently under scaling
Files contain unnecessary metadata
Embedded raster images bloat file size

If you want to resize, recolor, clean, minify, convert, or extract dimensions correctly, you cannot treat SVG as just a static file. You have to parse it deliberately.

That is what pushed me to build proper tooling instead of relying on snippets.

The Core Idea

ilovesvg.com is not just a converter site.

It is a collection of focused SVG utilities built around one idea:

If you are going to manipulate SVG, you need predictable parsing and clear transformations.

Each tool solves one specific problem cleanly.

SVG → Raster and PDF

Sometimes you need vectors.

Sometimes you need a PNG for social, a JPG for legacy systems, or a PDF for print.

So I built dedicated routes for:

SVG to PNG
SVG to JPG
SVG to WebP
SVG to PDF

The goal was consistent rendering, not hoping a browser interprets it the way you expect.

SVG Utilities I Personally Needed

These came directly from real use cases.

Background editor

Many SVGs are transparent. Sometimes you need a white background. Sometimes you need a specific hex color.

Resize and scale editor

Scaling correctly means respecting viewBox, transforms, and stroke behavior.

Recolor

Changing fill and stroke values across nested groups requires structured parsing.

Minifier and cleaner

Removing metadata and unnecessary attributes without breaking structure.

Stroke width editor

Scaling strokes intentionally instead of accidentally.

Flip and rotate

Applying transformations without corrupting geometry.

Dimensions inspector

Understanding intrinsic width, height, and viewBox quickly.

File size inspector

Seeing what is actually contributing to weight.

Accessibility and contrast checker

SVG icons still need accessible contrast and structure.

These are not flashy features. They are practical.

SVG vs IMG and Embed Code

When should you inline SVG?

When should you use an <img> tag?

How should you embed for performance and styling flexibility?

That became its own route because the answer depends on how you plan to use the graphic.

Base64 Support

If you have ever embedded SVG in CSS or HTML directly, you have dealt with Base64 encoding.

So I added:

SVG to Base64
Base64 to SVG

Predictable in, predictable out.

Raster → SVG

Vectorization is another rabbit hole.

I added routes for:

PNG to SVG
JPG to SVG
WebP to SVG
Logo to SVG
Icon to SVG
Sketch, scan, and drawing to SVG
Image and photo outline extraction

These are controlled transformations designed for specific use cases.

The important part was handling structure consistently instead of just wrapping an image inside an SVG tag.

What Building This Taught Me About SVG

viewBox is everything.
Scaling without understanding stroke behavior causes visual bugs.
Inline styles complicate transformations.
Many SVG files contain unnecessary junk.
Clean parsing matters more than clever UI.

SVG is powerful because it is structured. But that structure only helps you if you respect it.

Why Build Instead of Use Existing Tools?

Because I wanted control over parsing behavior.

When you rely on black box tools, you cannot predict:

What gets stripped
What gets preserved
What gets rewritten
How transforms are applied

Building my own forced me to define rules explicitly.

That clarity carries over into every project where I manipulate SVG.

The Bigger Pattern

I tend to build tools around topics I want to understand deeply.

MorseWords helped me understand parsing and boundaries.

ilovesvg helped me understand SVG as a structured language, not just a file format.

Building small, focused utilities is one of the fastest ways to understand something technical at a deeper level.

If you work with SVG regularly, what has been your biggest pain point?

Parsing? Scaling? Cleaning? Converting?

You can check out the toolkit here:

https://www.ilovesvg.com

I Built a Morse Code Tool to Help Me Actually Learn It

Suhas Sunder — Fri, 20 Feb 2026 18:35:26 +0000

A while ago I decided I wanted to actually learn Morse code.

Not just recognize “SOS.”

Not just paste text into a translator.

But understand how it works, how it sounds, and how spacing really matters.

So I did what I usually do when I want to understand something better.

I built a tool around it.

That project became MorseWords, a small web app for translating, listening to, and practicing Morse code.

Why Build It at All?

Because building something forces you to understand the rules.

If you are writing the encoder, you have to define:

What exactly counts as a letter break?
What counts as a word break?
How should spacing be handled?
What happens when input is messy?

If you are writing the decoder, you cannot hand wave boundaries. You have to formalize them.

That process taught me more than simply using a translator ever would.

Text to Morse

The encoding side is intentionally predictable.

Input is normalized and uppercased
Each character maps to standard International Morse
Output formatting is strict
- 3 spaces between letters
- 7 spaces between words

Example:

HELLO WORLD

Becomes:

....   .   .-..   .-..   ---       .--   ---   .-.   .-..   -..

Spacing is part of the output. That detail matters more than I realized when I started.

Morse to Text

Decoding made me appreciate how important boundaries are.

The decoder reads chunks of dots and dashes and uses separators to decide where letters and words end.

Rules are simple:

1 to 6 spaces means a letter gap
7 or more spaces, a slash, or a new line means a word gap

If a sequence is not recognized, it becomes ?.

That choice was intentional. When you are learning, seeing mistakes clearly is useful.

Audio Made It Practical

Reading Morse visually is one skill. Hearing it is another.

So I added playback with:

Adjustable speed in WPM
Pitch control
Volume control
Repeat mode
Flashlight signaling

Being able to slow things down and gradually increase speed made practice much more engaging.

It stopped being just a translator and started feeling like a small training tool.

What I Learned

The most interesting part was not the interface. It was defining constraints.

Morse looks simple, but once you start formalizing:

Character maps
Spacing rules
Input normalization
Error handling

You realize how much structure is hiding under something that seems minimal.

Building it made the system clearer in my head.

And that was the entire goal.

If you are learning something new, building a small focused tool around it is underrated. You understand the edges, not just the surface.

If you are curious, the project is MorseWords

Building a Small Rent Conversion Tool

Suhas Sunder — Wed, 18 Feb 2026 14:04:53 +0000

I wanted a simple way to compare rent listings that are billed on different schedules (weekly, every 4 weeks, monthly, annual). A lot of tools online convert between these using shortcuts that work “well enough,” but break down when you compare values across multiple periods.

This started as a small personal utility, but it surfaced a few design and math issues that are easy to miss when building micro-calculators.

Choosing a Consistent Conversion Model

The biggest decision was how to handle time periods consistently.

Instead of chaining conversions (for example, weekly → monthly → annual), everything goes through a per-day rate:

1 week = 7 days
Biweekly = 14 days
Every 4 weeks = 28 days
1 year = 365 days
Average month = 365 ÷ 12
Hourly values derived from days × 24

This avoids small drift errors and makes conversions reversible. Weekly and 28-day rent can land on the same monthly equivalent if they imply the same daily rate, which is expected behavior when you normalize through a single base unit.

Input Handling and Rounding

Two things that took more time than expected:

Input parsing

People paste values with commas, currency symbols, and decimals. It’s easy to accidentally misread values or silently “fix” them in a way that changes the number. I ended up being strict about what’s accepted and surfacing errors instead of guessing.

Rounding

Rounding happens only at display time. All calculations keep full precision internally. This avoids small compounding errors when converting across multiple periods.

UX Decisions That Mattered

The tool is intentionally simple visually. The important part is that assumptions are visible:

How long a “month” is in the model
How 4-week periods differ from monthly billing
How the daily rate is derived

For anything dealing with money, hiding these details makes the numbers hard to trust.

The Result

The tool is live here:

https://www.rentconverter.com

It converts between daily, weekly, biweekly, every-4-weeks, monthly, hourly, and annual using a consistent day-based model and shows a full breakdown so listings billed on different schedules can be compared directly.

Takeaways for Small Utility Apps

A few things I’d carry into the next build:

Pick one canonical unit and normalize everything through it
Make assumptions visible in the UI
Keep rounding out of the calculation layer
Treat input parsing as a real feature, not a footnote
Add reversibility checks to tests (A → B → A should be stable)

💀 Introducing WordSkull: A New Word Game with a Fantasy Twist! 🏰

Suhas Sunder — Thu, 24 Oct 2024 20:55:36 +0000

💀 Introducing WordSkull: A New Word Game with a Fantasy Twist! 🏰

Hey devs!

I’m excited to share my latest project, WordSkull a light and fun word game with a fantasy inspired theme! The concept revolves around skull shapes that keep things playful and engaging, blending word puzzles with a touch of adventure. ⚔️

🔍 What’s WordSkull about?

I’m starting off with a few game modes inspired by popular word games like crosswords, spelling bee, Wordle, etc. These modes put a twist on the classics and are designed to offer a familiar but refreshing challenge to players who love word puzzles. It’s a light, engaging experience with a unique twist on game design.

🛠️ What's next?

I have plans to expand with more game modes down the line, including an indie-inspired mode I’m particularly excited about! This will bring a new dimension to the gameplay, and I can’t wait to bring it to life. 🎮

Wallpapers

I've also been working on sharing some 4k HD fantasy themed AI generated wallpapers which will soon be available on here.

🚀 I’d love your feedback!

What would you like to see in a skull-shaped word game with a light fantasy theme?
Any game mode ideas or unique twists you’d love to see?
Any feedback on the direction I’m heading with the core modes?
Is it actually fun?

While the repo for WordSkull is private, feel free to check out my open-source project, Emoji Kitchen Game, which uses a similar tech stack: GitHub Repo. You can also play the game here: Emoji Kitchen Game.

Thanks in advance for your thoughts and time! 💀🧙‍♂️

🍳 Emoji Kitchen Game: Create Fun Emoji Combos! (Open Source Project) 🚀

Suhas Sunder — Tue, 22 Oct 2024 06:10:26 +0000

Hey Dev.to community! 👋

I’m excited to introduce Emoji Kitchen Game — a fun and interactive web app where you can mix and match emojis to create unique and sometimes hilarious emoji combinations. 🎉 Whether you’re a fan of emojis or just looking for a creative coding project to contribute to, I’d love to share this open-source project with you!

GitHub Repo

Emoji Kitchen Game

What’s Emoji Kitchen Game? 🤔

Inspired by the Google Emoji Kitchen, Emoji Kitchen Game allows users to combine different emojis in playful ways. You can select two emojis and watch as they blend into an interesting hybrid. It’s a great way to bring a bit of fun and creativity to your daily emoji usage!

Here’s what you can do:

🖼️ Create combos of different emojis
📱 Share your creations with friends on social media
🔄 Play around with random combinations for some light-hearted fun!

Why I Built It 🎯

I built Emoji Kitchen Game as a side project to improve my learning skills and explore some new technologies in the process. By working on this project, I’ve been able to dive deeper into React, TypeScript, and the Canvas API, all while creating something fun and interactive!

🚀 Built With

This web app is powered by a modern tech stack to ensure a seamless experience:

Remix.run for server-side rendering and routing.
React for an interactive, component-driven UI.
Express as the backend engine.
Tailwind CSS for beautiful, responsive styling.
TypeScript to keep everything type-safe and clean.

🏆 Features

🧩 100,000+ Emoji Mashups: Mix two emojis and discover endless fun combinations.
⚡ Super Fast: Built with Remix for fast loads and dynamic routing.
🎨 Responsive Design: Works great on any device — mobile, tablet, or desktop.
🖼️ Unique Illustrations: Delightful and playful emoji mashup graphics, inspired by Gboard’s Emoji Kitchen.

Thanks for reading! 🎉