Ten vendors could not build my product. So I built it myself.

I did not set out to write the software myself. I did what most founders do — I hired someone to build it. When that did not work, I hired someone else. Over the life of that product I worked with more than ten vendors. Not one of them delivered on time. Not one delivered something I could put in front of a paying customer without apologising for it first.

They were not bad engineers. That was the confusing part. They could write code perfectly well. What none of them did was learn the business before writing it — how the work actually ran, what it cost when it went wrong, which part of it was worth changing at all.

So I learned to build it myself, and built a product around the problems I could see first-hand rather than the ones in a specification. That gap — between people who can build software and people who understand the business it is for — is the whole reason this company exists.

How I got here

I have been building software for twenty years.

I graduated in 2005 and started as a mobile developer at Satyam. Two years in, I flew to Finland to deploy what we had built onto Nokia's servers — back when Nokia still set the terms for mobile. After that, a year and a half at Freescale, still building mobile. Then HCL, who sent me to Japan to work with Sony as an Android developer for around eighteen months.

Japan is the part that stayed with me. The engineering was not different — the code was the code. What was different was the assumption underneath it, that technology should quietly carry the routine work rather than sit beside it waiting to be used. I came home with an uncomfortable sense of how much of that gap existed in businesses I knew well.

That is what pushed me to start the restaurant SaaS, back in 2011. Four years, built on Ruby on Rails, sold to restaurants. It closed in the end — cashflow, not product. I would rather say that plainly than dress it up.

Afterwards I spent close to a decade in the corporate world, as a senior software architect and a senior Rails developer. Bigger systems, capable teams, real budgets — and the same pattern showing up from the other side: good engineering pointed at work nobody had measured the value of first.

Nine months ago I started Binarify again, this time to do the thing I had spent four years wishing someone would do for me.

What that experience turned into

Most AI projects do not fail loudly. They quietly stop being mentioned. MIT's NANDA study found 95% of enterprise GenAI pilots produced no measurable return. S&P Global found the share of companies abandoning most of their AI initiatives rose to 42%, up from 17% a year earlier. Those are not stories about the technology being bad.

They are stories about nobody owning the outcome. So the method is built against that:

• The number gets written down first. Before anything is built, we record how the workflow performs today and you sign it off. You cannot prove an improvement you never measured.
• It gets built inside the systems you already use. Not beside them. Adoption dies at the seam between tools, which is exactly where a vendor who has not watched the work will leave it.
• The result is measured the same way and handed over in writing — flattering or not.

Why companies of 10 to 200 people

Because that is the size where the problem I had bites hardest.

Below ten people there usually is not a workflow expensive enough to justify the work, and I would rather say so on the call than after the invoice. Above two hundred, there is procurement, an internal platform team, and a large consultancy already calling every quarter.

In between, there are real processes costing real money and nobody whose actual job it is to fix them. It is also the size that gets sold to badly — a proof of concept that impresses everyone in the room and changes nothing on Monday. I was that customer for four years, paying for it out of my own revenue.

How Binarify is set up

I lead every engagement myself — the first call, the baseline, the build. Behind that is a pool of more than ten senior developers and architects, each with over a decade of experience, brought onto a project as its scope needs. What you will not get is a bench of juniors, or a team you were never introduced to once the sales call is over.

I also have no case studies to show you yet. Binarify as an AI consultancy is nine months old, and rather than pad this page with logos I have not earned: early clients get reduced fixed pricing in exchange for permission to publish their before-and-after numbers, anonymised if they prefer. That is how the proof gets built, and it is the honest order to build it in.