I am now an uber Claude powered vibe coding app developer! (well not really)
Why I started building apps after decades of successfully avoiding writing code
When we started AgileData seven years ago we made an initial decision that has served us well for the last seven years, until now.
We would never build the last mile tool, the BI front end.
The reasoning behind this principles was creating a BI tool or BI platform had too many table stakes from day one to have a chance of succedding.
Too many expected features, too much competition, too much time, effort and moolah to build something that could compete with the established players.
So we used third party tools. Looker Studio, Power BI, whatever the customer had already paid for. We focused on the hard bit underneath, the data platform, the data, the business context, the patterns, the scaffolding.
All bound with the core principles of being able to scale at will, and rin on the smell of a oily rag ( well based on the cost of oil before the latest middle eastern “adventure”)
That was the right call and has lasted us well for the last seven years.
Then vibe coding turned up and we revisited our thinking.
TL;DR
We are betting the BI platforms of the previous waves become legacy and “one shot BI apps” become the norm.
Bold statement right?
Let me give you some context (after all without Context all we have is data)
Why we think “One Shot BI Apps” are the new black
Up until now if an organisation wanted a bespoke Information Product / BI App that did exactly what a consumer needed, they had to pay an expert development team to build it and then maintain it.
That took time, effort and money.
So instead they compromised, they bought a BI platform, a general purpose tool that kind of did what everyone needed but never quite did what anyone actually wanted.
Stakeholder don’t actually want a dashboard with 24 areas and 47 filters they have to squint at to find the one number they care about. That is just what they have had to live with until now.
They want an app that answers their specific question or even better tells them the next best action. They want an app that works the way they think and the way they work, with nothing else getting in the way.
Data teams doen’t want to spend three iterations building a Power BI report that gets used twice and then someone asks for “just one more chart”. They want to deliver something that actually gets used, that drives proven organisational outcomes and value and most of all and makes somebody’s life better.
That sure as shit ain’t the dashboards of old.
Stakeholders and Data Teams want something that does one thing well, enables one specific job to be done, and gets out of the way.
The BI platform was always a compromise. It existed because bespoke was too slow and too expensive.
And that where vibe coding using tools like Claude Code have changed the promise.
They promise:
Low cost :: Making bespoke cheap as chips.
Speed to market :: Minutes and hours, not weeks and months.
Democratisation :: Anybody who can describe what they need can build it.
Cost :: Less than your annual BI platform licence, and your big server/services infrastructure costs by a long way.
With all these promises why would they keep compromising?
We have seen this movie before
We have seen promises like this before, promises that are early in the hype wave, and then eventually get grounded in reality
We have seen how every time we democratise access to something in the data domain, we eventually end up with sprawl.
The OLAP wave democratised access to data. What did we get? A mess of cubes nobody could find or trust.
The Tableau wave democratised access to dashboards. What did we get? Thousands of dashboards, most of them showing slightly different numbers for the same thing, or a slightly different number of data columns.
The dbt/modern data stack wave democratised access to data transformation. What did we get? 5,000 dbt models with no actual data model, anybody?
Now we are about to democratise access to building BI apps. And the sprawl problem is going to make the previous waves look like a gentle ripple.
I have written thoughts about some of these anti-patterns in the new “AI” wave before:
But what if you already had the scaffolding?
Luckily we have spent the last seven years building out a data platform that is both opinionated and has all the scaffolding that should (in theory) help manage this inevitable sprawl.
So we started by creating a simple templating pattern in our platform. A way to quickly build and deploy a “one shot BI app” using your favourite LLM tool. Claude, ChatGPT, whatever you prefer.
Then we let it loose with one of our talented early adopters Network patterns, to see what he would actually do with it.
We were amazed with what he started creating.
Next we used it to build a prototype for a customer who wanted us to upgrade the capabilities they had been using with us for the last few years.
They loved it.
So once more into the breach, my friends.
“Can’t code, won’t code, don’t code” tries vibe coding
One of my frequent sayings is
I “can’t code, won’t code, don’t code”.
But I wondered, with the latest tools like Claude Code and the latest models like Opus 4.6, is that still true?
I find I learn best by doing.
So I thought I would experiment with creating an app using Claude Code to see how the process would work for somebody like me. Somebody who understands the patterns and requirements inside out, but has spent decades successfully avoiding writing code.
Now I could have vibe coded a “one shot BI app” for a customer, or built something with public dummy data to experiment and learn.
But the Information Product Canvas was the obvious first cab off the rank.
I have been iterating that pattern template for over a decade. I know the 12 areas, how they relate to each other, what the user experience should feel like, and what the anti-patterns look like.
If Claude Code got something wrong, I would (hopefully) know immediately.
Plus I had “build an IPC app” gathering dust on my backlog for years. I never wanted to spend the moolah to pay somebody to build it.
Vibe coding supposedly changed the economics.
The result
One of my other common sayings (apart from #Whoot!) is
Sharing is Caring.
I published the resulting Information Product Canvas app as open source.
You can read about what it does and how to get it running over on the Information Product Canvas companion site:
And grab the code from GitHub:
But of course I didn’t stop at one app
For those that know me know when I find something interesting, something that looks like a useful pattern, but I cant describe that pattern with clarity results in something I can’t leave well enough alone.
The Information Product Canvas app scratched one itch.
But it also made me realise how quickly I could experiment with ideas and templates that had been stuck on the backlog for years. Pattern Templates like the:
Business Event Matrix;
Concept Models;
Business Glossary;
Layered Data Architecture Checklist;
Data Dictionary;
Data Contracts;
Data Asset Catalog;
Ideas I couldn’t justify spending the time or money on before, but could now explore by whispering sweet nothings to Claude Code in the background for a few hours, while still doing other more important work.
So I have kept building. More standalone apps, all connected by a shared backend.
Some of them are getting close to useful. Some of them I still hate.
I will publish each of them as open source standalone apps as they get to a stage where I don’t hate them.
If you have been following my Context Plane experiments you will start to see how these pieces fit together.
https://agiledata.info/t/context-plane
If you want to help build them with me, just sing out and let me know, the more the merrier.
The bit I haven’t been sharing
As part of my Sharing is Caring mantra I realised I haven’t been sharing my journey as I learn the process and pros and cons of vibe coding something that needs to be actually used, as a person in the data domain who can’t code.
So as I keep working, off and on, on my vibe coding process and building out apps, I will post articles on what I have experienced and my thoughts around it.
What worked. What went sideways. What surprised me. What I learned about building software through conversation rather than writing code.
If you are a data person curious about vibe coding, or a builder wondering what it is like when someone who “can’t code, won’t code, don’t code” picks up Claude Code and starts whispering sweet nothings to it, hopefully the series will be useful.
If not, maybe turn off substack notifications for this site for a little while ;-)