A small business owner who starts using AI usually begins the same way. They open a chat assistant, explain what the business does, ask for help with a quote or a social media post, and get something useful. The next day they open a new conversation and explain the business again. A week later they paste a client's details into a conversation about a different client. A month later they have dozens of conversations, a few good outputs scattered across them, and no reliable way to get consistent results.
The tools are not the problem. Every major AI assistant now supports some form of projects, saved instructions, uploaded files or shared knowledge. What is missing is a structure: a deliberate way of telling the AI about the business once, keeping different pieces of work apart, and keeping the information current.
This final part of the series describes that structure. It is tool-neutral by design. The same arrangement works whether the business uses Claude, ChatGPT, Copilot, Gemini or whatever comes next, because it lives in plain files the owner controls.
Ridgeback Bookkeeping is fictional, a five-person bookkeeping practice in Polokwane, and its details are illustrative.
The idea: a business core plus separate projects
Think of the AI workspace as having two parts. The business core is a small set of files describing the business that every piece of work should know: what the business does, what it sells and at what price, how it writes, what it will and will not do, and the decisions it has made. The projects are separate spaces for separate pieces of work, such as one per client or one per recurring activity, each with its own notes, drafts and approved outputs.
Every project reads the business core. No project reads another project.
At Ridgeback, the business core has five files.
About the business. Two pages: who Ridgeback serves (small businesses in Limpopo that need monthly bookkeeping and annual submissions), what it does, what it does not do, and how a typical engagement works.
Offers and prices. The three service packages, what each includes and the current monthly fee. When prices change, this file changes, and every future quote uses the new prices.
Voice and style. How Ridgeback writes to clients: plain English, short paragraphs, never alarming, always ending with the next step. Examples of good emails are included, because examples teach tone better than descriptions.
Rules and boundaries. What the AI must never do: never give tax advice that has not been reviewed by the owner, never include a client's financial details in anything outside that client's project, never send anything directly to a client.
Decisions log. A dated list of business decisions, such as "From March we no longer take on payroll-only clients". This stops the AI from suggesting things the business has already decided against.
Why plain files, not just tool settings
Most assistants let users paste instructions into a settings box or a project description. That works, but it locks the business's knowledge inside one tool and makes it hard to review. Keeping the core as plain documents, in a folder the owner controls, has three advantages.
It survives a change of tool. If Ridgeback moves from one assistant to another, the files move with it. Nothing has to be rewritten from memory.
It can be reviewed. The owner can read the core files in ten minutes and see exactly what the AI has been told. A setting box spread across several tools cannot be reviewed so easily.
It forces clarity. Writing down offers, rules and decisions for the AI tends to reveal where the business itself has been unclear. The same file is a useful induction document for new staff.
This mirrors the approach software teams take with repository instruction files, which we discuss in Part 3, applied to a business rather than a codebase.
Keeping clients apart
The most important boundary in a small business's AI use is between clients. A bookkeeping practice holds financial information about every client, and POPIA expects that information to be used for the purpose it was collected and protected appropriately. We explain the general principles in What to ask before you let AI touch your data; this article is general information, not legal advice.
In practice, keeping clients apart means three things. Each client's work happens in that client's project, never in a general conversation. Client documents are uploaded only to that client's project, and only to an AI service the business has checked and is comfortable with for that kind of information. And outputs that leave the business, such as emails, reports and submissions, are reviewed by a person before they are sent.
The business core never contains client details. It describes the business, not its clients.
The operating rhythm
A workspace like this decays if nobody maintains it. Prices change, decisions are made, the voice drifts. The fix is a small, fixed rhythm rather than a large periodic clean-up.
Daily: work inside one project at a time, and start each piece of work from the relevant project, not a blank conversation.
Weekly: review the outputs that went out, note anything the AI got wrong, and add any new decision to the decisions log. If the same correction is needed twice, update the core file that should have prevented it.
Monthly: check the offers and prices file and the rules file against reality.
Quarterly: archive finished projects, remove stale files, and check which AI tools and integrations have access to what. Revoke anything no longer needed.
At Ridgeback this takes the owner perhaps an hour a week in total, most of it in the weekly review. The return is that the AI's output is consistent and current without constant re-explanation.
Starting this week
A small business can set this up in an afternoon.
- Write the five core files, even roughly. Two pages each is plenty.
- Create one project for the most frequent kind of work, and attach the core files to it.
- Write down the three most important rules, especially about client information and what must be reviewed before it leaves the business.
- Use the project for two weeks, and note every time the AI needed correcting.
- Turn those corrections into edits to the core files.
- Add further projects only when the first one is working.
For businesses thinking about the wider shift, our earlier article SMMEs don't need more tools; they need a digital operating model covers the operating-model side, and Small teams need better decision systems covers decision-making.
What the series adds up to
This series has described how a modern technology business can work: choosing recurring problems and narrow buyers for its products, keeping humans accountable for AI-assisted work, treating coding tools as components of a delivery system, turning research into reusable assets, and, here, giving a small business a simple structure for AI. The common thread is that AI rewards structure. The businesses that benefit most are not the ones with the most tools, but the ones that have written down what they do, what they will not do and who decides.
This is the final part. Start again at Part 1, Why boring software products can build a durable technology company, or see all parts on the series page.
How CloudNala can help
We help small businesses and SMMEs set up a practical AI workspace: the core business files, project structure, client-separation rules, review steps and an operating rhythm the owner can sustain. The result is consistent AI help that stays under the owner's control and can move between tools.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Talk to CloudNala or write to us at consult@cloudnala.co.za