What we do

Capability 02 of 10 · Built around how you run

Your business, modelled once, then run on software that fits.

CRMs, CDPs, internal tools, and custom platforms built around how your business runs. We start from your domain model, the accounts, orders, cases and consents your teams handle every day, and build the systems on top of it in your cloud, under your ownership.

model / your-company / core-domain
Consentconsents
  • PKiduuid
  • FKcontact_id→ contact
  • purposeenum
  • statusenum
  • captured_attimestamptz
  • sourcetext
Eventevents
  • PKiduuid
  • FKcontact_id→ contact
  • typetext
  • channelenum
  • occurred_attimestamptz
Opportunityopportunities
  • PKiduuid
  • FKaccount_id→ account
  • stageenum
  • amountnumeric
Casecases
  • PKiduuid
  • FKcontact_id→ contact
  • FKorder_id→ order
  • priorityenum
  • sla_due_attimestamptz
Contactcontacts
  • PKiduuid
  • FKaccount_id→ account
  • IDXemail_sha256text
  • phone_e164text
Accountaccounts
  • PKiduuid
  • nametext
  • tierenum
  • regiontext
Productproducts
  • PKskutext
  • nametext
  • pricenumeric
  • activeboolean
Orderorders
  • PKiduuid
  • FKaccount_id→ account
  • totalnumeric
  • placed_attimestamptz
Typical first release
12–24 weeks to first release
Scope
CRM · CDP · internal tools
Ownership
Your cloud, your IP
Illustrative model

An illustrative domain model for “Your company”: eight entities. An Account has many Contacts, Opportunities and Orders. A Contact has many Events, Consents and Cases. An Order has many Products through order lines, and a Case may refer to one Order. Beside the model, the same Account is shown as the record form a person would use, with its tier, region, owner team, health score and latest order.

Tall stacks of paper files and folders on an office desk

Where it breaks

When the spreadsheet becomes the system, the cost is quiet and weekly.

Most platforms we build replace something that grew by accident: an export, a shared sheet, an inbox rule. It works until the business depends on it. These are the signs.

  1. 01

    Same customer, four tools, four IDs.

    Sales knows them as ACC-10442, billing as C-88121, support by an email address and the spreadsheet by a company name. Every report starts with a matching exercise.

    9.5h / weekReconciling records

  2. 02

    Approvals by email.

    Discounts, refunds and credit limits are agreed in reply-all threads. Nobody can say who approved what, or when, without searching an inbox.

    7h / weekChasing sign-off

  3. 03

    Reports rebuilt every Monday.

    Someone exports five sheets, pastes them together and hopes the formulas held. The numbers are a week old by the time anyone reads them.

    6h / weekRebuilding reports

  4. 04

    No trail of who changed what.

    When a price or a status changes, there is no record of the old value, the person or the reason. Every audit becomes archaeology.

    4.5h / weekReconstructing changes

Across all four

27 h / week about 0.7 of a full-time role, before a single error is counted

IllustrativeFigures for a 40-person operations team. We measure your own baseline in the first week, before anything is built.

Internal tools · anatomy

Internal tools your teams choose to open. Designed around the work, not the table.

The screens are the part people see. The decisions underneath are what make a tool trusted: who can see which rows, how fast a queue clears, what needs a second pair of eyes, and what is written down forever.

An illustrative internal case-management tool for “Your company”. A sidebar with saved views; a case list filtered to open P1 and P2 cases in the West region, which is all the signed-in role can see, with three cases selected for a bulk action; the detail of a refund case whose status was just saved as pending and whose refund above 50,000 was approved by a second person; and an append-only, hash-chained audit log. Six numbered notes below explain the design decisions.

What we build

Six systems, one data model underneath them.

Platforms are designed from the data outwards, so reporting, automation and AI all read the same governed record. Build, buy or extend is decided module by module and written down as a decision record, so the reasoning outlives the meeting.

Two engineers talk through code on a monitor at a shared desk
01

Custom CRM

Pipelines, accounts, cases and field work modelled on how your teams sell and serve, with the integrations they depend on.

Build or buy

Extend Salesforce or HubSpot when most of the process fits out of the box. Build when the process itself is your advantage, or per-seat licences stop scaling with the team.

store
PostgreSQL · row-level security
flow
Temporal for renewals and onboarding
sync
Email, calendar and ERP, two-way
02

Customer data platform

Identity resolution, consented profiles and real-time segments that marketing, sales and service all read from.

Build or buy

Buy a packaged CDP for standard marketing use. Build a composable CDP on your own warehouse when identity, consent and cost must stay under your control.

match
Deterministic, then probabilistic
consent
Checked per purpose at activation
activate
Reverse ETL to CRM, email and ads
03

Internal tools & back-office

Admin consoles, partner portals and back-office tools that replace spreadsheets and email chains with audited work.

Build or buy

Use a low-code builder for simple screens over one table. Build when a tool needs real permissions, bulk work, approvals and an audit trail.

auth
SSO over SAML 2.0 or OIDC
work
Keyboard-first bulk actions
audit
Append-only, hash-chained log
04

Workflow & approvals engines

Onboarding, refunds, credit and change approvals as durable workflows with SLAs, escalations and maker–checker rules.

Build or buy

Configure your ERP’s workflow when the steps live inside one system. Build when a process crosses systems, waits for days or must never lose its place.

engine
Temporal · Camunda (BPMN 2.0)
timers
Retries, timeouts, compensation
rules
SLAs and escalations as code
05

Data platform & semantic layer

Ingestion, a medallion lakehouse and one semantic layer, so every dashboard, model and agent reads the same governed numbers.

Build or buy

Buy the plumbing: managed connectors and a cloud warehouse. Build the models, data contracts and metric definitions, because they encode how your business works.

ingest
CDC with Debezium and Kafka
model
dbt, tested in CI
metrics
Defined once, used everywhere
06

Legacy modernisation

Monoliths and ageing line-of-business systems replaced module by module, with parallel runs and a way back at every step.

Build or buy

Rehost when the system works and only the platform is ageing. Rebuild when the data model or the process no longer fits the business.

route
Strangler-fig routing facade
sync
CDC sync, daily reconciliation
undo
Rollback per module by flag

Signature · the Profile Stitcher

Eight events, one customer. Stitched, consented and activated.

A customer data platform is an identity engine before it is anything else. Step through a day of events from five channels and watch them resolve into one golden profile, under match rules you can change and a consent gate you can pull.

Interactive demonstration with fictional data. Use Next event, Play all or Reset to step through eight events. Switch the match rules between deterministic only and deterministic plus probabilistic, and switch marketing consent to withdrawn. The status line below the controls announces each change; the profile, segments, destinations and steward queue update to match.

cdp / identity-resolution / Your company Fictional data
Match rules

Event 8 of 8 · Web add_to_cart · ck_e913 scored 0.72, below 0.85 · queued for data steward review

Event stream5 channels

Identity graph7 identifiers · 1 profile · 1 in review

Golden profileKnown

P-00016 identifiers linked
Email
9b2e…41 · verified at login
Phone
+91 ••••• 4471
Loyalty
L-20931 · Silver
Lifetime value
4,850
Last seen
19:48 · Web
Marketing consent
Granted · 09:14 · signup form
  • Web
  • App
  • Store
  • Support
  • Email

Segments5 of 5

  • Known contactsverified emailIn
  • Store buyers · 30 daysPOS purchaseIn
  • Open support caseticket status openIn
  • High intent · 24 h≥ 2 product viewsIn
  • Email engaged · 7 daysclick or replyIn

Activationconsent checked per purpose, every sync

  • SalesforceCRM · sales and service Purpose · Service Synced Contact + open case · 16:22
  • HubSpotMarketing email Purpose · Marketing Synced List: Email engaged · 21:03
  • Google AdsCustomer Match Purpose · Marketing Synced Audience: High intent · 19:48
  • MetaCustom Audiences Purpose · Marketing Synced Exclude: recent store buyers

Data steward queue1 waiting

ck_e913 → P-00010.72 / 0.85

Same /24 network · similar session path · different browser

Nothing waiting. Matches that score below 0.85 land here for a person to decide.

Resolution logappend-only

  1. merge.queued ck_e913 → P-0001 · 0.72 < 0.85
  2. event.attached campaign_click → P-0001
  3. identity.linked ck_d201 → P-0001 · 0.91 · probabilistic
  4. profile.merged P-0002 → P-0001 · email + phone
  5. profile.created P-0002 · loyalty + phone

Deterministic first

Exact keys join records: a verified login, a hashed email, a loyalty ID, a phone number in E.164. These merges are safe to automate and easy to explain.

Probabilistic, with a threshold

Device, network and behaviour signals are scored. Above the agreed threshold the link is made and marked as inferred; below it, a data steward decides. Survivorship rules pick which value wins: verified beats typed, recent beats old.

Consent is a hard gate

Consent is stored per purpose and checked at every activation, not once at collection. A withdrawal stops marketing syncs within minutes and is logged with the rule it applied.

  • GDPR — General Data Protection Regulation (EU) 2016/679
  • DPDP Act 2023 — Digital Personal Data Protection Act, 2023

Let’s build what happens next.

Tell us what you’re building. We’ll answer straight.

Book a discovery call