Building ThinkFast

This post is the AI-shaped version of a raw thought dump about building ThinkFast.

The raw notes are available separately for anyone who wants the unfiltered version. This version is cleaned up so the actual lessons are easier to read.

What I wanted ThinkFast to be

ThinkFast had four priorities from the start: speed, ease, smoothness, and beauty.

That was the bar because ThinkFast is a free game. If something is free, the user does not owe you patience. It has to load quickly, feel good immediately, and be simple enough that nobody needs a manual.

The game itself is intentionally small. A word appears on the screen, and the player writes the first word that comes to mind as quickly as possible. That is the product. The hard part is making that tiny loop feel polished instead of cheap.

The questions started immediately

A tiny game still creates real product questions.

• How much infrastructure can I afford while keeping it free?
• What should I log?
• How do I know whether people are using it?
• Which events are worth sending to analytics?
• Should answers be public?
• Should unsafe answers be filtered?
• Should answers be grouped by meaning, or stored exactly as written?
• How do I protect the API if people or bots start hitting it?

That is what I like about shipping quickly. You stop debating the perfect idea and start dealing with the real shape of the product.

Analytics without burning the free tier

ThinkFast made me think more seriously about analytics.

I wanted to know whether people were opening the app, playing rounds, and submitting answers. At the same time, I did not want to log every tiny event and burn through the free PostHog allowance for no reason.

So the lesson was not simply "add analytics." The lesson was to be intentional: track the events that explain whether the product is alive, and skip the noise until there is enough usage to justify more detail.

What I cut

At one point, I tried to add semantic grouping.

The idea was that if multiple people gave answers that meant the same thing, ThinkFast could group them together. A user could also correct the category, and the system would slowly learn from the data. That sounded useful.

It was also too much for version one.

I could have used an AI semantic engine, but that violated one of the core rules for this product: keep it free. I also realized that the raw answer has value. If someone writes MHA, meaning My Hero Academia, I do not necessarily want to normalize that into something cleaner. The exact answer is part of the thought.

So I cut the semantic layer.

I also cut fuzzy matching. The app does not try to fix extra punctuation, capitalization, or incomplete words. Some of that may come back later, but the first version stores what the user actually wrote.

That is less clever, but it is more honest to the game.

Protecting a free app

The other big development lesson was protection.

Free apps still have costs. They can be scraped. They can be spammed. They can be hit with too many requests. I do not have millions of users, so some of this is early thinking, but it still matters.

The domain setup made me think about this more clearly. The project is hosted on Vercel, while my Varmada domain runs through Cloudflare. Because of the way the domain is routed, I cannot rely only on Cloudflare proxy behavior. Vercel has its own DDoS protection, and I added rate limiting so the API can return 429 responses if traffic spikes in a suspicious way.

That problem may become one of the future 60/60 products: a simple way for me to protect, track, and route all these tiny apps without rebuilding the same plumbing every time.

The design lesson

The biggest AI-agent lesson was that design philosophy has to be established early.

If I do not give the agent a clear direction, it defaults to too much text, too many explanations, and too many generic screens. ThinkFast forced me to keep pushing toward the product I actually wanted: minimal, smooth, dark, accented, fast, and intuitive.

The app should not explain itself forever. It should feel obvious.

That lesson is going to shape the rest of the 60/60 challenge. I want reusable instructions, reusable patterns, and a clearer way to bring agents into my taste instead of fighting the same battle on every build.

The launch was quiet

After I released ThinkFast, the first thing I did was fix bugs.

There were display bugs. Some text overlapped. Some text overflowed. Some mobile layouts were not readable enough. Those are the kinds of problems that matter more than fancy features because they directly affect whether a user can actually play.

Once those were cleaned up, I posted about the app on Threads and Twitter.

Both posts got basically zero views.

So the first users were not some huge audience. They were my wife, my sister, my brother, and a few of my own test accounts. The database is still fresh. There are barely any answers. The product is free, small, and early.

That is fine.

I am going to post it in a few relevant communities once these blog posts are live, because then people will have more than a link. They will have the product and the story behind it.

What ThinkFast gave me

ThinkFast gave me a shipped product, but it also gave me a list of future products.

I need better ways to manage footers across small apps, track outbound clicks back to Varmada, protect APIs, route analytics, and give AI agents a reusable design direction. That is the hidden value of the 60/60 challenge: every shipped product creates the next set of problems worth solving.

ThinkFast is not perfect. It is released, usable, free, and already teaching me.

That is enough for day one.