I was introduced to the Theory of Constraints early in my career, and— being young and overly optimistic— I just assumed this was how all businesses worked. Focus on flow. Identify bottlenecks. Fix them. Repeat. Easy, right?

Fast forward to today, and unless you’re deep in manufacturing or happen to have a Goldratt poster on your wall, chances are you’ve never even heard of it.

But I’m getting ahead of myself.

I often find myself repeating Donald Reinertsen‘s line from The Principles of Product Development Flow:

“I used to think that sensible and compelling new ideas would be adopted quickly. Today, I believe this view is hopelessly naive. After all it took 40 years before we recognized the power of the Toyota Production System”

So nearly two decades ago, it was with that same apprehensive optimism I took the opportunity to work in the IT division of an enterprise undergoing a Lean transformation. I was curious, eager, and just slightly annoying — always asking how these principles, coupled with Theory of Constraints, actually played out beyond the whiteboard.

Lean and Six Sigma were taking root in business units, and before long, they expanded into cost centers like IT. That environment planted the seeds for experimenting with Kanban systems in IT project and program delivery — and from those early experiments, kanbanway.com was born.

One of the most powerful outcomes of that phase was learning to track how long work stayed at each stage of a workflow. I owe a great deal to Doug MacAskill , Charles Cormier, Atul Kunkulol, Donald Dickson, Eric Falkjar along with David Anderson, Mike Burrows, Jeff Anderson, Alexei Zheglov, Kevin Behr for supporting & mentoring me during those formative stages of learning and experimentation. That experience made it clear: insights into risks, quality, scope, timelines don’t come from status reports — they come from tracking how work actually flows.

Fast forward a few years, and I found myself working with teams using Jira. That’s when I hit a wall. A very tall, very well-documented, but entirely opaque wall.

Jira would show how long a ticket had been sitting in a given status, but there was no way to tell whether that was normal or an outlier. Was it an exception or a systemic pattern? To answer that,
I needed historical data; aka changelogs. Jira treats changelogs like crown jewels — technically accessible, but practically locked behind dragons and a constantly deprioritizing service desk ticket.

Most tools that are not built from groundup keeping Kanban practices in mind offer dashboards and snapshot metrics that tell you where things are, but can’t answer questions like:

• How long does it take to get from “Ready for Dev” to “Shipped”?
• Where is work getting stuck?
• Are we improving over time?
• What patterns signal risk or instability?

At that point, not knowing how to code became a real handicap. While managers (Login Jones, Dennis Herdman, David Kwok) were sympathetic and extremely helpful, my requests for better access to changelogs kept getting de-prioritized in favor of, well, literally anything else. So I took matters into my own hands — and dove into Python. Those were the days of scouring Stack Overflow at 1am. Painful? Absolutely. But character-building, like all good debugging sessions.

Armed with some scrappy Python scripts and overly ambitious spreadsheets and pivot tables, I started analyzing throughput and cycle time. I brought these metrics into team retros, and suddenly,
things clicked:

• Improved ticket hygiene: tickets reflected real work, not just an existential undefined wishlist
• Better data quality: Jira began to mirror reality instead of being a digital junk drawer
• Reduced variation: we started seeing more consistent delivery patterns

As consistency improved, I set my sights on the next aspirational goal: forecasting delivery dates with data.

But before we go there, we need to talk delivery processes — because trying to forecast without understanding flow is like trying to predict traffic without knowing what a traffic jam is.

Delivery process is where flow lives (or dies).

Understanding the Delivery Process

Across most IT engineering and operational orgs — regardless of size or tooling — the delivery process tends to look like this:

• Work Intake: Ideas, requests, and bugs enter through intake queues – formal or informal
• Planning & Prioritization: Work is clarified, sized, and committed (supposedly. or they become queue jumpers)
• Execution: Tickets move through stages like To Do → In Progress → Done (hopefully your visual board is a better reflection of the workflow than just these 3 queues)
• Deployment & Feedback: Changes go live, monitored for impact or regressions

On a whiteboard, it’s elegant. In reality:

• Handoffs create invisible queues and untraceable delays
• Work-in-progress piles up in “In Progress,” even when no one’s touching it
• Bottlenecks shift daily, like some cruel game of delivery Whac-A-Mole
• There’s little insight into service level delivery agreements on work types, and if the team is meeting them (Ops teams are an exception where Incidents and Problems are tracked)

Most tools show you where things are. A few will even show you how long they’ve haunted a column.
But almost none of the generic tools like Jira help you understand whether that’s normal, improving, or on fire.

This missing perspective leads to vague retros, reactive firefighting, and little insight into why issues happen or how to fix them. For teams with lower maturity, the starting point must be simple.

That gap — between what’s visible and what’s actually happening — is what LeanMetrics was built to close. Not just a snapshot, but a trendline. Not just a board, but behavior over time.

The people I built this for? Folks like me — individuals who don’t have access to the Atlassian Marketplace or premium tools like Nave, ActionableAgile, Flowlens, Kanbanize, Flomatika, etc.

The real takeaway here?

• Make your board match your workflow
• If your Jira board says “To Do → In Progress → Done,” and your actual process has seven handoffs and a QA queue disguised as a Slack message … you’re not visualizing flow — you’re just decorating columns

If you’re not sure where to start, value stream mapping is a great way to kick off your improvement journey.

Armed with enough metrics to spark real conversations, I wanted to go further: give more people access. Automate the grunt work. Democratize flow insights.

That meant one thing — building a real app.

Building LeanMetrics

I had the scripts. I had the data. But building a real app? That was unfamiliar territory. My professional dev experience at that point was limited to duct tape, some SQL, and shouting at the browser.

Then ChatGPT was released.

I had some advantage. My exposure to AI until then had been through AIOps (thanks Ranji Narine, Khaled Zaky) and a cautious fascination with ML. Like everyone else in early 2023, I thought: “This is it.
I’ll just describe the app and it’ll write itself.” Spoiler: it did not.

I started discussing architecture, cloud deployments and asking for React code — React? What’s that? The responses were confident, verbose, and occasionally helpful. But it quickly became clear: ChatGPT (or Claude, and more recently Gemini) wasn’t building the frontend for me — it was pair programming with vibes.

There were long, painful nights and weekends of:

• Copy-pasting code that didn’t run
• Asking “what does this error mean?”
• Debugging line by line with GPT like it was a slightly overconfident junior dev who’d never seen your stack before

Frustrating? Sure. But also strangely exciting. It forced me to learn.

Eventually, I stitched together something functional:

• Cycle time histograms
• Throughput trend charts
• Filters
• Forecasting with MonteCarlo simulations
• Visibility into granular workflow efficiency

It was crude at first. But it worked. I could finally show teams what their delivery behavior looked like. No more speculation. Just flow — visualized.

Victory? Sort of. The insights were there — but they were trapped behind my laptop.

While I had automated the process of creating charts, only I could generate them.

There was no UI for credentials. No auth. No way for teams to try it themselves. Just me, manually running scripts like some overworked data sorcerer.

And after about a year of evenings & weekend hacking, trial-by-error deployments, and more than a few “why is nothing rendering” moments — LeanMetrics was born.

Best part – it was privacy focused and secure as best as I could make it. Dhruv Chandra – you would be very happy!

Lessons from Vibe Coding with AI

If I had a dollar for every time I typed python app.py and npm start and hoped for the best, I could’ve funded a UI designer. But of course professional developers/engineers already know this, and their jobs are secure.

Here’s what I learned from building with ChatGPT, Claude, Gemini, and whoever else was hanging out in my browser tabs at 2am:

It can write code, but not your code.

It’s great at scaffolding, but it doesn’t remember your tech stack, your quirks, or the dozen half-baked design choices you made at 11:47pm last Friday; even in the same conversation thread. You’ll ask for a button — it’ll give you a UI component that works beautifully in some other repo.

It doesn’t read your mind.

You can say, “I want a filterable histogram,” and it’ll give you something that looks like it belongs in a crypto dashboard from 2019. Styling? Impeccable. Logic? Nonexistent. You’ll spend more time debugging the AI’s optimism than your own code.

It’s confident — dangerously so.

ChatGPT will hand you broken code with the confidence of a developer who’s never touched a terminal. Something crashes? “Check your config.

Thanks, Socrates. Meanwhile, I’m five layers deep into an obscure NPM package trying to figure out why everything is pink.

Vibe coding is not software engineering.

It’s improv. It’s jazz. It’s pair programming with an intern who read a lot of Medium articles but forgot to run the linter. Sometimes it flows. Sometimes it explodes. Often, both.

It’s humbling in the best way.

AI won’t replace developers yet — it’ll just make you painfully aware of how much you don’t know. And that’s not a bad thing. Because once you survive the confusion, the re-prompts, and the hallucinated TypeScript error messages, you come out the other side sharper, more patient, and a tiny bit more dangerous.

More importantly, you’ve learnt to ask the right questions.

In the end, ChatGPT didn’t build LeanMetrics. But it absolutely gave me the motivation to attempt a build. It created blanks. It filled in the blanks and occasionally gaslit me.

Would I do it again? Absolutely. Would I recommend it?

Only if you’re okay laughing at your own stack traces, arguing with a robot, and occasionally searching for: “what does async do in React really.” the good old fashioned way.

Deployment and Operationalizing

Once I had a usable product, I turned my attention to making it operational:

• CI/CD: Still manual, but reliable. I documented every step and followed it religiously at every deploy. Automation remains aspirational — and that’s okay.”
• Containerized: I was very clear early on I wanted the app to run on containers and benefit from the small infra footprint (thanks for those early Cloud project
• Hosted: I was also very clear – no compromises on security and privacy in production. That added about 8 months to the project as I iteratively refactored.
• Monitoring: No logs. I didn’t want the app to retain any private data. GCP does basic infra logging to protect against threats. (Send me screenshots if you run into issues)

What’s Next

Over the years, I’ve been fortunate to be given the opportunity to improve team performance, and analysis like these have been foundational in the journey. User feedback will determine any further development of the app.

Not that the cat’s out of the bag, another aspirational project perhaps!

If even one team finds value in this app, then every 2am debug session and AI-induced existential crisis was completely worth it.