Why I Design the Data Model Before Building Any Automation

Why do I design the data model before building any automation?

Because automations break at the data, not at the tool. If records, fields, owners, and states are unclear, any workflow in Zapier, Make, or n8n will copy that confusion faster. So I spend the first part of every automation project deciding what the data looks like, who owns each field, and what each status means.

Clients usually arrive with a tool question. Should this run in Zapier or Make? Can HubSpot do it natively? Should we try an AI agent? Those are fair questions, and I answer them eventually. But the honest first answer is almost always "it depends on your data," and most teams have not written their data down.

This is the method I use, why I use it, and what it costs a client up front. It is the part of my work that looks least impressive in a demo and matters most six months later.

What do I mean by the data model?

The data model is the written answer to four questions: what records exist, what fields each one has, who or what is allowed to change each field, and what states a record moves through. It is usually one short document and a diagram. It is the plan the automation follows, not the automation itself.

For a typical B2B lead flow, the records might be contacts, companies, and deals. The fields include obvious ones like email and company size, and less obvious ones like lead source, lifecycle stage, and the reason a deal was lost. The ownership question asks, for each field, whether a form, an enrichment tool, a rep, or an automation is the source of truth.

The states are where most of the thinking happens. A lead is new, then maybe qualified, then maybe handed to sales, then maybe converted or recycled. Each transition needs a rule: what triggers it, who can trigger it, and what happens next. Once those rules exist on paper, building the automation is mostly translation.

Where did this habit come from?

It comes partly from my aeronautical engineering background. In that world, you define the system, its inputs, and its failure modes before you build any part of it, because fixing a design flaw after the fact is expensive. Business automations are far less risky, but the principle carries over well.

Engineering training teaches you to ask what each part is responsible for, and what happens when it receives something unexpected. Those are exactly the questions that matter when a form submission arrives with an empty company field, or when two automations both try to update the same lifecycle stage.

The rest of the habit comes from doing the work. Across 100+ projects for 25+ clients over 6+ years, the projects that stayed reliable were the ones where the data was settled first. The ones that needed rework usually had a tool picked before anyone agreed what the records meant. I do not have a tidy percentage for that, and I would not trust one if I did. It is a pattern, not a statistic.

What does this look like on a real system?

My automations for Ajust run in production on Airtable and WhaleSync, supporting work that has delivered 25,000+ cases, helped 400,000+ people, and saved 50,000+ hours. At that scale, a vague field definition is not a small annoyance. It repeats across every record the system touches.

When a system handles that many records, every ambiguity becomes a pattern. If a status field means slightly different things to two people, that difference shows up thousands of times. If a sync tool and a human both edit the same field, one of them will eventually overwrite the other. The data model is how you prevent those collisions before the first record moves.

The same principle applies at smaller scale. The automation I built for Kismet Health connects HubSpot through Zapier. Fewer records, simpler flow, same first step: agree on what the fields mean and who owns them, then build. I wrote about the ownership side of this in Airtable or HubSpot as the source of truth.

What questions do I ask before building anything?

I ask which system is the source of truth for each record, which fields an automation may write, what happens when a value is missing, and who gets told when something fails. These four questions catch most of the problems that would otherwise appear weeks after launch, when nobody remembers why a rule exists.

The write-permission question is the one clients find most surprising. Not every field should be writable by automation. A rep's manual note about a deal, or a corrected job title, should usually be protected from an enrichment tool that thinks it knows better. I covered which fields deserve that protection in which CRM fields an automation should never write.

The missing-value question is the most underrated. Real data is incomplete. Forms get skipped, enrichment returns nothing, imports arrive half filled. An automation needs a defined behavior for each empty field that matters, whether that is waiting, using a default, or sending the record to a person. My piece on what an automation should do when a field is empty walks through those choices.

Does this slow projects down?

It slows the start and speeds up everything after. The data model usually takes a few working sessions, and clients sometimes want to see a running workflow sooner. But the build goes faster with a clear plan, and the maintenance load is far lower, because fewer surprises reach production.

I price projects as a fixed fee, and most fall between $1,000 and $10,000. A fixed fee makes this tradeoff easy to explain. The data model work is included, not billed as extra hours, so the client is not paying more for the slower start. They are paying for a system that does not need to be rebuilt in three months.

There is a version of this work that skips the model and ships something in a day. Sometimes that is the right call, for a throwaway test or a one-off import. I say so when it is. For anything that will run every day and touch revenue data, I would rather spend the time up front.

What is the honest downside of working this way?

The downside is that the early deliverable is a document, not a working demo, and some clients find that hard to value. It also means I sometimes recommend a smaller automation than the client asked for, because the data cannot support the bigger one yet. That can feel like I am slowing their ambition.

I would rather have that conversation early than explain a broken system later. When a client asks for lead scoring and the data shows that half the records have no company size, the honest answer is to fix data capture first. Scoring built on missing data produces confident numbers that mean little.

Not every client agrees, and that is fine. Some want speed above all, and they may be better served by someone who works that way. Saying so plainly is part of how I keep projects healthy.

How can you apply this without hiring anyone?

Before your next automation, write one page: the records involved, the fields that matter, the system that owns each field, and the states a record can be in. Then list what should happen when a key field is empty. If you cannot fill in that page, the automation is not ready to build.

A spreadsheet is enough for this. One row per field, with columns for the record, the owner, whether automation may write it, and the rule for empty values. It takes an afternoon for most small teams, and it often reveals that two tools have been fighting over the same field for months.

Share the page with whoever uses the data, especially sales. They will spot wrong assumptions faster than any test, because they live with the consequences every day. I wrote more about this principle at scale in what Ajust taught me about automations that serve real people. The data model is one section of a short document I write before building, which I describe in how to write a one-page spec before building an automation.

What should you do next?

Pick the automation that causes your team the most cleanup work today. Write its data model on one page: records, fields, owners, states, and empty-value rules. Fix any field that two systems both write. Then decide whether the automation needs rebuilding or just clearer rules underneath it.

I build websites and the automations behind them for lead generation, and the data model is where every one of those projects starts. If you want a second pair of eyes on yours before you build or rebuild, reach out at pravinkumar.co. Let's chat.