A day of building without brakes. Our hackathon recap.

A phone reservation, fully handled by AI.

The biggest project of the day focused on a question that keeps coming up in the hospitality and wellness sector: what if a guest simply calls, has a conversation, and ends up with a reservation? No waiting lines, no forms, no human in between. It sounds like the future, but this was our Friday. To make this work, three layers need to operate like interlocking gears:

• a backend that understands requests and returns the right data

• a conversation engine that guides the dialogue

• an audio layer that converts speech to text and back

Starting plenary, with a shared architecture and defined scenarios, proved to be the right call. If the foundation isn’t solid, everything built on top of it will fail.

The MCP layer: the foundation underneath everything.

The first team started exactly there: a blank canvas and an existing data management platform. On top of that, they built an MCP layer: a set of endpoints the voicebot can call to retrieve information and perform actions. By the end of the day, it supported:

• retrieving products, locations, and availability

• creating actual bookings

The reservation flow works. Someone calls, the bot asks what they need, and the MCP layer handles everything behind the scenes. What stands out is what’s not there yet. The structure is intentionally designed to expand. Gift cards, more complex scenarios, additional roles in conversations, it’s all ready to be added. Built for today and tomorrow. Claude was used to build the MCP layer. ElevenLabs handled scripting and tooling. The conversation engine runs on Gemini Flash, orchestrated through ElevenLabs.

The voicebot: from text to real conversations.

If the MCP layer is the brain, the voicebot is the voice. The second team focused on the conversation itself. Not just technically, but also tonally. How should it sound? The first version used a calm, accessible tone suited for a wellness environment. Great for users, less ideal for testing speed. The solution was simple: switch to a faster test voice temporarily.

By the end of the day, the result was a full conversation, from greeting to confirmed reservation, in just two to three minutes. Someone calls a number, talks to AI, and books an appointment. One thing stood out: at one point, almost everyone at Cube was using the same AI model simultaneously. You could feel it in the performance.

Statamic Content Plugin: from raw text to page in two clicks.

Imagine having a Word document full of strong content that should already be a web page. Normally, someone has to manually rebuild it in a CMS, placing components in the right order. That easily takes an hour. This team built a plugin that removes that work entirely.

It works in two phases:

1. Scan
The plugin reads all available Statamic components, processes their structure, and uses AI to generate descriptions. It’s dynamic, new components are picked up automatically after a rescan.

2. Build
Paste your text, choose a collection, and the plugin creates a full page. The editor sees a preview with collapsible components and can generate a draft entry with one click.

Technical challenges.

The most interesting challenge was converting HTML into ProseMirror nodes, the format Statamic uses internally. Not simple paragraphs, but nested arrays of content objects, including recursive structures with unique IDs.

Then came the integration with Inertia.js, which Statamic 6 uses internally. Midway through the day, they decided to migrate the UI from Blade to Inertia. Not planned, but it resulted in a plugin that feels native instead of bolted on. Claude Code supported throughout the day: architecture, code generation, migration, and debugging.

Developer Mode for React Native apps: observe without interfering

Imagine a user reports an issue. You want to see exactly what they see, on their device, without accessing or modifying their data. That’s what this project solved. A Developer Mode feature for React Native apps, built in a single day.

It includes:

• a hidden activation method secured via environment variables

• a developer screen with three core features

Impersonation
Works via a QR code generated in the admin panel. Valid for 60 seconds. Scanning it gives read-only access to a user session.

Logging
API calls and errors are stored in encrypted files on the device.

Control
Sessions can be viewed, shared (AES-256 encrypted), or deleted.

The hardest challenge: session management.

Logging out normally clears all tokens, including the original session you want to restore. The solution: keep the original session in memory and restore it after impersonation ends. One of those solutions that feels obvious in hindsight. The entire feature, from backend to app, deep linking, encryption, and admin panelm was built with Claude Code.

Review Apps: every feature its own playground.

You always review code on an acceptance environment, never blindly. But what if every feature branch automatically gets its own fresh environment? Then you don’t have to wait for someone else to finish, and you can review changes exactly as they were intended, separate from other changes that happen to be on acceptance.

That is what this team built: review apps, automatically created per merge request, based on Docker and GitLab CI/CD. As soon as a developer creates a feature branch, a pipeline starts that connects via SSH to a Docker server and spins up the application, complete with database and cache instance. The URL is dynamically generated based on project and issue.

The foundation is there.

On top of that: a preview button in the issue via a Chrome extension, and within the merge request itself a comparison feature that lets you place changes next to other environments. At the end of the day, the deploys of both environments were working, both locally and via the pipeline. What is still on the roadmap: standard Docker configurations per framework and the full OTAP pipeline. But the foundation is there. And with its own environment per feature, reviewing becomes a lot faster and more accurate.

E2E testing with an AI agent: the browser as test pilot.

Manual end-to-end testing is one of those tasks everyone considers necessary and no one enjoys doing. You click through the same flow over and over, check if everything still works, and hope you didn’t miss anything. This team tackled that challenge with an AI agent that takes over the browser work. The foundation was already there: a working OpenClaw/NemoClaw setup with browser-driven flows. What was still needed were more robust test flows, better tracing, and smarter handling of accounts and credentials via 1Password. What was built that day: browser actions for navigation, selecting options, filling in forms, and performing validations. Plus tooling for reproducible test flows and insight into intermediate steps through debug and tracing functionality.

The biggest challenge was making multi-step browser flows reliable. Dynamic pages, complex reservation steps, iframes, and UI state synchronization, these are exactly the things automated tests tend to struggle with. The team worked through them methodically. The result at the end of the day: a working desktop browser flow that goes through a full reservation flow, from date selection and extras to ritual steps, and stops just before the payment step. The foundation for full E2E validation is there. AI supported throughout the day with architectural decisions, setting up the browser flows, test logic, and error analysis. The speed at which iterations were possible was noticeably higher than without it.

And beyond that: two projects that pushed the edges.

Two more projects filled the day, both valuable in their own way: CI/CD automation and an honest experiment with a new technology.

One team worked on integrating a CI/CD pipeline with an external deployment platform for Statamic and a DMP. The goal: deploy code from a local environment to staging via GitLab, without manual steps. By the end of the day, deploying both environments worked, locally and via the pipeline. HTTPS configuration is still an open point. The rest is in place.

Then there was an exploration of Vue.js Lynx, a relatively new package for building native apps with Vue. The honest conclusion after a day: the documentation is limited, custom fonts and SVGs cause issues in the native variant, and styling is not yet up to standard. But forty percent of the screens are built, the web build works, and the team now knows exactly where the limits are. That is valuable information. Knowing what doesn’t work yet is also building.

Tech Builds: what a day of building delivers.

At the end of the day, there was a demo. Someone called a number, spoke to an AI, and had a booked reservation two minutes later. A CMS plugin turned a raw text dump into a fully structured web page. A developer logged in as another user, observed, and stepped out again without leaving a trace. An AI agent clicked through an entire reservation flow without human involvement.

These are not features from a roadmap. They are proven assumptions, ready for the next sprint. Ideas that, in a single day, made the jump from “could this work?” to “this works.”

That is what a hackathon does. It replaces months of careful exploration with a single day of direct answers. And with an office now large enough to give every team its own corner, there was all the space needed to find those answers.