The problem: we do not need a CRM, we need our CRM
The brief usually arrives in one breath: we do not need a CRM, we need our CRM — four objects, the stages we actually use, and a task list that nags the right person, without the three hundred fields nobody will ever touch.
It comes from two directions. An operations lead who wants the team’s process, not a vendor’s. And an agency principal who wants to hand a client a deal tracker shaped to the client’s business — and hand the next client a different one, on the same license.
What gets built: four objects, your stages, your grids
CRM-like apps have shipped on this platform for years: company and contact objects with real foreign-key relations, task assignment, and workflows that move things along. Yours is assembled the same way, one named operation at a time.
- Objects:
crm_company,crm_contact,crm_deal,crm_task— real tables, with lookups from contact to company and from task to deal. - Forms:
setup-object-crudcreates the deal form, its relations and its create/update/delete actions in one call. Stage is a multiple choice with your stages, not theirs. - Workflows: a stage change emails the deal owner; a new task emails its assignee. Templated with the record’s own fields.
- Grids: the pipeline is an object view joining deal and company; “my open tasks” filters to the signed-in user; contacts by company for the account view.
- Groups: managers see every deal, reps see their own — enforced server-side on the actions and the grids, not hidden by a button.
Starter prompt
Build a solution called CRM Lite for a services team that tracks deals in a spreadsheet.
Objects: Company (name, industry, website); Contact (company, name, email, phone, role); Deal (company, name, stage as multiple choice: lead / qualified / proposal / won / lost, value, owner, expected close); Task (deal, title, assignee, due date, done).
Create a Managers group that sees every deal and a Sales group that sees only deals it owns.
Generate the screens, add a pipeline grid grouped by stage, a grid of my open tasks sorted by due date, and a grid of contacts by company.
Add a workflow that emails the deal owner when the stage changes and one that emails the assignee when a task is created.
Preview the diff before you commit.
Ship it: one publish, the whole team
Review the working copy, then publish: one operation puts Current into Testing and Production, and the pipeline is live for the team. Reps sign in and see their own deals on the web or on a phone; managers see all of them.
Your bill is one organization license — every builder, every app, every environment — and nothing your team does while building or running it is metered. You bring the AI subscription you already pay for. What the license covers, and the trade you are making: how we price · what you own.
Agencies: one account can host many tenants, so a second client’s CRM is a second tenant with its own rows, not a second install. Object data is isolated per tenant at the row level on every query.
Integrations used
A stage change and a new task each send their email through a workflow activity. If a Salesforce org already exists upstream, the platform’s Salesforce sync connects the two rather than making this a second source of truth. For everything else — a Slack channel, a billing system — an ExternalService activity posts to Zapier, Make, n8n or any HTTP endpoint.
Related
- Blueprint: CRM-lite — the copyable primitives map and prompt.
- Closed in 24 Hours: CRM-lite for 35 consultants in 22 hours — an illustrative agency build.
- For agencies — one license, many client apps.
- Next use case: Workflow and approvals — when the deal needs a sign-off.
Your IT lead will ask who can publish this, who can see the data, and what the agent is allowed to touch. The answers are written for them: the IT brief · security and governance.