A Non-Developer's First App, Built with AI

I'm a marketer, not a developer. Working with AI, I started on a Monday afternoon, opened internal QA 27 hours later, and launched a Closed Beta early Thursday morning. Here's how I built it, with the numbers, the mistakes, and the tech stack, nothing held back.

After our launch event yesterday, a lot of people asked me how I actually built this thing. Giving a talk or shooting a video felt like too much, so I decided to write it up instead. Truth is, AI wrote this post too, working from our commit history, Slack messages, and meeting notes. All I said was, "People seem curious about this stuff, so write a blog post focused on what they'd find interesting and leave out anything sensitive." I didn't change a single word. (When I try to edit it, it only gets worse. The "Wrapping up" section at the end is the only part I added.)

You can sign up for the app at app.bloomworld.ai. Once you sign up you go straight onto the waitlist, and people get access in order.

Bloom

Why a web app, and why me

As I mentioned in an earlier post, I built a web app for the Bloom community. People inside the company had talked about building an app before, but App Store and Google Play review takes time, and above all we didn't think we had the resources to spare, so it never happened.

Then our community members kept telling us they wanted an easier way to get information and more chances to connect with each other. We decided to build the thing everyone is most used to, a mobile app, and to start with a web app since it doesn't need any store review.

The question was who would build it. After some thought, I decided to do it myself, a non-developer marketer who had never built an app, or anything else for that matter. My biggest worry was picking up the project, failing to see it through, and leaving it half done.

So I first showed my coworkers the MVP screens and features I'd made, and asked whether, with something like Opus 5.5 these days, this could be done within a week. They said that was more than enough time. They also said one person driving it from start to finish would be far more efficient than several people trying to coordinate.

Timeline: started Monday afternoon, launched early Thursday

I took them at their word and got started that Monday afternoon.

- Mon 9/28, 3:28 p.m.: First commit, starting from a PRD in Notion and the prototype screens I'd made - Tue 9/29, 6:26 p.m.: Internal QA begins, 27 hours after the first commit - Wed 9/30: QA rounds 2 and 3, more than 100 pieces of feedback addressed - Thu 10/1, early morning: Closed Beta begins, invitations go out to our Gardeners - Thu 10/1, evening: Launch event, "Bloom App x Gardeners"

Of course I'm still fixing small features and copy. But it runs smoothly and every feature I planned made it in. At this point I feel like we could add everything LinkedIn, Remember (a Korean business card and networking app), Luma, and eventually even Discord do (though that last one depends on how much server capacity it eats).

I also tried a feature where AI finds events that fit you, just by saying "hook up OpenRouter's free models." It uses three free models in turn, and if one gets blocked it moves on to the next. I set it up so it can't use a paid model, even by accident.

The first four days in numbers

These cover Monday afternoon, 9/28, through Friday morning, 10/2.

- Commits: 942 (489 app, 453 server) - Merged PRs: 83 (43 app, 40 server) - Automated server tests: 5,541. Every one has to pass on every deploy (including the existing Mixer server tests) - Pre-deploy integration QA: 30 real user flows, from sign-up to check-in - Numbered planning decisions on record: 124 - App screens: 14 - QR bug at the event: about 15 minutes from report to deploy - First day of Closed Beta: 332 sign-ups (being let in from the waitlist in order)

"What language did you use?"

Yesterday a community member asked what programming language I used. I told them I'd never thought about it. It didn't really matter for building it, haha.

So while writing this post, I asked Claude for the first time.

- App: A web app (PWA) built with HTML, CSS, and JavaScript. Add it to your home screen and it opens like an app. The prototype screens I drew with Claude are used as the real screens - Server: Python (FastAPI) + PostgreSQL. We grew the same server that had been running Mixer since August - Deployment: Docker on AWS Lightsail, with Cloudflare in front. GitHub Actions only ships code that passes the tests - Zero-downtime deploys: Two app servers run side by side and get swapped out one at a time, so deploying in the middle of an event doesn't cut anyone off - Payments: PortOne + Toss Payments. Registering a card costs 0 won; Plus is a 20,000 won monthly subscription - Integrations: Automatic import of Luma events, blog and YouTube feeds, web push notifications - AI: OpenRouter's free models for event discovery

The PRD is the guardrail

Before building anything, I wrote the PRD in Notion in as much detail as I could. When you keep adding features, it's easy for the AI to go off the rails and build all sorts of things. So every time it built a new feature, I had the AI check it against the PRD on its own to make sure nothing drifted from or conflicted with the original plan.

When something needed to change, it had to update the PRD first and log what changed and why, with a number. My own thinking changes as I build, too. Those decisions added up to 124 in four days.

The PRD starts with background, goals, and KPIs. The target is 1,000 Mixer sign-ups by October 31. Your first Mixer is free as long as you register a card, and from the second one on it's Plus (20,000 won a month, unlimited Mixers).

When we ran Mixer on the web in August and September, close to 170 people signed up. Back then it was 20,000 won per session, but some people said a subscription would be better, so we switched. I'm hoping that makes it easier for people to come this time.

One of our Gardeners, a developer at Toss (the Korean fintech company), asked how I'd built it in two days. They seemed more curious about the feel of it than the features. Honestly, there were already lots of great references to draw from, and I had a pretty clear idea of what I wanted to build:

- Find and create events, like Luma - Find and create small curated gatherings, like Mixer - Connect with each other, like on Remember - Cute touches, like decorating your card - AI sorting events into topic tags

How we did QA

QA ran in three layers.

1. At night, Claude on its own. When I say "run QA," it spends the night in a real browser clicking through 30 flows itself (sign-up, invitations, the waitlist, Mixer applications and card registration, connection QR codes, on-site check-in) and fixes what it finds. Before any deploy, it has to pass all 5,541 server tests and all 30 flows.

2. During the day, a company Slack thread. Coworkers tried it on their own phones and left one issue per message in the thread. The developers described things precisely. Me, I honestly wrote total garbage, haha. Claude read the thread regularly, put a green check on each message it had seen, and posted a status update after fixing things.

3. Finally, a recording. Junsu and I spent an hour looking at our phones and just talking, without taking a single screenshot. I handed over the whole transcript of that meeting and said, "Listen to what we said and fix it yourself," haha.

We did the same thing on the Discord where our community members are. When someone posts in the feedback channel, Claude reads it, puts a green check on it, fixes it, and then posts what's been addressed.

What happened at the event

At the launch event yesterday, I demoed the app and asked everyone there to try connecting with each other. And wouldn't you know it, the QR codes that had been working fine stopped working. Some people said scanning the QR logged them out, others said the code was too dense to scan, all at once.

Right there I told Claude, "The QR isn't working, fix it." A few minutes later the fixed code was up, and in about 15 minutes it was deployed. In the old days, this is when I'd have called a developer in the evening and begged them to take a look fast. It was a simple feature, sure, but there was nothing I handed to the AI that it couldn't do.

The cause was interesting, too. When you scan a QR code with the iPhone's built-in camera, it opens in Safari, not in the app you added to your home screen, and the two keep separate logins. Nobody had actually been logged out. Safari just didn't know they were logged in.

So we changed the instructions to tell people to use the "Scan QR" button inside the app, and made it tell you to go back to the app if it opens in Safari anyway. We also made the QR code less dense (from 53 modules to 41) and drew it bigger.

How someone who doesn't know git avoids breaking things

- Work always happens off to the side, and only what passes tests and QA goes into the live service - The order is always the same: change request (PR), automated tests, integration QA, release. Server first, then the app - Production data only changes when I've OK'd it. When it needs checking, it only reads numbers - What changed and why gets recorded in the PRD and the work log

Invitations, Clubhouse style

Sign-ups work by invitation, like early Clubhouse. Since this is a Closed Beta, I wanted to bring people in gradually, starting with some of our members. Everything has its trade-offs, but where early on we wanted as many people as possible to come, now I wanted to gather people who are on the same wavelength and build a character that's our own.

So invitations went first to people who'd come to our events many times, people who came to yesterday's launch party, and our Gardeners. Each person got 2 to 10 invitations so they could bring in people they know first. If you don't have an invitation, put yourself on the waitlist and people get in every week, in order.

The onboarding video: inspired by 222

Last, I made an onboarding video, about 50 seconds long. You can skip it, of course. But this is where I wanted to put in real effort.

The inspiration was an app called 222. It's a New York app backed by Y Combinator, and it's also the reason we started Mixer in the first place. The slogan is great: "explore serendipity."

As it happened, a friend who lives in New York was visiting Korea for a bit yesterday, and while we were talking about Bloom, they asked if I knew 222. You need a US phone number to sign up for 222, so actually joining is hard and you can only watch the onboarding video. But that opening video alone pulled me right in and got me interested. While studying it, I also found a YouTube channel that breaks down how apps like this handle sign-up.

Inspired by that, I wanted mine to feel like a movie trailer. The most important part was the copy. At first I just dropped in my LinkedIn post about why I built this, and that turned straight into the script for the onboarding video.

For photos, I tossed it the ones on my blog and told it to use whatever it wanted, and it put everything together without me touching a thing. At first the copy felt a little cringey and I wasn't sure about it. I tried to fix it myself, but I had no ideas, and the more I edited the cringier it got, so I went with what the AI wrote.

Wrapping up

The key to this project was writing a fairly detailed PRD in Notion up front and starting development from that. To do that, I had to be clear with myself about what I wanted to build, and in the end the picture in my head came to life almost exactly. I think that's why the result didn't stray too far or fall short.

The other thing was handing the feedback loop to AI. User feedback on Discord and internal feedback on Slack get collected in real time, and Claude acts on it right away. It doesn't apply every suggestion as is, of course. Requests that fit the PRD get applied right away with no check-in, and suggestions that fall outside our standards get sent to me first for review. It was really good at telling what it could decide on its own and what it should ask me. The things it asked about were usually a little outside our standards but pretty convincing, and when I approved them, Claude updated the PRD and, once the change was in, announced it in each channel.

What matters most here is less the automation and more the process of building in public, together with the community. As members volunteer feedback and different opinions and ideas mix together, the app gets a little better every day, new features get added, and the screens and UX get polished. Users get to watch their own ideas show up in the product in real time, so they get more and more invested. It feels less like an app you use and leave, and more like a space we're building together.

The fun part was the day we first introduced the app to our Gardeners. It was around 3 a.m., and naturally I was asleep. While I slept, development wrapped up, invitations went out to the Gardeners by one-on-one DM, their feedback came in, and the app kept getting fixed based on it. Seeing that, I thought, "OK, I can really trust it with this," and it was a huge relief.

AI is like a water dispenser. With a water dispenser, you set it to pour the right amount and you can do something else in the meantime. If you don't get the amount right, too little comes out, or it overflows. AI is the same: ask for the right amount at the right level and it delivers exactly what fits, so I can work on other important things in the meantime. We used to not have a water dispenser at home, so to get a drink I had to stand at the sink holding a cup and wait, and I hated wasting those 10 seconds. Now I just push the button, go do something else, and come back to drink, and it's so much more relaxing. It's a slightly silly comparison, but that's how relaxed and reassured I feel working with AI.

So that's how I built the first app of my life. More than anything, building it was so easy and the result turned out so well that it was a ton of fun. Going forward, I want to keep improving it while trading ideas freely with our community members.

You can check out the app at app.bloomworld.ai. If you have an invitation you're in right away; if not, join the waitlist and you'll get in in order. If you know someone who's a Bloom member, ask them for an invitation. And if you want to help build it with us, come join the Bloom Discord (discord.gg/KRvfQTNrxH).

Originally written in Korean on Brunch, October 2, 2026.