Vibe-Coded Service Desk in 3 Days: What It Really Cost

We built a Jira Service Desk copy. Vibe-coded in 3 days. Well, sort of…

A year ago we had a brilliant teambuilding idea. Let's take a break from programming by... programming. The goal: could we vibe-code an entire service desk in a single day? So we split into small teams and started vibecoding.

And I mean vibecoding. Not agentic coding, not "AI-driven development." We did it the loose way on purpose, because the real question was: does vibecoding without any proper setup actually work? Short answer: it gets you something that looks done. It doesn't get you something that is done. Here's what the day, and the three weeks after it, taught us.

Vibecoding doesn't scale across a team

The first surprise was how hard it was for us humans to cooperate. With more than one team touching the backend, we spent more time resolving merge conflicts than building features. Vibecoding in a group needs serious coordination, and on a project this small I wouldn't put a team of humans on it at all. A team of AI agents plus one human? Different story, and I'll come back to it.

Vibecoding without a spec, or a workflow, is a trap

Our "specification" was one sentence: we need to build a service desk. Everything else we discovered as we went. Maybe add a Slack integration? Tickets from email? Image upload? Should the client be able to change priority?

That's a perfectly fine way to build a prototype, the kind you throw away once it has taught you what the spec should be. But we didn't want to throw it away, we wanted to build on top of it. So every feature we'd stumbled into had to be retrofitted properly, and that cost us far more time than two hours of spec up front would have.

Same story with the workflow. No feedback loop, no dedicated agent for end-to-end tests, none of the plugins and skills we use today. It was fast, sure. But the output isn't comparable to a proper agentic run in terms of bugs, security, or the ability to run unattended.

It looks like it's done. It isn't.

Here's the part I'd underline.

Getting from the hackathon to a first real MVP took me about two more days: fixing what the vibecoding left behind, refactoring the roughest parts into something maintainable. And it worked. A service desk MVP in roughly three days is a solid result, and it was real enough that we onboarded a few early clients on it.

Then the clients started using it, and we spent almost three more weeks before we were happy with the core.

So where did those three weeks go? Two places, and both were avoidable.

Part of it was features and refinements that only surfaced once clients were in the tool. That sounds like unavoidable product discovery, but it wasn't. A few hours of proper brainstorming up front, plus a little research with the people who'd actually use it, would have surfaced most of those before we wrote a single line. We skipped that thinking, so the tool told us later, the expensive way.

The other part was bugs. That's what plain vibecoding gives you when nothing is reviewing the work and nothing is testing the UI: it looks great in the demo and then falls over in real use. Those aren't specification problems, they're workflow problems, and they're exactly what a proper agentic loop, with a reviewer and an e2e tester, catches before anything reaches a client.

So the three weeks weren't a mystery. They were the bill for skipping two things: the thinking and the workflow. Do both properly up front and most of that time never gets spent.

How we'd do it now: agentic coding

That hackathon was fun (mostly). We vibecoded, drank beer, and turned out a decent result given the circumstances 😄. Today we'd do almost none of it the same way (except for the beer, of course 🍻). Two things changed everything, and both now live in a plugin the whole team can install from our internal Claude Code marketplace (I posted about it on LinkedIn, in Slovak).

Specification first. I say this in every article and I'll keep saying it because it keeps being true: the spec is the most important part now. You can spend more time writing the specification than writing (generating) the code, and that's completely fine. For something the size of the service desk, the plugin includes a /draft-spec skill that walks us through it, so we can go from idea to a real spec quickly, whether it's a whole system or a single new module on an existing one.

A real workflow, not just a chat window. Typing into Claude Code or Codex and hoping (with fingers crossed) is not a workflow. The rest of the plugin is the workflow itself, and it looks like this:

Split the spec into tasks. Our /plan-backlog skill breaks the spec into individual tasks and creates a progress.md file that tracks progress automatically.
Work the tasks in a loop. We call /loop /next-task, and the loop keeps pulling the next task until the queue is empty.
Inside each task, a small team of agents does the work: an Implementer writes it, a Reviewer checks it, and an E2E tester actually drives the UI (AI loves to ship a broken interface, so this one earns its keep). The Reviewer and the tester can hand a task back to the Implementer if something's off.
Task done, next task pulled.

The point is what it did to the output: the quality jumped enormously.

And I have proof. We decided to replace the rest of Jira, too. Because why not 😄. Phase one meant adding a Backlog, a Kanban board, time tracking, and a bit of a redesign. This time we ran it through the real agentic workflow: proper spec, split into tasks, each task built by the team of agents with a feedback loop. The result? Three days, feature deployed. One day on the spec, one day reviewing the PRs and sending feedback, and roughly five or six hours in between where the agents worked the backlog unattended. Two of the three days were human work. The agents ran on their own for an afternoon.

Same three days as the hackathon. Different three days, though. The first sprint shipped a real MVP, then charged us for everything we'd skipped: the thinking and the workflow. The second one shipped and stayed shipped, because both happened before the code, not after it.

One honest caveat, because it matters: this isn't "leave for the weekend and let the robots ship to production." We plan for a couple of hours, kick off the workflow, and come back to a stack of open PRs. A human reads them and reviews before anything merges. The agents do the heavy lifting. A person still owns what goes out the door.

So if you take one thing from our beer-powered hackathon: when you're picking a partner for a production app, look for the ones running an agentic workflow, not the ones vibecoding your product on vibes. ;)