Overview
You ran the Tool Sprawl Audit. You can see the mess now. The instinct at this point is to jump straight to building something, usually a content system, because that is where the pain is loudest.
Do not build yet. A module built without an object model just recreates tool sprawl inside a nicer tool. The same lead in three places. The same offer described four different ways. The same asset remade because nobody could find it.
This guide is the step between the audit and the first module. You are going to name the objects your business runs on, decide exactly one home for each, and define the minimum every record needs. It is the least glamorous work in the whole build and the highest leverage.
Core idea
An object is anything your business creates, tracks, or acts on repeatedly. A lead. A piece of content. An offer. The test is simple: if you would be annoyed to lose the history of it, it is an object.
Define each object once, in one place, and let everything else link to it. A link and a copy look similar on screen. They behave nothing alike. A copy drifts the moment it is made. A link stays true because there is only one record underneath it. Every duplicate record in your business is a future disagreement about which version is real, and you are the one who gets pulled in to settle it.
What this helps you do
- Kill the “which version is right” tax. One record per object means the answer is always the same: the record.
- Make connections possible. Systems can only link objects that exist as records. This guide makes “the connections are the product” real instead of aspirational.
- Give AI something safe to work with. An assistant reading one clean record produces useful drafts. An assistant reading three conflicting copies produces confident nonsense.
- Onboard anyone, including future you. When the objects are defined, a new hire or a new tool inherits the structure instead of your memory.
The eight objects
For most expertise-based businesses, eight objects cover the whole operation. Your names can differ. The structure should not.
- Idea. Raw input before it becomes anything: a note, voice memo, or recurring client question. Minimum fields: the idea, source, and current status. Connects to the content or offer it eventually becomes.
- Content. Anything you publish or deliver, in any format. Minimum fields: title, format, channel, status, and publish date. Connects to its source idea, campaign, offer, and reused assets. Content is not a file; it is a record that points to a file.
- Campaign. A container for coordinated effort toward one outcome over a defined window. Minimum fields: goal, date range, and status. Connects to its content, promoted offer, and generated leads.
- Offer. A thing someone can pay you for, defined once. Minimum fields: name, price, what is included, and who it is for. Connects to campaigns, sales content, and the clients who bought it.
- Lead. A person or business that might buy, from first touch to decision. Minimum fields: name, contact, source, stage, and next action. Connects to the producing campaign, considered offer, and eventual client record.
- Client. A lead that converted, carrying its full history forward. Minimum fields: contact, active offers, status, and key dates. Connects to its origin lead, purchases, work, and content.
- Task. A unit of work with an owner and due date. Minimum fields: what, who, when, and status. Connects to the object the work is for. A task attached to nothing is a sticky note; a task attached to a campaign or client is operational memory.
- Asset. A reusable building block such as a logo, template, testimonial, bio, or case-study statistic. Minimum fields: what it is, where the file lives, and usage notes. Connects to every content piece and offer that uses it.
The source of truth decision
Every object gets exactly one official home. Not one primary home and a backup. One.
The clean cases are easy. The ugly cases are where the OS is actually won. Your leads are in your CRM, email tool, and a spreadsheet from that event last spring. Pick one—the CRM, almost always. The others become either synced mirrors that never get edited directly, or they get retired.
Two rules make the decision stick. First, the home is where edits happen. If you catch yourself updating a record anywhere else, that is not a second workflow; it is a leak. Second, other tools may display an object, but they may not own it. Your email platform can show a lead. It does not get to define one.
Expect this to feel slower for about two weeks. You are trading the convenience of editing anything anywhere for the certainty of one true record. That trade is the whole business model of an OS.
The framework
Do this in one working week. Not because it is hard, but because dragging it out invites re-litigating decisions that were already right.
- List your objects. Start from the eight above. Rename them to match your language. Cut anything you do not actually track. Add nothing yet.
- Assign one home per object. For each object, write down where it officially lives today and where it should live. Where those differ, that is a migration, and it goes on the list.
- Define minimum fields. For each object, name the five or six fields it cannot exist without. Resist designing the perfect schema. Minimum means minimum.
- Map the connections. For each object, list which other objects it must link to. This map is the blueprint every module gets built against.
- Retire the duplicates. Every copy outside the official home gets synced, frozen, or deleted. This is the step people skip. It is also the step that makes everything above real.
When your eight objects each have one home, a minimum field set, and a connection map, you are ready to build your first module.
Use the Core Objects Worksheet to record each decision and build the retirement list for every duplicate you found in the audit.