Kenneth Kiffer Fong
HomeArticles

The Long Discovery

2026-07-14

It's Tuesday morning and I'm sitting in a cafe in Singapore, waiting for my 3-shot cappuccino - 3 shots because that's pretty much the max coffee I can consume in a day, and as with mornings like these, I need my pickup.

In a short while I will be walking over to our client's office to start a week's work of sessions with various divisions in their team. As I had walked into the lobby of the hotel yesterday I realised that it had been 3 years since I started this routine - three or four times a year I would take a flight down from KL to SG on Monday, check into the same hotel because it is walking distance from my client's premises and walking in Singapore is very pleasant - then start a 4-day workshop meeting with their management, IT, legal, sales, after-sales, and operations. Sometimes these trips are stressful, rife with politics and some internal friction with my team from back home. Today I feel rested and hopeful.

The sessions this week will be similar. Today, I will have an overview session with the top management to talk about the commercial contracts and future plans - we have been talking about eventually having the full end-to-end Customer Life Cycle 360 platform that, actually, all our other implementations have been leading up to. They'll want to talk timeline and numbers, and how data flows to each other. Later today, I will want to talk to their DPO and senior legal partner - there are a couple of contracts that I've submitted - one for renewal, and another for the latest project that I had already proceeded with before the agreement was signed as we were running on trust and relationship, but an agreement in the end must always be there - to clarify a few matters. Tomorrow will be interesting - a "train-the-trainer" session had been scheduled, in particular for the leads-management system, the leads management system product that we had deployed for the clients 2 months ago and this month was the end of Phase 2. Interesting because I absolutely have no intention on training the trainer. He's gotten most of what he needs from me, from IT, from various sources in the last few trips and online sessions. What I want to do is have him train me - and then see where the gaps might be. He knows his material. He knows the system, inside out. He knows the people and the operations and the way they ask questions, the way they work, the way they take shortcuts way better than I ever could, though I have myself spent quite a bit of time on ground before development and after deployment. He'll know how to train them, how to conduct the sessions and how to convey what they need. I don't want to teach and have him emulate me - instead, I want to help and augment his task.

I had designed the leads-management system to be the leads management system specifically built for this client and their related Malaysian counterpart. In fact, that was one of the selling points when they asked me to put together a business case that they could submit to their global principals as in, why us, why me. We had even gotten an accolade a couple weeks back where the MD had mentioned to their entire team "if it didn't happen in the system…" - meaning, if they didn't record it there - "…then it didn't happen". Separately she had also told, through the Director of IT, that she has never seen a system present the marketing leads funnel so transparently before. That remark was partly the catalyst for my visit this week. I wanted to see now how they are doing it well, using it so well that top management is happy. This way, I can also ensure that the trainer is teaching the shortcuts and little tools that I have purposely included in the workflow that should make the operational folk happy.

On Thursday is what I would consider my triumph in the sun - not really because it is a triumph - but because last week I had finished what I consider one of my best work currently, and Thursday (and possibly Friday) is the exposition. Mid last year the client had seen that they were having issues with their current queue management system vendor, who was not just jacking up the price of subscription but also forcing both technical and digital upgrades on the client. They asked me if we could add an enhancement to the App Ecosystem - my product - that was already running and formed a core part of their everyday operations. As usual, I thought about it, chewed about it, went downstairs and walked through their after-sales operations. Then I said yes, and went about what I called the "long discovery" process, where I "discovered" their system, walked through it as a customer, as various parts of their operations - call centre, reception, after-sales personnel, admin - then started designing the architecture. This was going to be a major extension to the Customer loyalty & CRM app ecosystem that I had already deployed for them. It was to solve a major daily operational workflow, but at the same time I did not want to just "replace". As with all the things I've been doing in the past 3 years, I wanted to improve, give the tools and data that was logical for all users - customers, internal ops and management - to have and use, and of course: I absolutely wanted to productify it.

This is where AI is a godsend, and my first foray into what began as vibe-coding with AI, then today doing both full-on architecture augmented by AI with vibe-coded prototype, and on the other spectrum on another new upcoming product altogether, me being the architecture and AI being the developer - not vibe-coded - but full all out development. But back in June 2025, while sitting in their meeting room and having 2 hours to myself because the next session was scheduled much later due to their internal needs, I thought to myself:

I had already seen the videos on YouTube where people all over were excited with vibe-coding this tool and that. I thought, why not just vibe-code a prototype…? I knew that whatever was built via AI at the time - this was one year ago - was really not ready for actual enterprise production and business, and I also knew that my lead tech would balk at it (later I found out I was wrong about that). But for a prototype? Should be fine.

With every single project I had, I already started with specs that, now looking back, were really just compiled lists. What the system should have. What modules. The workflow. What each node on the workflow should have. What should be able to be done on both sides. Nowadays my specs docs have evolved greatly from those list days, but that was enough to start. I fed that to Gemini at the time, gave more inputs, gave my actual workflow for both the customer and internal operations in story form (best for me to recall and dump everything), and in an hour I had an MVP v0.1. I walked through it myself, made tweaks, made rework, and in the end, I had my first prototype - Mk1. And I also had my first insight and learnings about how to develop with AI.

First: if you want something but didn't say it and it was a critical component - then the AI will assume it for you. So be clear, be detailed.

Second: AI sometimes completely somehow left things out it had already previously included and I had approved in subsequent run-throughs or additional things.

Third: sometimes it will say it did something, e.g. "fixed this" but it was obviously not fixed, actually nothing was done at all. This was especially present when the thread got too long.

In subsequent builds, my workflow evolved. I realised the first thing I should do was always to create the actual documentation. Full specs. How I wanted the MVP Prototype to work, vs how I wanted the real one to work. Decisions log. And I had to store this somewhere else - GitHub, and even my Obsidian account for easy reading. And then to always make sure AI always started with the consumption of those documentation. And each time we add a module, there should be:

I won't go into the full workflow but this approach has helped me continue working through subsequent AI drift, or to pick up quickly when I needed to start a new build thread because the previous thread had gotten too long, and even one time - I'll write about this one day - when my entire array of Cowork projects were somehow memory wiped. In that instance, I panicked, I bellowed; then I gathered my documentation and restarted the "training" process and was up and running again by the end of the day (mostly because I had multiple projects and "assistants" in those Cowork projects and I needed almost all of them that day).

Well, I am presenting the Mk5 prototype on Thursday. I really should drop the "MVP" part of that because it is no longer an MVP. In that session I had presented Mk1 which quickly became Mk2 after a round of discussion, then into Mk3. Mk4 was the previous full workflow prototype that gave everyone the full scope, full idea of how everything worked. Then unfortunately I had to park the queue-management system because the leads-management system came in. It was a critical project at the time and the client's MDs decided that on their side, no other digital development was allowed concurrently - the leads-management system got all their attention and focus at the time. That also worked for me as well, my team's currently really small and we couldn't have worked on the leads-management system and the queue-management system at the same time. But that was fine, because what was needed at the time was me - my work, my process design.

So I got to work on the Mk5 prototype. This was going to be the final MVP, and right after, I needed to handoff the entire thing to my developers. Not just the Prototype, but the full specs of what is to be in the real full system. How it differed to the prototype - because the prototype had hardcoded transactions and downstream "consequences" for demo. How the full queue logic worked - not in a technical sense, but in a real now what happens next and now what sense. My development team had complained that I was not detailed during the leads-management system project - it's true, I own that, but we were also working with a severe deficit in time and other factors that didn't allow me my usual "long discovery" phase. But at the same time, I also realised that even when I WAS detailed, my development team had missed out things before. So I realised I needed to change the way I worked.

So for the Mk5 prototype, as usual, I started with the documentation we already had. I fed that to AI.

Then the transcripts of meetings.

Then the change requests or additionals that I knew.

That all went into the documentation. I even started a new documentation system that I felt worked for our situation that had multiple views depending on the persona of the reader - a TLDR persona, a full in-depth Developer persona view, and an Operational "how to use this" view. This living documentation system - Salient, or my "Saliences" as I referred to each instance of the living documentation - was vibe-coded, of course but I fully intended on fleshing it out to a full framework build later.

We - the AI and I - brainstormed, discussed, became a committee of 3 (2 different AI threads - one for the actual documentation and build, one for poking holes) to scope out the entire thing. The workflow.

When all that was done, documented, and saved into multiple places with a workflow of updating - we built. At each stage, as I said before, we started with what we knew based on documentation. We referred back to transcripts to see if clients said anything in particular. I gave my full input and how I wanted this section to work, what it should have. The AI compiled and read it back to me. I verified or changed something. It came back with updated specs, and then a Verify list. Then it built.

I would verify - or refine, because once you have the actual thing in front of you, you really know what needed change or what didn't work and what was missing. Then it built, we finalised, and moved on. Repeat.

And so, this week, I am presenting the Mk5 prototype, and behind the scenes I have a full specs documentation array that I've already tested by dropping it into another AI thread to see if it was enough to build from. Seems yes. We'll see when I hand off to my developers in early August.

All this started 3 years ago when I first flew down to Singapore to talk to the client about deploying the same Customer App Ecosystem - the engagement platform - that had already been deployed and launched in Malaysia for their Malaysian same-brand counterpart - for their use in Singapore. At the time, this was going to be my 3rd Customer App Ecosystem and I had learnt a lot from my first Instance. While I always had the vision and intention to productify from day one, there were so many gaps and issues in my first 2 Instances - a lot of it was because I had never done one before. Now I knew. 3 years ago I came down and started my long discovery process, which surprised the Clients at the time because my discovery took longer than the actual build. But I needed to make sure I got it correctly. How their operations worked. How their management worked. And how their Clients behaved. And then, in 2023, the Singapore Apps Ecosystem was launched - with three brand apps fronting the customer loyalty system, the first actual really productified Instance of the engagement platform. Then it went into "maintenance" because I wanted the product to achieve stability. In the meantime we enhanced it in minor ways here and there - including a Body & Paint Repair Request, a sync so that the App could finally grab existing members from their global-owned and mandated DMS which didn't really allow for external connection at all. And then, last year, came the leads-management system, and later this year, the queue-management system. Customer 360 after that.

A colleague of mine back home once told a client that "hey, we do apps too now, you know!"

I smiled because the sentence was true yet had such a great gap from what we truly do now. Yes, we do apps now too. We truly do. And much, much more.