What 20 Years in IT Taught Me About Building Digital Products

I didn't plan to become a digital product builder. I planned to be good at my job, whatever that job happened to be at the time. Over 20 years, that job changed a lot — analyst, data migration specialist, IT director, ERP consultant, CRM manager. Different titles, different industries, different problems.

But the through line was always the same: how do you take something broken or missing and make it work?

You learn more from failure than from success

Early in my career at Accenture, I worked on large SAP implementations for companies like Rio Tinto and Alstom. These were massive, expensive, high-stakes projects. The kind where a bad data migration doesn't just cause a bug, it stops a production line.

I learned fast that in environments like that, being right isn't enough. You have to be clear, documented, and two steps ahead of the problem. I also learned that even the most sophisticated enterprise systems fail when the humans using them don't trust them.

That lesson stuck with me.

The player-coach mentality

At some point in my career I became a manager. And I noticed something: a lot of managers stop doing the actual work. They delegate, they review, they approve. They lose touch with the details.

I refused to let that happen to me.

I kept my hands in the technical work even when my title said I shouldn't have to. Not because I didn't trust my teams, but because I believe you can't lead technical work you don't understand. You make better decisions when you've been in the weeds recently. You ask better questions. You spot problems earlier.

That player-coach approach is something I bring to every project today.

The gap nobody talks about

There's a massive gap between what enterprise tools promise and what smaller organizations can actually extract from them.

Big vendors sell the dream. Then they leave. And the organization is stuck with a system nobody fully understands, documentation that's already outdated, and a support contract that costs more than it delivers.

The RMWB transit situation was a perfect example. A system nobody could use anymore, expertise that had walked out the door, and 125,000 residents depending on the buses running on time.

We built a bridge. It worked. The city kept moving.

What I know now that I wish I knew earlier

Scope is everything. Every project that went sideways had one thing in common: the scope wasn't controlled early enough. Not because people were incompetent, but because nobody wanted to be the one to say no. I've learned to say no early and clearly. It saves everyone.

Users are the product. You can build technically perfect software that nobody adopts. Adoption comes from involving users early, building what they actually need, and making the tool feel like it belongs in their workflow.

Speed matters more than perfection. A good product shipped in two weeks beats a perfect product shipped in six months. Markets move, priorities shift, budgets disappear. Get something real in front of real users as fast as possible and iterate from there.

Technology is a means, not an end. I've worked with companies that chased every new tool and platform, always looking for the technology that would solve their problems. The technology was never the problem. The clarity of thinking about the problem was.

Why I started akafal.com

After 20 years I reached a point where I wanted to do the work I actually love, without the politics, the bureaucracy, and the layers of approval that slow everything down in large organizations.

I started akafal.com because I believe serious businesses deserve serious digital products, built by someone who has seen enough to know what actually matters.

Not an agency with a sales team and a portfolio of junior developers. A person. With a track record. Who answers your messages and ships your product.

Twenty years taught me a lot. The most important thing: it's never really about the technology. It's about understanding the problem well enough to solve it simply.