What a local customer database looks like in practice

The cloud CRM trap

Salesforce and HubSpot are built for sales teams with pipeline stages, lead scoring, and tracking pixels. If you are a freelancer, a contractor, or a one-person shop, you are paying for an entire sales floor you will never staff. The mandatory cloud login means your client list sits on someone else's server, behind someone else's pricing page.

Spreadsheets are the usual fallback, but they break down fast. A typo in a client name creates a second phantom client. Notes get crammed into cells that wrap across three rows. There is no way to pull up a contact card or see every interaction with a client in one place. The data is flat, which is why it stops working after about 50 clients.

Airtable improves on spreadsheets, but the free tier caps you at 1,000 records and charges per seat after that. A clean, local relational database handles all of this without the overhead.

The shape of a client database

A useful customer database needs two tables that link together. The first table holds the client record itself: name, company, a status field (Lead, Active, Past, or VIP), email, phone, website, address, and a notes field for context that does not fit anywhere else.

The second table logs interactions. Each interaction record points back to a specific client and carries a date, a type (Call, Email, Meeting, or Note), a written summary, a next follow-up date, and a flag for whether the follow-up is done.

The reason for splitting these into two tables is practical. The client record stays clean and scannable. It does not bloat with paragraphs of call notes. The interaction log grows independently, and because each entry has a follow-up date, you can filter for overdue items without scrolling through everything. A flat spreadsheet conflates the contact and the history into one row, which is why it stops working after about 50 clients.

In Dosirak, these tables are defined in plain TOML files inside a project folder. You can read them in any text editor, and the data itself is stored in SQLite on your disk.

What an agent does with this schema

A clean, typed schema is readable by an AI agent the same way it is readable by a human. When the database defines a clients table and an interactions table with specific field types, the agent does not need a tutorial. It connects through the MCP protocol, reads the schema, and knows what queries and records are valid.

That means you can ask: "Show me all clients who haven't had a follow-up in 30 days." The agent runs the query against the local database and returns structured results. You can also paste raw meeting notes into the agent. It parses out the client name, the date, a summary, and a follow-up date, then proposes a new interaction record with those fields filled in.

How much of that the agent can do on its own is up to you. It arrives read-only, so at first it can read the schema and nothing more. Grant it the interactions table and it can log meetings for you. Leave the clients table read-only and it can still look up a phone number without ever rewriting one. Put an approval gate on a table and its writes wait as todo cards, showing the parsed fields for you to approve or correct before anything lands. More on this in the MCP database feature page.

Spreadsheets, cloud CRMs, and a local database

Where this approach falls short

• Sales teams of 50 who need shared pipeline dashboards and lead routing. That is a real CRM problem. Use HubSpot or Salesforce.
• Email automation sequences. Drip campaigns, scheduled follow-up triggers, and open-rate tracking require a dedicated email platform. Dosirak does not send email.
• Per-user audit trails and permissions. Dosirak is a single-operator tool. It does not track which team member changed which record or restrict access by role.

Questions