No-Code
No-code can speed up a project, but technical choices remain. Compare workflows, dependencies, and costs before committing to ensure long-term success.
Sur cette page4 sections
You have a service idea, you open a tool, move a few blocks around, and a first page starts taking shape. Honestly, I get the appeal. You finally move from "we should do this" to something you can actually show and test.
No-code allows you to build websites and applications using visual tools, without writing every line of code yourself. I develop with code, but I see no reason to look down on a tool that lets someone test their idea. What interests me happens after that first page: how will the project function in real life?
Then two people request the same time. Does the first booking block the slot? Does someone need to approve the request? And if the client cancels, who is notified and when does the slot become available again?
These are the questions that define the service. Drag-and-drop can help us build screens and certain rules; it cannot decide for us how our business should operate. It's the same when writing everything by hand: flawless code won't fix a misunderstood booking rule.
At this stage, insisting on a fully custom application can complicate the launch without adding much value. Above all, the project needs to meet its users, not give us an excuse to build an impressive infrastructure.
The choice becomes more interesting as the business evolves. A specific rule, a link to existing software, or multiple access levels might be simple on one platform and complicated on another. I prefer to look at these cases early on, while we can still choose calmly.
On Bubble, for example, retrieving your data and exporting an application ready to run elsewhere are two different things. Applications remain tied to the platform; rebuilding their logic elsewhere requires work. Not all no-code tools have the same rules, so this example doesn't apply to the entire category.
This doesn't make it a bad choice. It simply changes the conversation if your goal is to keep the option to leave, or if the service is to become the core of your business. We then look at exports, subscriptions, and integrations with as much care as the page editor.
If an existing tool meets your needs well, I'd rather we use it than have you fund its reproduction. However, if adaptations start looking like a series of workarounds, we can discuss a different foundation before accumulating technical debt.
The right starting point for us to work together is your actual user journey. Show me what the user needs to be able to do and what is blocking you today. We can then choose how to build it without turning "code vs. no-code" into a religious debate.
No-code allows you to build websites and applications using visual tools, without writing every line of code yourself. I develop with code, but I see no reason to look down on a tool that lets someone test their idea. What interests me happens after that first page: how will the project function in real life?
The form looks great, but two people want the same slot
Imagine a small business offering appointments. You add a calendar, a name field, and a booking button. Visually, the work looks almost done.Then two people request the same time. Does the first booking block the slot? Does someone need to approve the request? And if the client cancels, who is notified and when does the slot become available again?
These are the questions that define the service. Drag-and-drop can help us build screens and certain rules; it cannot decide for us how our business should operate. It's the same when writing everything by hand: flawless code won't fix a misunderstood booking rule.
A first version can already provide real value
To collect requests, test an offer, or replace a spreadsheet sent via email, a visual tool can be very suitable. You can have a few people try the workflow, see where they hesitate, and fix it before going further.At this stage, insisting on a fully custom application can complicate the launch without adding much value. Above all, the project needs to meet its users, not give us an excuse to build an impressive infrastructure.
The choice becomes more interesting as the business evolves. A specific rule, a link to existing software, or multiple access levels might be simple on one platform and complicated on another. I prefer to look at these cases early on, while we can still choose calmly.
Renting a space doesn't mean you own the walls
A hosted platform might let you modify many things without allowing you to take the entire application to another host. It's a bit like a commercial space you fit out for your business: you can own what you put inside without owning the building.On Bubble, for example, retrieving your data and exporting an application ready to run elsewhere are two different things. Applications remain tied to the platform; rebuilding their logic elsewhere requires work. Not all no-code tools have the same rules, so this example doesn't apply to the entire category.
This doesn't make it a bad choice. It simply changes the conversation if your goal is to keep the option to leave, or if the service is to become the core of your business. We then look at exports, subscriptions, and integrations with as much care as the page editor.
My job isn't to sell you as much code as possible
Custom development allows for finer tuning of certain rules and a wider choice of components. It also requires developing, testing, and maintaining what has been built. You remain dependent on software, services, and people; you shift part of the responsibility onto the project.If an existing tool meets your needs well, I'd rather we use it than have you fund its reproduction. However, if adaptations start looking like a series of workarounds, we can discuss a different foundation before accumulating technical debt.
The right starting point for us to work together is your actual user journey. Show me what the user needs to be able to do and what is blocking you today. We can then choose how to build it without turning "code vs. no-code" into a religious debate.
