A year or a year and a half ago, it was hard to imagine that with a cup of coffee in hand, in just one evening, by describing your needs to someone on the other side of the screen, you could get something that used to take weeks or even months.

When I need to cover some functional need, how do I act? I look for a ready-made solution on the internet, some inexpensive SaaS tool or an open-source project. But sometimes there simply isn’t a suitable solution - and then what? You could write it yourself, but that’s exhausting: solving a (clearly not the most important) task by spending time on yet another CRUD, describing Helm charts or Docker Compose, figuring out where to store data, and resolving another dozen typical questions. Such tasks either get postponed indefinitely or are solved in a very hacky but quick way. Of course, I really love technology (you can take my word for it as someone who uses Grafana with Prometheus alerts to track personal finances), but there’s just not enough time for every problem.

This is where vibecoding comes to the rescue! I often see posts in this format:

Vibecoded a service - very convenient and beautiful, and it solves the task!

But what exactly was vibecoded, and what was done manually? I became curious how hard it would be to write a tool through AI that solves my problem with minimal manual fixes.

What am I going to vibecode? At Mayflower we release every day, and often several times a day. We already have many processes and automations for this, but with the growing number of services it would be nice to have a calendar tool with all the information about each release. And it would also be convenient to let other teams know that I want to roll out a new version of a service on a certain day. Since this tool will likely expand, it’s important to meet a few non-functional requirements:

• The code must be maintainable;
• Include documentation;
• Be easily extensible;

A small note: I know there are great vibecoding tools like Cursor, but I’ll be using GPT-5, since only a couple of weeks have passed since its release at the time of writing this article, and I’m really curious how well it can generate full projects and work with codebases.

Stage 1 - Preparation and Generation🔗

The goal of this stage is to write a prompt that reflects all functional and non-functional requirements, as well as corner cases, run the generated project, and make sure everything works.

Requirements described:

You are a professional studio developing IT projects on demand, including design, backend, frontend, infrastructure, and documentation.
You’ve received an order from an important client for a critical tool for their business.

Project description:
The project is a web application for managing all company releases.

Functional requirements:

1. The application has a calendar showing all releases (multiple per day or none). Clicking on a release opens a page with full release info.
2. Release management:
   • Create, edit, and delete releases (via interface with forms or via API. Any data can be changed)
   • View all releases with filters by status, release manager, or type
   • Ability to add comments to releases
3. Release information should include:
   • Release date and time
   • Release status (planned, succeeded, failed)
   • List of duty officers responsible for the release
   • Notes (with add/edit capabilities)
   • Useful links (API provides name + link, users can also add manually, e.g., release build: https://example.com)

Use cases:

1. CI will send release data to the application via API
2. Users can view the release calendar and add new releases

Non-functional requirements and tech stack:

1. Frontend:
   • Next.js v14 with the new App Router
   • Use shadcn for UI components
2. Backend:
   • Golang (with Gin or another popular, convenient framework)
   • GORM for DB access
3. Infrastructure: Nginx
4. Database: MariaDB
5. The project should be containerized into Docker images and described in docker-compose (so the client can immediately test). All variables (DB, app addresses, etc.) should be in a .env file.
6. For migrations use Goose. Write migrations as SQL files in the backend’s migration directory, embed them into the backend image.
7. Migrations can be run with go run main.go migrate (or with cobra CLI commands).

You can plan for some extra functionality, but don’t overcomplicate.

After sending this prompt and a couple of clarifications, GPT-5 returned a zip archive. Inside were 3 directories:

• backend
• frontend
• nginx

Exactly what I expected. After the first run I had to fix a couple of small errors, but the project launched and worked. What I saw in the browser pleasantly surprised me:

I didn’t think I’d need many frontend changes - it was exactly what I wanted. But upon reviewing the codebase I was disappointed: it was poorly structured, and some requirements weren’t met. The first version of the sources is here - https://github.com/thatqa/release-calendar/tree/v1

Okay, I’ll note what I don’t like and fix it first.

• All migrations in a single file
• No GORM
• Messy* routes, with everything from param validation to raw SQL inside

Also, while testing I found a bug - when adding a release, it showed up on the next day instead of the chosen one.

Result of stage: a generated project that can be launched and clicked around. Visually fine, but the codebase was unfit for long-term support. I wrote down the main issues to fix.

Stage 2 - Fixing Errors and Spec Mismatches🔗

The goal of this stage is to fix spec mismatches and errors, ensuring everything works properly.

First, fix the date bug when adding a release:

Why does the release end up on the next day instead of the chosen one?

Fix: https://github.com/thatqa/release-calendar/commit/e34de48f840b02f717503bf265a3414a40304ba2.
Cause: mismatch between local time and UTC on the frontend.

Then split migrations into multiple files:
https://github.com/thatqa/release-calendar/commit/537a05de4371ffe7b30c4f417c1f19727aad079a

Next, add GORM. For future expansion, it’s more convenient than raw SQL:

https://github.com/thatqa/release-calendar/commit/8fbd01b6cafb062dd90fa31fb8b12221570b8802
https://github.com/thatqa/release-calendar/commit/1c9334382be32062b11e8d7e799796c7529566ad

Migrations remain in Goose SQL, while GORM is only used as the ORM layer at runtime. This way the schema is controlled, reviewed, and avoids "magic" auto-generation.

The last big fix was splitting routes into layers for maintainability. Controllers now only handle request validation, call use cases, and return responses. Commits:

• https://github.com/thatqa/release-calendar/commit/c14c9fa343ca50cf74d4766aaf5dab9b5903905e
• https://github.com/thatqa/release-calendar/commit/aea5ceb8a9c6d3ec292c5709fb573873bdae7f94

Result of stage: fixed initial bugs, added architecture layers, controllers simplified. The project became much more maintainable and extensible.

Stage 3 - Adding Calendar Markers🔗

The goal of this stage is to see if GPT-5, with full project context, can add new functionality.

Currently, the calendar doesn’t show which days have releases - only visible by clicking. We want markers under each day based on release statuses:

• Red: failed releases that day
• Green: successful releases that day
• Blue: planned releases that day

GPT suggested an optimization: aggregate release statuses by month in one query, returning a compact structure for the frontend.
Changes: https://github.com/thatqa/release-calendar/commit/78f04b1882c6b48add4f186e3f4175b9f8224075

Result of stage: new feature works, and when GPT-5 has the full project, such features are built quickly.

Stage 4 - AI Feature!🔗

Of course, it needed AI. I wanted one-click summaries of release comments and notes.

GPT suggested two backend modes:

• If OPENAI_API_KEY exists: call the model for a summary
• If not: fallback heuristic (extract key phrases, deduplicate, build a brief summary)

Changes: https://github.com/thatqa/release-calendar/commit/9f88992a5ac3f90883098a130c07db79f52fd0dc

Result of stage: AI feature was easier to build than expected. A few manual tweaks - and it was done.

Conclusion🔗

In one evening I went from "idea in my head" to a working tool with frontend, backend, migrations, and even an AI feature. The first version needed lots of small fixes, the architecture required work, and the code wasn’t very maintainable. But this solves the "blank page" problem: you can quickly get a prototype, then step by step refine it into something worth using long-term.

GPT-5 performed better than I expected: it can build a working project, propose optimizations (like a single monthly query for the calendar), and occasionally suggest smarter solutions. But manual fixes and developer judgment are still essential - otherwise, hacks pile up quickly.

This experiment showed me three things:

• AI is a great way to avoid the blank-page problem.
• Even with a perfect prompt, some work will always remain for humans.
• Embedding AI features is easier than I thought :)

Resulting project: https://github.com/thatqa/release-calendar