Custom objects, under the hood

Every business sells a little differently. A recruiting firm tracks candidates and roles. A fund tracks investors and portfolio companies. A services shop tracks projects and partners. Most CRMs make you squeeze all of that into contacts and deals. K3X lets you add the objects your business actually runs on, and this post explains how that works under the hood.

Custom objects are not a second tier

Every K3X workspace starts with people, companies and deals. Custom objects sit right alongside them and behave the same way. They get fields, views, permissions, relationships, reports and API access. There is no lighter version of anything.

That was the most important decision in the data model. The quick way to build custom objects is to store them as loose JSON on a generic table. It ships fast and limits you almost immediately: you cannot filter or sort on those fields efficiently, and you cannot point a relationship at them. We chose to do the harder thing once rather than pay for the shortcut on every feature after it.

Schemas that change without downtime

Each object has a schema made of typed fields, stored and versioned separately from the records themselves. Adding a field is a metadata change plus a background backfill, never a locked table. That is what makes it possible to change your CRM with a sentence like “add a Partners object with a tier and a region” while your team keeps working.

Relationships you set once

If a deal has a “sourced by” partner, the partner record should list its deals without anyone setting that up twice. In K3X, a relationship is stored once and read from both ends. Creating it adds a field on each object, and both sides stay consistent in the same transaction.

Field types for real data

Real-world data is messy, so field types matter. A few that make the biggest difference:

• Multi-select, because most real categories allow more than one answer.

• Currency with a code, so teams working in several currencies are not stuck with a plain number.

• Record lists, for things like “this project involves these five people”.

• AI fields, filled in for every record from the sources you choose.

Imports that respect your model

Moving from another CRM means mapping someone else’s data model onto yours. The K3X importer proposes matching objects and relationships, and shows a preview of the first records before anything is written, so you can check the mapping with data you know.

What we would tell another team

Build the flexible thing properly from the start, or not at all. Every shortcut in a data model turns into a migration later. Making custom objects first-class cost more up front, but it is the reason the rest of K3X can be shaped by a prompt.