Over the last year I designed and built eight such systems inside one company, for its legal, collections, customer service, sales and technology teams. Each one is measured by the hours or the money it saves.
Pick the problem closest to yours. The scoping note below shows how I approached a similar one.
Four of the eight results
The industry does not matter. Appointment reminders at a clinic, delivery records at a courier and the returns process at a retailer are all the same kind of problem, and I approach them the same way.
Tell me which process costs you time or money, who works on it, and roughly how many hours a week it takes. Three or four lines are enough. You do not need to prepare a document or book a call.
I tell you whether the problem is worth fixing and, if it is, the smallest system that would fix it. Sometimes the honest answer is that it is not worth fixing.
I send a one-page scoping note that sets out the problem, the system I would build, who would use it, and how we would measure the result. After that we discuss the next step.
An example exchange, with the names removed
Our support desk handles about 900 tickets a month. Two team leads spend most of Monday working out which tickets are waiting on whom. We do not know where the time actually goes.
This is worth fixing. The smallest system would read the tickets you already have, measure the time taken to resolve each one, separate the time spent waiting on the customer from the time spent waiting on your own team, and show the result to your two team leads every Monday. Nobody would need to enter anything new. The number to watch is the hours your team leads spend on this each week, and the time they spend today is the baseline. A system like this is a few weeks of work for one engineer. Tell me who is on your team and I will tell you how I would approach it.
Each case study follows the same structure: the problem, the constraints, what I built, the result, and what I would do differently.
Every system started with a conversation with the people doing the work. I measure what the problem costs, in hours or money, before anything is designed. The technology is chosen last.
User sign-in, user roles, security review and monitoring are built once and shared. Each new system starts from that foundation, so it ships in weeks and nothing is built twice.
Each system shows what it did and for whom, in hours or money. The person who owns the system can report that figure without needing me.
Wherever an AI model hosted by the company is accurate enough, the system runs on a server the company already pays for, in its own cloud account or on its own hardware. The cost is a fixed server rather than a fee on every request, and the data stays with the company.
Founder, twice
Too Decimal used field sensors and machine learning to forecast weather for farmers. Saaspect, a venture studio, built software for pharmacy, construction and legal businesses.
Two patents
Both were granted for the field sensors and machine learning behind Too Decimal's local weather forecasts.
National innovation award
The Gandhian Young Technological Innovation Award, 2019, presented by the Vice President of India.
Every system I build includes a view of what people actually ask it. In one case that view turned out to be worth more than the system itself.
Every identity check at customer onboarding was a paid vendor service. Most of them now run on the customer's phone. The one that needs a large model runs on our own server.
Describe the problem in a few lines. Within two working days I will tell you whether it is worth fixing and what the smallest system to fix it would be. If it is, we talk it through. The approach I recommend keeps the system on a server you already pay for, so your data stays with you.
If you are not writing about a business problem, the same form works for a job opportunity, a speaking invitation, a question or a press enquiry. Please say which.