DEV Community: Funny

I Thought I Was Building One 2048 Game. It Turned Into Three.

Funny — Mon, 17 Aug 2026 04:38:20 +0000

I originally only wanted to make one small browser game.

The idea was simple: keep the familiar rules of 2048, but replace the numbered tiles with cupcakes.

I have always liked how little explanation 2048 needs. You open it, move a few tiles, and within seconds you understand what is happening. The original 2048 project is a good example of how far a simple game mechanic can go without needing much around it.

What I wanted to change was not the rule itself, but the feeling of progression.

Instead of watching 2 become 4, then 8, then 16, I wanted one cupcake to turn into another cupcake, and eventually into something much more elaborate.

That became 2048 Cupcakes.

At that point, I wasn't thinking about reusable architecture or building a collection of games. It was just one page.

Most of my time went into things that looked small from the outside: getting tile movement to feel right, making merges easy to read, handling swipes properly on mobile, saving the board, and making sure the game still felt comfortable at different screen sizes.

None of those things were especially difficult on their own.

There were just a lot of them.

The second version changed the project

Once the cupcake version was working, I had another idea.

What if the same game used Doge images instead?

My first instinct was to copy the project, replace the artwork, change a few strings, and move on.

I almost did that.

Then I looked at what I would actually be copying:

movement logic
merge rules
score calculation
keyboard controls
touch controls
animations
game-over detection
local saving
sound
hint logic

Almost everything would remain the same.

Only the images, names, and presentation were really changing.

That was the point where I stopped thinking of it as one cupcake game and started separating the game itself from the theme.

The core does not need to know whether a tile represents a cupcake, a dog, a princess, or a number.

It only needs to understand the board.

A tile has a value. Tiles move. Matching values merge. The score changes. A new tile appears. Eventually there may be no legal moves left.

Everything visual can sit somewhere else.

Once I had that separation, Doge 2048 became much easier to build.

The game logic stayed almost untouched. I could focus on the Doge progression, the images, and how the theme felt instead of rebuilding the mechanics.

Then I tried a third version: Princess 2048.

That was probably the moment I knew the separation had actually worked.

By the third theme, adding another game was no longer mostly a programming task. Most of the work had moved toward artwork, progression, naming, and presentation.

What started as one page had quietly become a small themed 2048 collection.

I didn't want a backend just because I could build one

Another decision I kept throughout the project was to avoid adding a backend unless there was a real reason for one.

A game like this needs to remember a few things:

the current board
the score
the best score
the number of moves
sound preferences
display preferences

It would be possible to create accounts, authentication, an API, and a database to save all of this.

But I couldn't find a good reason to ask someone to register just so a 4×4 board could survive a page refresh.

The browser already gives us localStorage, so that is enough for the current version.

The tradeoff is obvious: progress stays in that browser instead of following the player across every device.

For this kind of game, I am comfortable with that.

Someone can open the page and start playing immediately. There is no login form and no network request required just to restore a game.

It was a useful reminder that more infrastructure does not automatically mean a better product.

Touch controls were more annoying than expected

Keyboard controls are easy.

An arrow key gives you a direction. WASD does the same thing.

Touch input sounded equally simple at first.

Record where the finger starts, record where it ends, work out the direction, and move the board.

In practice, it needed much more tuning.

If the swipe threshold is too low, an ordinary tap can become an accidental move.

If the threshold is too high, a deliberate short swipe feels like the game ignored you.

Diagonal movement also needs to be interpreted in a predictable way, and mobile browsers have their own scrolling behavior that can conflict with the game.

It made me think more about the difference between something being technically correct and something feeling correct.

The board can move exactly as the code intended and still feel bad to play.

That kind of detail ended up mattering more than adding another large feature.

The move guide became its own little problem

Later, I started experimenting with a move guide.

The naive approach is easy: test the four directions and choose whichever move gives the highest immediate score.

It is also not very good.

A move that creates a nice merge right now can leave the board in a terrible position two or three turns later.

So the guide needs to care about more than the next score.

Things like empty spaces, board smoothness, where the largest tiles sit, and how many future moves remain all start to matter.

Once the search becomes deeper, computation time becomes noticeable.

Doing too much of that work on the browser's main thread can interfere with animation and user input.

That led me to Web Workers.

The current board can be sent to a worker, the heavier search can run separately, and the suggested move can come back without making the interface feel stuck.

I did not expect a little 2048 game to lead me there when I started.

That has probably been the recurring pattern with this project.

The rules are simple.

Most of the work is somewhere else.

It is in how a swipe feels.

It is in whether the game remembers where you left off.

It is in whether a second theme means copying hundreds of lines of code.

It is in whether a helper feature makes the whole interface stutter while it is thinking.

The third theme was the real test

The first theme could not tell me whether my structure was reusable.

There was nothing to reuse yet.

The second theme exposed the duplication.

That gave me a reason to refactor.

The third theme told me whether the refactor was actually useful.

By the time I was working on Princess 2048, I wasn't rebuilding movement, saving, scoring, touch handling, or the move guide.

Those parts were already there.

That was much more satisfying than designing a generic system before I knew what needed to be generic.

If I had tried to predict every future theme while making the first game, I probably would have created abstractions for problems that never appeared.

Building the second version showed me the real boundary.

I'm still trying to keep it small

There are plenty of directions this project could go.

I could add accounts, cloud saves, global leaderboards, daily challenges, multiplayer, a backend API, or a larger frontend framework.

Some of those might make sense later.

Right now, the main experience still works with HTML, CSS, and vanilla JavaScript.

I like that.

The goal isn't to use as little technology as possible.

It is to avoid adding technology before there is a problem that actually needs it.

For now, I would rather spend time improving how the games feel, experimenting with themes, and watching how people actually use them.

The most useful lesson from this project turned out to be fairly simple:

Build one real version.

Build another variation.

Notice what actually repeats.

Then make that part reusable.

Sometimes the second version tells you what the first one was really supposed to become.

I Turned a Few Tests I Like Into a Website

Funny — Wed, 12 Aug 2026 16:33:41 +0000

Lately, I've been working on a small website built around simple online tests.

There wasn't much of a plan in the beginning. I had been looking at different test sites and noticed that a lot of them had something in common: the rules are simple, you can start immediately, and you get a result within seconds.

I like that kind of thing.

Reaction time tests are probably the best example. The screen changes color, you click, and you get a result somewhere around a couple hundred milliseconds.

That's technically the end of the test.

But then you see the number.

You try again.

The second run is a little faster, so naturally you want to do one more.

That feels different from a lot of online tools. You don't just use them and leave. The result itself gives you a reason to try again.

At some point I thought: maybe I should just build a site around these.

First, I needed a name

Naming it took me longer than I expected.

I looked through a lot of domains with test in them. Most of the obvious good ones were long gone. The rest were either too long, awkward to say, or sounded like a brand without giving any clue what the site was actually about.

Eventually I bought PickTests.com.

Pick a test.

Nothing clever about it.

It just fit.

Once I had the domain, I made a pretty long list of things I could build: reaction time, clicking speed, typing speed, aim, memory, and a few others.

My thinking was simple.

If it's a test website, just keep adding tests.

Five is better than three. Ten is better than five. Twenty is better than ten.

At least that was how I looked at it in the beginning.

Once I actually started building, that changed a bit.

Somewhere along the way, I stopped caring so much about quantity

Looking back, I was still measuring the site by the number of pages it had.

More tests meant a bigger site, and a bigger site felt like progress.

But when you're the one actually building them, you start noticing that adding another page isn't the hard part.

The harder question is whether the new thing adds anything at all.

Reaction time tests have been around forever.

So have sequence memory tests and number memory tests.

I could reproduce the familiar version of each one, move on, and eventually end up with a site containing dozens of tests.

But I didn't feel much attachment to that.

So I stopped following the original list.

Right now, the site has six tests: reaction time, aim, sequence memory, number memory, multiple-object tracking, and a color interference test.

A few things I originally planned to build still aren't there.

There wasn't really a big turning point.

It was more that every time I finished a test and played it a few more times, small questions started showing up.

Is this part too fast?
Does the randomness feel strange?
Did the difficulty jump too much here?
Should a score tell you anything beyond one number?

Then I'd change something and play again.

And change something else.

The multiple-object tracking test ended up taking much longer than I expected for exactly this reason.

The idea itself is simple: remember a few targets, watch them move among other objects, and pick them out again at the end.

But once it was running in a browser, small changes to the number of objects, speed, or movement time made a huge difference.

One round could feel almost too easy, while the next suddenly felt impossible to follow.

Even something as basic as movement time took a lot of back and forth. Three seconds could feel too easy. Five seconds could be long enough for you to lose track and get frustrated.

I ended up adjusting several things together until it felt closer to that point where losing makes you want to try again instead of close the page.

A surprising amount of time went into things like that.

Nothing especially difficult from a technical point of view.

Just lots of small details.

A while ago, I probably would have looked at some of them and said, "good enough."

Now I seem to spend more time getting stuck on exactly what "good enough" means.

A few things I decided not to build

Leaderboards were one of them.

They're an obvious fit for this kind of site.

Who has the fastest reaction time?

Who can remember the longest number?

I thought about it.

But once you add a leaderboard, the next questions arrive pretty quickly: accounts, a database, score validation, cheating, and so on.

In the end, I left it out.

For now, scores stay in the browser.

There's no account and no login.

You can see your latest result, your personal best, and your recent attempts.

That's enough for what the site is right now.

The technical side has stayed simple as well: HTML, CSS, and vanilla JavaScript.

No backend, and no heavy framework just for the sake of having one.

These are small tests that should open quickly and be playable right away, so I prefer keeping the rest of the site fairly light too.

The current version has reaction, memory, aim, tracking, and attention-related online tests that you can play directly in the browser.

I'm taking it slowly for now

The site has ended up a little different from what I imagined at the start.

There aren't that many tests yet, and I haven't tried to turn it into something more complicated than it needs to be.

There's still plenty I could add.

I'm just not in much of a hurry anymore.

For now, I'd rather keep working on the ones that are already there.

If I come across another test that I genuinely find interesting and would want to play more than once, I'll probably add it.

I don't know whether that eventually means ten tests, twenty, or roughly the same number I have now.

I'll keep building and see where it goes.

Project: PickTests — Online Tests

I Thought Browser Tests Would Be Simple. Then I Started Building PickTests.

Funny — Tue, 04 Aug 2026 08:00:35 +0000

I recently started building PickTests, a collection of small browser-based tests for reaction time, memory, focus, speed, and coordination.

At the beginning, I thought this would be a relatively simple project.

A reaction time test needs a timer. A sequence memory test needs a few blocks. An aim trainer needs targets that appear in different positions.

The basic idea behind each test is easy to understand, and the first working version can often be built quickly.

But after working on several tests, I realized that getting the code to work was only the beginning.

Why I started PickTests

I have used many browser-based benchmark and skill-testing websites over the years.

Some of them are useful, but the experience often feels inconsistent. One test looks modern while another feels unfinished. Some pages are difficult to use on mobile. Others are filled with so many unrelated elements that the test itself becomes hard to focus on.

I wanted to build something simpler.

The idea behind PickTests is straightforward:

Choose a test, understand it quickly, complete it, see your result, and try again.

There is no account to create, no software to download, and no long setup process.

I am not trying to build a professional assessment platform. PickTests is meant to be a lightweight place where people can test themselves, compare their own results, and come back when they want to try again.

Building the first version was the easy part

The first test I worked on felt surprisingly manageable.

The screen changes state, the user reacts, the browser measures the time, and the result appears.

Once that worked, I thought the difficult part was mostly finished.

It was not.

Small questions started appearing everywhere.

What should happen when someone clicks too early?

How long should the random waiting period be?

Should the result be based on one attempt or several rounds?

What happens when the user switches tabs halfway through the test?

How should the same interaction work on a phone?

None of these problems looked large on their own, but together they determined whether the test felt reliable or frustrating.

That became a repeated pattern throughout the project.

The basic logic was usually simple. The experience around that logic required much more thought.

Small details can change the entire test

An aim trainer is a good example.

The main interaction is simple: show a target, let the user click it, then move it somewhere else.

But target size changes the difficulty. The distance between targets changes the pace. The size of the playable area changes everything again on mobile devices.

Even the way a target is positioned matters. If part of it appears outside the playable area, the test immediately feels unfair.

The same is true for memory tests.

A sequence can be displayed correctly, but the test may still feel wrong if the animation is too fast, too slow, or unclear. The user should know when to watch and when to respond without needing to think about the interface.

These details are not advanced technical problems. They are product decisions.

That was one of the biggest lessons for me.

A small browser tool can have very little code and still require a surprising amount of design thinking.

Consistency became more important as the project grew

PickTests currently includes several different types of tests, including reaction time, aim, sequence memory, number memory, visual tracking, and attention-based tests.

Each one has its own rules, but I do not want them to feel like unrelated pages collected under the same domain.

The instructions should use a similar tone.

Buttons should behave consistently.

Results should be easy to understand.

Restarting a test should feel familiar.

Mobile interactions should not feel like a reduced version of the desktop experience.

As I added more tests, I started spending more time on the shared experience between them.

This made me slow down.

Instead of adding as many tests as possible, I decided to improve the existing ones before expanding too quickly.

A large number of unfinished tests may make the website look bigger, but it does not make it better.

I would rather have fewer tests that feel complete.

Why I kept the technology simple

PickTests is built with plain HTML, CSS, and JavaScript.

There is currently no frontend framework, backend, database, or account system.

This was not a statement against frameworks. I simply did not need one for the current version.

Each test has a limited number of screens and states. Keeping the technology simple makes it easier for me to understand every part of the interaction and adjust it quickly.

It also fits the product.

A user should be able to open a test and begin almost immediately. The website does not need a complicated application structure to provide that experience.

Using a simple technical foundation has allowed me to spend more time on the parts users can actually feel: timing, feedback, spacing, difficulty, mobile behavior, and result clarity.

The result is more than a number

At first, I treated the result screen as the final step.

The test ends, a number appears, and the job is done.

But a number without context is not always useful.

If someone gets a reaction time of 240 milliseconds, they may wonder whether that is good, average, or poor.

If a memory test ends at level eight, they need to understand what the level represents.

Users also need to know whether a higher or lower score is better and what they can do next.

The result screen is not separate from the test. It is part of the experience.

I am still working on this part.

I want results to be clear without turning every page into a long explanation. The goal is to give enough context while keeping the flow lightweight.

Building for mobile changed many decisions

It is easy to build a browser test while sitting in front of a desktop monitor.

The problems become more obvious when the same test is opened on a phone.

The screen is smaller. Touch input is different from mouse input. Browser controls reduce the usable height. Accidental touches are more common. The device may rotate halfway through a test.

A layout that feels spacious on desktop can become crowded on mobile.

A target that looks reasonable with a mouse may feel too small for a finger.

Because of this, mobile support cannot be something added after the desktop version is finished.

It influences the test itself.

This is one of the areas I am continuing to improve across PickTests.

PickTests is also a learning project

Beyond building the tests, PickTests is my attempt to learn how to grow an English-language web product from zero.

I am an independent developer, and this is still an early project.

There is no large team, existing audience, or launch campaign behind it.

I am learning how to choose useful tests, create pages people can understand, improve the experience, and gradually make the website discoverable through search.

That process is slower than simply publishing new pages.

It requires deciding what is actually worth building and whether each page gives users a reason to stay, try again, or return later.

I do not know yet how far the project will go, but that uncertainty is part of why I find it interesting.

What I am working on next

For now, my priority is not adding dozens of new tests.

I am improving the tests that already exist.

I want to make the difficulty more balanced, the mobile experience more reliable, and the result pages more useful.

After that, I plan to explore more tests related to typing speed, attention, memory, and coordination.

But I want each new test to earn its place on the website.

PickTests is still small, but building it has already changed how I think about small web tools.

The code may be simple.

The idea may be easy to explain.

But making a tool feel clear, fair, and worth using again is where most of the real work begins.

You can try the current version here:

https://picktests.com/

I would be interested to hear what feels good, what feels confusing, and which parts still need improvement.

What I Learned Building a Few Tiny Random Tools

Funny — Wed, 08 Jul 2026 11:21:14 +0000

I have been working on a small website called WheelPage lately.

It is not a big product. It is mostly a collection of simple random tools:

a spinner
a 3D dice roller
a coin flipper

At first, I thought this would be easy.

A spinner picks one item from a list. A dice roller returns a random number. A coin flip gives you heads or tails.

The logic is simple.

But once I started building it, I kept getting stuck on small decisions.

Not the technical parts. Those were manageable.

The harder questions were more like this:

Should this button be visible by default?
Is this animation actually useful?
Will this feature make the page feel crowded?
If I do not add it, will the tool feel unfinished?

None of these questions were difficult alone.

But they kept coming back.

That was the part I did not expect.

The dice roller was the first problem

The simplest dice roller is easy to build.

Add a button. Click it. Show a random number from 1 to 6.

The feature works.

But when I looked at that version, it felt wrong.

It was random, but it did not feel like rolling a die. It felt more like a random number generator.

A real die has a tiny physical process. It moves, tumbles, and settles. That moment is short, but it changes how the result feels.

So I turned it into a 3D dice roller.

Then another problem appeared.

If the animation was too short, it felt fake. If the animation was too long, it became annoying.

I clicked the same button again and again, trying to find a timing that felt natural.

At some point, I realized I was not really tuning an animation.

I was trying to define the boundary of a small tool.

It should feel like a die, but it should not make the user wait just to make the interaction feel more realistic.

Features are easy to add

While working on the dice roller, I started thinking of more features.

multiple dice
roll history
sound effects
D20 and other tabletop dice
custom colors
copy result

Every idea made sense.

A D20 is useful for tabletop games. Multiple dice are useful in some cases. Roll history can help if someone rolls several times.

But most people do not open a dice roller to explore features.

They open it because they need a die now.

Maybe they are playing a board game and forgot to bring one. Maybe they just need a quick random result.

They do not want to study a dice tool.

They want to roll.

That changed how I thought about the page.

A feature can be useful by itself, but still become a burden when placed next to everything else.

With small tools, knowing when to stop is often harder than knowing how to build.

The spinner needed a different approach

The spinner is different from the dice roller.

It is heavier by nature because users need to provide their own options.

People might use it for things like:

deciding what to eat
picking a name in class
choosing a task
running a small giveaway

So features like editing, sorting, shuffling, and saving history make more sense here.

But the main flow still has to stay clear:

Where do I type?
How do I spin?
Where is the result?

Everything else can exist, but it should not block those three steps.

This was a useful reminder for me.

Just because a feature is available does not mean it should be visually important.

The coin flipper should stay light

The coin flipper is the opposite.

It exists for a simple fifty-fifty moment.

Two options both seem fine. You just want to stop thinking about it and let the coin decide.

That kind of tool does not need many rules. It does not need many buttons.

It just needs to flip.

I still added a small flipping motion because without it, the result felt too sudden. But I do not want to make it much more complicated than that.

The simpler the tool is, the more obvious every extra piece becomes.

One unnecessary button can make the whole thing feel worse.

I am learning to accept short sessions

I used to think a website should make people stay longer.

More page views. More clicks. More reasons to come back.

Those things can matter.

But for tools like a spinner, a die, or a coin, a short session is normal.

Someone opens the page. They click once. They get a result. They leave.

That is not a failure.

For this kind of tool, it might be the right behavior.

If it does not make the user think too much, wait too long, or feel interrupted, it has done its job.

Some tools are better when they stay out of the way.

Current state

Right now, WheelPage is still small.

The data is not dramatic. Bing has started bringing in some impressions and clicks. Google is moving slower, which is not surprising for a new site.

I am not rushing to add more features yet.

Most of my time is going into small details:

Can the main button be reached comfortably on mobile?
Can the page load a little faster?
Does the animation feel natural?
Does the result appear clearly?
Do the English and Chinese versions sound natural?

These things are boring, but they matter.

A small tool does not have much room to explain itself. The first few seconds matter a lot.

For now, the tools are here:

Spinner: Spin the Wheel
3D Dice Roller: Dice Roller
Coin Flipper: Flip a Coin

I am still adjusting them slowly, mostly around speed, clarity, mobile comfort, and language.

What I learned

Before building these tools, I thought small tools were simple.

Now I think they test a different kind of discipline.

The smaller the tool is, the more careful each decision becomes.

A large product can hide some rough edges behind more features. A tiny tool cannot. If the main action feels wrong, the whole tool feels wrong.

So my goal for WheelPage has become simpler.

It does not need to be big. It does not need to be loud. It does not need to make people stay longer than necessary.

If someone opens it when they need a quick decision, uses it smoothly, and leaves without feeling bothered, that is enough.

Small tools can be small.

But they still deserve care.

I Built a Website That Tries to Make People Leave Faster

Funny — Mon, 04 May 2026 03:05:15 +0000

Most websites want you to stay.

Scroll more.
Click more.
Sign up.
Come back tomorrow.

I built one that hopes you leave quickly.

It is called WheelPage:

https://wheelpage.com/

It is a small browser tool for tiny decisions.

Spin a wheel.
Flip a coin.
Get an answer.
Move on.

That is the whole idea.

No account.
No dashboard.
No onboarding.
No attempt to become another habit.

Just a small page for moments like:

What should we pick?
Who goes first?
Heads or tails?
Which option should I choose?

These are not important decisions.

But they still take a little attention.

A few seconds of hesitation.
A small back-and-forth.
A tiny interruption in the day.

I wanted to build something that quietly removes that.

Simple is not the same as careless

At first, this felt almost too small to care about.

A coin flip can be one line of JavaScript:

Math.random() > 0.5 ? "Heads" : "Tails"

But a real coin flip is not just a result.

There is a tiny pause.

The coin goes up.
Nobody knows.
Then it lands.

That little moment matters.

The same is true for a wheel.

If it stops too fast, it feels cheap.
If it spins too long, it wastes time.
If it has too much animation, it becomes noise.
If it has no feeling at all, it feels unfinished.

So the work became less about adding features, and more about removing the wrong ones.

The goal is not engagement

This is the part I keep coming back to.

For many products, a longer session is a good sign.

For this one, maybe it is the opposite.

If someone opens WheelPage, flips a coin, gets an answer, and leaves in ten seconds, that might be success.

The tool did its job.

It did not ask for more attention than it deserved.

I like that idea.

Not every product needs to pull people deeper in.

Some tools should simply appear, help, and disappear.

Still small, still learning

WheelPage currently has two main tools:

https://wheelpage.com/

https://wheelpage.com/coin-flip/

I am still polishing the motion, sound, mobile layout, and the feeling of the result.

It is not a big project.

But I am learning that small tools can still teach real product lessons.

Clarity matters.
Timing matters.
Restraint matters.
Tiny interactions matter.

I would love honest feedback:

Does it feel too simple, or simple in the right way?

Thanks for reading.

I Built a Tiny Decision Tool and Learned That Simple Still Matters

Funny — Sun, 03 May 2026 14:36:33 +0000

I’ve been building a small browser-based project called WheelPage.

It is not a big product.

It does not use AI.
It does not have a complex dashboard.
It does not solve a huge enterprise problem.

Right now, it only does two simple things:

spin a wheel
flip a coin

The site is here:

https://wheelpage.com/

And the coin flip page is here:

https://wheelpage.com/coin-flip/

At first, this felt almost too small to talk about.

But while building it, I started to realize something:

Simple tools are easy to underestimate.

Why I started building it

I like small tools.

Not everything needs to become a platform.
Not every product needs onboarding.
Not every decision needs a productivity system.

Sometimes you just want to open a page, make a tiny decision, and leave.

Who goes first?
What should we choose?
Which option should I pick?
Heads or tails?

These are small moments, but they happen often.

So I wanted to build something that respects that kind of moment.

A tool that does not ask too much from the user.

No sign up.
No account.
No setup.
No unnecessary steps.

Just use it and move on.

The hard part is not the idea

A spin-the-wheel tool is not a new idea.

A coin flip tool is not a new idea either.

That is obvious.

The interesting part for me is not whether the idea is new.

The interesting part is whether a small, familiar tool can still feel good.

Can it be fast, but not lifeless?

Can it be playful, but not annoying?

Can it be minimal, but not unfinished?

That balance is what I keep thinking about.

Small interactions matter more than I expected

When building the wheel, I thought the main problem would be the random result.

But the result is only part of the experience.

There are many small details:

how fast the wheel starts
how long it spins
how it slows down
whether the sound feels satisfying or distracting
how the result appears
whether the mobile layout feels natural
whether the buttons are obvious without instructions

None of these details are huge by themselves.

But together, they decide whether the tool feels cheap or cared for.

The same thing happened with the coin flip.

Technically, a coin flip could just be:

Math.random() > 0.5 ? "Heads" : "Tails"

But that does not feel like flipping a coin.

A real coin flip has a tiny moment of suspense.

So I started thinking about motion, timing, sound, and result reveal.

Not because the tool needs to be fancy.

But because even a very small tool should feel intentional.

Minimal does not mean careless

This is probably the biggest lesson for me so far.

I used to think “minimal” mainly meant removing things.

Remove settings.
Remove steps.
Remove distractions.

That is still true.

But now I think minimal also means keeping only the things that matter — and making those things good.

A minimal interface still needs:

clear text
good spacing
fast loading
responsive layout
accessible buttons
useful empty states
small feedback after user actions

If a user only spends ten seconds on the page, those ten seconds still matter.

Maybe they will not remember the design.

But they will remember whether it felt smooth or frustrating.

I am also learning distribution

This project is also a small experiment in distribution.

I am trying to learn whether simple browser tools can grow through:

SEO
multilingual pages
Chrome extensions
small community posts
directories
slow, consistent improvement

I do not expect one launch to change everything.

For a project like this, I think growth is probably more like planting small seeds.

One page.
One tool.
One improvement.
One backlink.
One small mention.

Then repeat.

That process is slow, but I like it.

What I am still unsure about

I am still figuring out the direction.

Should WheelPage stay very minimal?

Or should it become more playful?

Should I add more tiny decision tools?

Or should I focus only on making the wheel and coin flip feel really polished?

Should the site feel like a utility?

Or more like a small, friendly place for everyday decisions?

I do not have a final answer yet.

That is part of why I am sharing it here.

What I would love feedback on

If you have a moment, I would really appreciate honest feedback.

Especially on these questions:

Does the site feel clear when you first open it?
Does the wheel feel simple enough to use without thinking?
Does the coin flip feel too plain, or appropriately minimal?
Should small tools like this be more playful?
Are there any tiny decision tools that would naturally fit this project?
From a developer or indie builder perspective, does this kind of project feel worth continuing?

Here is the site again:

https://wheelpage.com/

Thanks for reading.

This is a small project, but I am trying to build it carefully.

When I Got Tired of Small Decisions, I Built a Very Small Tool

Funny — Tue, 13 Jan 2026 13:58:58 +0000

The reason I wrote this is pretty simple.

One day, I noticed that what interrupted my day the most wasn’t big or complex problems.

It was small decisions that didn’t really deserve much thought:

Which task should I start with?
What should I eat for lunch?
If there are a few options, which one do I pick first?

Each one feels small on its own.

But when they keep showing up throughout the day, they break your focus again and again.

What really drains you is usually not big decisions, but these small moments that feel unimportant—yet still make you stop and think.

I Tried Fixing This with Tools

At first, I tried to solve this with different tools.

But something ironic happened:

To avoid overthinking, I ended up spending more time on the tools themselves.

Logging in.

Setting things up.

Figuring out how they work.

Getting shown more things I “might want to try.”

Instead of helping me get started, the tools became another distraction.

That’s when I realized I wasn’t looking for a smarter system.

I was looking for something quieter.

A Tool That Stays Out of the Way

That’s how WheelPage started.

It’s not a productivity system, and it doesn’t try to help you make better decisions.

It only does one thing:

When you don’t want to think anymore, it gives you a quick, neutral result.

The first thing I built was a simple decision wheel.

You type in your options, spin it, and get a result.

Later, I noticed something interesting.

Most people don’t really care which option the wheel lands on.

What matters is that, when the result shows up, they can finally move on.

Sometimes you’re just sitting in front of the screen, not sure where to begin.

That single result is often enough to get you started.

Over time, people started using the wheel in ways I didn’t expect:

To break a deadlock in a team
For classroom activities
To give themselves a random starting point when they’re stuck
Or just to help them do something first

If you want to see this basic feature, it’s here: Spin the Wheel

Why I Added a Coin Flip

One piece of feedback kept coming up:

“Most of the time, I’m just choosing between two things.”

So I added an even simpler tool: Coin Flip.

There’s nothing to set up.

No instructions.

You open it and flip.

Heads or tails.

What surprised me was what people told me afterward.

Many said they didn’t fully let the coin decide for them.

Instead, the moment the coin landed, they suddenly realized which side they were hoping for.

That moment is small, but it matters.

If you’re curious, you can try it here: Flip a Coin

A Few Things I Chose Not to Do

While building WheelPage, there were a few things I avoided on purpose.

No accounts

Because using something once shouldn’t require signing up.

No piling on features

Every time I think about adding something, I ask myself:

Is this actually helping someone,

or am I just making it feel more like a “real product”?

No trying to keep you around

The ideal experience is simple:

use it, then leave.

I think of WheelPage as a small thing in a drawer,

not something that asks for your attention all the time.

In the End

WheelPage isn’t meant for big life decisions.

It exists for something much smaller:

helping you stop spending attention on tiny choices.

Sometimes, a random and emotionless result helps you move forward faster.

And sometimes, it even helps you notice what you wanted all along.

If you run into the same kind of friction, this little tool might save you a bit of attention.

It’s there when you need it.

Quiet.

And not in a hurry.

WheelPage — A Simple Decision Wheel and Coin Flip Tool

Funny — Sun, 14 Dec 2025 07:55:42 +0000

I built a coin flip tool and realized the result doesn’t really matter

I didn’t plan to build a product.

The idea started because I kept getting stuck on small decisions:

which task to start, whether to continue something or stop, what to do next when my brain felt tired. None of these choices were important, but they kept slowing me down.

So I built a very simple coin flip page (https://wheelpage.com/coin-flip/).

No login, no settings, no explanation. You open it, flip once, and move on.

I honestly thought almost no one would use it.

The mistake I almost made

At the beginning, I tried to “improve” it.

I thought people would want:

history
statistics
customization
more control

So I started adding things. And the page became heavier, slower, and honestly… less useful.

At some point I removed almost everything again.

What surprised me was that usage didn’t drop. It felt more natural. People didn’t want a system — they wanted a moment.

What people actually use it for

Some users told me something interesting.

They said the coin result itself wasn’t the important part. What mattered was their reaction to it.

If the coin landed on “Heads” and they felt disappointed, the decision was already made — the coin just exposed it.

I didn’t design for that. It happened naturally.

Why I kept it minimal

I also built a simple decision wheel later, but the principle stayed the same:

No accounts
No ads
No dashboards
No “engagement features”

You open it, use it, close it.

I don’t want people to stay. I want them to leave faster.

What this small project taught me

Building something “boring” taught me more than some bigger projects.

Not everything needs growth loops.

Not everything needs optimization.

Sometimes removing features is the best decision you can make.

And sometimes, a tiny tool works not because it gives an answer — but because it helps you notice how you feel about the answer.

I’m curious:

Have you ever built (or used) something small that turned out to be more useful than you expected?

Or noticed that the value wasn’t in the result, but in your reaction to it?

If anyone is curious, the project lives here:

https://wheelpage.com/

I Built a Tiny “Coin Flip” Tool — Because Sometimes a Simple Choice Is All You Need

Funny — Wed, 19 Nov 2025 14:59:46 +0000

We all overthink.
Even developers.
Especially developers. 😅

So I built a tiny tool to solve one very specific problem:

👉 When I can’t decide, I let a coin decide for me.
One click. Heads or tails. No mental load.

Here it is:

👉 Coin Flip: https://wheelpage.com/coin-flip/

(Instant decision-making. Zero UI noise.)

💡 Why I Built It

Sometimes the smallest decisions steal the most time:

Which task to start

Whether to refactor now or later

Which feature to pick

Even what to eat for lunch

Instead of burning mental energy, I wanted a stupidly simple way to break the deadlock.

So I made this tiny coin.

No ads
No distractions
No dark patterns
Just flip → decide → move on

✨ Bonus: I Also Made a Random Decision Wheel

If you want something more playful:

🎡 Spin Wheel: https://wheelpage.com/

It’s great for picking features, choosing tasks, or settling arguments with teammates.
Dev teams somehow love it. 😂

🧩 Feel Free to Use It (or Fork the Idea)

If you also struggle with micro-decisions, give it a try.
And if you build your own variant (code, design, or logic), I’d love to see it.

Why I Built a Simple Decision-Making Tool

Funny — Tue, 30 Sep 2025 03:34:06 +0000

I didn’t set out to “build a tool” or start a project. It started with something much smaller: indecision.

Almost every day, I found myself stuck in little decision loops.

🍔 What should I eat for lunch?
📋 Which task should I start with?
🎲 Who goes first in a game night with friends?

None of these were “big problems,” but they drained more energy than I expected. I’d spend five minutes scrolling food delivery apps, or ten minutes asking everyone to vote on what to do. By the time the decision was made, I was already tired.

One day, half-jokingly, I typed “spin the wheel” into Google, thinking maybe a randomizer could make the choice for me. What I found were clunky websites: overloaded with ads, auto-playing videos, confusing menus, and pop-ups everywhere. All I wanted was a wheel that spins — nothing more.

That frustration gave me the spark: what if I just made one myself?

Starting small 🚀

I didn’t plan a “startup” or think about features. I opened my laptop and began sketching out the simplest possible thing: a blank wheel, a box to type in options, and a button that says Spin. That was it.

When it first worked, it felt almost silly. The wheel spun, landed on a slice, and gave me an answer. But it solved the exact problem I had: I didn’t have to overthink. The decision was out of my hands, and I could move on.

Why I kept going 💡

The funny thing is, once I used it myself, other people wanted to use it too.

👨‍👩‍👧 Friends used it at dinner: each person would type in one suggestion, and the wheel would decide.
🎓 Teachers told me they used it in classrooms, adding student names to make participation random and fair.
🎥 Someone even told me they used it for small giveaways during livestreams.

It made me realize that small tools, even ones that feel almost trivial, can quietly fit into people’s daily routines.

What it means to me 💭

Building this wheel wasn’t about technology. It was about creating a tiny pocket of calm in situations where my brain usually spirals into indecision.

There’s something oddly comforting about handing over the choice to a spin. You’re no longer the one obsessing over pros and cons, you’re just watching a wheel turn — and somehow, that feels lighter.

For me, this tool is a reminder: not every problem needs a complicated solution. Sometimes, a simple spin is enough.

Try it yourself 🎡

If you’ve ever been stuck in one of those tiny decision moments, you might find this tool helpful too.

I put it online here: https://wheelpage.com