The problem
Internal tools rarely fail for technical reasons. They fail because they were designed far from the people who use them: too many fields, steps that do not match the real work, an interface nobody has time to learn. The result: the spreadsheet comes back, data scatters, and the tool becomes a constraint instead of a support.
What I put in place
Designing a business tool is first about listening: understanding the work as it is done, then supporting it without making it rigid.
Observe before designing
I spend time with the people who will do the work in the tool: what they do, in what order, what slows them down, what they work around. That is where the good design decisions are, not in a specification document.
Tested mock-ups, well-modelled data
Clickable mock-ups, tested with users before a line of code. In parallel, a clean data model: what is entered once, what is computed, what is kept as history. That is what avoids duplicates and parallel spreadsheets.
Build or buy, in the right place
An off-the-shelf CRM is often enough for the base; bespoke goes on what sets you apart: a particular case workflow, automations, connections to your other tools. The running cost is stated before I start.
Put into production and keep alive
Staged go-live, short training, feedback collected during the first weeks and built in. I operate the tool afterwards: updates, backups, evolutions.
Where AI has its place
In a business tool, AI serves to remove data entry and sorting, not to decide for you: pre-filling a case from an e-mail, classifying a request, proposing a reply to review, summarising a history. Each automation has a person at the end and a log of decisions.
Frequently asked questions
Off-the-shelf CRM or bespoke?
Often both: an off-the-shelf CRM for the base (contacts, pipeline), bespoke for what sets you apart. I tell you clearly where each franc goes and what running it costs over time.
How long until a first usable tool?
A few weeks for a first version in production on a reduced scope, then iterations. A tool is built with its users, not ahead of them.
Will my teams need training?
An hour is enough if the tool was designed with them. Long training is the symptom of a design made elsewhere.
What happens to the tool if I stop working together?
The code and the data are yours, documented. Another provider can take over.
A concrete case on your side?
Tell me what costs you time; I get back to you within 24 business hours with a first read, no obligation.