Nigel and I have been pretty busy lately, we signed up a couple of Information Product builds and runs, that meant some heavy work in both our AgileData Information Platform and our AgileData Way of Working.
One of the bits of work was going through SOC2 certification, we are finally ready for the Type 1 audit, I have to say that doing SOC2 as a two person company is interesting, think I will write more on that later.
Another bit of work was the result of winning a competitive public tender to extend out the VIEW system we have been building and supporting with New Zealand on Air for a few years.
The RFP wanted new data collections for a bunch of social platforms and extended capability for the current Linear, Video on Demand and Web Journalism data sources we already had been running for a while. As well as providing these capabilities to two other NZ media funding agencies.
It also allowed us to package up the new VIEW360 capabilities as a commercial product to take to the global market. What we are branding as MediaView360.com. (still working on the messaging, branding and website for that one).
Until we embarked on iterating these capabilities, we had always used Google Data Studio as our primary last mile tool for our customers to consume their information from.
Data Studio was well integrated with Google BigQuery, it was free (well no license costs) and it did a lot of what the other more expensive BI tools and platforms did.
It was good enough. But it wasn’t great. And we wanted to make Information Products that were great!
When we started AgileData almost 8 years ago, the one thing I said we would never build is a BI front end, the table stakes were to high and there were too many other good options. the problem to be solved was the complexity of the data in the messy middle not yet another BI tool.
So guess what, we decided now was the right time to move that stake.
The ability to use GenAI tools to build what you need and more importantly what you want in this space is no less than fricking amazing.
Don’t get me wrong, its not all honey and marshmallows, there are a lot of things that you still need to wrangle, a lot of still muttering under your breath, a lot of four letter words. I think my go to skill in Claude Code at the mo is /wtf.
But we are managing to build and run things with just Nigel and I, just two co-founders, which we would have normally needed a full team to do.
And we were lucky (or maybe clever) that a lot of our DataOps patterns were easily adopted for our Information Products, our new “Information Product Builder” and “AgileData Practioner” capabilities.
For example I can push a change to the Information Product github repo for a customers AgileData Tenancy and it will deploy that new version automatically into the private Google App Engine container for that customers tenancy and give us all the serverless cost and performance benefits we have had for our AgileData App for years, by resuing that same pattern.
But again ill leave that Pattern as a post for another day.
So for this article I thought I would share a couple of things that we have built lately that I found exciting.
I have previously written how we are building out a Design System for the Information Product Builder to use.
This gives us scale through the DORO principle (Define Once, Reuse Often)
But we have learnt as we have worked in this new way that building and deploying cookie cutter “Dashboards” that all look and behave the same wasn’t going to cut it. If we were going to do that we might have just reused an open source BI tool or licensed one of the many BI Dashboarding platforms.
What we have found is we should reuse the core of our Design System, but then focus on the unique areas the Stakeholder or Subject Matter Experts really want.
As part of the VIEW360 Information Products one of the data sources we collect is Linear TV data.
One of our key customer Stakeholders asked there any way we could present this data in the form of a TV Guide.
I was sceptical, but as is the AgileData way, I thought lets do a McSpikey, a research spike, and see what happens.
This is what happened:
These are screenshots of the component from our Design System with dummy data, not from our Customers tenancy or their data.
I was surprised how easy it was to “vibe” code this component.
And then of course the flood gates of ideas opened. Would we be able to click on the Programme and see the underlying measurements for it, was the next thing we were asked.
Back to another iteration with Claude Code to which the answer was of course yes.
This Way of Working of small iteration, small builds with constant feedback before we move on to the next small iteration really is the key, that is the agility.
Initially I used to take what I was asked by the Stakeholder via email or via a meeting transcript and summarise it and give it to to Claude Code. I found that I was doing the equivalent of listening to the Stakeholder speaking German, translating it to English so I could understand it and then translating it to French so Claude Code could understand it. That translation process caused no end of problems.
Now I just paste the selected part of the email or the selected part of the transcript and get the hell out of the way.
Again, this is not YOLO or a fully AutomatedAI pattern. I am always the Human in the initial loop, reviewing and asking Claude Code to refine things to both make sure it uses or improves our Design System (this process is a lot harder than it looks) and to provide a strong opinionated view on what is good enough to share for feedback.
I am however doing a McSpikey at the moment to see if I can take myself completely out of the loop and have the Stakeholder or Subject Matter Expert interact directly with an Information Product, called PIONEER, to do the initial ideation.
We will see how that one goes.
Another example from another customer.
For this customer we are building a bundle of Information Products that help with debt recovery optimisation.
We are building them to solve that customers problem and they will take that solution to market and resell it. Build it Once, Sell it Many (BIOSIM doesn’t really have the same ring as DORO, or maybe it does …)
For one of the problems we needed to solve in this space the Stakeholder said they thought a “Vintage Analysis” might be useful.
What the hell is a Vintage Analysis I thought.
So off goes another McSpikey.
This is a Vintage Analysis.
Its what I know of as the Cohort Analysis Pattern. Something we have used a lot in SaaS companies.
Again screenshots of the component from our Design System with dummy data, not from our Customers tenancy or their data.
I didn’t know what a Vintage Analysis was, the LLM did.
We now have a bunch of these and each one is a reusable component in our Design System that is parameterised. They can be used by each customer tenancy, but tailored for that customer.
And when we update one of the components in the Builders Design System we can cascade those changes efficiently to a shit ton of customer tenancies, without losing their personalisation. Again that pattern was harder than it looked.
That is how we can scale as a two co-founder company.
I often say writing helps me think.
We have been so busy lately I have not made the time to write.
So this article really started off as oh I love those components lets finally make some time to write about them.
And at the end of the writing process I have three takeaways in my head:
GenAI tooling allows us to quickly iterate in small chunks and then get feedback, it helps us in increase our agility.
Personalised components that do exactly what the Staleholder wants, really does provide Stakeholders with a magical experience.
To scale, spend as much time on automation, resuse, iterating your Way of Working as you do on the build itself.
Now back to Vibe coding the next component a customer Stakeholder has imagined.