AI has brought a new idea into companies. The business side can now build the tool it dreams of itself, without going through a developer. The promise is appealing, and it's partly true.
We tested it on ourselves. Our finance manager, not a developer, built our forecasting and cash-flow tool by conversing with AI. Then we industrialized it. Here's where the business side can go far, and where engineering takes back the reins.
When the business side codes its own tool
The need was concrete: a management tool to build forecasts, track cash flow month by month and vary assumptions. The tools already in place didn't fit.
Forekasts, our forecasting tool, remained hard to read for anyone who wasn't already a specialist. Its display could be misleading, and its exports arrived without the formulas. RCA, our accounting firm's reporting tool, was clear, but locked to a single workstation, so impossible to share remotely.
Rather than settle for it, the person who keeps our books built the tool herself, by conversing with AI. She knows finance, not code. The first working prototype was ready within a day.
Building iteratively, as close as possible to the need
The usual cycle specifies everything, then builds. Here, the order is reversed: you start from an idea, get a result, evaluate it, adjust, and run it again. The tool gets sharper as you watch it work.
This shift has a major effect. It removes the translation intermediary between the person who knows the business and the person who codes. With it go the lost context and misunderstandings.
The result matches the real need, not the assumed need. Many of the answers obtained couldn't have been specified in advance. It's by seeing a concrete result that the request becomes clearer.
Accurate calculations, as a non-negotiable requirement
A management tool only has value if its figures are accurate. This is the point where the dialogue with AI was firmest.
The scoping instruction was explicit: don't simplify the software to make the job easier, but guarantee accurate totals, even if it means more complex code. Accuracy first, ease second.
Behind this requirement lies a conviction. A management tool that silently rounds or approximates is more dangerous than useful. It steers decisions on false grounds.
The prototype knows its limits
This prototype did the job. But it remained a prototype, and it didn't hide it. Holding onto that clear-sightedness matters as much as building it.
Its limits were clear: data kept only in the browser, no authentication, no real sharing, all the code in a single file, no logging or recovery plan, security left unaddressed.
A prototype is a laboratory. It serves to learn and validate a need, not to be deployed as-is. Confusing it with production software is the costliest mistake.
The remarkable point lies elsewhere. The ceiling reached by the business side wasn't technical. It came down to choices about architecture, storage, security and continuity. Precisely where engineering regains its full value.
Industrialization, where engineering regains its value
Taking over this prototype didn't mean rewriting everything. It meant porting it into a durable architecture, without losing what made it accurate.
We separated the back end, exposed via API, from the cleanly rewritten front end. Authentication, structure and the deployment pipeline were inherited from an existing foundation. That foundation saved a considerable amount of time.
The core remained the business rules. We preserved them exactly, then proved that fidelity: the same inputs in the original prototype and in the deployed application, then a comparison of results. As long as they match, the port is faithful.
That's the difference between moving fast and moving fast carelessly. Speed comes from the reused foundation and the support of AI. Reliability comes from the method: tests, comparison, review.
The stack, in full transparency
Since we're talking about rigor, we might as well describe the building blocks. Nothing exotic: proven components, assembled cleanly, rather than a fashionable stack.
- An API-First back end, carrying the business rules and data persistence.
- A server-side database, replacing the prototype's local storage: centralized, shared, durable data.
- A rewritten front end, carrying over the tabbed interface and the financial summary tables.
- Authentication and access management inherited from an existing foundation, rather than reinvented.
- A deployment pipeline already in place, putting the application online in minutes.
The guiding choice isn't technological fashion. It's keeping the tool under control, hosted and reversible, because it now carries our own management data.
Govern rather than forbid
This story raises a question many executives are discovering. Your business teams are already building tools with AI, sometimes without telling you.
Forbidding it doesn't work and deprives the company of real energy. But a tool born off the radar becomes a risk the day it becomes central: security left unaddressed, no one to maintain it, no backups.
The answer fits in one word: govern. Document, standardize, secure, and give the business side a framework to contribute safely. At GDN, a simplified workflow lets a non-technical person propose changes, which are then reviewed by an engineer.
The main point of vigilance isn't technical, it's organizational: a well-scoped task, small and frequent changes, a review that's always possible. The rest follows.
What the business side can do alone, what engineering makes durable
This project taught us a useful boundary. The business side, equipped with AI, goes much further than we tend to believe. It expresses its need by building it, with no intermediary translator.
But it hits a ceiling, always in the same place: durability. Making a tool secure, shared, backed up, maintainable and compliant remains an engineer's job. This isn't a limit of AI, it's the nature of moving into production.
So the real question isn't whether to let the business side build. It's knowing at what moment engineering should take over so that a useful tool becomes trustworthy software.
We answered this question on our own management tool, before putting it to others. It's a good test for any partner: has it walked the path it's proposing to you?
If this idea speaks to you, we can deploy it at your place
We lived this journey, from a business-built prototype to industrialized software, on our own tool. It transposes easily. If this topic speaks to you, get in touch: we'll talk about it concretely, at your own pace.