People often ask me what framework I use or which technology I recommend. The truth is, I have never been someone who learns technology by memorising names or following trends. I learn by solving real business problems. Many years ago, I built a UI component system that made my projects more consistent and easier to maintain. Years later, someone looked at my code and said, “This is basically Bootstrap.” I smiled because, at the time, I had never even thought about Bootstrap. I wasn't trying to use a framework — I was simply trying to solve a problem.
The same thing happened again around 2009. As my projects became larger, I realised I needed a better way to control code quality. I designed my own PHP project structure so developers could only access the folders they were supposed to access. Business logic, presentation, and data were separated to make maintenance easier and reduce mistakes. Years later, I discovered that what I had built followed the same philosophy as the Model-View-Presenter (MVP) pattern. I didn't set out to implement MVP. I was simply designing a better way to build software.
The Problem Comes First, the Name Comes Later
Looking back, I realised this has always been my approach. I rarely start with a technology or a framework. I start with the problem. Once I understand the problem deeply, I build the architecture that solves it. Sometimes the industry already has a name for it. Sometimes it becomes a recognised design pattern. Either way, the name has never been the goal. The solution has always been the goal.
Why the Database Comes First
If there is one area I have always believed deserves the most attention, it is the database. Frameworks change. Programming languages evolve. AI models improve every few months. Cloud platforms come and go. But your data remains. A poorly designed database will create problems for years, no matter how modern the technology stack is. A well-designed database, on the other hand, allows applications, frameworks, and even entire platforms to evolve without disrupting the business. To me, the database is not just another component — it is the foundation of the organisation's digital assets.
That is why, throughout my career, I have invested more time in database architecture than in chasing the latest technology trends. Naming standards, relationships, primary keys, audit trails, migrations, scalability, and future-proof design are not glamorous topics, but they are the reason software survives. If people remember me for one thing, I hope it is this: build the database right, and everything else becomes easier.
If your organisation is facing challenges in database architecture, system design, digital transformation, or AI-ready application architecture, I would be glad to have a conversation. The right database design doesn't just solve today's problems — it creates the foundation for the next decade of growth.