Three years of evolving one system, in public.

When we started working with AK Suppliers & Distributors in 2022, the engagement was modest in scope. Their existing WooCommerce store needed structured proforma invoice generation, branded PDFs, and a unified order management surface for the team. A few months of work, a deployment, a handover.

That was the plan. What actually happened, over the three years since, is the kind of evolution that almost never gets described publicly, because nobody thinks to write about a relationship that just keeps working. This essay is an attempt.

What we shipped, in roughly the order it happened

The first version was the brief we agreed to. Proforma generation, branded PDFs, basic order management. The team adopted it within weeks. The owner could finally see what was happening on a single screen each morning.

About six months in, the team identified that their phone and WhatsApp order intake was where most of the friction still lived. The first version had not addressed it, because the brief had not asked for it. We added a structured intake module. The team migrated the most predictable orders to the structured channel and kept WhatsApp for the relationship-heavy ones.

Around the one-year mark, WhatsApp Cloud API became reliable enough to integrate directly. We added a WhatsApp layer that handled order notifications, proforma sharing, and customer reminders. The previous external WhatsApp tool got retired.

In the second year, the catalogue grew enough that search performance on the storefront degraded. We added Typesense for product search. The front of the store got faster. The team's catalogue management workflow got faster too.

A few months later, the founder asked if we could move the mail infrastructure off third-party SMTP onto something the firm owned. We deployed a mail server on the same VPS. The monthly notification cost went to zero.

A modernisation round followed. We migrated the application server from a traditional Apache + PHP setup to FrankenPHP. Performance improved measurably. The deployment story became simpler.

A PWA wrapper, web push notifications, server-side conversion tracking for the firm's ad spend, refinements to the proforma template, a second catalogue category that needed different variant logic. Each addition came from an operational need the firm noticed. None of them were on the original roadmap, because the original roadmap could not have anticipated them.

The current state is a system that does materially more than what we shipped in the first version, runs faster, costs less to operate, and is recognisably the same application as the one we deployed in 2022. None of the additions required a rebuild.

Why this is unusual

Most operational software engagements end one of two ways. The first way is project handover: the vendor ships the agreed scope, the client takes ownership, and the system either fossilises in the state it was delivered or gets quietly replaced when the firm outgrows it. The second way is the rebuild: every three or four years, the firm realises the system has not kept up with the business, and a new vendor is brought in to start over.

The third way, where the system and the firm evolve together over years without either of them needing to break, is the rare one. The reason it is rare is not technical. It is that it requires both parties to commit to a relationship structure that does not have a clean exit.

For the vendor, it requires staying invested in the operational reality of a single firm year over year. The economics of this are not obviously better than chasing new logos. The accumulated knowledge of how the firm runs is valuable, but it is illiquid. We cannot re-purpose it to grow a different account.

For the client, it requires accepting that the system will keep evolving with their needs, which means a continuous spend that is larger than zero but smaller than a periodic rebuild. The psychological challenge is the continuous nature. Most founders are more comfortable with discrete capital projects than with ongoing operational expenses.

When both parties get past the structural friction, the third option becomes the best one for both. The vendor gets predictable revenue and accumulated expertise. The client gets a system that fits how the business actually runs, year after year, with no rebuild trauma.

What makes the relationship work

The technical pattern matters less than the relationship pattern. The technical pattern is the one most clients ask about: which stack, which framework, what is the deployment shape, what does the upgrade path look like. All of those answers exist and we are happy to share them. They are not why the engagement works.

The relationship pattern is the one that determines whether the engagement makes it past year one. It requires three things.

A clear understanding, on both sides, that the system is the firm's asset, not the vendor's product. The code lives in the firm's repository. The infrastructure is in the firm's accounts. The vendor can be replaced if the relationship goes wrong, and the firm knows this.

A working rhythm of small improvements, surfaced by the firm's operational reality, prioritised together, shipped on a regular cadence. Not a roadmap meeting twice a year. A continuous conversation, with weekly check-ins and quarterly larger releases.

A founder on the client side who treats the relationship the way they would treat a senior hire. Time invested, attention paid, feedback honest. The systems we build evolve well when the founder is engaged. They drift when the founder disengages.

The AKSD pattern is the one we want more of

The firm describes the long-term partnership tier on our /approach page as the recommended option. Most clients pick the alternative, which is project handover. The math favours the partnership for most of the clients who could afford it, but the psychological friction of ongoing engagement keeps the take rate lower than it should be.

Three years into the AKSD relationship is when the case for the partnership shape becomes obvious. The firm operates today with a system that does more, costs less, and fits better than any alternative they could have bought off the shelf. The system is owned by them. The evolution continues. The math is good.

For founders considering this shape of relationship: the case strengthens with time. The first year looks like overhead. The third year looks like compounding. We are happy to talk about whether the pattern fits your business.