Introduction
At Lonestone, thirty of us share three meeting rooms. Sometimes booked through our calendars, more often claimed by whoever gets there first. Not ideal at the best of times, even less so since around ten co-tenants joined our offices. We needed a tool that was simple, shared, and accessible to everyone. Rather than waiting for a solution to appear, I decided to build one myself — without knowing how to code.
How might we give thirty people a simple, shared room booking system, without resorting to an oversized third-party tool?
Product design for the booking tool.
Prototyping and AI-assisted development with no prior engineering skills.
Built with Vincent Ghislain — iterations, fixes, and production deployment on Render.
Problem definition
Room booking tools exist, but they are either too heavy to deploy or too generic to fit the reality of a shared coworking space. In a human-scale environment, what you need is a tool anyone understands in ten seconds, accessible without friction and flexible enough to grow.
An everyday problem, no existing solution
The "first come, first served" approach works until the day it doesn't. The arrival of new co-tenants made the problem both visible and urgent.
Oversized third-party tools
Market solutions assume an infrastructure, an admin setup, and an onboarding process that nobody at a place like Lonestone has time to manage.
A mockup as a starting point
Rather than specifying requirements in the abstract, I chose to materialize the intention in one hour with a single screen. No wireframes, no business rules, just a vision of what it could look like.
Solution design
In one hour, I produced a single screen to give the idea a concrete shape. No formalized user journey, no functional specs, just enough to communicate the intent and start a conversation with the AI. That evening, I shared the mockup with my favorite LLM, walked it through my constraints and intentions, and came away with a clear action plan to start building.
I don't know how to code. Two to three hours later, Rooomies was running locally, looked like the mockup, and had the core features in place: booking a room, canceling a reservation, browsing booking history. The code is far from perfect and hard to scale, but it does the job. I had also set up a back-office to manage users and rooms, already thinking about what might come next.
Vincent Ghislain joined the project two days later. Together we improved the UI, added recurring meeting support, fixed avatar persistence bugs, and secured the back-office. Vincent also handled the production deployment on Render. It was my first commit. Quite a moment.
Results & learnings
This experiment ran for a few weeks and gave the Lonestone team and our co-tenants a way to book a room, cancel a reservation, and check booking history — no training, no documentation, no friction.
This project gave me something years of design work hadn't quite delivered: the satisfaction of shipping something end-to-end, from the first mockup to production. No client to convince, no brief to interpret, just a real problem and the drive to solve it.
It also confirmed that a mockup remains the best language for communicating intent, including with an AI. Showing before describing works just as well with LLMs.