People assume the hard part of building an app is the code.

For my first webapp, BriefBee, the code was the quick bit (even though I have no idea how to code). The hard part was everything that happens after “it works.”

‍

How I came up with the idea

BriefBee started as a reaction to life inside an agency where teams are siloed and designers are shared. Every project kicks off with a brief, yet no two briefs ever look the same.

Designers, editors and retouchers I spoke to told me they were constantly translating formats, and managers admitted to brief fatigue.

I wanted to see if I could make the process feel calmer and more consistent, so I tried a simple idea: an AI powered chatbot that asks role-specific questions, pulls together the messy bits, and spits out a clean, custom branded document.

‍

The Build Phase

Within two weekends I had a working web app. Lovable handled the front end and dashboard, Supabase took care of auth and data, and n8n ran the AI Chat Agent and automated the workflow. I even used Resend to create email notifications for the user. I took it a step further and gave it a name and a suite of brand assets… because I can’t help myself.

It moved fast. The dashboard as done in minutes and the first chat loop was almost there. Even the branded pdf exports felt good once the pipeline was finally in place (after a lot of wrestling). That early momentum felt very addictive.

‍

Then it broke

Then, the cracks started showing, which i guess is the issue with vibe coding.

I began with raw HTTP requests in n8n long before I found the Agent nodes, which meant broken headers everywhere and a lot of “why is this node red again.”

But the real bottleneck was the time it took me to learn just enough JSON to fix it all, before starting it again with the right nodes.

Fonts and margins in the PDF export behaved… until they didn’t. And because Lovable already had its own chat UI built from the initial prompt… while my AI brain lived in n8n… the wiring sometimes felt like teaching two strangers to talk, in different languages.

Everything worked in the end, I just didn’t ship it, and that part still stings a little.

‍

What I really mean by vibe-coding

When I say vibe-coding, I mean building software by describing what you want in plain language and letting an AI generate the code for you. Tools like Lovable make this feel like magic. You prompt. It assembles pages, functions, and even bits of backend with an easy Supabase integration. You stay in natural language almost the entire time. It is brilliant for speed and for getting from zero to something you can click, but it’s difficult to scale.

Where I believe it falls down is the invisible decisions. To keep things moving, the AI fills in gaps you didn’t specify. It chooses a data shape. It guesses how state should flow. It picks an auth pattern and error paths. None of these are wrong in isolation, but they are the AI’s strategy, not yours. As soon as you add a non-obvious requirement, those hidden choices surface as fragility, and security can get messy if you do not tighten the boundaries yourself.

That’s what happened to BriefBee. The loop worked fast because the AI made hundreds of tiny calls on my behalf. When I later tweaked roles, exports, and how the PDF should be styled, I was negotiating with earlier guesses I never explicitly approved. It caused it to break and it often led the AI to change stuff it really shouldn’t need to.

‍

So what’s the fix?

For now, I treat tools like Lovable, Base44 and Replit as a starting position for prototypes and small internal tools. They’re incredible for getting from “what if” to something you can click. They’re just not quite ready to carry a heavier product without a lot of extra scaffolding… yet. (I think they’ll get there pretty quickly though).

If you are going to use them, front-load the thinking. Write a real PRD. Spell out the data model, roles, permissions, edge cases, error states, and what a finished export should look like. Put as much of that context into the very first prompt as you can, so the AI isn’t forced to guess. The fewer blanks you leave, the fewer hallucinations you inherit later.

That’s the rule I’ll follow on the next build: prototype fast with vibe-coding, but only after I’ve answered the boring questions in writing. If the idea earns its keep, I can harden it or lift the good parts into a more explicit codebase (and hire someone who knows what they are doing).

‍

Why am I sharing this?

Because this site is where I practice in public. BriefBee did what I wanted it to do by proving I can take an idea and turn it into a working web app pretty quickly, with no coding skills. It also showed me where speed turns sticky, where vibe-coding is brilliant for momentum but shaky when you ask it to behave like a finished product. Writing this down is how I make the next build cleaner.

Most importantly, I’m not trying to present a highlight reel. I’d rather show the bits I got wrong, the blind spots, or where a tool just insn’t ready yet for my grandiose ambition. If I document the mess, I’m less likely to repeat it. And if you’re building something similar, maybe you dodge a week of head scratching that I’ve already done.

Sharing the path creates a little accountability. If I say out loud that I should have shipped earlier, I’m more likely to push the next thing over the line. If I explain where the approach bends, I’ll feel the weight of that choice when I’m tempted to cut the same corners again.

There’s also a selfish reason, I want to understand if there is demand for a product like BriefBee. If this idea still resonates with people who write and wrangle briefs, I can justify bringing it back to life (but better). If it doesn’t, that’s useful too. Either way, I learn in public and keep moving.

‍

If you are a marketing manager, creative director or anyone who spends time writing briefs, I’m curious. Would you actually use a chatbot that guides the questions and outputs a branded PDF you can send straight away? If yes, drop me a note or DM me on LinkedIn and let me know how you’d use it.

‍