What should business software look like when AI is part of the architecture?
I'm building Kerrzo to explore that question.
Kerrzo brings the operational context of a business together so people and AI can work from the same understanding.
Customers, sales, support, projects, people and knowledge become connected parts of the same system, with AI designed into the architecture from the beginning.
- Product
- Kerrzo
- Exploring
- AI-first business operating system
- Status
- Active · 2026 — now
Customer context alongside the sales pipeline. A view from Kerrzo's marketing UI collection, while the product continues to evolve.
Most business software was designed before AI could do the work.
CRMs store customer records. Support systems store tickets. Project tools store tasks. HR systems store people. Knowledge bases store documents.
Each system understands one part of the business.
AI changes an interesting assumption:
What happens when the software can understand the context across all of them?
That's the question behind Kerrzo.
I don't want to bolt a chatbot onto a collection of traditional business tools. I'm interested in what the underlying product should become when AI is part of the architecture from the beginning.
The interesting part isn't adding AI to business software.
It's rethinking the software around it.
Start with the work businesses already do.
AI only becomes useful when it has meaningful business context to work with.
Kerrzo starts with recognisable workflows: leads, pipeline, customers, sales and campaigns alongside support, knowledge, projects, people and operations.
Some areas exist today. Some are evolving. Others are still the direction of the product.
The important part is that the operational system and the intelligence layer are being designed together.
Projects, progress and delivery milestones in one operational view. From the Kerrzo marketing UI collection.
The agent workspace presents the direction across sales, support, operations, production and people. Marketing UI mockup; capabilities are still evolving.
The application creates the context.
The AI makes the context useful.
Answering questions is only the beginning.
The first useful layer is straightforward: let someone ask questions about their business.
What happened with this customer?
Why are these opportunities stuck?
Which support issues keep appearing?
What changed this week?
But answering questions is only one use of shared context.
If the system understands the business, the user, their permissions, the relevant data, the workflows and the available tools, AI can increasingly help with the work itself.
I'm exploring things like preparing follow-ups, researching leads, summarising customer history, spotting stalled opportunities, triaging support, preparing meetings, updating records and surfacing things that need attention.
These are things to build and test — not a list of finished capabilities.
The direction is from software you operate to software that increasingly helps operate the business with you.
AI-first still needs good architecture.
The current stack includes Next.js, Vercel, Supabase and Postgres, with retrieval, AI models, agent workflows and integrations.
The interesting decisions aren't the logos. They're the boundaries between them.
Next.js · Vercel
Supabase · Postgres · pgvector
Models · Agents · Integrations
Across every layer / organisational boundaries and user permissions
- 01
Shared data
Operational data and AI context should not become disconnected worlds. The same business model needs to support both.
- 02
Permissions
AI should operate within the same organisational and user boundaries as the application. Access to a tool is not permission to use every record.
- 03
Knowledge
Documents and unstructured knowledge need to participate alongside structured business data. Retrieval is part of that connection.
- 04
Models
I don't want the product to assume one model or provider will solve every workload forever.
- 05
Agents
Agents need context, tools and boundaries. The important work is deciding what they can do, for whom, and where a person needs to remain involved.
The way I'm building it is changing too.
Kerrzo is also changing how I think about building serious products.
The workflow increasingly combines product thinking, architecture, AI-assisted coding, rapid prototyping, testing, real usage and iteration.
The same technology changing the product is changing the economics and speed of building it.
That lets me explore more — but being able to build more doesn't remove the need to decide what matters.
Building it isn't the test.
AI-assisted development makes it possible to build more.
That creates its own danger: it's easier to confuse software shipped with value created.
Kerrzo is my primary commercial product bet. But product-market fit still has to be earned.
The platform only becomes interesting as a business if people use it, rely on it and eventually pay for it.
The next phase isn't about proving that I can build the platform.
It's proving that the platform deserves to exist.
This page will change.
Kerrzo is active work.
Some ideas here will survive. Some won't.
The architecture will change. The product will change. And hopefully my understanding of the problem will change with it.
That's the point of putting it in Building rather than pretending it's already Shipped.
I'm documenting the product as I build it.