We’ve just had an event in NNE with around 450 intended participants. An idea was to have a web-app for the event to increase participant engagement through gamifying speaker-audience interaction, idea generation & voting and gathering feedback.
We had fewer than 2 months from zero to app launch.
Because I’ve never developed an app and stakes were so high, my first instinct was to not take on the project. But my mind changed as soon as I saw the prototype that Axel vibe-coded in 30 minutes. We had never developed an app, but we took on the task and Copilot quickly became our friend and mentor.
We had rough expectations for what the app should do, described it to Copilot, showed it some of NNE’s corporate identity elements, and off it went. This was what we eventually came up with:
Vibe-coding wasn’t without challenges
We had to navigate working across two developers. As Axel and I shared this project, we thought about working collaboratively on GitHub.
But this quickly became problematic. Despite working on separate features for the app, our Copilot agents would overwrite the same files based on our separate prompts. This meant that pushing our edits into a single repository often resulted in several complicated conflicts.
(There is in fact, a painfully obvious easy fix: just get Copilot to resolve the merge conflicts! Thanks Matias 😄)
It was easy hosting and adding features to an app locally, but it was a different animal hosting it on the cloud. We had to decide on a cloud provider, get Copilot to recommend services necessary for the app, verify its recommendations, decide on a deployment method, make sure it didn’t get prohibitively expensive… and we also started running into errors that were not easily vibe-coded away.
On top of struggling to get a proof-of-concept that works from the cloud, security was also a big concern. How can users start logging in and interact securely with and within the app, and how would we set that up? When users start getting onto the app, how can we ensure that all features can handle 450 users using them simultaneously?
We starting hitting milestones
Plenty of questions, loads of doubts, but I’m glad that Axel and I had very different working styles. Axel rarely hesitates attempting or executing on an idea, while I’m usually a chronic overthinker stuck in analysis paralysis.
In this regard, I made sure that we didn’t execute on every single whim of an idea, and Axel very quickly got things that I thought were very complicated to start working, simply because he did it.
The first milestone we achieved was seeing the app deployed in Azure. A virtual network, an app-service, a database… we have a web-page!
We bought a domain, connected it to Azure Communications Service, updated the email-sending quota to 500 per minute… And we could now receive emails from the app! People should be able to receive their log-in credentials through their company emails concurrently.
Testing. The app needed to hold up on all features for 450 users. They would be logging in, asking questions, answering quizzes, submitting pictures, accumulating scores… So a separate Copilot agent came up with load-testing the app using K6. We could now send 500 emails to one email address without issue, and 450 users could exist on the app without lagging or crashing it!
We did not, however, know how to test sending credential emails to 500 separate existing company email addresses. So we technically could still run into issues if 450 different users tried logging in at the same time.
On the day of the event…
The app was a success! (Or so I was told 😄)
Streams of users logged in, asked questions, quizzes showed up on the app when it was time, people answered, points were awarded when quizzes closed, users could see their ranking, badges were awarded, photos were uploaded… the app functioned as it should. And we were some very happy people.
Here’s what building for 450 users taught me:
- Vibe-coding is way too much fun. All you need are ideas and expectations, and Copilot delivers. In fact, Copilot often times exceeds expectations.
- Do first, overthink later. Because code and changes are now so cheap, just ask, receive a prototype, and outsource your analysis paralysis to Copilot. It often comes up with good recommendations, but if you’re still not sure, give it second- (third-, fourth-…) order analysis paralysis by challenging its recommendations and iterate.
- Trust your agent, but verify. There were various instances where Copilot said a feature is delivered, but it was nowhere to be found after deployment. Because of that, I recommend testing each feature as they are built, instead of wrapping several in one big request, lest the smaller ones get forgotten.
- Seeing is believing, but stress-test it. Having a product in record time is exhilarating, but it could be vulnerable in the most unexpected places. We expected displaying pictures to be problematic (because size), but apparently ranking users based on their scores was equally, if not more problematic. Go through all your features and report your observations to your agent, it resolves issues quite robustly.
- Make error logs your b…usiness. You don’t have to be frustrated by a sea of red text anymore. Even better than observations, give your agents your error logs. They read and debug in record time — they win, you win.
- Stay calm and make sure everyone has internet. The app was developed in a calm environment with strong internet connectivity. These could be big assumptions during the event — and they were. Some users faced system timeouts as they had poor internet connectivity on their phones depending on where they were, which impacted user experience and engagement. So having a robust Wifi at the venue is crucial for such an app to succeed.
If you’re interested in how the app held up during the event based on monitoring metrics in Azure, discuss the system architecture, share how vibe-coding has overhauled your workflow… reach out, leave a comment — let’s connect!
The opinions and positions expressed are my own and don’t necessarily reflect those of NNE.
