Back to Blogs

Blog Part 3: The Launch, the Panic, and the "15-Request" Problem

Note: This is the third part of my series on building BeamUp.in. If you’re just joining, you can catch up on Part 1: The Why and Part 2: The Build.

From Team Member to Solo Founder

In my career so far, I’ve been part of countless "Go-Live" calls across multiple organizations. I’ve sat in pre-launch decision meetings where teams performed final checks and experts from different departments scrutinized, designs, functionality, every line of code. As a designer, I’ve analyzed design, inspected design, and tested things countless times and said yes or no to the product owner or project managers from design team.

But this time, it was different. This time, I wasn't just being asked,"Is everything good to go from the design team?" This was the first time I was the person responsible for everything—from the concept and requirements to the design and deployment—was in my hands. I was 100% responsible. It was just me and my AI digital assistants. I did the first deployment of my life (yaayyy for that!), and it went well at first. But before we get to the point where everything broke, let's look at how I got there!

Building a Platform

I had the tool working in Google AI Studio, but I didn't just want to share a test link. I wanted to build a platform. I wanted a space that could house not just this resume scanner, but all the future experiments I planned to build.

I went the "traditional" route for hosting. I chose WordPress because it gave me the freedom I needed, fit into the ecosystem I was comfortable with, and—most importantly—I had a coupon, a history of working with it, and I knew where everything was. To keep costs at essentially zero, I didn't buy expensive themes or plugins. Instead, I went back to my Virtual Team of Gemini Gems.

I chose a very basic free theme and told my "Web Developer" persona what I needed. They generated the HTML and CSS code blocks, which I then inserted into the free WordPress theme. It took some styling iterations, but it worked. I had a website. Now, I just had to connect the tool.

The Deployment Chain: GitHub & Vercel

This was a major learning curve. Even though I knew about GitHub, I didn't really know the details of "repositories" or "deployments." When I saw the Sync to GitHub icon on AI Studio, my curiosity took over.

I did some research to find out what it was for, and once again, I consulted my digital team. They suggested multiple options for how to do this. I’m not going to cover all those options here because that would take another blog post on its own, but I chose the most cost-efficient one: GitHub and Vercel. For those of you who don’t know what GitHub and Vercel are, I’m adding links to some very useful videos below that explain the basics:

Learn the Basics: GitHub

Github for dummies

Github explained in 10 mins

TLDR: GitHub creates a repository (free up to 100GB) to hold your code safely.

Learn the Basics: Vercel

Vercel product walktrhough

TLDR: Connect your GitHub repository to Vercel. Vercel takes your code and hosts it as a live, working app.

The ecosystem was now complete: well at least in theory, I needed to set up repository, Vercel with my Gemini Api key etc. Once that was done then I would design in Google AI Studio, push the code to a GitHub repository, and Vercel would automatically update the live tool. Finally, it was all done! But then, how do I show this live tool on my website? My virtual consultants came to the rescue. Amongst the many suggested approaches, I used an iFrame—a concept I had heard of but never implemented myself—to "window" that tool directly into my WordPress site.

The "First Launch" Panic

I posted the link on LinkedIn, and the response was amazing. People were messaging me saying, "This is amazing, it works. Thank you for this!" In the first two days, about 60 people had used the tool.

Then came the second day!

The Developer's Panic: I received a DM from a former colleague: "Chinar, the tool isn't working." I went to the site, and he was right. Everything was gone. Nothing was visible. That was the first time I truly felt the developer's panic. Nothing is technically "at stake"—there’s no money on the line, no giant brand or job—but my "experiment" was broken. That also after it was working perfectly fine just few hours back! What made it worse? I was traveling. I didn't have my desktop. I only had my phone.

Power of Editing on the Go: Mobile

Using just my mobile phone, I opened Google AI studio in mobile browser (there is not dedicated app for the AI studio yet!) I started analysis, asked Google AI studio to do a detailed QA of the tool. Also provided Ai studio with the live link of tool and screenshot of error. But it was not able to resolve the issue. Then I took the tool link and gave it to my Backend and Frontend Gems. I asked them to analyze why it had stopped working .

💡 Pro-Tip: The Generalist vs. Specialist Approach

In hindsight, this might have happened because I had not given System Instructions to Google AI Studio while building my app.

There was a good reason for that: I wanted a very generalist code-building tool. However, if you are looking for something very specific, you can provide System Instructions to guide the AI's behavior more strictly.

Learn more about System Instructions: 🔗 Google AI Studio: System Instructions Guide 🔗 Video: Deep Dive into Gemini System Prompts

They found the issue, I converted their analysis into a prompt for Google AI Studio, and I patched the code—all from my phone while in transit. (In hindsight, I also could have used the Gems directly to give me appropriate prompts as well!) An hour and a half later, it was back up. I messaged my colleague: "Please check now." It was working.

The "Success" Problem: 15 Requests Per Minute

Two days later, another round of panic. A student reached out saying they were getting a "Server Busy" error..

I realized I was a victim of my own success. On the free tier of the Gemini API, there is a limit of 15 requests per minute. And so many people were using the tool at once that we were hitting the ceiling. It was a moment of mixed emotions—I was happy people loved the tool, but concerned they couldn't access it.

I'm still working on the best way to navigate those limits without breaking the bank, and I will cover that in the next blog!

Lessons from the Launch:

The "Digital Team" is real: I couldn't have debugged a deployment error from my phone without my Gem consultants.
Redundancy is key: Always have a way to access your code on the go.
Scale happens fast: Even a small project can hit API limits if it solves a real problem.

Blog Part 3: The Launch, the Panic, and the “15-Request” Problem