Why we don't have a "Deals" page (and why your template gives you one anyway)

A power user from a previous CRM tried RadiusOS last month and told me, in the kindest possible way, that our data model felt backwards. "Where are the Deals? Where's the Account hierarchy? Why is everything just… a Record?"

It's a fair question. Every enterprise CRM you've used makes you pick a primary entity — Contact, Deal, Account, Opportunity — and bolts the others on with foreign keys and join tables. So when you land in RadiusOS and see Records instead of Deals, the muscle memory misfires. You go looking for the page that isn't there.

I want to explain why we built it this way. Not because we forgot. Because we picked the opposite default on purpose.

The shape of the model

Every item in your pipeline is a Record. Whether it's called a Deal, a Listing, a Job, a Client, or an Application depends entirely on which template you started from. Underneath, they share the same flexible schema.

A Real Estate template renders Records as Listings with address, square footage, and price. A SaaS template renders the same Records as Deals with ARR, stage focus, and close date. A Fitness Coaching template renders them as Clients with primary goal, package type, and renewal date. Same database object underneath. Different lens on top. Your template chooses the lens.

That means you don't navigate to a "Deals" page in RadiusOS, because there isn't one. You navigate to your Pipeline, and the pipeline IS your records, with the fields your template defined. One screen, one query, one click.

Why I picked this

Three reasons.

One: most small businesses don't fit a contact-first or deal-first mold. A real estate agent's primary unit isn't a contact — it's a listing. A roofer's primary unit isn't a contact — it's a job. A fundraiser's primary unit isn't a contact — it's an investor conversation. Forcing every business through the same shape was the original sin of enterprise CRMs. They were built for SaaS sales orgs in 2008 and the rest of us have been adapting to that shape ever since.

Two: multi-table joins are a UX tax. In a contact-first CRM, you click into a contact to see their company, click into the company to see their deals, click into a deal to see its line items. That's three clicks before you've answered any question worth asking. RadiusOS keeps the contact, company association, pipeline metadata, AI score, and activity timeline on one record. One click, one view, all the context.

Three: custom fields are first-class. Every record carries its template's metadata fields natively. There's no "convert this lead into a contact, then convert the contact into a deal" workflow because there's nothing to convert — it's all the same record from day one. You don't lose data crossing entity boundaries because there are no boundaries.

The questions I get

"What if I want multiple deals per contact?" Use multiple Records that share an email or phone, or use Tags and Notes to track parallel opportunities on a single record. For most solopreneurs and small teams, one record per active relationship is the right resolution. By the time you genuinely need parallel deal tracking on a single contact across years, you've usually outgrown the SMB tier of CRMs anyway.

"What about Account-level reporting?" Reports group records by Company association, Tag, Stage, custom field values, AI score range, and a few other axes. You can answer "how much pipeline do I have at Acme Corp" by filtering on Company. The Account view is a query, not a separate object. Same answer, fewer clicks.

"Can I migrate from a multi-object CRM?" Yes. Import Contacts and Deals as Records — we map both into the unified schema during CSV import, and existing relationships survive. What was a Deal in your old CRM becomes a Record with a stage and a contact-association field in RadiusOS. Less data, same information.

When this is the wrong CRM

I want to be honest about fit, because the worst thing you can do as a founder is sell a tool to someone it's wrong for.

RadiusOS is the wrong choice if you need true multi-object reporting at enterprise scale ("opportunity-line-item breakdown across 50,000 accounts in 12 segments"). It's the wrong choice if you have a sales team running weekly committed-vs-pipeline forecasting per AE that depends on a separate Deal entity. It's the wrong choice for B2B account-based selling that genuinely needs Account Hierarchy and Opportunity as distinct objects.

For all of those, the enterprise multi-object CRMs exist for a reason and they'll serve you well. We didn't try to compete with them. We're building for the other 95% of teams.

For everyone else — solopreneurs, realtors, trades, small B2B, fundraisers, recruiters, fitness coaches, freelancers — the unified Record model is faster to learn, faster to navigate, and adapts to your business instead of making you adapt to it.

The lens is the product

If you've used RadiusOS already, the model is invisible to you. You see Listings, or Deals, or Jobs, or Clients, depending on which template you picked. That's intentional. The fact that they're all Records underneath is a design decision, not a user-facing feature. We don't make you think about it because you shouldn't have to.

If you're switching from an enterprise CRM, expect a few days of "wait, where do I…?" muscle memory. Then it gets faster. Most of the operators we talk to a month in say the same thing: "I miss less than I expected, and I click less than I used to."

Read the long version with examples and migration notes in our help article: Why RadiusOS uses one Record model (not separate Deals, Contacts, and Jobs).

Or just pick a template that matches your business and see how it feels — browse the marketplace.