Delivering
software that
matters.

When I joined this engagement there was no SOW, no SOP, no RAID log and no agile process in place. The client had an ecommerce platform running on physical infrastructure in Malaysia and needed it migrated to AWS while keeping the payment checkout flow secure and the business running.

My first two weeks were spent onsite in Malaysia doing discovery. I sat with infrastructure teams, payment vendors and business stakeholders to map out every data flow and integration touchpoint before writing a single project document. There was no existing structure to inherit and no prior delivery lead to hand over from.

From that discovery I built the project baseline from scratch. This included the SOW, SOP and SLAs, a RAID log, a dependency map and a steering cadence. I also introduced agile practices to a team that had never worked that way, coaching them through Scrum one sprint at a time.

The payment integration workstream carried the highest risk. I coordinated between development, QA and the third party payment gateway to make sure the checkout journey was both secure and compliant before go live. In parallel I managed the data migration covering customer records, product catalogues and transactional data, making sure nothing broke during the move to AWS.

By the time we reached go live the numbers told the story. Delivery predictability improved by 15 percent. Manual testing effort dropped by 40 percent once automated regression suites were in place. The go live itself was clean with no major incidents.

What this taught me is that governance is not something you wait to receive. When there is no playbook the job is to build one fast enough that the team can move with confidence while you are still building it.

Midway through a release cycle our sprint velocity and dependency data started telling a different story than our original commitment. The integration work was slipping and the gap between what leadership expected and what the data showed was widening.

Rather than wait for the gap to become a crisis I brought it forward early. I pulled together sprint velocity trends, dependency mapping and a risk register update into a clear RAG status report. Then I built an options paper for leadership with two real choices, slip the release date or descope certain features and ship on time.

I presented both options with their trade offs laid out plainly, no hedging and no burying the bad news. Leadership chose to descope. We delivered a stable release on the original date and I followed up immediately with a plan for the deferred scope so nothing fell through the cracks.

This is the kind of decision I try to bring to every programme. Data should drive the conversation, not opinions or optimism. And when you give stakeholders a clear choice instead of a vague warning, they can actually decide.

The starting brief was simple. Build an AI tool that teaches children multiplication using short video lessons. The obvious answer is a video generator, type in a fact, get a video back. I deliberately built something else.

A video generator treats every output as disposable, regenerated fresh each time with no real concept of what a specific child already knows or how they learn best. What I wanted to design was a learning engine that happens to deliver through video, with the personalisation logic sitting underneath the content rather than inside it.

The first real design decision was separating two things that are easy to lump together. Surface personalisation changes how a lesson looks, a different counting object, a different colour palette, a different narrator voice. Structural personalisation changes how a child is actually taught the concept, full sequential counting versus building a new fact from one already mastered.

Mixing these two up is a real failure mode, not a theoretical one. Swapping a theme is cosmetic. Swapping a teaching method without checking whether a child is ready for it can teach an incorrect mental model. The architecture treats them as structurally different from the first layer onward, not as two settings on the same dial.

That thinking shaped a five layer system. A learner profile layer captures each child through a static profile and a dynamic profile built from observed behaviour, with special considerations modelled as independent parameters rather than a single mode. A content generation layer separates script writing from content assembly so themes can change without rebuilding the underlying pedagogy. A live adaptation layer watches correctness, latency and replay behaviour, defining mastery as an explicit rule rather than a vague system judgement. An inclusive design layer treats accessibility as a first class parameter set with a non negotiable minimum pacing floor, not a separate mode bolted on afterward. A measurement layer tracks mastery per fact rather than per video watched, producing a simple parent facing summary instead of a wall of data.

The detail worth pulling out is in the learner profile layer. Early drafts considered a simple toggle, default mode versus special needs mode. I rejected that on purpose. A binary toggle assumes every child sharing a label needs the same thing, which is false. Two children with the same diagnosis can need opposite settings on stimulation level, repetition tolerance and pacing. Every child is configured through the same small set of independent dials, just set differently for that child. The architecture designs for the underlying need directly, not for a label.

Writing the architecture document was satisfying in the way design documents usually are. It also left an honest gap. A document describes how a model should behave when given the right context. It does not prove the model actually behaves that way once that context is real.

That gap is what led me to the Model Context Protocol, MCP, which lets a model call real functions outside itself instead of only answering from what it already knows. I built a small Python server exposing three tools, one returning a child's full learner profile, one checking whether a themed lesson script already exists for a given fact and one saving a newly written script for reuse. Then I connected it to a real client and watched what the model actually did with them.

The most useful moments were not the ones where everything worked smoothly. The first time I asked the connected model to call the profile tool, it declined. The tool had no stated connection to anything we had discussed, and the model reasoned that pulling a child's data into an unrelated conversation just because the tool was available was not something it should do without being told why. That is exactly the behaviour you would want from a system handling data about children, and it appeared on its own.

Once I rebuilt the profile data to match the architecture's real schema, including attempt level detail on facts still in progress, the model's reasoning changed in kind, not just in accuracy. Given three attempts on one fact, correct, then incorrect, then correct again, it correctly judged the fact as not yet mastered against the architecture's three consecutive clean attempts rule. It then connected that judgement to the child's low repetition tolerance on its own, flagging that drilling the fact too hard in one sitting would work against another stated parameter, something nothing in my prompt asked it to cross reference.

When I asked it to generate a new lesson script and save it for reuse, it checked the available tools, noticed there was no save function yet and stopped to ask rather than pretending the problem was solved.

The hardest bug in the whole project came from one misplaced blocking line of code that prevented a new tool from ever registering, not from anything conceptually difficult. Most real engineering friction looks exactly like that, plain and unglamorous, not like a deep gap in understanding.

What I keep coming back to is this. Giving a model structured real context doesn't just make its answers more accurate, it changes the shape of its reasoning. That is the actual argument for architecture work like this. Not that it produces a nicer document, but that it is the difference between a system that answers questions and one that reasons inside a real situation.