Raw Notes

This is the raw thought dump behind the edited ThinkFast build post. It is intentionally left messy for readers who prefer the unfiltered version.

There are a lot of things that I realized midway through thing fast that I was like, Oh my God, this is going to kill me. First things first is people tend to overcomplicate what ideas to have, right? A lot of people say build what already exists, but it's okay to build random new stuff too. That's how stuff Uber, stuff Airbnb, stuff like, you know, TaskRabbit and stuff I get invented. You want to build new things. Novelty brings about curiosity, which which brings about possible success. Unicorn companies are basically novel companies that happen to win the gamble of market capital. And so what tends to happen with these new products is people need to find the next big thing, but then they overthink their stuff. I've never seen ThinkFast on everybody, but I know that I would love ThinkFast, and that's my only criteria is I need to build something that I will have a direct use for. It's not something that I'm going to build and never use. That's a very important factor that I think into account when I built ThinkFast. And right off top, yesterday I completed the app and today I already started using it. So this morning I was just on it for fun. just the fact that I'm on it for fun already tells me, yeah, this is pretty good. All right, obviously there's some bugs. Obviously the app is not perfectly polished. Obviously after a little while the app will be so bloated because there's going to be so many answers on the database, that it's gonna be absolutely impossible to keep it for free because we're gonna have to pay for more storage. But as of now, it's a cool little app that was built in a few minutes. Actually, it took me exactly, I think, five hours or six hours from end to end.

Something else that I learned with ThinkFast is how important it is to have a design philosophy off-top when you're working with agents. So ThinkFast, I had TODO a lot of here and there with my agent to make sure that everything he was building was on par with my vision. And it really made me think of a lot more products I can build that will help me with that design vision problem. Right? And that's another thing that this 60 by 60 does is within the first app, I think fast within the first app I was building, I already had my 10 next apps because I thought of 10 other ideas that would help me with all this project. So my current app for today is repurposing Varmada.com. I want Varmada.com to actually have a story now. It's not just going to be a landing page for my business. And so with ThinkFast with this design vision problem that I had, now I needed to have some sort of direction that I wanted to always bring my agents. I know I want to use Drizzle. I know I want an API-focused API-centric application. I don't want to have so much load on the client. I know I want Snappy, Smooth, Graceful animations. I know I want the minimalistic, dark with an accent colorish. I want it to look beautiful. I want it to look sleek, minimalistic. I want to cut off text. text is... not good. AI slot tends to be very text based. We want stuff to be intuitive, intuitive. intuition brings about ease, right? Whenever something is easy to look at, and something is easy to understand because it follows principles that are seen everywhere, it's going to be really easy for the user to operate. And that's the philosophy I want to go with. My initial renders for ThinkFast were bonded with text. So much text was in it. And it took me a long train the engine to say, yo, stop doing so much AI stuff.

Another thing that I needed to establish is the tools that I needed. So a lot of AIs, they have their own set of tools. They think that that's the best because that's what they see the most in their training data. But in my case, I really wanted the tooling to be in a specific way. Furthermore, I stray away from MCP now. Whenever I have a new super based project, I literally just provide the database URL and the database password to my agent into a script. And I say, here's a script, user database password, password in that address URL that are in the dot end. If don't look at it, don't print it out on the page, but use them to access the database and read through what's in the database and do changes migrations and functions and triggers and stuff that you would need TODO to be able to access all this information.

Alright, when it came to developing ThinkFast, here are the things that I prioritized. I wanted speed, I wanted ease, I wanted smoothness and performance, and I wanted it to look beautiful. That's my main focus when it comes to building a free game, sort of, because ThinkFast is, after all, a game that people play, and moreover, it is free. I wanted to- be cheap. I do not want to have to pay for ThinkFast. And that was my criteria. That is the things that I provided to my Metaprompter to create a prompt for my development of ThinkFast. So the things that I encountered along the way are I needed to make sure that I have enough resources to provide the game to many people. I needed to have a way to track user inputs. I needed to have a way to make sure that the user playing the game understand how much time he has. So I had to play around with the UI of the timer and the color changing in the background and stuff that. Something else that I have to worry about is, what am I gonna log? How am I gonna know that people are on the app? What am I gonna do? It made me think that cookies are important, made me think that analytics are important, made me think that I have to use post-hog in a way that is smart, not just render and or sorry, not just log every event because that will completely exhaust my free post-hogs. target count. And then also I need to understand how am I going to have users? Do I want to have users have not safe for work answers available? Should their answers even be public? How do I want to keep track of the top answers? Do I want semantic searching? So I did at some point include semantics. I was trying to build a semantic engine so that whenever a user enters something, they have the opportunity to say if that's what they meant. It'll automatically be put into a category and then And then they can say, no, that's not what I'm- and that would train the data. I could obviously have used the semantic engine by OpenAI, but I said, now would go against one of my four core principles of keeping this free. Eventually, I took off that availability, so we don't have semantics. Another thing we don't have is we don't have near-site texting or whatever it's called, which is the thing that basically connects a word if it's got an extra period or if a couple of The letters are written. written in capital case by accident or for where it is not completed because the user didn't have enough time. Stuff that were already implemented but they were too buggy. So I decided I would just leave it as is. Why? Because for example, if somebody had a quick thought to write MHA, for example, I would want the user to have the MHA the way they wanted it. MHA as in my hero academia. And that would cause the user's input to be exactly what they thought. So if a user wrote it by accident in capital case, it would actually be the actual way to writing it. If we had automatically normalized it to minimal case, we are losing some value from the thought of the user, which to me didn't make sense. And I would rather have a think fast data pool filled with answers that look the same and have high points and have high margins than have something that is semantically the same. is not incredibly accurate to what the user wanted to write. So semantics for me were a no-go at the end of the day. So at the end, I just decided to build this app the way it is, your input and whatever your input is going to be the thing that is stored. We don't have any way to find closeness. So that's one thing that I have to fix. Another thing that I have to fix is rate limitations. So this app is going to be free and that's the first time that I have a free app out there, and I didn't want it to have DDoS. So the problem with the... is that unless you have a provider that has systems in place to prevent that, it's essentially just you're going to have to be a key-value store owner, and you're going to be rate limiting users individually by IP address. Rate limiting users by IP address forces you to maybe damage people that are in the same IP address that didn't do anything wrong. Obviously at the state of the app right now and at the state of the current scale of the app, that would never happen. I don't even have two users, let alone a million, that could actually, some of them have the same IP address. But it is something that I always think about. And it's important to like, take a step back because over engineering things really causes you to like, understand that, oh my God, I should probably stop, right? And so yeah, that's pretty much the core principles I was thinking about. It was rate limitation. So what I ended up doing for a rate limitation is that I went out with Vercel. Because my domain is hosted on my Varmada.com website, which is a. domain host fit on CloudFlare. My Vercel domain redirection causes me to close the proxy, which now makes me vulnerable to DDoS. Thankfully, though, Vercel has its own DDoS protection. And on top of that, I added a rate limiting route. So if there's too many robots or if out of a sudden I got 300 requests on my slash API route, I'll completely 429 those requests. So I have some protection in place. It is something that made me think about those protections. And thankfully I have those, but it didn't make me think that I have to have some weight of protecting myself from that too. So that might be a product that I build within the 60 by 60. Another thing that I thought about is now I'm gonna build a lot of products and I'm supposed to have a footer for all of them that redirects the vermodic because that's the whole point is to garner an audience. And it's gonna cause me to, you know, have to have UT. and I always log my stuff in one CRM database that I connect all my projects to. So that causes me to have another idea is to, you know, make a way so I can easily create clicks and track those clicks. So that's going to be one of my 60 by 60 ideas.

But yeah, so that's about it. That's pretty much all I did for thing fast The first thing I did once I released it is make sure that the bugs were fixed There were some display bugs where the text was not overlapping and it was overflowing and you could not read as a user some It bugs some visual bugs when it continued to mobile sizing and stuff that but overall now it should be polished and It is completely free and what I did do is I pushed a post on both threads and Twitter both of them didn't absolutely zero views and so I didn't get any new users besides my wife and my sister and my brother and six of my accounts testing out stuff and so the app is completely free and virginized right now There's barely any answers. Virginize is not a real word. Whatever the real word is. That's the one I meant. That's what I meant and I also did Think about where I can post this and ask Chad Jip D for a bunch of stuff. And he gave me a bunch of subreddits to post it in which I will post it in once these blog posts have been up so that people can have a visual and a look on my thoughts building the 60 by 60.