Build Your Own Back Office
Your website is for your customers. Almost everything else — what to charge, what the competition is doing, why you turned that client down in March, which lead to chase first — happens somewhere else: your head, a notes app, and eleven browser tabs. You can build that somewhere else, as a private app nobody but you can see, in an afternoon. Start with the prompt further down this page; it builds the shell, and you add one module at a time.
This is the second app, and it is not part of your website. The site is the shopfront; this is the back room. Keeping them separate is deliberate, not lazy: your competitor notes and your pricing logic have no business sitting in the same database as a public page, and the two are used by completely different people — customers use one, only you use the other.
You do not need a business yet to build one. If you are still deciding whether to start, the back office is the cheaper first move: nothing is public, nobody sees it, and the questions it holds — who am I for, what do I charge, who else is doing this — are the ones you are already trying to answer.
Key takeaways
- The dividing line is simple: if anyone other than you needs to open a live page for the tool to work, it belongs in your website's app. If only you ever use it, build it separately.
- A back office has three layers: foundations you define once, trackers that record what happened, and generators that use both to produce something. The generators are only worth having because of what the first two store.
- Build the shell first, then add one module at a time — all into the same app, not five separate ones.
- The modules that survive are the ones that record something that already happened. The ones that ask you to maintain a forecast or a framework get abandoned within weeks. This is the most reliable pattern in the evidence, and it should decide what you build.
- Do not rebuild polished software you already pay for. Build the thing that does not exist.
The test: does anyone but you need to touch it?
This one question sorts every tool you might want.
If a customer, a donor, a subscriber or a lead has to open a live page for the thing to function — a booking form, a quote request, a newsletter signup, a gift-card purchase — it belongs in the same app as your website. That is the only public surface you have, and it is where the data comes in. Those tools live in the kits that extend your site.
If you are the only person who ever opens it — competitor notes, your pricing logic, a log of decisions, a scoring system for leads you enter yourself — there is no reason to attach it to your public site, and two good reasons not to. It is private material sitting one misconfiguration away from an indexed page, and it clutters the database of a site that should stay simple.
Note what the test does not ask: whose information it is. A list of your clients is about your clients, but if you are the one typing them in and nobody else ever logs in, it is back-office. The question is about who operates it, not who it describes.
What a back office is made of
Three layers, and the order matters, because the third only works because of the first two.
Foundations are what you define once and rarely change: what your business is, who it is for, what you sell and what is included, what you charge and why, the positions you hold and the ones you will not concede. These are not a to-do list you maintain. They are reference material that everything else reads from.
Trackers record what already happened: competitors and their prices, a decision and the reasoning behind it, a client conversation, a lead and where it got to, a renewal date. They accumulate. You never have to "keep them up to date" in the abstract — you add a row when a thing happens.
Generators use the first two to produce something: a draft written in your voice because your brand definition is sitting right there, a weekly summary that knows what you decided last month, a comparison against what you recorded about a competitor last quarter.
The generators are the reason to build any of this, and they are also where it goes wrong. A generator that only sees what you just typed into it is a chat window with extra steps — you could get the same thing by opening an AI assistant and typing. What makes it worth building is the store behind it. Before you add any generator, ask what is in the database that you could not have told an assistant in thirty seconds. If the honest answer is nothing, do not build it.
Build the shell first
This prompt builds the empty command centre: the app itself, one foundation record describing the business, and a running log. It deliberately does not build a dashboard full of charts you have no data for yet. Add the modules afterwards, one at a time, into this same app.
Paste it into Base44 as a new project — not into the project that holds your website.
Build me a private internal business management app. This is not a public website — it is a personal back-office tool that only I will use. Nobody else signs in, and nothing here is shown to customers. ABOUT I run a small business on my own. I need one private place to keep the decisions, facts and notes that currently live in my head and in scattered documents. Start minimal: I will add more sections later, and I want the structure to make that easy rather than having lots of empty features now. DESIGN Calm, dense and functional — a working tool, not a marketing page. Neutral colours, clear typography, comfortable on a laptop and usable on a phone. No hero images, no illustrations, no decorative graphics. Prioritise reading and typing over looking impressive. DATA Create two entities. 1. "Business Profile" — a single record I edit in place, holding: business name; what I do, in one paragraph; who it is for; what makes me different; the three things I want to be true about the business a year from now. Every field is long-form text, and every field is optional so I can fill it in gradually. 2. "Log Entry" — a running record of things that happened and decisions I made. Fields: date (defaults to today); a short title; type (choose one of: decision, note, conversation, idea, problem); the entry itself as long-form text; and "why", a separate long-form field for the reasoning behind it. Sort newest first. PAGES - Home: the Business Profile shown as readable text with an edit button, and underneath it the ten most recent Log Entries with date, type and title. If the Business Profile is empty, show a short prompt to fill it in instead. - Log: the full list of Log Entries, newest first, with a filter by type and a search box that searches title, entry and why. An "Add entry" button at the top that opens a form. - Profile: the Business Profile edit form on its own page. FUNCTION - Adding a log entry takes one click from anywhere in the app. - The "why" field is never required, but it is always visible in the form — I want to be reminded to fill it in. - Entries can be edited and archived, never hard-deleted. - Give me a way to export everything as a file, so my notes are never trapped. Build this as a working app I can start using immediately. Do not add analytics, charts, dashboards, notifications or integrations — I will ask for those later if I need them.
Two things to set before you rely on it. Make the app Private in its settings, so it requires sign-in and only you are invited — at the time of writing Base44 offers Private, Workspace and Public visibility, and private apps are on paid plans only, which is worth knowing before you put anything sensitive in. And run the export once, early, so you know your material can leave.
What to add next
Add one module at a time, and add it into the same app. The point of a back office is that the parts feed each other; five separate apps give you five places to forget about.
The three worth doing first, in this order:
A competitor tracker. Who else does what you do, what they charge, what they promise, and what changed since you last looked. It works as well for someone deciding whether to start as for someone already running — market research and ongoing monitoring are the same records, six months apart. It is also the module that most benefits from automation later: a scheduled check that tells you what moved, rather than you remembering to look.
Your brand and voice, written down. What you sound like, the words you use and the ones you refuse, who you are talking to, what you will not claim. On its own it is a document. Its real job is to be the thing every piece of generated writing reads from, which is the difference between output that sounds like you and output that sounds like everybody.
A decision log. The starter above already gives you this — use it properly. Not a diary: the decision, the reasoning, and what you expected to happen. Six months later it is the only record of why the business is shaped the way it is, and it is the single hardest thing for any assistant to help you with, because nobody else has it.
After those, the ones that earn their place for most solo businesses: a client or lead tracker sized for the few dozen you actually have rather than the thousands a CRM is built for; a services catalogue that defines what you sell and what is included, so quotes and proposals stop being rewritten from scratch; a correction log that captures the edits you make to AI output and why, feeding them back into your voice definition; and a renewals tracker for the subscriptions that quietly bill you.
What not to build
This is the part most guides skip, and it is where the time goes.
Do not rebuild polished software you already pay for. Invoicing, accounting, full CRM at scale, calendar scheduling — these are mature products, and a self-built version gets to roughly eighty per cent, never gets the last twenty, and is quietly abandoned a few weeks later while you go back to the tool you were trying to replace. Build what does not exist for you, not a worse copy of what does.
Do not build anything that needs you to maintain a framework. Quarterly goal boards, elaborate multi-platform content calendars, budget categories finer than your actual bookkeeping, an affiliate programme nobody has asked for. The pattern is consistent: modules that record something that already happened survive for years, and modules that require you to keep a forecast current are abandoned within weeks. The clue is the verb. If using it means "update", be suspicious. If it means "add", it will probably last.
Do not build a module whose only new feature is an AI button. A task list with a "summarise my week" button is a task list. The question is always what the store contributes.
Do not build for the business you hope to have. A client onboarding pipeline when you have two clients is theatre. Build the module when the volume makes it annoying, not before.
What's here now
The starter prompt above is complete and works today — a real, private, usable app, with the two things everything else builds on.
The step-by-step build guides for the individual modules are being written, competitor tracking first. Until they are published, the honest position is that you can build several of them yourself from the starter: the pattern is the same each time — one entity, a list page, a form, and a place for the reasoning. This page will list them as they ship.
What this doesn't solve
A back office is not a business. It will not find you customers, and time spent arranging your own tools is time not spent on the work — the failure mode here is building the system instead of running the business, and it is common enough to name.
It also assumes you are the only user. The moment someone else needs access — a partner, a bookkeeper, an assistant — you are into permissions, roles and shared conventions, and the honest answer at that point may be an off-the-shelf product rather than something you maintain yourself.
And the material inside it is only as good as what you put in. The tracker with three entries from the week you built it is worse than useless, because you will trust it. Nothing here removes the habit; it only makes the habit somewhere to go.
Your website is the part everyone sees. This is the part that decides what it says. Copy the starter prompt above into a new project and fill in the first field — then come back for the modules as they ship. Building for customers instead? Start with your profession's playbook. You can build this.