2 mins read
Who Owns How You Operate?
Custom building an erp system with requirements yet to be listed.
Part 1: Take the Wheel
ReBuild the navigation to suit my needs - when my needs.
Over the years, I've explored countless business systems. Traditional PHP-based Enterprise Resource Planning (ERP) solutions, newer JavaScript frameworks, AI-generated business applications, and the growing number of platforms promising to build an entire business system in minutes.
My own ERP had reached the point where it needed to evolve. It was built on CodeIgniter, a framework that had served me well for years, but it was becoming increasingly difficult to maintain and no longer kept pace with how I wanted to build software. I explored several Laravel based options and even considered moving everything to a modern framework like Next.js. But I didn't want the migration itself to become another long-term project. What I needed was a solution I could implement quickly, one that could keep up with the growing number of projects I was managing without months of rebuilding from scratch.
Many of them are genuinely impressive. Some are beautifully designed, others offer an incredible range of features, and AI has made it easier than ever to generate applications in a fraction of the time it once took. But almost every solution comes with a catch. More often than not, that catch is another subscription, another closed ecosystem, or another platform that expects you to work within its limitations.
The bigger issue, however, wasn't just the mounting subscriptions...
It was flexibility, adaptability and scalability.
Most importantly, self-hosted and I have full controll.
No matter how capable these systems were, I eventually found myself asking whether they could adapt to the way I wanted to work. The honest answer was usually not quite. More importantly, I realised something about myself.
I don't always know what I need.
As projects evolve, businesses grow, and new ideas emerge, my requirements change. What feels like the perfect workflow today may become a bottleneck six months from now.
The software isn't the only thing evolving... I am too.
That eventually led me back to an open source solution, Frappe ERPNext. My first impression wasn't great.
From a user experience perspective, it felt frustrating to use.
It didn't feel like a system that had been designed with the end user as the first priority.
The navigation was confusing, common tasks required too many steps, and something as straightforward as creating a project or issuing an invoice often meant jumping between multiple screens just to understand where everything lived.
The more I worked with it, however, the more I realised I was looking at it from the wrong perspective.
Instead of asking whether the interface was intuitive, I started asking why it had been designed that way in the first place. That's when I understood why Frappe Framework puts the data first.
A layered, domain‑driven architecture with a clearly separated data‑access layer and well‑defined boundaries can address my unknowns as I scale
Organising data well is one of the hardest problems to solve when building business software. User interfaces can always be redesigned, workflows can be simplified, and features can be added over time, but a poorly structured data model becomes increasingly difficult to fix as an application grows.
Years ago, a workmate of mine—the CTO of a company I worked for at the time—made an offhand comment during a conversation about software architecture. I don't think he expected those few words to leave much of an impression, but they stayed with me. They fundamentally changed the way I think about designing business systems, and I still find myself coming back to that lesson today.
At the time, I understood the words, but I don't think I fully appreciated what they meant. It wasn't until I started building larger systems that the lesson really clicked. It's a pretty tall order for this design brain but nonetheless it should be considered in the process.
There's a classic software principle behind this: favor composition over inheritance. Inheritance locks behavior into a rigid hierarchy. Change the parent, and every child breaks. Composition builds systems out of smaller, independent parts that link together, so you can rearrange them as requirements shift. That's exactly what I found in Frappe. A DocType doesn't inherit from some master "business object" class. It links to other DocTypes, nests child tables, and gets extended through custom fields and apps. Nothing forces a rewrite when the business changes shape.
Most UI and UX designers spend their time thinking about screens, interactions, and visual hierarchy. Those things are important, but underneath every interface is a data model that determines what the application can become. If the data is designed well, the interface can evolve almost indefinitely. If the data is poorly designed, every future improvement becomes a compromise. So before asking "is this navigation intuitive," I started asking "Should it be inherited or composed and independent?" A wireframe is temporary. A data table is a commitment.
I realised this wasn't an accident. It was the philosophy behind Frappe ERPNext. It wasn't optimised for first time users. It was designed as a flexible platform that developers could extend and adapt to almost any business.
That was something I knew I could work with.
I can redesign an interface. I can improve navigation. I can build better workflows. What I didn't want to rebuild from scratch was a solid data foundation, and I believed Frappe had already solved that part remarkably well.
Building or customising an ERP or CRM was never the mission. It was simply a tool I needed to manage my services. Just one component in a much larger system. An investment that gives me the freedom to shape the platform around the way I work, instead of working around the platform.
I may not know exactly where this journey will end, but I do know one thing. I need to be the one driving the vehicle.
If the destination changes, I need the freedom to change course without fighting the platform itself. I want to decide what takes priority, what can wait, and how I move through the system as my work evolves.
That's why the first thing I changed wasn't accounting, projects, or any other business module.
It was the navigation. Once I had the wheel, I could take the platform wherever I needed it to go.
Every piece of software eventually teaches you how it wants you to work.
The real question isn't whether AI will change how businesses operate.
The question is whether you'll remain the person deciding how your business operates, or whether your tools quietly begin making those decisions for you.
If you can relate, feel free to reach out.
