What building our own AI meeting assistant taught us about AI transformation
At Renessai we spend a lot of time helping organisations scale their AI work: picking the right problems, getting the data and governance right, deciding what to build versus buy versus partner on, and organising the people who deliver it. There's an old saying in the industry about eating your own dog food. It's a fair test of whether you believe what you're selling. So we asked ourselves the obvious question: are we actually doing what we tell our clients to do?
Renessai is now two years old. We started with the basic stack any new consultancy buys:
Google Workspace,
Sana.ai for meeting notes,
Attio for CRM,
Operating.app for consulting ops,
Slack for internal chat.
It got us up and running. Then, in the middle of growing, we drifted. At the start of this year we finally did to ourselves what we'd been telling clients to do: sat down, mapped the stack, and asked where our data, our workflows and our decisions actually lived.
AI inside external platforms, or AI on top of your data?
Over the past two years, every business platform has bolted AI features onto its product. Sana.ai grew from a meeting note-taker into a generic ChatGPT-like platform. Google Workspace added Gemini in Docs, Sheets, and Slides. Slack launched personal AI agents. Each vendor pitches the same story: we know your business context best, our AI uses it best, stay inside our walls. Many of their features overlap with each other, and you end up paying multiple times for roughly the same outcome.
The real question underneath all of this: do you want to live inside the AI boundaries third-party vendors decide for you, or own your own data and context layer and design AI workflows on top of it, under your rules and toward your goals? Most organisations, us included, start with third-party platforms. That's fine. Tools like Sana.ai or Microsoft Copilot are useful enough to get going and eventually limited enough to frustrate you. For us the answer was clear: we want to think beyond the AI capabilities of existing platforms.
Mapping the stack, one module at a time
To own our data and build our own AI workflows on top of it, the first job was to map everything we had in play. Every process, every data source, every platform. Then for each tool: can we get our data in and out on our own terms, or does the vendor decide what leaves the building?
There's no established methodology for rebuilding how a company actually works once AI agents are in the loop, so we borrowed one. Carliss Baldwin and Kim Clark's 1999 book Design Rules, Volume 1: The Power of Modularity argues that complex systems survive change only when they're split into modules with clear interfaces. We applied that thinking to our tools. Treat every tool as a module with data coming in and data going out. If we own the interface, we can swap, substitute or augment the module without touching the rest. If the vendor owns it, we're stuck with whatever they decide to build next. This is also what we advise our clients to do.
The first module to substitute was the meeting assistant. Sana.ai had a problem that blocked everything else: it locked our meeting data behind no API. We couldn't access our summaries or transcripts programmatically. We couldn't build anything on top of them. Meetings are a big part of a consulting firm's daily life, so owning that data matters.
Which led to the next question: build, buy, or partner?
The death of bad SaaS is real
Replacing Sana.ai with a better (meaning more suitable) SaaS meeting assistant would have been an easy decision two years ago. Not obvious anymore. There were alternatives with proper export APIs that would have fixed our Sana.ai problem, but most of them were bloated with the same AI features we'd already been paying for in other tools: personal agents, meeting digests. More things to pay for, none of which we needed.
Meanwhile, 2025 turned out to be the year of coding agents. Claude Code and others collapsed the cost of producing code, especially in the hands of experienced software people. In early 2026 the stock market caught up. Listed SaaS companies plummeted. LinkedIn filled with posts about building your own CRM over the weekend and declaring the death of SaaS.
We saw a real opportunity to replace bad SaaS, the kind that locks your data in and ignores your workflows, with something built in-house for the way we actually work. And to test the weekend-CRM hype on something smaller than a CRM. Having used Claude Code daily for about eight months, it was pretty easy to get a rough version of our own meeting assistant running in two days. Getting a production-quality version ready for wider use took about two weeks. We keep changing it based on user feedback. That's the whole point of owning the tool.
So the hot takes about building production-quality CRMs over the weekend are mostly noise. But the shift is real: building instead of buying (or partnering) is more approachable to more companies than ever before. That said, producing more software for yourself doesn't move your business anywhere without a proper strategy. If you're going to build, maybe point that capacity at your customers. Rebuilding internal systems that already work and carry years of domain knowledge wastes your best people on work that will never show up in revenue.
“Meetings are a big part of a consulting firm's daily life, so owning that data matters.“
Towards company-as-code
Our in-house AI meeting assistant went live in early March 2026. We own our meeting data now, and it feeds directly into our internal workflows and the AI agents we work with every day, like Claude Cowork. Those agents finally have the business context they need to be useful.
A few things this one tool swap taught us, more broadly:
Data access decides the ceiling.
If your existing tools don't let you reach your own data, no amount of AI features bolted on top will take your transformation further than those tools allow.Map the stack as modules first.
We swapped Sana.ai without touching Slack, Google Workspace or Attio because we'd drawn clean boundaries first. Without those boundaries, one change breaks the rest. Start where real pain meets a small blast radius.Decide which layer you own and which you rent.
Sana.ai, Google Workspace and Slack were each pitching themselves as the single assistant that would know our business. But each one only knew its own slice: meetings, docs, or chat. Own the layer that holds your client data, your meeting notes, the way your people actually work. Rent the rest without apology.Attention, not code, is the scarce resource.
Every internal tool you build is a build cost, a maintenance tail, and the opportunity cost of the customer-facing work you didn't do instead.Drift is the default state.
We'd been selling transformation to clients while our own stack quietly became the thing we tell them to avoid. Without someone whose job is to keep noticing, nothing corrects it.
Substituting one meeting assistant is a small step. The bigger project is turning Renessai into something closer to company-as-code: an organisation defined by code, data, context and skills, where software, AI agents and people actually combine instead of sitting next to each other.
When they do, a team our size can take on work that used to need a much bigger one, and move through it at a pace that used to belong to much bigger budgets. It also means the company stops depending on any single person carrying the context in their head. When someone takes leave or moves on, the context stays put.
That's easier said by consultants than done. It's why we're now doing it to ourselves.
