Kota AI

Context

Kota started from a specific version of a common problem: I run a registered business and freelance alongside it, and needed one place to manage both, invoices, estimates, proposals, without paying for software built for accountants.

That’s the wider pattern too. For many South African service businesses, the drag isn’t the work. It’s everything around it. Quotes go out late. Invoices sit unsent. Follow-ups slip. Proposals get rewritten from scratch. Context lives across memory, WhatsApp threads, notes, and half-finished documents.

Most tools treat these as separate workflows. In practice they’re one problem: the same person doing the work is also the back office, and the admin arrives at the worst possible moment.

Kota is my attempt to design around that.

The Problem

Admin breaks momentum. Important tasks don’t fail because they’re hard. They fail because they arrive at the wrong time, with too much friction.

Operational context doesn’t compound. A proposal doesn’t know your pricing. A draft message doesn’t know your tone. A quote doesn’t know your VAT status. The business re-explains itself to every tool, every time.

AI usually adds a layer instead of removing one. A generic assistant answers questions. That isn’t the same as moving work forward. In this category, a paragraph is rarely enough. The output has to become a usable artifact.

There’s UX, and there’s AX. Kota isn’t just a human interface. It’s also a set of agents that have to receive context correctly, choose the right tool, and hand back something a person can trust without re-checking it line by line. Getting the agent experience wrong is invisible until it isn’t: a wrong tool call, a hallucinated total, a follow-up sent in the wrong tone. Designing Kota meant designing both sides of that relationship, not just the screens.

That produced the central design question:

What does an AI product look like when it’s designed around operational follow-through rather than conversational novelty?

My Role

Everything: problem framing, product definition, UX, interface design, brand, system architecture, and implementation. Solo, end to end.

Process

Validating the opportunity

Wave’s exit left a real gap. Wave was the default free invoicing tool for freelancers and small operators, until it exited Africa entirely in December 2020. What replaced it locally was either expensive international software (Xero, QuickBooks, and Sage all run R200 to R1,000+ a month) or thin local alternatives that don’t integrate with the payment rails South African businesses actually use.

Price sensitivity made a real free tier non-negotiable. FinScope’s 2024 MSME survey puts roughly R150 to R200 a month as the ceiling for what South African small businesses will pay for a comprehensive tool, and most are already running finances through personal bank accounts with no accounting background. That’s the same floor that made Wave the default before it left the continent, and it’s why free couldn’t be a crippled trial (see Key Decisions).

Compliance shaped the data model before a line of UI was drawn. SARS has specific requirements for what a tax invoice must contain, VAT has to be calculated and displayed a particular way, and POPIA sets real requirements for how financial data gets stored and consented to. Designing those in from the start is why “South African context designed in, not localised later” (see Key Decisions) was an actual technical decision, not a talking point.

This was desk research, not interviews: market sizing, a competitor teardown, and regulatory requirements, done in Claude alongside the PRD and user stories before any building started. It told me the gap was real and specific. It doesn’t replace hearing directly from a business owner, which is still the gap noted below.

Designing in code, not Figma

I didn’t design this in Figma first. Planning happened in Claude, PRD and user stories, before the build itself shifted to AI-assisted coding workflows (Codex, Cursor, Claude Code), with brand and visual assets made in Affinity. The design process happened inside the build.

The loop was consistent: build, test, reduce, iterate. I went deliberately wide early, exploring a much larger feature surface than the final product needed, then cut. If a flow introduced friction, it got simplified. If a feature was impressive but didn’t improve the task, it got removed.

The real discipline wasn’t generation. It was reduction.

Surface	Original plan	Now
Home	Daily briefing, one priority item	Same idea, now pulls real cash-flow numbers from the facts engine
Ask Kota	Added mid-plan as its own pure-chat room	Still exists, folded into Home rather than kept as its own sidebar item
Finance	Invoices, quotes, estimates, proposals	Unchanged. The one surface that’s stayed the proven core the whole way through
Products & Services	Manual entry, named “Services” early on	Live, and now builds itself automatically from invoice line items instead of requiring manual entry first
Documents	Uploads and compliance files	Unchanged
Workspace (notes, spreadsheets, tasks)	Planned as one combined surface	Cut. Task data is still used by the daily nudge and a digest, so the cut isn’t fully clean
Settings	Nine tabs covering business, billing, compliance, and more	Same shape

Tasks are the interesting exception inside that Workspace cut. They didn’t go with the rest of it: the AI creates a task whenever an action needs to happen, and other features, a daily nudge and a digest among them, depend on that data existing. Cutting the combined workspace UI was the easy part. What actually earns its place in a product doesn’t always announce itself in advance.

Core product surfaces

Interface surfaces

The places users return to: chat, customers, finance, services, tasks, practical guidance, and the business context Kota uses to do useful work.

Deciding what the system returns

This is where the interaction design actually happened, before a single screen existed. The strongest decision wasn’t technical: the product had to return finished operational outcomes, not assistance. Ask for an invoice and you get a draft to review and send, not a paragraph about invoicing. Context compounds quietly in the background, business name, tone, pricing, compliance posture, so none of it gets re-explained. Anything sensitive or mutating still surfaces for review before it goes anywhere. And wherever a deterministic answer is available, it wins over an agentic one: reliability over theatrics.

A small router sits under the interface, sending each request to the right kind of agent rather than one general assistant trying to do everything. None of them generate interface code directly. Each returns a typed, structured response, and the frontend renders the matching component. That’s what keeps the product feeling designed, rather than defaulting to a chat window.

Earning trust with computed facts

Kota gives financial advice, so people have to trust the numbers behind it. Language models are inconsistent response to response, which isn’t good enough for a figure tied to someone’s tax position. So the model never states a number it didn’t compute. A separate facts engine calculates things like what’s overdue, who actually pays slowest, and how close the business is to the VAT threshold, directly from real invoices and payments, in code. The model only narrates those facts. It never generates them. That distinction is what makes the advice something a business owner can act on, not just read.

The invoice journey

The goal was to collapse friction without hiding process. The user stays in control; the blank page disappears.

AI estimate flow

Create an estimate with AI

This is the core interaction pattern: plain language becomes a finance document, but every money-moving step still lands in a reviewable product surface.

Key Decisions

Structured responses over free-form generation. Typed contracts meant the UI stayed predictable and debuggable, at the cost of flexibility. For an operations tool handling money, that trade was obvious.

Four agents, not twelve. Every additional agent adds routing ambiguity and failure modes. I kept the roster to reasoning patterns that were actually distinct.

South African context designed in, not localised later. ZAR, VAT, EFT workflows, and local compliance language shaped the data model from the start rather than being retrofitted.

Free forever, not a crippled trial. New users get the full paid tier automatically for 14 days, then drop to a genuinely usable free plan, unlimited invoicing, quotes, and clients, rather than a hard paywall. The only thing that’s actually rationed is AI conversation, and even that’s a rolling seven-day window rather than a fixed weekly reset, so the limit always feels equally close instead of something people learn to game. Given Wave was free and South African businesses are this price-sensitive, a real free tier was the floor the product had to clear, not a growth hack bolted on top.

Outcome

Kota is two weeks into a month-long beta with seven to ten SME owners, using it in their actual businesses right now. Early signal is specific rather than just positive: people respond well to the finance composer (invoices, estimates, quotes, and proposals in one surface) and to how much ground it covers without feeling complicated. Nothing has forced a major pivot yet, only small adjustments, but it’s early enough that I’d call that a promising start rather than a conclusion.

Reflection

What worked. Deciding the output format before the interaction model. Once “return a usable artifact” was fixed, most UX questions answered themselves.

What I’d do differently. Test sooner. I got too deep into working out how the agents would interact with each other before validating the interaction with anyone real. It held up, but that was partly luck. I’d now put a rough version in front of business owners earlier, before committing to the architecture.

What I’m still unsure about. Whether the chat-led entry point is right. It’s the fastest way in for someone who knows what they want, and the worst way in for someone who doesn’t. That’s an open question I’d want real usage data to settle.