Deep Plan: Baserow CRM Transformation — Super Database

Created: 2026-03-24 Owner: Dmitri Zasage, Solanasis LLC Status: SUPERSEDED by deep-plan-baserow-80-20-execution-2026-03-24.md — kept for broader reference Complexity: Multi-phase (touches schema, automation, integrations, UI, plugins) Estimated phases: 6 phases, ~2-4 sessions each

NOTE: Dmitri narrowed scope on 2026-03-24: free tier only, no n8n, no Apollo (deferred), no guild sharing (vision only). The focused 80/20 execution plan is at deep-plan-baserow-80-20-execution-2026-03-24.md. This broader document is kept for reference on deferred items.

Executive Summary

Transform Solanasis’s self-hosted Baserow from a basic 5-table contact database into a relational CRM super-database with:

Proper relational schema (People ↔ Organizations ↔ Interactions ↔ Deals ↔ Meeting Notes ↔ Tasks)
Automated Fireflies → Baserow meeting note sync (currently only saves to markdown files)
Apollo.io import pipeline ready for bulk prospect data
Forms for quick manual data entry
Views configured as daily operational dashboards
Community plugins where they add genuine value (not plugin sprawl)

The north star: Baserow becomes the single source of truth for all CRM data — contacts, interactions, pipeline, meeting notes, tasks — with everything properly linked relationally so you can click from a person → see their org → see all meetings → see all deals → see all tasks.

Current State Assessment

What Exists Today

Component	Status	Assessment
Baserow self-hosted	Running at baserow.solanasis.com	Healthy, Docker + Cloudflare tunnel
Core tables (5)	Tag, Location, Organization, People, Meeting Notes	Migrated from Coda — basic but functional
People table	179 rows, 19 fields, link_rows to Tag/Location/Organization	Missing: status, deal stage, last contacted
Meeting Notes	37 rows, Person→People link_row	Broken UX — no proper date sorting, no auto-population from Fireflies
Pipeline tables	Foundation (200+), fCTO (50+), MSP (100+)	Isolated — flat tables, not linked to People/Org
Fireflies sync	Hourly, saves markdown to solanasis-docs/	Gap: Data goes to files, NOT to Baserow
TypeScript client	Robust, dual auth, batch ops, rate limiting	Reusable for all new automation
Python migration scripts	3 pipeline-specific scripts + field mapper	Pattern established, can replicate
Forms	None configured	Gap
Views (filtered/kanban/etc.)	None configured	Gap
Community plugins	None installed	Opportunity
Apollo integration	Mentioned in playbooks, no implementation	Gap

Your own playbooks converge on the same target schema. Here’s the synthesis:

Playbook	Key Recommendation
`baserow-vs-coda-playbook.md`	5-table schema: People, Companies, Interactions, Opportunities, Tasks
`baserow-airtable-ai-native-crm-playbook.md`	Keep minimal, API-first, 0-1 plugins max, thin CLI wrapper
`solanasis-custom-erp-crm-build-plan.md`	Long-term: custom Frappe CRM. Short-term: Baserow as bridge
`guild-cooperative-crm-sharing-playbook.md`	Future: shared CRM across guild members
`email-to-baserow-crm-extraction-plan.md`	Pattern: extract → dedup → batch import via API

Conclusion: The playbooks already describe the destination. This plan provides the concrete implementation path.

Phase 1: Schema Redesign — Make It Relational

Priority: CRITICAL — everything else depends on this Effort: 1 session (~2-3 hours) Dependencies: None

1.1 New Tables to Create

Interactions (replaces the “one giant Notes field” anti-pattern)

Field	Type	Notes
Title	text (primary)	Auto-generated: “{Type} with {Person} — {Date}“
Person	link_row → People	Required
Organization	link_row → Organization	Optional, auto-populated from Person’s org
Date	date	Required
Type	single_select	Call, Meeting, Email, LinkedIn, Referral, Voice Note, Other
Channel	single_select	In-Person, Zoom, Phone, Email, LinkedIn, WhatsApp
Summary	long_text	Key takeaways (2-3 sentences)
Outcome	single_select	Positive, Neutral, Negative, No Response
Next Step	text	What needs to happen next
Follow-up Date	date	When to follow up
Fireflies ID	text	Links to Fireflies transcript (for auto-synced meetings)
Transcript Link	text	Path to markdown transcript file
Source	single_select	Manual, Fireflies, Email Sync, Apollo

Why: Your playbooks unanimously say “Use a dedicated Interactions table.” Right now meeting history is split between the Meeting Notes table (37 rows) and markdown files (70+ Fireflies transcripts). This table unifies everything.

Deals / Opportunities

Field	Type	Notes
Deal Name	text (primary)	e.g., “Acme Corp — Security Assessment”
Organization	link_row → Organization	Required
Primary Contact	link_row → People	Required
Service Line	single_select	Security Assessment, DR Verification, Data Migration, CRM Setup, Systems Integration, AI Implementation, fCIO, fCSIO, fCOO
Stage	single_select	Prospect, Discovery, Proposal, Negotiation, Won, Lost, On Hold
Estimated Value	number (currency)	Dollar amount
Probability	number (%)	0-100
Expected Close	date	Target close date
Source	single_select	Referral, Cold Outreach, Inbound, Network, Conference, Apollo
Pipeline	single_select	Primary, Foundation, fCTO, MSP, VC
Blockers	long_text	What’s preventing progress
Next Action	text	Immediate next step
Won/Lost Reason	text	Post-close learning
Created Date	date	When deal was created

Tasks

Field	Type	Notes
Task	text (primary)	What needs to be done
Person	link_row → People	Optional
Organization	link_row → Organization	Optional
Deal	link_row → Deals	Optional
Due Date	date	When it’s due
Status	single_select	To Do, In Progress, Waiting, Done
Priority	single_select	Urgent, High, Normal, Low
Type	single_select	Follow-up, Proposal, Research, Admin, Outreach
Notes	long_text	Additional context

Pipeline Stages (lookup table for Deals)

Field	Type	Notes
Stage Name	text (primary)	e.g., “Discovery”
Order	number	Sort order (10, 20, 30…)
Default Probability	number	Auto-fill when deal enters stage
Color	text	Hex color for kanban cards
Is Terminal	boolean	Won/Lost/On Hold = terminal

1.2 Modifications to Existing Tables

People — Add Fields

New Field	Type	Why
Status	single_select	New, Active, Warm, Cold, Client, Partner, Dormant, Do Not Contact
Lead Score	number	0-100, calculated from interactions
Last Contacted	date	Auto-update from latest Interaction
Next Touch Date	date	When to reach out next
Deal Count	count (formula/lookup)	How many active deals
Interaction Count	count (formula/lookup)	Total interactions
Pipeline Source	single_select	Manual, Apollo, LinkedIn, Foundation Pipeline, fCTO Pipeline, MSP Pipeline, VC Pipeline
Apollo ID	text	For dedup when importing from Apollo

Organization — Add Fields

New Field	Type	Why
Industry	single_select	Finance, Healthcare, Nonprofit, Tech, Legal, Education, Government, Other
Size Band	single_select	1-10, 11-50, 51-200, 201-1000, 1000+
Account Status	single_select	Prospect, Active Client, Former Client, Partner, Vendor
Annual Revenue	number	For qualifying
City	text	For geographic targeting
State	text	For geographic targeting

Meeting Notes — Migrate to Interactions

The existing 37 Meeting Notes rows should be migrated into the new Interactions table, then the Meeting Notes table archived (not deleted — per your archive rules).

Migration mapping:

Person → Person (same link_row)
Date → Date
Notes → Summary
Follow-up Date → Follow-up Date
Type → “Meeting” (default)
Source → “Manual” (these were manually entered)

1.3 Implementation Script

Create solanasis-scripts/baserow/schema-upgrade-v2.py:

Connect to self-hosted Baserow via JWT API
Create new tables (Interactions, Deals, Tasks, Pipeline Stages)
Add new fields to People and Organization
Seed Pipeline Stages with default values
Migrate Meeting Notes → Interactions
Verify all link_row relationships work
Generate upgrade report

Reuse existing patterns from: foundation-pipeline/migrate_to_baserow.py and baserow/src/migrate/schema.ts

1.4 Validation Checklist

All link_row fields resolve correctly (click Person in Interaction → opens correct People row)
Pipeline Stages seeded with: Prospect (10%), Discovery (20%), Proposal (40%), Negotiation (60%), Won (100%), Lost (0%), On Hold (0%)
Meeting Notes data migrated to Interactions (37 rows)
People table has new Status, Lead Score, Last Contacted fields
Organization table has Industry, Size Band, Account Status fields
No duplicate tables or orphan fields

Phase 2: Views & Forms — Daily Operating Dashboard

Priority: HIGH — makes the database usable day-to-day Effort: 1 session (~1-2 hours) Dependencies: Phase 1 complete

2.1 Views to Create

Views are configured via the Baserow UI (not API). These are the recommended views for each table:

People Table Views

View Name	Type	Filter/Sort	Purpose
All Contacts	Grid (default)	Sort: Name A→Z	Master list
Hot Leads	Grid	Status = Active OR Warm, Sort: Lead Score DESC	Daily outreach targets
Needs Follow-Up	Grid	Next Touch Date ≤ today + 7 days	Weekly review
Clients	Grid	Status = Client	Current client list
Partners & Referrers	Grid	Status = Partner	Referral network
Dormant	Grid	Last Contacted > 30 days ago, Status ≠ Do Not Contact	Re-engagement targets
Recent Additions	Grid	Sort: Created DESC, Limit 50	What’s new

Deals Table Views

View Name	Type	Filter/Sort	Purpose
Pipeline Kanban	Kanban (PREMIUM)	Group by: Stage	Primary daily view — drag deals between stages
Pipeline by Stage	Grid	Group by: Stage, Sort: Expected Close	Free alternative — grouped grid mimics kanban
All Deals	Grid	Sort: Expected Close ASC	Full list
This Month	Grid	Expected Close = current month	Closing focus
Stale Deals	Grid	Updated > 14 days ago, Stage ≠ Won/Lost	Deals that need attention
Won	Grid	Stage = Won	Success tracking
Lost	Grid	Stage = Lost	Learning/patterns

Interactions Table Views

View Name	Type	Filter/Sort	Purpose
Recent	Grid	Sort: Date DESC	Quick review of all activity
This Week	Grid	Date = last 7 days	Weekly summary
Follow-ups Due	Grid	Follow-up Date ≤ today + 3 days	Action items
By Person	Grid	Group by: Person	See all touchpoints per contact
Meetings Only	Grid	Type = Meeting	Filter to meetings
Fireflies Synced	Grid	Source = Fireflies	Auto-synced entries

Tasks Table Views

View Name	Type	Filter/Sort	Purpose
Today	Grid	Due Date = today, Status ≠ Done	Daily task list
This Week	Grid	Due Date ≤ end of week	Weekly planning
Overdue	Grid	Due Date < today, Status ≠ Done	Red flag view
Kanban	Kanban (PREMIUM)	Group by: Status	Visual task board
By Status	Grid	Group by: Status	Free alternative — grouped grid
By Priority	Grid	Sort: Priority (Urgent first), then Due Date	Triage view

Organization Table Views

View Name	Type	Filter/Sort	Purpose
All Organizations	Grid	Sort: Name A→Z	Master list
Active Clients	Grid	Account Status = Active Client	Client roster
Prospects	Grid	Account Status = Prospect	Sales targets
By Industry	Grid	Group by: Industry	Vertical analysis

2.2 Forms to Create

Baserow forms create new rows. These 4 forms cover 90% of manual data entry needs:

Form 1: Quick Contact Capture

Target table: People Visible fields:

Name (required)
Email
Phone Number
Title
Organization (link_row — dropdown of existing orgs)
LinkedIn
Source (default: “Manual”)
Status (default: “New”)
Notes

Use case: After a networking event, conference, or random intro — quickly add someone without navigating the full table.

Form 2: Log an Interaction

Target table: Interactions Visible fields:

Person (link_row — dropdown, required)
Date (default: today)
Type (required: Call, Meeting, Email, LinkedIn, etc.)
Channel
Summary (required)
Outcome
Next Step
Follow-up Date

Use case: After any call, meeting, or meaningful exchange — log it in 60 seconds. This is the most important form for CRM discipline.

Form 3: Create a Deal

Target table: Deals Visible fields:

Deal Name (required)
Organization (link_row)
Primary Contact (link_row)
Service Line
Stage (default: “Discovery”)
Estimated Value
Expected Close
Source
Pipeline
Next Action

Use case: When a conversation turns into a real opportunity.

Form 4: Quick Task

Target table: Tasks Visible fields:

Task (required)
Due Date (required)
Priority (default: “Normal”)
Person (link_row)
Deal (link_row)
Type
Notes

Use case: Capture a follow-up or action item quickly.

2.3 Form URLs & Bookmarks

After creating forms, bookmark them in your browser toolbar for 1-click access:

baserow.solanasis.com/form/[contact-form-slug] → “Add Contact”
baserow.solanasis.com/form/[interaction-form-slug] → “Log Interaction”
baserow.solanasis.com/form/[deal-form-slug] → “New Deal”
baserow.solanasis.com/form/[task-form-slug] → “Quick Task”

Phase 3: Fireflies → Baserow Automation

Priority: HIGH — currently the biggest data gap Effort: 1-2 sessions Dependencies: Phase 1 (Interactions table must exist)

3.1 Current State

Fireflies AI → (hourly Claude Code sync) → Markdown files in solanasis-docs/
                                            ↓
                                     NOT connected to Baserow

3.2 Target State

Fireflies AI → (hourly Claude Code sync) → Markdown files in solanasis-docs/
                                            ↓
                                     ALSO creates/updates Interactions row in Baserow
                                            ↓
                                     Auto-links to People row (name matching)

3.3 Implementation: Extend the Existing Sync

The Fireflies sync already runs hourly via scheduled-tasks/scripts/run-fireflies-sync.py → invokes Claude Code with the prompt from 01-fireflies-sync-prompt.md.

Option A (Recommended): Add Baserow step to the sync prompt

Update 01-fireflies-sync-prompt.md to include a Step 6:

### Step 6: Push to Baserow Interactions Table

For each NEW meeting/voice note that was saved to markdown:
1. Call Baserow API to search People table for matching contact name
   - Match: first non-Dmitri participant name against People.Name
   - If no match found, create a new People row with the participant's name and email
2. Create a new Interactions row:
   - Person: link to matched/created People row
   - Date: meeting date
   - Type: "Meeting" or "Voice Note"
   - Channel: "Zoom" (or inferred from meeting platform)
   - Summary: AI summary from Fireflies (first 500 chars)
   - Source: "Fireflies"
   - Fireflies ID: the transcript ID
   - Transcript Link: relative path to the markdown transcript file
3. Update People row:
   - Last Contacted: meeting date (if more recent than current value)

Option B (Alternative): Separate Python script

Create solanasis-scripts/baserow/fireflies-to-baserow.py that:

Scans solanasis-docs/meeting-notes/meeting-transcripts/ for files with YAML frontmatter
Reads fireflies_id from frontmatter
Checks Baserow Interactions table for existing Fireflies ID to avoid duplicates
Creates new Interactions rows for unsynced meetings
Matches participants to People rows by name/email
Runs as a cron job or appended to the existing sync

Recommendation: Option A is simpler (one sync process instead of two), but Option B is more robust (separate concerns, easier to debug). Start with Option A, refactor to Option B if the sync prompt becomes too complex.

3.4 Name Matching Strategy

The trickiest part is linking Fireflies participants to People rows:

Exact name match — search People.Name for the participant name
Email match — if Fireflies provides participant email, match against People.Email
Fuzzy match — handle “Jonathan Dekle” vs “Jon Dekle” (use first + last name)
No match — create a new People row with Status = “New”, Source = “Fireflies”

Implementation: Use Baserow’s search API parameter on the People table, or pull all People rows into a local lookup map (179 rows is small enough to cache).

3.5 Backfill Existing Transcripts

After the sync is working for new meetings, run a one-time backfill:

Read all 70+ existing transcript files from meeting-transcripts/ and voice-notes/
Parse YAML frontmatter for date, participants, fireflies_id
Create Interactions rows for each, linking to People where possible
This gives you instant history in the Interactions table

Script: solanasis-scripts/baserow/backfill-fireflies-interactions.py

Phase 4: Pipeline Consolidation & Apollo Import

Priority: MEDIUM — needed before “super database” status Effort: 2 sessions Dependencies: Phase 1 (schema), Phase 2 (views)

4.1 The Problem

Right now you have isolated pipeline tables:

Foundation Prospects (200+ rows) — flat table, no link to People/Org
fCTO Partners (50+ rows) — flat table, no link to People/Org
MSP Prospects (100+ rows) — flat table, no link to People/Org

And you want to add Apollo data on top of this.

4.2 Strategy: Unified Pipeline via Deals Table

Rather than keeping separate pipeline tables forever, migrate the qualified/active prospects from each pipeline into the unified schema:

People table ← contact info from each pipeline
Organization table ← company info from each pipeline
Deals table ← opportunities, with Pipeline field = “Foundation” / “fCTO” / “MSP” / “VC”

Keep the raw pipeline tables as read-only reference (archive, don’t delete). The scored/enriched data is valuable for reference but shouldn’t be the operational layer.

4.3 Pipeline → Unified Schema Migration

For each pipeline (Foundation, fCTO, MSP):

Extract qualified prospects (Tier A + B only — don’t dump C/D into the CRM)
Dedup against existing People/Org (email-based, then name-based fuzzy)
Create People rows for new contacts
Create Organization rows for new companies
Create Deals rows with Pipeline field set appropriately
Link everything — People → Organization, Deal → People + Organization

Script pattern: Follow the existing migrate_to_baserow.py pattern but target the unified tables instead of creating new flat tables.

4.4 Apollo.io Import Pipeline

Apollo exports are CSV files with standardized columns. Build a reusable import pipeline:

Script: solanasis-scripts/baserow/import-apollo.py

apollo_export.csv → Parse → Dedup against People/Org → Create rows → Link → Report

Apollo CSV → Baserow Field Mapping:

Apollo Column	Baserow Table	Baserow Field
First Name + Last Name	People	Name
Email	People	Email
Phone	People	Phone Number
Title	People	Title
LinkedIn Url	People	LinkedIn
Company	Organization	Name
Website	Organization	Website
Industry	Organization	Industry
# Employees	Organization	Size Band (mapped to bands)
City	Organization	City
State	Organization	State
Person Source	People	Pipeline Source = “Apollo”

Dedup strategy:

Email match (primary — most reliable)
LinkedIn URL match (secondary — catches email variations)
Name + Company match (tertiary — fuzzy, flag for manual review)

Import modes:

--plan — dry run showing what would be created/skipped
--run — execute import
--update — update existing rows with new Apollo data (for re-enrichment)

4.5 Apollo Sync Considerations

Apollo exports can be large (1000+ rows). Use batch API (200 rows/batch).
Apollo data refreshes. Plan for periodic re-import with --update mode.
Store Apollo ID on People rows for reliable dedup across imports.
Filter before import — don’t dump every Apollo contact into Baserow. Use scoring or segment filters in Apollo first.

Phase 5: Community Plugins & Premium Features

Priority: MEDIUM — enhances UX but not blocking Effort: 1 session Dependencies: Phase 1-2 (schema and views must exist first)

5.1 Baserow Plugin Ecosystem Reality Check

Your baserow-airtable-ai-native-crm-playbook.md already nailed it:

“Do NOT assume community plugins will turn self-hosted Baserow into Premium for free.” “Use 0-1 plugins max at first.”

This is still the right call. The plugin ecosystem is small and experimental. Here’s the current landscape:

5.2 Community Plugins — Evaluated

Plugin / Feature	What It Does	Available?	Worth It?	Notes
Grid views (built-in free)	Filtered/sorted/grouped tables	FREE	Core of everything	Grouped grids are the free-tier workhorse
Form views (built-in free)	Data entry forms	FREE	Essential	All 4 CRM forms work on free tier
Gallery views (built-in free)	Card-style record display	FREE	Nice-to-have	Use for People cards with avatar
Kanban views (built-in)	Drag-and-drop boards	PREMIUM	High value	Deal pipeline, task board — #1 reason to go Premium
Calendar views (built-in)	Date-based visualization	PREMIUM	High value	Interactions/tasks by date
Dashboard views (built-in)	Charts and analytics	PREMIUM	Medium value	Pipeline reports, conversion metrics
AI field type (built-in)	GPT/Claude generates content per row	PREMIUM	Medium value	Auto-summarize interactions, score leads. Alternative: external Python script calling AI API + writing back via Baserow API (free, aligns with “keep AI logic external” principle from playbooks)
Row comments (built-in)	Discussion threads on records	PREMIUM	Medium value	CRM-style collaboration on deals/contacts
Row coloring (built-in)	Color-code rows by field values	PREMIUM	Nice-to-have	Visual priority/status indication
BaseCharts (community plugin)	Chart widgets in views	Community	MAYBE	Only if you need in-Baserow charts without Premium. Check compatibility before installing.
BaseScript (community plugin)	In-browser JavaScript scripting	Community	NO	Proof-of-concept quality. Use external Python scripts instead.
Baserow geo plugin (community)	Map/geography views	Community	NO	Only useful if territory mapping becomes critical. Premature.

5.3 Self-Hosted Premium Features — Cost/Benefit Summary

Premium pricing for self-hosted: $10/ u ser / m o n t h (ye a r l y) or$ 12/user/month (monthly)

The full Premium feature assessment is in the Budget Decision section above. In summary:

Kanban + Calendar + Dashboard views are the highest-value Premium features for CRM use
AI field + Row comments are the next tier of value
Row coloring, password-protected views are nice-to-haves

Recommendation: If you’re serious about making Baserow feel like a CRM (not just a database), Premium is worth the $120/year for a single user. The kanban pipeline view alone transforms the deal-tracking experience. If you want to stay free, grouped grid views are a functional alternative — just less visual.

5.4 External Dashboarding (Alternative to Premium)

If you don’t want to pay for Premium dashboards:

Tool	How It Connects	Cost	Best For
Metabase (self-hosted)	Direct PostgreSQL connection to Baserow’s DB	Free	SQL-powered dashboards, embed in other tools
Grafana (self-hosted)	PostgreSQL datasource	Free	Real-time monitoring, alerting
n8n + Google Sheets	n8n reads Baserow API → writes to Sheets → Sheets charts	Free	Quick and dirty
Baserow API + Python	Matplotlib/Plotly charts generated by scripts	Free	Automated report generation

Recommendation: Skip external dashboarding for now. The built-in views (kanban, calendar, filtered grids) cover 80% of dashboard needs. Add Metabase later if you need SQL-powered analytics.

Phase 6: Automation & n8n Workflows

Priority: LOWER — automate after schema is stable (per your own playbook advice) Effort: 1-2 sessions Dependencies: Phases 1-4

6.1 Automation Philosophy

Your playbooks say it best:

“Do NOT automate heavily until the schema is clean. A sloppy model gets automated into a bigger mess.”

Phase 6 comes LAST intentionally. Stabilize the schema, use it manually for a week or two, then automate the friction points.

6.2 Recommended n8n Workflows

n8n has native Baserow nodes (Create Row, Update Row, Get Row, List Rows, Delete Row) and Fireflies nodes. These are the high-value automations:

Workflow 1: Fireflies → Baserow (Enhanced Sync)

Trigger: Cron (hourly)
→ Fireflies: Get recent transcripts
→ Baserow: Search People table for participant match
→ IF match: Link Interaction to existing Person
→ IF no match: Create new Person, then link
→ Baserow: Create Interaction row
→ Baserow: Update Person.Last Contacted

Note: This could replace the current Claude Code-based Fireflies sync for the Baserow-writing portion, while keeping the markdown file sync as-is.

Workflow 2: Deal Stage Change → Task Creation

Trigger: Baserow webhook (row updated in Deals)
→ IF Stage changed to "Proposal"
→ Create Task: "Draft proposal for {Deal Name}" due in 3 days
→ IF Stage changed to "Won"
→ Create Task: "Send onboarding email to {Contact}" due tomorrow
→ Create Task: "Generate invoice for {Deal Name}" due in 2 days

Workflow 3: Follow-up Reminder Digest

Trigger: Cron (daily at 8 AM MT)
→ Baserow: List Interactions where Follow-up Date = today
→ Baserow: List Tasks where Due Date = today
→ Baserow: List People where Next Touch Date = today
→ Format into digest
→ (Optional: email or Slack notification)

Workflow 4: Apollo CSV Auto-Import

Trigger: File dropped in watched folder (or manual trigger)
→ Parse CSV
→ For each row: dedup against People/Org
→ Create/update rows in Baserow
→ Generate import report

6.3 Baserow Webhooks

Self-hosted Baserow supports webhooks (even on free tier):

Trigger on row created, updated, deleted
Sends JSON payload to any URL
Can trigger n8n workflows

Set up webhooks on:

Deals table → trigger on stage changes
People table → trigger on new contact creation
Interactions table → trigger on new interaction (for auto-updating People.Last Contacted)

Assumption Register

#	Assumption	Validation Method	Status
A1	Self-hosted Baserow supports form views on free tier	Baserow docs confirm forms are free	VALIDATED — forms are available on all tiers
A2	Baserow kanban/calendar views require Premium license	Baserow pricing page	VALIDATED — kanban, calendar, dashboard are Premium ($10-12/user/month). Grid/Form/Gallery are free. Plan includes free-tier alternatives (grouped grids).
A3	Fireflies MCP provides participant email (not just name)	Check Fireflies MCP response schema	NEEDS VALIDATION — currently unknown if email is included
A4	Baserow row count won’t hit practical limits	Self-hosted has no enforced row limits	VALIDATED — self-hosted is limited only by server resources
A5	The current 179 People rows can absorb pipeline + Apollo data without performance issues	Performance depends on field count and link_rows	LOW RISK — even 10K rows is fine for Baserow
A6	BaseCharts community plugin works on current Baserow version	Need to check version compatibility on GitHub	NEEDS VALIDATION — check GitHub repo before installing
A7	n8n has native Baserow nodes	n8n integrations directory	VALIDATED — Baserow node exists in n8n
A8	Meeting Notes → Interactions migration preserves Person link_rows	Need to verify link_row IDs survive table-to-table migration	NEEDS VALIDATION — test with 1 row first. Mitigation: Do NOT copy link_row IDs directly. Instead, read the Person name from each Meeting Notes row, look up the corresponding People row ID in the Interactions table’s link_row format, and create the link fresh. This avoids ID mismatch issues.

Quality Checklist

KIS (Keep It Simple): Schema adds only what the playbooks already recommend — no over-engineering
DRY: Reuses existing migration script patterns, TypeScript client, field mapper
Catch-Early: Each phase has its own validation checklist
Error Handling: Import scripts already handle rate limits, batch failures, dedup
Security: No credentials in code — all from .env, no new secrets needed
Test Strategy: Dry-run mode on all import scripts (—plan flag)
Rollback: Archive old tables (don’t delete), migration scripts are idempotent

Phase Dependencies & Recommended Sequence

Phase 1: Schema Redesign ──────────┐
                                    ├── Phase 2: Views & Forms
                                    ├── Phase 3: Fireflies Sync
                                    ├── Phase 4: Pipeline + Apollo
                                    │
                                    └── Phase 5: Plugins (can start after Phase 2)
                                              │
                                              └── Phase 6: Automation (after Phases 1-4 stable)

Recommended execution order:

Phase 1 — Schema (do first, everything depends on it)
Budget Decision — Decide on Baserow Premium before Phase 2 (see below)
Phase 2 — Views & Forms (immediately after schema, makes CRM usable)
Soak Period — Use the CRM manually for 3-5 days to surface schema issues
Phase 3 — Fireflies sync (high-value automation, fills the biggest data gap)
Phase 4 — Pipeline + Apollo (consolidate all prospect data)
Phase 5 — Plugins (enhance after base is solid)
Phase 6 — Automation (last — automate proven workflows, not assumptions)

Budget Decision: Free vs. Premium Self-Hosted License

This decision must be made before Phase 2. Several high-value features are Premium-only:

What’s Free on Self-Hosted Baserow

Feature	Available Free?
Grid views (with filters, sorting, grouping)	YES
Form views	YES
Gallery views	YES
Link rows (relational fields)	YES
Lookup / Formula fields	YES
REST API (unlimited)	YES
Webhooks	YES
Unlimited rows	YES (server resources are the limit)
Unlimited tables	YES

What Requires Premium ($10-12/user/month self-hosted)

Feature	CRM Impact
Kanban view	Drag-and-drop deal pipeline, visual task board
Calendar view	See interactions/tasks by date
Dashboard view	In-Baserow analytics and charts
Row coloring	Color-code by status, stage, priority
Row comments	Add notes/discussion to any record
AI field type	Auto-generate summaries, lead descriptions
Password-protected views	Share specific views with contractors

Recommendation: Two Paths

Path A (Recommended): Purchase Premium — ~$120/year

$10/user/month billed yearly (1 user = Dmitri)
Unlocks kanban boards, calendar views, dashboards, AI fields, row comments
Makes Phase 2 views dramatically more useful
This is the “super database” path — kanban pipeline is the #1 feature that makes a CRM feel like a CRM

Path B: Stay Free — $0

Use grid views with filters and grouping as the primary interface
Grid grouped by “Stage” field is a functional (if less visual) alternative to kanban
Calendar views replaced by filtered grids sorted by date
Dashboards built externally (Metabase or Python scripts) if needed
The CRM still works — it just looks more like a database and less like a CRM product

Pro tip: Baserow offers a 30-day free trial of Premium on self-hosted instances. You could test drive kanban/calendar/dashboards during Phase 2 before committing.

Open Questions for Dmitri

Cloud → Self-hosted migration status: Has the data been migrated from Baserow Cloud (ID: 387807) to self-hosted (ID: 54)? The continuation prompt at operations/continuation-prompt-baserow-migration.md is ready but may not have been executed. This determines whether we start with the existing 179 People rows or a fresh instance.
Pipeline table disposition: Should we keep the flat pipeline tables (Foundation, fCTO, MSP) as read-only archives after migrating qualified prospects to the unified schema? Or delete them?
n8n availability: Is n8n installed/available on your infrastructure? If not, should we plan for it, or stick with Python scripts + Claude Code sync?
Premium license: Would you consider Baserow Premium ($5/user/month self-hosted) for dashboard views and row comments? Or keep it free and use external tools?
Apollo workflow: When you say “dumping in our whole pipelines from Apollo” — is this a one-time bulk import, or do you want an ongoing sync that re-imports periodically?
Guild CRM sharing timeline: Is the cooperative CRM sharing concept (from the guild playbook) something that should influence this schema design now? (e.g., multi-tenant fields, access control)

Suggested Next Step

Start Phase 1 immediately. The schema redesign is the foundation everything else builds on. It can be done in a single session:

Run the schema upgrade script to create Interactions, Deals, Tasks, Pipeline Stages tables
Add new fields to People and Organization
Migrate Meeting Notes → Interactions
Verify all relationships work

Then move to Phase 2 (views & forms) in the same session if time allows — this makes the database immediately usable for daily operations.

Say the word and I’ll start building Phase 1.

Solanasis Docs

Explorer

deep-plan-baserow-crm-transformation-2026-03-24