Bets by Mitch
What’s Bets by Mitch
I am a notoriously bad sports gambler. It feels like I lose every bet I place. I don’t place too many crazy parlays either. I usually bet the spread, but just lose. I have tried strategies like doing the opposite of what I think will be the winning bet, but once I switch to that strategy all of a sudden my original ideas were great! I wanted to start tracking these bets more easily, the apps make it a little difficult to know how much money you’re throwing away. So I decided to make a quick web app tracking my bets.
Now as a software engineer, I believe you always have to keep the tools in your shed sharp. So I didn’t want to just sulk on how bad I am at gambling (gambling should be illegal!) and decided to take the opportunity to try some new products and tools in the AI coding realm. The goal of this exercise was not to find best practices or provide suggestions on what product is best. I just want to tinker and report back into the void.
The Website
To build the UI, I used Lovable. I was amazed. I gave it a single prompt and it essentially built the whole site in one go. I was very happy with the design and the features it delivered for my website. I ended up iterating for a bit to build out a separate “parlays” view, an admin console, and provide API docs (more on that later). This in total probably did not take more than 30 minutes.
Here we can see it provided a graph showing historical performance that can be filtered by both time and sport! Football ended up being my best sport.
The parlay view was built after a couple more prompts.
Some recent bets.
Now I have not had to work on front-end code professionally day to day in a few years, but from what I can tell the code it produced was suitable React code. It built reusable components, used hooks, didn’t overdo it and introduce something like Redux when it was unnecessary. I was okay with it. Behind the scenes the data store it looked to use was backed by Supabase. I am not familiar with Supabase and it did feel odd that it felt like it was writing and reading directly to a DB from front-end code, but I didn’t dig too deep. Maybe there was some API layer hidden in there, maybe this is something people do today. I don’t know and didn’t want to spend too much time digging. It’s a toy app about how bad I am at gambling!
The MCP Server
I found it burdensome to add my bets through the admin console Lovable built for me. I thought maybe this should be something else that an AI can do for me. So I asked Lovable to expose an API for CRUD actions on bets and parlays. Here it did create an API (that the front end did not leverage) in /supabase/functions/api, that I assume leverages an edge-functions-like feature in Supabase. Once again, I didn’t dig deep! I also asked Lovable to write some API docs for this API.
Now I wanted to build an MCP server on top of this API. So I followed the instructions for Cloudflare’s remote MCP servers. Or maybe more accurately Cursor + Claude Opus 4.5 followed the instructions. I asked Cursor to put the server behind OAuth and follow the API docs provided by Lovable to write an MCP server. This probably took under an hour end to end with getting everything set up and deployed.
Next I needed to leverage that MCP server with a client. First I tried ChatGPT. Getting the MCP server connected wasn’t extremely straightforward and there were a few hiccups. Probably more user error than anything, but the UX wasn’t very straightforward. So instead, I reached for the MCP originators and tried it out on Claude. While custom “connectors” are paywalled behind the pro plan, the setup is extremely easy and straightforward.
Adding a bet to my website was now as easy as sending Claude a screenshot of the bet on mobile.
Conclusion
The amount of functionality I was able to build out in just a couple of hours using these tools was almost a relief. These tools make side projects more fun again. I’m not worried about syntax or following clean code or avoiding premature optimizations. I was only worried about getting the product and my experience as a user right. These are not problems solved by AI, but AI was a good sidekick in this process. Proofs of Concepts, MVPs, side projects shouldn’t be perfect.
I honestly don’t think I wrote any code myself. I only entered prompts. Obviously if I was building something for production, I would’ve reviewed the code more closely. If it wasn’t just some fun project maybe I would’ve cared about the structure of the codebase more. One quick example is the MCP path and the UI’s Admin console would’ve used the same APIs.
There is no doubt though that these tools have their place. Imagine being a web engineer and getting a quick Lovable PoC that product whipped up instead of a back and forth on Slack with some vague instructions because the ticket was empty. Or early stage startups being able to build internal tools easily. Providing the right amount of dev time to admin functionality so engineering could focus on the right issues was always a painful balance. That burden now should be low. Customer Support or the back office could potentially even build their own admin tooling. The democratization of code is a good thing, there’ll still be a place for engineers even if everyone throws some code out there via an LLM.
Next Steps
I don’t think I’ll add on much more to Bets by Mitch or place many more bets. The data shows that I should stop betting immediately! Although from a tooling perspective it already seems like MCPs and Cursor are out of vogue. It’s now all about subagents and skills and Claude Code. So next I’ll find some new toy project to mess around with some other cool features.