Vibe Coding the Tools
Your Business Is Missing

The first session goes from an empty account to a published app with an admin dashboard. Not a good app. A real one. Here is what I would do the same way again.

I set up the design system before I described a single feature. Base44 lets you import one from a URL, so I fed it our hackathon landing page and let it pull the dark theme, the purple accent, the button styles. It took a couple of minutes and it meant the first version already looked like it belonged to us. Doing this afterwards would have meant re-skinning every screen it had already built.

Then plan mode, not build mode. I dictated the brief out loud rather than typing it, which is how I get the detail in – the four participant types we actually see at every edition. The people who already have their team and just want to start. The people with an idea who need to recruit. The people who want to join someone else's thing. And the people who want to be left alone and just watch. None of that is on any website. It only exists because we have run this five times.

The step people skip is the fourth one. Plan mode asked me a question I could not answer without changing the whole shape of the thing. It wanted to know how ticket verification should work – and answering it made me say out loud that we run this every quarter, which means multiple events, which means the entire data model needed an event layer I had never mentioned. That was a very big piece of information I had simply not given it. If I had been in build mode, I would have found that out three sessions later.

I also cut things on purpose. Mentors are display-only, no booking system, because booking is not the point. You can add it later; you cannot un-spend a week on it. That kind of scoping is the same discipline as shipping something complete in 48 hours – decide what the thing is for, then protect that.

What came back was better than I expected. A live admin dashboard with participant mix by track, editable pitch order, an invite flow for ticket buyers. And one decision I did not ask for: it separated the permanent profile from per-event participation records, so someone who comes to two hackathons does not sign up twice. It made that call because it had understood we run these quarterly. The Q&A paid for itself.

Version one was a solid six out of ten, and I want to be precise about that number because it is the correct expectation. Six out of ten after one prompt is extraordinary. Six out of ten is also not something you put in front of 150 paying participants. The second session is the boring part that makes it real, and it has its own rules.

The first one is counterintuitive if you have been taught to give an AI one clear instruction at a time. Batch your changes. Ask for six things in one message, not six messages. It is faster, it burns fewer of your monthly credits, and the model handles it fine. The catch is on your side: when it comes back, you have to check all six. It will quietly do five.

The second rule is to use the thing as a user, not as its author. I created a team called HackBase, then went looking for it on my own home screen – and it wasn't there, because being a team's leader hadn't been wired to being its member. You do not find that by reading the code. You find it by clicking around like someone who paid for a ticket.

The one change I genuinely stopped for was splitting a single full-name field into first and last name. It asked me to approve it, because it is a database change, and it was right to ask. But the reason I wanted it is not technical at all: I address people by their first name in every email we send, and real names are messy. Double names, emojis in the middle, titles. If the field is one blob, the greeting comes out wrong, and a wrong greeting is the fastest way to look like a robot to 150 people. That is a product decision wearing a database costume.

The move I did not expect to like this much was asking the agent what it would improve. It came back with a profile-completion nudge, the current team surfaced as a link in the sidebar, and a live preview of how your profile looks to other people. All three were better than what I had queued up. That is the same posture as letting an agent write back into your own documentation – you get more out of it when you stop treating it as a typist.

And a small thing that saves a whole afternoon: I did not write new legal pages. HackBase's footer points at the Pirate Skills imprint and privacy policy, because the data does in fact land with us. If the tool is for your own business, reuse your own business's paperwork.

Second session ends with a working burger menu, a real logo, a profile people would actually fill in, and a footer that says built with 🤍 by Startplatz and Pirate Skills. Still not launched – sign-up and onboarding come next, and that is the part that decides whether any of this gets used.

This page is not finished, and that is the point. Every session gets recorded and added here as its own part, with its own link, so you can follow one piece without watching the rest. The deadline is real: 150 people walk in on September 4th and either use this thing or don't.

You can look at what exists so far at hackbase.base44.app. It is genuinely half-built, which is the honest state of a thing being made in public.