Over four days, I spent about 25 hours and $30 taking a small browser-game website from idea to launch.
The budget was simple:
- About 25 hours of work
- $10 for the domain
- $20 for AI coding tools
The project started with a video about a Mahjong Solitaire website in Romania. It claimed the site was making $5,000–$20,000 a month. I could not verify that number, but the category itself was clearly active: established competitors ranked in search, and people were playing these games.
My angle was to pair the games with explanations of their rules, symbols, and Asian cultural background. I hoped that would give the site a clearer identity and create useful search content around the games.
Building was the easy part
Roughly half of the 25 hours went into building, testing, and tuning the games. The work was not frictionless. AI-generated code misunderstood rules, computer opponents got stuck, prompts needed several rounds of refinement, and visual assets had to be checked for licensing.
Still, those were ordinary engineering problems. Given enough time, I could work through them.
The harder question was where the users would come from.
That question shaped almost every other decision: the topic, positioning, domain, content, and how much of the product was worth building. I knew there was demand for the games, but I had not shown that my site could reach it.
Before writing code, I should have looked more closely at:
- Search volume and keyword trends
- The strength of the sites already ranking
- Long-tail searches a smaller site could target
- Gaps in the existing products and content
Instead, I relied on the video, visible competitors, and a loose assumption that proven demand meant there was room for one more site.
My confidence in that assumption dropped as the project went on. Once the traffic path felt uncertain, another round of interface polish no longer seemed especially valuable.
A market can be real without being reachable for a new product.
Where I drew the line
I could have kept tuning the computer opponents, adding content, and polishing the interface. I decided to stop at a version that was playable and measurable.
Without real users, I could not know which game mattered most, whether the difficulty felt right, or which feature deserved another day of work. More polish would mostly have reflected my guesses.
I added analytics and a daily check for search traffic, human activity, and returning visitors. The first week is mainly about confirming that indexing and tracking work. Search impressions and rankings will take longer, so I plan to watch the site for one to three months without adding much more development time.
For now, the rules are:
- Fix bugs that affect play, indexing, or measurement
- Keep the site online
- Collect enough data to see whether anyone arrives and returns
- Invest again only when there is a real signal
What I would validate first next time
For the next MVP, I want to test the path to users before I build the product. That means answering a few questions early:
- Are people searching for this topic?
- Can a small new site realistically rank?
- What do the leading products already do well?
- Where are they noticeably weak?
- Is there a narrow entry point where I can offer something better?
The number of competitors does not answer those questions. Three dominant sites can be harder to compete with than ten neglected ones.
The useful question is not only whether demand exists. It is whether I have a realistic way to reach it.
What 25 hours gave me
As a software engineer, my default instinct is to improve correctness, completeness, and technical quality. This project was a useful reminder that a product does not need to be finished before it meets the world.
In 25 hours, I went through the whole loop:
idea → positioning → product → domain → deployment → payments → analytics → launch
I also came away with practical experience in AI-assisted development, Cloudflare, Stripe, analytics, SEO, and thinking more clearly about acquisition.
The site has not proved that it can become a business. It may find an audience, or it may remain a small experiment. Both outcomes will tell me something.
What matters is that the 0–1 process is less abstract now. The next build should be faster, and the validation should start earlier.