We build the org so your admins can still change it.

Two kinds of org call us. One has nothing yet and needs Sales Cloud, flows and integrations built. The other has too much — nine years of triggers, three overlapping automations, and nobody left who knows why. We take both, and both start the same way: watching the process before touching a field.

Shape
Fixed-scope project
Typical length
6–12 weeks
Priced
Fixed scope, or time & materials
Starts with
A workshop, not a proposal
You keep
Repository, runbook, admin training
Proven by
70+ projects

Twelve weeks, four stages, one handover.

Drawn to scale
01WorkshopWeek 1We sit with the people doing the work and map what actually happens, not what the process document says.
02Architecture noteWeek 2What we will build, what we will not, and what it costs to change our minds later. You approve this before any code.
03Two-week incrementsWeeks 3–10You see it working in a sandbox at the end of each one. No six-week silences.
04HandoverWeeks 11–12Repository, deployment runbook, and a working session with your admins on the parts they will own.
Drawn at the long end: twelve weeks. A six-week build runs the same four stages with two increments instead of four — the workshop, the architecture note and the handover do not shrink. The length is fixed at the workshop, not before it.

Everything this engagement can touch.

Five areas

This is the whole surface the engagement can cover. Most orgs need three of these five — the workshop decides which, and what you do not need does not get built.

CRM customisation

Sales Cloud, Service Cloud and Experience Cloud configured for your processes rather than for a demo org.

  • Objects & fields — custom objects, field-level security, picklist standardisation, and layout optimisation per profile
  • Validation rules & formulas — business rules enforced at the point of entry, so bad data does not get in
  • Lightning App Builder — page layouts and dynamic forms that surface the right information for each user
  • Process automation — record-triggered flows, screen flows and scheduled automation that replace manual steps

Salesforce integrations

The right connector for each job, and a written reason for the choice.

  • REST & SOAP callouts — named credentials, connected apps, OAuth 2.0
  • Platform Events & Change Data Capture — event-driven patterns for real-time downstream updates
  • External Services — declarative integration with OpenAPI endpoints, callable from Flow
  • Heroku Connect — when the org needs its data in Postgres; scoped and run under 02 — Heroku consulting

Lightning Web Components

When declarative tools hit their limit, we write the component — and we write it so the next person can read it.

  • Complex data tables with inline editing and bulk actions
  • Third-party library integrations (Stripe, maps, charts) via static resources
  • Experience Cloud components with community-aware data access
  • Security-review-ready patterns for AppExchange submissions

AppExchange development

End-to-end managed package delivery. If this is the whole engagement rather than part of it, 03 — Product development is the shape you want.

  • 1GP packages — namespace management, patch releases, push upgrades
  • 2GP packages — unlocked package architecture and scratch-org CI/CD
  • Security Review — PMD static analysis, manual code audit, submission support
  • Subscriber management — LMA integration, trial management, upgrade handling

Data migration & rollouts

Moving data into or within Salesforce without losing a weekend to it.

  • Bulk insert / update / upsert with a full audit trail and rollback
  • External ID strategy — so a migration can be re-run instead of unpicked
  • Pre-migration deduplication and post-migration duplicate rules
  • Change-set reviews, deployment runbooks, post-deploy smoke tests

The handover

What you are left holding.

Weeks eleven and twelve are not a formality. They are the reason the other ten were built the way they were.

  1. The repositoryEvery line of Apex, LWC and Flow metadata, in your git, under your account. No vendor repo, no licence to keep paying.
  2. The deployment runbookHow it deploys, what breaks first, and what to check at 2am. Written during the build, not reconstructed at the end.
  3. A working session with your adminsLive, on the parts they will own, with their questions. Not a recorded walkthrough nobody watches twice.
  4. The architecture noteWhat we built, what we deliberately did not, and what it would cost to change either.