When Is Vibe Coding Enough? An Internal Office App in a Few Days
An annoying daily problem became an internal business application used by the whole company, and it took only a few days. We had no development team, no separate budget and no new infrastructure. The app was built by a colleague who doesn't write code on a daily basis. The coding was done with AI, using a method called vibe coding.
Two things made this possible. The first was Google Workspace, which already offered ready-made solutions for the harder parts of software development: sign-in, user permissions and operations. The second was artificial intelligence, which guided the work from the first step to publishing. The LogiNet parking booking app is a good example of how much you can get out of a platform you already have, when you aim for a targeted solution built on that platform instead of a big app development project.
The problem: parking booking in Google Workspace, with no overview
Our office has several parking spaces. We added them to Google Workspace as resources, so they can be booked from Google Calendar, just like meeting rooms. On paper, this worked. In practice, it was hard to tell quickly which space was free right now, or who would leave first.
We first checked whether Workspace has a ready-made screen for this. It doesn't. The built-in tools offer either a usage report after the fact, or a door display for meeting rooms that depends on hardware. Meeting room booking systems on the market would work, but they are too big and too expensive for a few parking spaces.
Step one: a "dumb" but quick test with Google Calendar
The simplest option was the embed feature in Google Calendar. We showed the calendars of all the parking spaces side by side on one page. This took half an hour, and it showed us right away what we really needed.
An embedded calendar only displays information. It doesn't tell you which space is free in the next few hours, you can't book from it, and users still have to read the answer from the calendar columns themselves. Still, the test was worth it. It showed us quickly, and at low risk, that the basics were already in the calendars. We only needed a smarter interface on top.
Why Google Apps Script? The platform handles sign-in and access control
We chose Google Apps Script because it runs inside Workspace, and the platform takes care of the hard part. The company Google account handles sign-in. Access control is built in too, so only people in our domain can open the app. It needs no server or database of our own.
The most important architecture decision was that the app never writes directly to the parking calendars. The booking is created in the user's own calendar, and the parking space is added as a guest that confirms automatically, exactly as when we book a meeting room in Google Calendar. This way, nobody needs separate write access to the resources, and a booking can also be managed from your own calendar. Google Calendar stays the single source of truth.
Vibe coding in small steps: a working app in two hours
The first Apps Script version took one more hour. It showed the day's parking bookings on one screen and highlighted the one in progress. After about two hours, we had a working app that could take bookings. We added more features and redesigned the whole interface over the following days, next to our daily work, in shorter and longer blocks. (Even within those few days, development was not going on all the time.)
New features always went in as small steps that we could try right away. This way, colleagues' feedback could go into the next round. Along the way, we also learned an important lesson about how to work: with AI coding too, it pays to plan the screen first and write the code only after that.
AI coding in practice: when fixing bugs, a screenshot says more
The AI wrote the code, and it also led the bug fixing, in rounds. We described the bug, the AI named the possible causes and made a fixed version, and we tested it. If needed, the next round followed. Where several causes were possible, the fix covered all of them.
With display problems, we soon found that a screenshot works much better than any written description. A shifted button, a wrong color or a header that breaks badly on mobile is hard to put into words, and the description is never exact, so fixing it took several rounds. With a screenshot, the AI saw exactly what was wrong, and the bug was usually solved in one round. It was also a nice surprise that the fixes did not break other parts that already worked.
Parking space booking in practice: what can the app do today?
The "Today" view: at a glance, you see which space is free and how long the others are booked, and you can book the free spaces with one click.
Today: at a glance, you see which parking space is free in the coming period. If none is, you see who leaves first.
Daily view: a timeline of all bookings for the day, with the past period faded. You can also page through the following days.
New booking and My bookings: book, edit and delete in one place, with a list of your own bookings for today and the future.
Office days: the app reads the working location in Google Calendar to see which days we come in, and you can book for these days with one click.
Guest booking: you can also book a space for a visitor. On request, the guest gets a confirmation by email, and also a notice about changes and cancellations.
Built-in Help: it explains how to use the app in eleven chapters, so we needed no separate training.
The "Daily view" timeline: the bookings of all parking spaces on one screen. The vertical line shows the current time.
Convenience features beyond the basics
Once the basics worked reliably, we added convenience features based on needs that came up during use. With instant booking, a space that is free right now can be booked with one click, without filling in a form. If someone stays longer than planned, they can extend their running booking by one hour, also with one click.
On the Settings screen, everyone can choose the default values for the booking form: their usual arrival and departure times, and whether a guest booking sends a notification by default. This way, most bookings can be sent without any changes.
The "New booking" form starts with your default settings. The upcoming office days are at the top, and on the right you see right away if the time slot you chose clashes with another booking.
The secondary calendar got special attention. An event that blocks almost the whole day is distracting in the primary calendar you also use for work. So users can switch to a separate "My parking" calendar. Booking works the same way, but this calendar can be hidden in Google Calendar with one click. The app does not allow the switch while a booking is active, so no booking gets lost halfway.
An internal tool at business application level: user permissions and internal publishing
An internal app also reaches company data, so security questions were on the table from the start. We had to think through on whose behalf the app runs, whose calendar it queries, and what happens when it sends an email to an external guest in our name. The app always works with the permissions of the signed-in user. So nobody sees more than they would see in Google Calendar anyway.
We moved the app to our own Google Cloud project under the company organization. There we enabled the Google APIs we needed and set up an internal consent screen. This removed the red warning screen for unverified apps. The permission request now shows our own app name, and error logs and quotas became visible in one central place.
Our own Cloud project also opened the way to publishing. With the Google Workspace Marketplace SDK, we published the app as an internal app in the organization's Marketplace, with an icon, a description and a privacy notice. Internal publishing needs no Google review, and approval is in the hands of our own admin. So the parking booking app shows up in colleagues' Google app launcher just like Gmail or Calendar, and nobody has to send links around.
What we learned: in AI software development, the code was not the hard part
The parking booking app is not a big software project, and that is exactly the point. A real, everyday problem got a working solution on a platform we already use, in a few days, next to our daily work. The key was not a special technology. It was simply that we started: everything that came after grew out of one quick test.
Looking back, the most useful lesson was where the difficulty really was. It was not in the code. The AI wrote it, and we fixed the bugs together with it. The real challenge was the platform's admin interfaces (the Cloud Console, the consent screen, the Marketplace settings). A developer moves through them out of routine, but someone who is not a developer can easily get stuck. Here too, the AI gave us something to hold on to, step by step, and we needed Google admin rights at only a few points.
On the other side of the scale is the platform. Sign-in, permissions, data and distribution were already in place, so the work could focus entirely on the real problem: giving a clear overview of the parking spaces. A mature platform and an AI that stayed by our side the whole way made it possible for a colleague who is not a developer to go from the first idea to the company app launcher.
