The ads are running, the site form is live, and enquiries are landing. Three weeks in, I ask the founder the only question that matters: did any of them become customers? The answer lives in a HubSpot account somebody set up during a free trial two years ago, half-tagged, with a pipeline nobody moved a deal through since spring. So we open a spreadsheet instead, and now there are two versions of the truth.
That scene is why SharpOS has a CRM at all. This is part of our surface-by-surface series; today is Customers, the row on our replacement ledger that names Salesforce and HubSpot. Those two products are the anchors, so you can place what I'm describing. What we built is smaller than either, on purpose, and I'll be precise about where it stops.
TL;DR: Customers is a customer list with a shared schema, statuses stored by id, CSV that round-trips, and the same property system as our pages and cards. It sits next to the ads and the forms that produce the leads. It is not a sales platform.
What a CRM of that shape is for, and where it strains
Salesforce and HubSpot are built around a sales organisation: pipelines, sequences, forecasts, territories, a rep who lives in the tool all day. That is the right shape when you have that organisation. The businesses we work with are owner-operated. One or two people talk to buyers, in between running the company, and the marketing that produces those buyers is run by us, inside the workspace they already open.
The r/hubspot threads say the rest. "You need a CRM if you have more than one person involved in the sales process. It doesn't have to be HubSpot, but it can't be a spreadsheet." And, from someone who just joined a small company: "HubSpot is a mess." The common reply is that it works if you set it up properly, which is true, and is exactly the problem. Setup is a job, and in a six-person business nobody owns it. The CRM ends up one login away from the work that feeds it, and a record one login away is a record that goes stale.
What Customers does instead
Customers is the organisation-scoped CRM in SharpOS. Each organisation keeps its own customer list, a shared custom-field schema, per-customer values, statuses and notes. Members browse and segment through saved table and board views, import and export CSV, and work each record in a detail view that pairs structured fields with a collaborative rich-text description. Viewers read, editors change records, managers administer statuses, and the Customers feature flag is enforced in the UI and in every backend access path.
The part that matters for the scene above: the list lives in the same organisation as the ads, the forms and the boards. A form submission can create or update a customer through Automations, the customer-created trigger fires downstream steps, and the founder reads the result on the same screen where the week's work is queued. When the board view is open (it is the default), the leads sit in columns by status and drag between them. Nobody has to remember to update a second system, because there is no second system.
You can open a fixture-only workspace and click around the surface here: Customers in the showcase. The feature page with the walkthrough is at sharphaw.digital/features/customers.
How it works
The design decision that keeps Customers small is reuse. Custom fields, value editing and the details panel are one shared system across pages, board cards and customers; Customers plugs in as one more host and keeps only its own storage and permissions. As the feature doc puts it, the tables are customer-specific and nothing else is.
Underneath, a customer is a small record — a name, an email, a pointer to a status — plus its own values for the organisation's shared field definitions, and statuses are records of their own rather than labels typed into a column. Three consequences of that shape:
- Status is a built-in field, and a customer points at a status rather than storing its name. New organisations are seeded with Lead → Qualified → Customer → Churned, and an org can rename, recolour, reorder and delete freely. Renaming "Lead" to "Enquiry" orphans nobody. Deleting a status forces a reassignment first, in batches of 200.
- The schema is organisation-wide. Every customer shares the same field definitions; each customer stores its own values. Twenty property types are available, including money, members, media, and relations to a page, a board, a card or another customer. Changing a definition's type clears incompatible stored values rather than leaving garbage behind.
- Search is index-only. Free-text search runs over an index of name, email and every text-like field value, with no fallback to scanning the whole table. To keep mid-word queries index-backed ("harp" finding "SharpHaw"), the indexed text is extended with bounded word suffixes when the record is written. The honest cost: the footer shows how many rows you've loaded, never an exact organisation-wide total, and typed filters evaluate over a bounded candidate set and say so when they truncate. CSV import got its own route rather than a dialog, because it is where CRMs usually lie to you. Upload, map, preview, commit. Headers auto-match Name, Email, Status and property labels; definitions are never created from headers; you choose update or skip for rows whose email matches an active customer; failing rows come back with line numbers as a correctable CSV. Export writes the same headers the importer accepts, so export, edit and re-import is a round trip. The cap is 5,000 rows or 5 MB per import, committed in batches of 100.
Everything above is also reachable over REST and MCP on the same operations the UI uses, which is how an agent can create a customer record from a form submission without a person in the loop.
What it doesn't do
There is no deal object, no pipeline with stages and amounts, no forecasting, no email sequences, no inbox sync, no lead scoring. Money is a property type you can put on a customer; it is not a revenue report. If you run a sales team that lives in sequences and quarterly forecasts, keep Salesforce or HubSpot and don't let anyone tell you a smaller thing is secretly better. It isn't better. It is smaller, and for the business in the opening scene smaller is the point: a table with a schema, statuses that can't orphan a record, and a place next to the work. It is not a spreadsheet either. Emails are unique per organisation, statuses are ids, filters are typed and evaluated on the server, and roles decide who may change what.
Where it sits in the service
In practice Customers is where Ads Management becomes legible: the spend runs in Meta and Google, the enquiries arrive through the site form, and the founder can see which of them turned into a customer without asking us. Like every surface here it ships inside SharpOS, included with the subscription.
Your turn
For the small businesses you've built for: what was the moment the spreadsheet stopped being enough, and what did you reach for next?
This is part of SharpOS, surface by surface. Part 1, the whole ledger and the row we couldn't replace: We replaced a 12-tool client stack with one workspace we built.
Top comments (0)