Understand before building.Stay after delivering.
I start from how things really work for you — exceptions and indispensable spreadsheets included — before choosing any technology. The decision to build comes afterwards, with you, and it is written down.
The last mile.Where trust is won.
A tool people trust is won in the final details: where software meets your reality. That is where I spend the time it takes.
What a demo shows quickly
- Model
- Interface
- Prototype
- Demonstration
- Feasibility
What only reality brings to light
- Business context
- Real data
- Unwritten rules
- Exceptions
- Permissions
- Real users
- Integration
- Security
- Operations
What starts after the demo
AI assistants make prototypes easy, and that is a good thing. These are the questions that matter next for a tool that lasts, grouped by what is at stake — the ones I work through with you.
Data
What the tool shows must be accurate, complete and up to date.
- Which data is authoritative when two systems contradict each other?
- How do you bring across twenty years of existing data without losing anything?
- How do you cope with several hundred thousand records?
People
The tool has to follow the organisation as it really is, not an ideal chart.
- What happens when twelve people make changes at the same time?
- Who is allowed to see what, and to change it?
- How do you test with real users, while they are doing their job?
Change
An exception or a change must not bring everything to a halt.
- Where do the business exceptions nobody mentioned end up?
- What breaks if this essential process is changed?
- How do you roll back after a change that went wrong?
Time
What works on demo day has to hold up over time.
- How will the tool hold up in three years’ time, without its author?
- Backups and migrations: who has actually tried them?
- What will the infrastructure cost in eighteen months, at real volume?
A first proof, quickly.A durable build, afterwards.
Your project moves forward in stages, each one defined in advance and checked with you: you invest as results come in, building only what is needed to decide what comes next.
POC
Proof of Concept
Is it possible?
Show that a concept or a technical solution is feasible, on the precise point that raises doubt. With today’s tools the answer often comes quickly: it is necessary, rarely sufficient.
POV
Proof of Value
Is it worth it?
Check that the solution brings real value for the need in question, against criteria set in advance that can be observed or measured. For example:
- How much time the problem wastes, per week and per person
- How many people are actually affected
- What the current situation costs, errors included
- What share can be automated, and what share must remain human
- What already exists on the market, and at what price
- What value a bespoke tool would genuinely create
MVP
Minimum Viable Product
What really needs to be built to learn and move forward?
The smallest version that makes sense, used in real conditions, to learn from actual use and test the essential assumptions. Neither a throwaway mock-up nor a finished product: a foundation that is already useful and can grow.
Something you can actually run
Then seeing it through to production: data migration, permissions, backups, documentation, handover. Beyond, dotted: operation and further changes.
The right choice is not always a build. If existing software covers most of the need at a reasonable cost, I will recommend it.
Six steps, in this order
Go and see
Look at the real work: the files people actually open, the workarounds, the exceptions nobody has documented.
Frame the problem
Written down, quantified, shared with those who described it. If it needs correcting, now is the time: the moment it costs least.
Decide
Build, buy, adjust what already exists or do nothing. The recommendation is written down, with its risks and its cost.
A first proof
When the problem lends itself to it, something observable within a few weeks: a measurement, a clarified workflow, a first automation.
Build with the users
Usable versions early on, tried out during the real working day, corrected with the people who use them.
See it through to production
Data migration, permissions, exceptions, monitoring, backups, documentation, handover. Then stay on hand until everything holds.
Every step produces something concrete: a written decision or something that works.
The same method,applied to my own products.
Never separate a figure from its source
Every value in France ÉcoScan carries its source, period, unit, scope and status.
France ÉcoScanWrite the protocol before the result
FYRIS’s performance is measured on years the engine has never seen, and published with its limitations.
FYRISPromise nothing the calculations cannot back up
Visionary Stats Pro calculates exact probabilities from the rules of the games — and refuses to promise any winnings.
Visionary Stats ProCheck against an independent reference
The Astro Destiny One engine is checked against an independent astronomical reference, and its delivered readings are sealed.
Astro Destiny One
What I buildmust work without me.
A good tool is an asset that belongs to you: you can run it, evolve it or hand it to someone else. These principles are checked line by line at delivery.
- The accounts belong to you
- Hosting, domain names, online services: opened in your name, administered by you. Any access granted to me can be withdrawn in a minute.
- Your data remains yours
- In your environment, exportable at any time in an open format.
- Transferable code and documentation
- A repository that belongs to you, a complete history, documentation written for someone who does not know me.
- Replaceable components
- An external service, an AI model or a supplier is called from behind a clear boundary. Changing it remains a technical decision, not a rebuild.
- Automations with limited rights
- Whatever is automated acts with the minimum of permissions, within its own scope, and leaves a record of what it has done.
- Backups and rollback, actually tried
- Not merely configured: tried. A restore that has never been attempted is not a backup; it is an intention.
- An emergency stop
- An automation can be suspended without stopping the business, and the previous way of working temporarily restored.
- No artificial dependency
- No closed format, no key that only I would hold, no compulsory maintenance in disguise.
Three commitments
- Pricing from the reality on the ground
- A quote is built after looking at the real work: it serves the project, not just the signature.
- Starting from the problem
- The architecture follows from the problem, the volumes and the users — never from a technical preference.
- Delivering with the keys
- A delivered solution must be understandable, runnable and transferable without me. At delivery, within the agreed scope, you receive:
- Useful documentation: installing, using, running and evolving the tool
- The agreed access and configuration, in your name
- What day-to-day operation needs: backups, monitoring, procedures
- Knowledge transfer to whoever will take the tool over
- Written handover conditions, for your own team or another provider
- The freedom to entrust future changes to Visionary Édition, or not
Maintenance and further development can be a separate engagement. The rights transferred are those set out in the contract.
Setting a course.A dream, run like a project.
Visionary Édition carries an ambition beyond software: to fund an Ultim trimaran in its colours by 2030. Today it is an entrepreneur’s dream, not yet a boat. Yet it says something true about the way the studio works: an ambitious project can grow from a personal idea, and it moves forward in stages, with no shortcuts.
From course to helm
Set the course
A project starts with an intention, a need, a destination. Not with a technology.
Design
Choose an architecture cut for the real constraints — the way a hull is drawn for its waters, not for the boat show.
Build
A product comes together piece by piece, through successive choices, each one checked before the next.
Trim
Details, validations, corrections: this is where reliability is won.
Sea trials
A demo alongside the pontoon is not enough. The product has to hold up in the real conditions it will be used in.
Hand over the helm
Whoever carries the project must be able to understand it, use it and evolve it — without depending on whoever built it.
An inspiration, not an offer: every project seen through brings this course closer, and those who work with the studio will be able to follow it.
“We’ve always done it this way.” What if we did it better?Your idea deserves a proper look.
An everyday problem, a tool that no longer keeps up, an opportunity to seize, a product that does not exist anywhere yet: let’s work out together what is worth doing, and how to build it.
Every idea, however modest, deserves a real conversation. No specification or set budget needed: just tell me what you would like to improve or create.