Turning a spreadsheet into a CRM
the vendor cannot switch off.
A solo real estate agent's business was running on a spreadsheet. The ask was simple to say and harder to solve well: turn it into software other agents could buy. The result is a self-contained CRM that works offline, keeps the core data local and turns optional encrypted backup and sync into the paid service.
A spreadsheet can run a business.
That does not make it a product.
The original workbook already contained real operating logic: transaction deadlines, commission math, status coloring and follow-up tracking. Turning that into software meant rebuilding the behavior rather than simply copying the appearance.
The harder conflict was architectural. The product needed to work on a laptop and a phone and create recurring revenue, but the desired business model was deliberately simple: sell the product without creating a heavy SaaS operation around it.
The obvious build was SaaS.
I chose not to build it.
A traditional SaaS platform would have introduced accounts, a permanent database, more infrastructure and a monthly fee attached to the app itself.
Instead, I separated the product from the service. The CRM became a single self-contained file the agent owns and can use offline. The one capability that genuinely needs infrastructure, encrypted backup and multi-device sync, became an optional service called Safeguard.
A purpose-built operating system for a solo agent.
Today
A triage view that names the people who are overdue and sorts them by how long they have waited.
Pipeline
List and drag-and-drop board views for leads and active opportunities, with connected records across the system.
Deals
Contract-date-driven deadlines, per-deal task checklists and transaction tracking that replaces spreadsheet formulas with real application behavior.
Earnings
Commission math plus annual goal-versus-pace tracking, connected back to the underlying deals.
Sphere
Cadence-based follow-up, awaiting-reply resurfacing and relationship history that records real touches.
Field work
Open-house kiosk capture, one-tap call/text/email, templates with merge fields and calendar export for birthdays and home anniversaries.
Make the subscription pay for a real service.
The CRM does not need a server to function. Backup and cross-device sync do.
Safeguard encrypts the database on the agent's device before anything is sent to the backend. The service stores ciphertext rather than readable client data and keeps dated snapshots for recovery. That makes recurring revenue attached to an actual ongoing service rather than rent on a file the buyer already owns.
Turn the constraint into the product position.
The obvious path: a hosted CRM with user accounts, a central database and a monthly subscription to keep using the software.
What I chose instead: an owned, local-first application plus a separate paid backup and sync service.
Why: it matched the intended distribution model, kept the core product durable and private, and made the recurring fee enforceable because it pays for infrastructure that actually has to keep running.
Testing was part of the product, not the polish pass.
The end-to-end sync test caught a genuine data-loss risk: a fresh install could overwrite an existing database on first pairing. The fix was tested before launch rather than discovered by a customer.
The application, not a concept rendering.
These screens were captured directly from the working Solo Agent CRM. Sample data is shown so the product can be demonstrated without exposing a real agent's client information.
Overdue follow-ups, unanswered messages, relationship moments and operating metrics live in one daily view.
The same records can be managed as a list or a drag-and-drop board without duplicating data.
One contract date drives the option, inspection, appraisal, financing and closing timeline.
Closed commission, projected net and annual pace stay tied to the underlying deal records.
A full-screen capture mode turns a phone or tablet into a lead intake surface at the property.
Backup and cross-device sync are optional, encrypted on-device and separate from the owned core application.
The asset changed category.
What began as a personal spreadsheet became a tested software product with a product architecture, onboarding, data-safety features, pricing logic, an optional encrypted service and a distribution path.
Market outcomes are deliberately not represented yet because the public launch is pending. The defensible proof at launch is the product itself: version 1.0.0, tested behavior and a business model built around what the architecture actually requires.
The hidden assumption inside a build request is often the expensive part.
“Turn this spreadsheet into a CRM” sounds like an implementation request. The higher-value work was deciding what kind of product it should become, what infrastructure it truly needed and how the technical constraint could become the reason someone chooses it.
That is the same role I want See Kirk Work to play for clients: not simply building the requested thing faster, but making the product, architecture and business-model decisions around it before the obvious answer becomes an expensive commitment.