Solanasis Docs

solanasis-baserow-vs-coda-playbook

10 min read

Solanasis Playbook: Temporary CRM Using Baserow vs Coda

Purpose

This guide packages the key parts of our discussion into a practical playbook that another AI can use to help design, maintain, automate, or migrate a lightweight CRM setup.

The main context is:

  • We are using Baserow Free today as a temporary CRM.
  • We are evaluating whether Coda would be a better fit.
  • We want to understand how well Claude Code can work with each platform.
  • We want Baserow to behave like a lightweight relational database, not just a spreadsheet.
  • We want to understand how Baserow forms actually work and where they fit.

1) Executive summary

Use Baserow as the temporary CRM backend.

Why

Baserow is a better fit when you want:

  • structured records,
  • table relationships,
  • filtered workflow views,
  • API-driven automation,
  • Claude Code CRUD operations,
  • eventual migration to a more formal CRM or self-hosted stack.

When Coda makes more sense

Use Coda if the system is primarily:

  • solo or lightly shared,
  • doc-centric,
  • note-heavy,
  • more like a founder operating workspace than a real backend.

Best hybrid pattern

  • Baserow = system of record for contacts, companies, interactions, pipeline, tasks
  • Coda = SOPs, notes, meeting prep, dashboards, richer narrative workspace

2) Claude Code compatibility: Baserow vs Coda

Core answer

Claude Code can work with both Baserow and Coda in broadly similar ways at the API level.

That means another AI or Claude Code can:

  • call either API over HTTP,
  • use token-based authentication,
  • read and write JSON payloads,
  • generate scripts in Python/TypeScript/Bash,
  • perform CRUD-like operations.

Important nuance

They are not identical in behavior.

Baserow feels more like a database

  • Table-oriented
  • Row-oriented
  • Schema-friendly
  • Cleaner mental model for CRM data
  • Better fit for agent-driven automation

Coda feels more like a doc/app platform

  • Docs with embedded tables
  • More workspace-like behavior
  • Better for human collaboration and narrative context
  • Less ideal as a clean backend system of record

Practical guidance for another AI

If asked to build or automate a temporary CRM for Solanasis:

  • prefer Baserow for structured records and automation,
  • prefer Coda only if the user wants a doc-first workspace experience.

3) Coda free-plan limitations that matter

Key point

Coda’s API is available on free plans, but the practical limitations are less favorable for a CRM backend than Baserow.

Main limitations to keep in mind

  • Shared docs on Free have meaningful size/object limits.
  • Automations and sync-related features are limited.
  • API writes can be less clean operationally because they may be asynchronous.
  • It is better suited to lightweight workspace use than heavy structured CRM operations.

Practical conclusion

Coda Free may look generous for a solo founder workspace, but it becomes cramped faster when used as a shared CRM.

4) Why Baserow Free currently feels generous for API use

Key point

Baserow Free is constrained more by:

  • row limits,
  • storage limits,
  • concurrency/fair use,

than by a small obvious per-month API cap.

Implication

If the user has been “getting away with tons of free API calls,” that is consistent with the current experience of Baserow Free.

Practical conclusion

For a scrappy founder-led temporary CRM, Baserow Free is a very workable starting point.

5) The trick to making Baserow act like a lightweight database

Core mindset shift

Do not treat Baserow as one big spreadsheet.

Treat it like this:

  • Tables = entities
  • Link fields = relationships
  • Lookup / rollup / formula fields = derived data
  • Views = workflows
  • Forms = intake screens
  • API = automation layer

Common mistake

The most common failure mode is trying to keep everything inside one giant contact table.

That makes Baserow behave like a spreadsheet.

The solution is to split the model into related tables.

6) Recommended minimum CRM schema in Baserow

This is the recommended lightweight schema for Solanasis.

Table A: People

One row per human contact.

Suggested fields:

  • Full Name (primary field)
  • Email
  • Phone
  • LinkedIn URL
  • Role / Title
  • Status
  • Owner
  • Primary Company (link to Companies)
  • Priority or Warmth Score
  • Last Contacted On
  • Next Touch Date
  • Source
  • Notes (brief)

Table B: Companies

One row per organization.

Suggested fields:

  • Company Name (primary field)
  • Website
  • Industry
  • Size Band
  • Location
  • Account Status
  • Contacts (reverse/linked relationship)
  • Opportunities (reverse/linked relationship)
  • Notes

Table C: Interactions

One row per touchpoint.

Suggested fields:

  • Interaction Title (primary field)
  • Person (link to People)
  • Company (link to Companies)
  • Date
  • Type
  • Summary
  • Outcome
  • Next Step
  • Follow-up Due

Table D: Opportunities / Deals

One row per active commercial opportunity.

Suggested fields:

  • Opportunity Name (primary field)
  • Company (link to Companies)
  • Primary Contact (link to People)
  • Service Line
  • Stage
  • Estimated Value
  • Probability
  • Expected Close
  • Blockers
  • Next Action

Table E: Tasks

One row per follow-up task or reminder.

Suggested fields:

  • Task (primary field)
  • Related Person (link to People)
  • Related Company (link to Companies)
  • Related Opportunity (link to Opportunities)
  • Due Date
  • Status
  • Priority

Why this works

This structure reduces duplication and makes the CRM behave like a real lightweight relational system.

7) Field-type strategy: how to avoid spreadsheet chaos

Use the correct field types on purpose

Use these aggressively:

  • Primary field
  • Link-to-table
  • Lookup
  • Formula
  • Autonumber
  • Single select
  • Multiple select
  • URL
  • Email
  • Phone

Examples

  • In People, Primary Company should be a link to Companies.
  • In Interactions, link to both People and Companies.
  • In Opportunities, link to Company and Primary Contact.
  • Use Lookup fields to display related info without copying it.

Practical rule

If a value belongs to another entity, do not copy/paste it into multiple tables. Link to it instead.

8) Primary field vs row ID vs autonumber

These are different and should not be confused.

Primary field

  • Human-readable label for the record
  • Appears when linked elsewhere
  • Should be clear and meaningful

Row ID

  • Internal stable system identifier
  • Useful for API/integration logic
  • Not the same as the visible record name

Autonumber

  • Human-friendly sequential ID
  • Useful for internal references
  • Optional, but nice to have

Best practice

For CRM use:

  • make the primary field human-readable,
  • rely on row ID for system/API stability,
  • add autonumber if you want readable internal numbering.

9) Constraints and data protection

Key mindset

A database protects itself. A spreadsheet usually does not.

Practical use

Use constraints and controlled field types wherever possible.

Most important early constraints

Apply uniqueness or strong standardization to:

  • Email
  • LinkedIn URL
  • Website
  • External IDs

Why

Duplicate contacts and duplicate organizations become a mess fast.

10) Views are workflows, not just filtered tables

Key idea

Do not create duplicate tables for every workflow.

Create views instead.

Examples of useful CRM views

People views

  • Hot Leads
  • Needs Follow-Up This Week
  • Introducers
  • Dormant Contacts
  • Decision Makers

Company views

  • Targets
  • Active Clients
  • Partners
  • Not Now

Opportunity views

  • Pipeline
  • Waiting on Them
  • Proposal Sent
  • Closed Won
  • Closed Lost

Task views

  • Today
  • This Week
  • Overdue
  • Waiting

Daily operating principle

Work from views, not from raw tables.

11) How Baserow forms actually work

Core answer

A Baserow form is a table-backed intake screen.

When submitted, it creates a new row in the target table.

Important limitation

Forms are primarily for creating records, not for editing existing ones.

Best way to think about forms

Forms are one input channel into the database. They are not the database itself.

12) What forms are good for in a personal CRM

Good use cases

  • Quick lead capture
  • Interaction logging
  • Referral intake
  • Intro request capture
  • Post-call debrief entry
  • Structured data entry from a contractor or assistant

Not good for

  • Ongoing record management
  • Visual deduping
  • Bulk cleanup
  • Editing existing records repeatedly
  • Full CRM workflow management

13) Recommended forms for Solanasis CRM

Form 1: Quick Lead Capture

Target table: People

Suggested visible fields:

  • Full Name
  • Email
  • LinkedIn URL
  • Primary Company
  • Source
  • Notes

Suggested hidden or prefilled values:

  • Status = New
  • Source metadata
  • campaign/channel data

Form 2: Interaction Log

Target table: Interactions

Suggested fields:

  • Person
  • Company
  • Date
  • Type
  • Summary
  • Outcome
  • Follow-up Due

Form 3: Referral / Intro Intake

Target table: People or Interactions

Suggested fields:

  • Referred Person
  • Referrer
  • Company
  • Why they may need help
  • Warm intro or cold referral
  • Notes

Form 4: Post-Call Debrief

Target table: Interactions or Opportunities

Suggested fields:

  • Person
  • Company
  • Call Summary
  • Outcome
  • Next Step
  • Follow-up Due
  • Stage (if opportunity exists)
  • Estimated Value (optional)

14) Best operating workflow for the user

Daily

  • Work from filtered views
  • Log each meaningful touch in Interactions
  • Update Next Touch Date
  • Create Tasks for time-bound follow-up
  • Keep short notes in master records
  • Keep chronology in Interactions

Weekly

  • Review follow-ups due
  • Review dormant but valuable contacts
  • Review pipeline by stage
  • Clean duplicates
  • Promote serious leads into Opportunities

Monthly

  • Standardize field values
  • Archive dead records
  • Check for duplicates or schema issues
  • Export a backup if operational importance is rising

15) Claude Code / API guidance for another AI

Claude Code can be used to:

  • import CSVs,
  • create/update contacts,
  • enrich records,
  • dedupe records,
  • log interactions,
  • generate follow-up lists,
  • sync data programmatically.

Important rule

Do not automate heavily until the schema is clean.

A sloppy model gets automated into a bigger mess.

Safe sequencing

  1. Stabilize schema
  2. Standardize fields
  3. Create views
  4. Add forms
  5. Then automate with API + Claude Code

16) What another AI should recommend by default

If asked what Solanasis should do right now, the default recommendation should be:

Recommendation

  1. Stay on Baserow Free for the temporary CRM.
  2. Use the 5-table CRM schema.
  3. Add constraints/standardization to key fields.
  4. Build filtered views for daily operations.
  5. Create only 2 forms to start:
    • Quick Lead Capture
    • Interaction Log
  6. Use Claude Code against the API only after the structure is stable.

17) Mistakes to avoid

Mistake 1: one mega-table

This destroys the relational advantage.

Mistake 2: copying company info onto every contact row

Use links and lookups instead.

Mistake 3: keeping all history in one giant notes field

Use a dedicated Interactions table.

Mistake 4: treating forms like edit screens

Forms should mainly be treated as record-creation intake screens.

Mistake 5: overbuilding too early

Do not build a full enterprise CRM architecture on day one.

Mistake 6: heavy automation before schema stability

Fix structure first, automate second.

18) Blunt strategic recommendation

For this temporary CRM, the right move is:

  • use Baserow as the lightweight backend,
  • keep the schema clean,
  • use views as workflow lenses,
  • use forms as intake screens,
  • let Claude Code operate on that clean structure,
  • and delay any migration until the actual usage patterns are proven.

That gives Solanasis a scrappy but sane system without turning the setup into spreadsheet chaos or premature enterprise software.

19) Suggested prompt for another AI

Use the following prompt as a starter:

You are helping maintain and improve a lightweight CRM for Solanasis.
 
Current system:
- Platform: Baserow Free
- Purpose: temporary personal CRM
- Goal: behave like a lightweight relational database, not a spreadsheet
 
Your priorities:
1. Preserve a clean relational schema
2. Avoid duplication across tables
3. Prefer views over duplicate tables
4. Use forms only as intake/create-record tools
5. Keep automation secondary to schema quality
6. Make recommendations that stay scrappy, practical, and migration-friendly
 
Core tables:
- People
- Companies
- Interactions
- Opportunities
- Tasks
 
Default recommendation:
- Keep Baserow as system of record for now
- Use Coda only for notes/docs if needed
- Add automation only after schema is stable
 
When proposing changes:
- prefer simplicity,
- prefer fields/links/views over hacks,
- avoid overengineering,
- explain tradeoffs clearly.

20) Optional next artifact to create

A future AI could next produce:

  • a precise Baserow table blueprint,
  • field-by-field configuration,
  • select-option lists,
  • recommended views,
  • recommended forms,
  • naming conventions,
  • and starter API scripts for Claude Code.

Graph View