There are clients with whom you negotiate a quote, a schedule and a scope. And then there are the others. The ones who know exactly where you live, know your holiday plans and can calmly explain, while you are supposed to be off work, that “it’s only a small website”. In my case, that particularly demanding client was my wife. 😄

During my summer break, Eva wanted to launch a website to develop her physiotherapy activity and offer adapted physical activity sessions by video. The initial request sounded almost relaxing: a few pages to present what she does, a contact form and a page explaining the online classes.

In other words: a small brochure website. The kind of project a developer accepts thinking it will take a few quiet evenings between two days of holiday.

Of course, that is absolutely not what happened.

At firstA brochure site and a few presentation pages.
In the endBookings, payments, accounts, administration, emails and business logic.
DeploymentA containerised application designed for straightforward production deployment.
PaymentsA Stripe integration implemented and tested in a few hours.

01The most dangerous client: the one who lives with you

I genuinely thought that, after all these years, Eva had understood one fundamental part of my job: when I ask for a complete expression of requirements, it is not just to annoy the client with documents and meetings.

An incomplete requirement does not disappear because development has started. It simply comes back later, usually at the worst possible moment, once the technical choices have already been made and every “small additional feature” starts moving three others.

The scenario was therefore completely classic: “we just need to present my activity”, then “it would be useful if people could book”, then “so they need to be able to pay”, then “they probably need an account”, and finally “and how am I supposed to manage the classes?”.

A few iterations later, the little brochure website had quietly decided to become an application.

Scope creep is not an AI problem. It existed long before vibe coding. AI simply makes it possible to absorb certain changes much faster… which can paradoxically encourage people to ask for even more.

02From brochure website to real business application

As the project was scoped, the real perimeter of Mumkine.fr became much more ambitious.

The project now includes several components:

  • Public website: presentation of the activity, services, geographical coverage and online activities.
  • Contact form: a simple way to make contact regarding the physiotherapy pathway.
  • User area: authentication and access to the information required for the services offered.
  • Calendar: publication and consultation of available sessions.
  • Online booking: session registration with capacity management and a complete user flow.
  • Payment: Stripe integration for the activities concerned.
  • Administration: management of sessions, users, content and day-to-day operations.
  • Transactional email: centralised on an existing mailcow infrastructure that I already know well.
  • Blog: publication of practical content around the project and the activity.

The public site also clearly separates two paths: perinatal physiotherapy in the Yvelines area on one side, and adapted physical activities available online on the other.

That may sound like a small detail, but it matters. As soon as an application starts managing several activities, you should avoid building one enormous identical funnel for everyone. The business rules, payments and information requested are not necessarily the same.

03The paradox: using AI to scope a project developed with AI

This is where the project becomes interesting: we used artificial intelligence at two completely different levels.

The first level was not development. It was scoping.

Before asking an AI to produce files, routes, a database or an interface, you still need to know what you actually want to build.

This is precisely the problem I regularly see with vibe coding: the tool can produce code extremely quickly, but if you keep changing direction it can also produce, extremely quickly, several different versions of a bad architecture.

The real accelerator is therefore not just the AI writing the code. It is the combination of a properly structured requirement, explicit decisions and an AI that can then turn those decisions into an implementation very quickly.

04Léopold: turning ideas into usable requirements

To put some order into Eva’s ideas — and incidentally save what was left of my holiday — she used Léopold.

Léopold is an AMOA / business-analysis assistant that I am developing in partnership with Jean-Francis Ochs. Its job is precisely to start with a need that may still be vague, ask the necessary questions, retain the decisions and produce deliverables that can actually be used.

What I wanted here was not an enormous specification document that nobody would read. I wanted enough structured information to answer practical questions quickly: actors, user journeys, authentication, persistent data, administration, payments, emails, cancellations and business rules.

Léopold can produce scoping summaries, specifications, detailed studies, data models, UX proposals and a starting point for an OpenAPI contract. Thanks to its exports, I could reuse the result directly as context for the development work.

And that is probably the most important part of this story: AI did not eliminate business analysis. It made it even more useful.

05An architecture deliberately designed to be easy to deploy

Once the need was stable enough, I made a simple choice: I wanted production deployment to be almost boring.

No fifteen components to install manually. No endless deployment guide. No server where you need to remember that somebody edited a file by hand six months ago.

The application is therefore designed around a compact Docker deployment, with the required persistence in a volume so backups, upgrades and redeployments are much more predictable.

This choice does not eliminate the usual concerns: environment variables, secrets, backups, migrations, logs, monitoring and rollback still matter. But for a project of this size, I would rather control a coherent deployment unit than multiply external dependencies for no good reason.

06Do not forget email

There is one feature that is almost always underestimated in a web project: email.

Account creation, booking, confirmation, practical information, cancellation, password recovery, administrative messages… the “small website” very quickly starts sending a lot of messages.

I therefore reused my mailcow infrastructure. mailcow is an open-source Docker-based mail suite that notably brings together Postfix, Dovecot, Rspamd and SOGo.

The main benefit for me is that I do not have to reinvent a different email strategy for every project. When a component is already known, monitored and backed up, reusing it is often much more sensible than rebuilding a complete infrastructure.

07Stripe, MCP and a huge productivity gain

The payment part is probably the best illustration of the productivity shift brought by current tools.

We chose Stripe.

One important point on VAT: the answer depends on the exact nature of the service. Care provided by a physiotherapist within the regulated scope of the profession may qualify for an exemption, but that does not automatically mean that every activity offered by a physiotherapist receives the same tax treatment. This therefore has to be assessed activity by activity.

What interested me most from a technical point of view was Stripe’s official MCP server. MCP — Model Context Protocol — allows an agent or compatible environment to access tools explicitly exposed by a service.

Stripe now provides an MCP server that can notably search its documentation and interact with a large part of its API. In my case, I connected it to my Codex environment.

I am obviously not claiming that four days of work always become two hours. It depends entirely on the project. But for this specific integration, the productivity gain was spectacular.

A large part of the time saved is the time we used to lose moving around documentation, checking a parameter name, finding a method again, creating a test object or understanding an API error.

This is where the agent becomes genuinely interesting: not only when it generates twenty files in thirty seconds, but when it reduces the number of back-and-forth steps required to understand and correctly integrate a third-party service.

08Why not simply use a CMS and plugins?

To be clear: Mumkine could absolutely have been built using other technologies.

WordPress, a site builder, a specialised booking tool, a payment plugin and several SaaS services could certainly have produced a functional result.

I have nothing against those solutions. They are often the best option when the requirement fits exactly with the way they work.

The problem starts when the needs move even slightly away from the path anticipated by each module. You install a booking plugin, then a payment module, then an extension to change one rule, then another one to connect accounts, then a hook, then some CSS… and you end up with a “no-code” solution that nobody really understands as a whole.

AI-assisted development changes the economics. A specific feature that would previously have taken a day can sometimes be produced much faster. That makes custom development relevant again for some smaller projects, provided you remain capable of maintaining what you build.

09What vibe coding actually changes

This project mainly confirmed something for me: vibe coding does not really replace the developer. It shifts part of the developer’s work.

The developer therefore does not become a spectator. Quite the opposite: the faster AI can code, the faster bad decisions can also be implemented.

Someone still has to be able to say: no, this logic should not be duplicated; no, we do not store that key in Git; no, a successful payment in the browser is not enough; and sometimes simply: no, we do not need this feature.

10What AI still does not do for you

This is probably the least glamorous part of an article about vibe coding, but it is essential.

An agent can help you write a Stripe integration. It does not take responsibility for an incorrect payment.

It can generate a database schema. It does not decide for you which data you are actually entitled or justified to keep.

It can produce a Dockerfile. It does not automatically verify that your backups will genuinely let you restart the service on the day your server disappears.

And it can produce a huge amount of clean code around a bad functional decision.

Ultimately, the expression of requirements becomes even more important in the AI era. When production becomes cheaper, the risk is no longer only developing too slowly. It is also developing a huge amount of useless functionality at impressive speed.

11And what about my holiday?

So, returning to the title of this article, I really was on holiday.

And I really did work.

And yes, the client still has not paid the invoice. 😄

But this small family project ultimately turned into an excellent laboratory. It let me test how far agent-assisted development can now be pushed when the need is correctly scoped and the architecture remains coherent.

The conclusion is not that anybody can now create a complete business application in two hours by vaguely explaining an idea to an AI.

The conclusion is much more interesting: a person who understands the business, good functional scoping and a developer who knows how to steer agents properly can now turn an idea into a genuinely usable product extremely quickly.

Saving time does not necessarily mean working less.

In my case, it mainly gave my wife time to add many more features before the end of my holiday. 😂

Key takeaways

  • Mumkine was initially supposed to be a simple brochure website.
  • The scope evolved into a real application with accounts, booking, payments and administration.
  • Léopold was used to structure the requirement before continuing development.
  • AI-assisted development is far more effective when functional decisions are explicit.
  • The project uses a Docker architecture deliberately kept easy to deploy.
  • Email is centralised through mailcow.
  • The Stripe integration was greatly accelerated by its MCP server and my development environment.
  • Vibe coding makes custom development more accessible, but it does not remove architecture, testing or security.
  • The faster AI develops, the more important requirement scoping becomes.

Links and sources

This article is a personal account of the design and development of Mumkine. The development times mentioned relate to this specific project and should not be treated as a general estimate for a Stripe integration or for building an equivalent site.

The VAT information is provided only to explain the project context. The tax treatment of a service depends on its nature and the professional’s situation and should be checked for each activity concerned.