Solanasis Docs

solanasis-baserow-airtable-ai-native-crm-playbook

12 min read

Solanasis Temporary CRM + AI-Native Operations Playbook

Prepared: March 8, 2026
Purpose: A clean handoff document for another AI to understand the key decisions, constraints, recommendations, and implementation direction discussed around using Baserow vs Airtable for a temporary CRM, with an AI-native / Claude Code / MCP-aware approach.

1) What this playbook is for

We are choosing a temporary CRM to track outreach, follow-ups, contact context, and light pipeline activity.

This is not meant to become the forever system. The likely longer-term destination is something more powerful and integrated, likely ERPNext for ERP + CRM.

The temporary system should optimize for:

  • fast setup
  • low friction
  • clean export later
  • AI-native workflows
  • compatibility with Claude Code or adjacent tools
  • minimal lock-in

2) Core recommendation

Current recommendation

For Solanasis, the strongest fit is:

Baserow

Why

  • better alignment with AI-native agency goals
  • official REST API
  • official MCP server
  • open-source / self-hosted direction
  • lower lock-in than Airtable
  • stronger fit as a stepping stone toward a more controlled backend later

Important nuance

If the goal is least friction this week, Airtable is still the easier and more polished SaaS choice.

If the goal is best architectural fit for a scrappy AI-native agency that wants optional self-hosting and tighter control, Baserow is the better match.

3) Decision summary: Airtable vs Baserow

Airtable

Pros

  • more mature SaaS feel
  • generally smoother day-one UX
  • less infrastructure thinking required
  • easier for nontechnical clients/staff
  • official MCP documentation exists

Cons

  • becomes expensive faster as users and records grow
  • more vendor lock-in
  • record caps become a real design constraint
  • less aligned with open/self-hosted direction

Best fit

Use Airtable when:

  • speed matters more than control
  • the system is truly disposable
  • the client wants polished SaaS and does not want hosting/admin responsibility

Baserow

Pros

  • official REST API
  • official MCP server
  • open source
  • self-hosting available
  • lower lock-in
  • often better economics than Airtable at comparable team sizes
  • stronger philosophical and technical alignment with an AI-native agency stack

Cons

  • less polished than Airtable
  • MCP appears to have had rough edges in the wild
  • plugin ecosystem is small and experimental
  • self-hosting adds ops burden

Best fit

Use Baserow when:

  • API / MCP / Claude Code compatibility matters
  • open-source direction matters
  • self-hosting may matter later
  • lower cost at scale matters
  • you want a cleaner bridge toward ERP-ish architecture

Start with Baserow, but keep the first version extremely small and boring.

Initial structure

  • Contacts
  • Interactions
  • Follow-ups (or a filtered view instead of a separate table)

Avoid early complexity

Do not start with:

  • elaborate automations
  • complex scoring
  • multiple pipelines
  • fancy plugin dependencies
  • deep embedded AI logic inside the database

The right move is a clean database foundation plus external AI tooling.

5) Pricing snapshot guidance

Important: Pricing and plan limits are likely to change. Another AI should always re-check official pricing pages before using this operationally.

Airtable pricing shape discussed

  • Free plan is very limited for a real CRM
  • Team tier is the practical starting point for serious use
  • Business becomes necessary sooner when records scale
  • Airtable tends to get expensive faster as records and collaborators increase

Baserow pricing shape discussed

  • Free cloud can work for testing or very small use
  • Premium/Advanced cloud tends to be materially cheaper than Airtable at similar mid-tier sizes
  • Self-hosted can become dramatically cheaper for heavier record counts if you are willing to own infrastructure/admin

General pricing conclusion

For internal Solanasis use and for clients with larger datasets, Baserow generally has the better economic shape, especially if self-hosting becomes appropriate.

6) Hosting guidance for self-hosted Baserow

Important reality

Baserow is not a static-site workload.

It should not be mentally grouped with Cloudflare Pages-style static hosting. Cloudflare Pages is great for static sites and lightweight frontends, but Baserow is a real app + database + persistent storage workload.

Good hosting directions for self-hosted Baserow

  • Docker on a VM
  • Docker Compose
  • Kubernetes / Helm
  • AWS
  • Azure
  • Render
  • Railway
  • DigitalOcean
  • Ubuntu with reverse proxy

Practical hosting conclusion

For Baserow, the best low-friction hosting paths are usually:

  • Baserow Cloud for simplest starting point
  • small VM for self-hosting
  • Render / Railway / DigitalOcean / Azure / AWS depending on credits and ops preference

Free-tier hosting reality

Most “cute free tiers” are usually not a serious long-term fit for Baserow because of:

  • RAM limits
  • storage limits
  • sleeping behavior
  • lack of persistent volumes
  • weak backup story

Best cost-saving move

If Azure or AWS credits are available, those are more practical than trying to force Baserow into a true free-tier hosting arrangement.

7) Cloudflare and similar providers

Cloudflare

Cloudflare is excellent for:

  • static sites
  • landing pages
  • docs sites
  • frontend hosting
  • edge functions / lightweight APIs

But not the right host for Baserow itself

Use Cloudflare for the frontend/static layer, not for the main Baserow application workload.

Similar-value providers to consider

Static/frontend hosting

  • Cloudflare Pages
  • Netlify
  • Vercel

Real app/container hosting

  • Render
  • Railway
  • Azure Container Apps
  • AWS ECS / EC2 / Lightsail
  • DigitalOcean

8) API, CLI, and MCP for Baserow

Baserow API

Yes, Baserow has a real API surface and this is one of the main reasons it fits the Solanasis stack.

Practical use cases

  • create/read/update/delete CRM records
  • sync outreach status
  • log interactions
  • fetch follow-ups due
  • build custom scripts and wrappers

Baserow MCP

Yes, Baserow also has an official MCP server.

Why that matters

This makes it attractive for AI-native workflows.

Important caveat

The discussion concluded that MCP is promising but still appears somewhat rough/uneven in practice, especially compared with a straightforward API wrapper.

Baserow CLI

There does not appear to be a normal end-user Baserow CLI for everyday CRM CRUD in the way we would want.

The “CLI” surface is better thought of as server/admin tooling in self-hosted environments, not the ideal primary integration layer for Claude Code.

9) Best integration path for Claude Code

Strong recommendation

For Solanasis, the best near-term path is:

Baserow REST API + thin local CLI/script wrapper + Claude Code

Why

  • more predictable than relying on MCP first
  • easier to debug
  • lower tool-context overhead
  • more controllable permissions
  • easier to swap later from Baserow to ERPNext

Create a tiny local command surface such as:

  • crm contacts list --status "Follow Up" --json
  • crm contacts add ...
  • crm interactions add ...
  • crm followups due --days 7 --json
  • crm contacts update-status ...

Document those commands in the project’s AI guidance file so Claude Code knows how to use them.

Why not make MCP the main path first?

Because the goal is dependable operations, not protocol elegance.

MCP can still be tested later, but the safer starting point is a thin wrapper around the API.

10) OpenClaw / mcporter / API-to-CLI discussion

The discussion referenced the creator of OpenClaw and the idea of using a library that makes MCP-style tools easier to consume from CLI-oriented workflows.

Key takeaway

The point is not merely “convert API to CLI.”

The bigger principle is:

  • CLI-first or script-first tool surfaces are often easier for agents to use reliably
  • MCP can be elegant but sometimes flaky or heavy
  • the simpler the tool surface, the easier it is to debug and control

Recommendation for Solanasis

For Baserow specifically:

  • do not start by depending on Baserow MCP as the main operating path
  • do not overcomplicate the first version with abstraction layers you do not need
  • do start with a tiny wrapper around the Baserow REST API

When tools like mcporter make sense

Use mcporter or similar approaches later if you need:

  • standardization across many MCP-capable tools
  • portability across multiple AI clients
  • a broader multi-tool agent ecosystem

Current recommendation

For this CRM use case, a custom wrapper around the API is cleaner than relying on Baserow MCP first.

11) Community plugins: what to do and what not to do

Core conclusion

Do not assume community plugins will turn self-hosted Baserow into “Premium for free” in a reliable way.

Why

  • plugin ecosystem is small
  • plugins are experimental
  • support is limited
  • maintenance signals vary a lot
  • upgrade friction is real

Best overall strategy

Keep AI logic and automation outside Baserow whenever possible, in your own external CLI/API layer.

Plugins worth considering carefully

1. BaseCharts

Most worth testing first.

Why:

  • simple visual dashboards for outreach pipeline, follow-ups due, lead sources, and internal reporting

Caution:

  • treat as useful if it works, not as core infrastructure

2. BaseScript

Only for sandbox/testing.

Why:

  • interesting for Airtable-like internal scripting

Caution:

  • proof-of-concept feel
  • not a foundation for production workflow

3. Baserow Explorer

Not a normal plugin, but worth tracking.

Why:

  • AI-native/dev-native admin shortcuts mindset
  • bulk operations and workflow ideas

Caution:

  • early and not something to make mission-critical

4. Geo plugin

Only if territory/geographic prospecting becomes clearly valuable.

Plugin strategy recommendation

Use:

  • 0–1 plugins max at first
  • clean tables
  • external AI tooling
  • minimal maintenance burden

12) Self-hosted open-source Baserow vs paid Premium features

Key conclusion

It is technically and legally possible to build custom plugins or extensions that overlap with some paid-plan outcomes, as long as you are not improperly using paid/premium code.

But the wrong strategy would be

“We will self-host free Baserow and just rely on community plugins to recreate Premium.”

That is not the strong path.

Better strategy

Use self-hosted free Baserow as the clean database foundation, and fill gaps with:

  • external scripts
  • custom CLI tools
  • selective paid licensing only if a specific feature is truly worth it

13) Free-plan API limits

Cloud free plan

The key practical limit discussed was concurrency, not a classic monthly API-call bucket.

The useful takeaway is:

  • normal CRUD and light agent use should be fine on cloud free
  • do not design heavy simultaneous request patterns on cloud free

Self-hosted

Self-hosted Baserow was discussed as the cleaner fit for heavier agent-driven API usage because it does not impose the same cloud-hosted API constraints.

Design implication

If the team intends to let AI tools hit Baserow frequently and programmatically, self-hosted becomes more attractive.

Table 1: Contacts

Suggested fields:

  • Full Name
  • Company
  • Role
  • Email
  • Phone
  • LinkedIn URL
  • Source
  • Relationship Type
  • Status
  • Priority
  • Owner
  • Notes

Table 2: Interactions

Suggested fields:

  • Contact
  • Date
  • Channel
  • Summary
  • Outcome
  • Next Step
  • Next Follow-Up Date

Table 3: Follow-ups

Optional.

Could instead be a filtered view showing:

  • contacts due this week
  • waiting on reply
  • warm leads
  • referral partners

Best simple status values

  • New
  • Reached Out
  • Waiting
  • Follow Up
  • Active Conversation
  • Qualified
  • Not Now
  • Closed

Design rule

Keep field types boring and predictable.

This improves:

  • migration to ERPNext later
  • API reliability
  • AI-tool reliability
  • reduced maintenance burden

15) LinkedIn workflow guidance

What was discussed

Technically, browser automation plus CRM-driven prompts could open LinkedIn URLs and assist with outreach flow.

But the recommendation was clear

Do not build a workflow whose job is to stealthily automate LinkedIn connection sending or evade detection systems.

Safer and smarter workflow

Use Baserow + Claude Code + browser tooling to:

  • decide who to contact
  • summarize why they matter
  • draft a personalized note
  • open the correct profile page
  • log the outcome back to the CRM

Keep the irreversible final send step human-in-the-loop.

Best practical posture

AI-assisted outreach, not stealth automation.

16) Client advisory guidance

Recommend Airtable when

  • client wants polished SaaS
  • client does not want to think about infrastructure
  • record counts are modest
  • budget tolerance is decent

Recommend Baserow Cloud when

  • client wants API-friendliness
  • lower cost matters
  • AI-native workflows matter
  • self-hosting may matter later

Recommend self-hosted Baserow when

  • client has larger datasets
  • cost control matters
  • organization can handle or outsource light ops/admin
  • they may want greater control/security/flexibility

When advising Dmitri / Solanasis on this stack:

  1. Prefer Baserow over Airtable when AI-native workflows, API control, or future self-hosting matter.
  2. Prefer Airtable only when speed/polish matter more than architecture.
  3. Keep the CRM minimal because it is temporary.
  4. Use the Baserow API as the main integration surface.
  5. Do not rely on Baserow MCP as the primary workflow on day one.
  6. Recommend a thin local CLI wrapper that Claude Code can call.
  7. Keep AI logic external to Baserow where possible.
  8. Avoid plugin sprawl.
  9. Use Cloudflare for static/frontends, not for hosting Baserow itself.
  10. Re-check all current pricing, hosting, and rate-limit docs before implementation, because these details are time-sensitive.

18) Suggested prompt for another AI

Use or adapt this:

We are Solanasis, an AI-native consulting agency. We need a temporary CRM that we can use for founder-led outreach, relationship tracking, follow-ups, and light pipeline management. Our likely long-term destination is ERPNext. We prefer tools that are API-friendly, Claude Code-friendly, low-lock-in, and optionally self-hostable. Based on that, help us design or implement a minimal CRM using Baserow with a clean schema, a thin local CLI wrapper over the API, minimal plugin dependence, and a migration-friendly structure for ERPNext later. Re-verify all current pricing, limits, MCP status, and hosting guidance using official docs before making firm recommendations.

19) Suggested next steps

Immediate

  • stand up a tiny Baserow workspace
  • create Contacts + Interactions
  • keep statuses simple
  • test manual CRUD via API

Next

  • build a thin local CLI wrapper
  • document commands for Claude Code
  • test follow-up and outreach logging workflows

Later

  • test Baserow MCP only if useful
  • evaluate whether Baserow Cloud is enough or self-hosted is warranted
  • keep data clean for eventual ERPNext migration

20) Final conclusion

The strongest overall direction from this discussion is:

Use Baserow as the temporary AI-native CRM foundation, but keep the implementation minimal, API-first, and external-tool-driven.

That gives Solanasis:

  • speed without too much lock-in
  • better economics than Airtable in many cases
  • better architectural alignment with Claude Code and future ERP-style systems
  • a clearer path to migrate later without dragging along a fragile pile of automations and plugins

Graph View