Services
What I do, and what you actually get
Six service lines. Each one names the business problem it addresses, how the work runs, what is handed over, and who it is for — so you can tell early whether it fits.
Enterprise Salesforce Integrations
Salesforce and your other systems, agreeing on the same facts.
End-to-end integration between Salesforce and the systems that surround it — ERP, warehouse, finance, commerce, or a government registry. Designed around what happens when the other side is slow, wrong, or offline, because that is what determines whether an integration survives.
The problem
Salesforce holds one version of reality and the warehouse, ERP, finance, or registry system holds another. Records drift, syncs fail silently, and someone reconciles by hand in a spreadsheet. When the other system goes down, work is lost rather than queued.
Ideal client
An organisation running Salesforce alongside at least one operational system of record — ERP, WMS, finance, or a government registry — where disagreement between the two has an operational cost.
What this covers
- REST API integration, inbound and outbound
- Middleware architecture — MuleSoft, AWS Lambda, SQS
- Named Credentials, token refresh, and credential rotation
- Retry, idempotency, and dead-letter design
- DTO contract design held separate from the Salesforce schema
- Error-handling frameworks with operator-visible failure logs
Approach
- 01Map every integration point: direction, trigger, payload shape, and volume.
- 02Define the contract as a DTO, deliberately separate from the Salesforce schema.
- 03Choose the pattern per flow — synchronous, queued, or batch — on latency and failure tolerance, not habit.
- 04Design retry, idempotency, and outage behaviour before writing the callout.
- 05Hold endpoints and credentials in Custom Metadata and Named Credentials, never in code.
- 06Put the external service behind an interface with a mock double, so behaviour is testable without a live callout.
Deliverables
- Integration architecture document with a flow diagram per interface
- Apex REST endpoints and outbound integration classes
- Middleware configuration (MuleSoft, AWS Lambda/SQS, or equivalent)
- Error-handling and retry framework with an operator-visible failure log
- Interface specification covering endpoints, payloads, and error codes
- Apex test suite covering the failure paths, not only the happy path
- Runbook covering what breaks, how it surfaces, and how to recover
What to expect
- Integrations that queue rather than lose work during an outage
- Failures that surface to a human instead of passing unnoticed
- Endpoint changes handled as configuration, without a deployment
- A documented contract both teams can build against
Custom Salesforce Development
Apex and LWC built to be maintained by someone else.
Business logic and user interface built on the platform properly — one place per concern, bulkified by default, and tested for behaviour rather than for a coverage percentage. Written so the next developer can read it without a walkthrough.
The problem
The org has grown by accretion. Business logic is duplicated across triggers, flows, and process builders; test coverage exists to satisfy the deployment gate rather than to prove behaviour; and every change carries unquantified regression risk.
Ideal client
Teams needing senior development capacity on a platform that already carries real operational load, where breaking production is not an option.
What this covers
- Apex service layers, triggers, and asynchronous processing
- Lightning Web Components with real empty, error, and loading states
- Complex business logic — pricing, scheduling, reconciliation, payment plans
- Bulkification and governor-limit design
- Apex test suites that assert behaviour
- Refactoring logic scattered across triggers, flows, and process builders
Approach
- 01Establish one place per concern — logic in a service layer, triggers as thin entry points.
- 02Bulkify by default and design for governor limits rather than discovering them in production.
- 03Write tests that assert behaviour, including the negative cases.
- 04Build Lightning Web Components against real user tasks, not as a technology upgrade.
- 05Leave naming and structure that reads clearly without a walkthrough.
Deliverables
- Apex service, trigger, and asynchronous classes
- Lightning Web Components with accessible markup and empty/error/loading states
- Apex test suites
- Code documentation and inline reasoning where a decision is non-obvious
- Deployment-ready metadata under version control
What to expect
- Logic that lives in one findable place
- Test coverage that catches regressions rather than satisfying a percentage
- Components users can operate without training
Evidence
Salesforce Automation
Remove the manual step, keep the audit trail.
Process automation that replaces re-keying and email chains with something the business can audit. Declarative where a Flow is sufficient and legible to an admin; Apex where the logic is complex, high-volume, or needs real tests.
The problem
Operational staff are re-entering data across systems, chasing approvals over email, and maintaining a spreadsheet the CRM was supposed to replace. The process works because people remember it, which means it does not scale and cannot be audited.
Ideal client
Operations, sales, or finance teams whose CRM records the outcome of a process that still runs largely on human memory.
What this covers
- Record-triggered and screen flows
- Approval processes and escalation design
- Apex automation where declarative tooling is the wrong fit
- Notification and alerting design
- Reports and dashboards covering the automated process
Approach
- 01Document the process as it actually runs, including the undocumented workarounds.
- 02Separate what genuinely needs a human decision from what only needs a rule.
- 03Automate declaratively where a Flow is sufficient and legible to an admin.
- 04Move to Apex where the logic is complex, high-volume, or needs real tests.
- 05Make every automated action traceable after the fact.
Deliverables
- Record-triggered flows and approval processes
- Apex automation where declarative tooling is the wrong fit
- Notification and escalation design
- Process documentation reflecting the automated state
- Reports and dashboards covering the process
What to expect
- Fewer manual handoffs and less duplicate data entry
- An audit trail on decisions that previously lived in inboxes
- Automation an internal admin can understand and adjust
Solution Architecture
Decide the shape before committing the budget.
The design work that happens before a delivery team starts: data model, integration landscape, security model, and the decisions recorded with their trade-offs. The cheapest place to find a structural problem is here.
The problem
A programme is about to be built on assumptions nobody has written down. The data model came from the first requirement discussed, the integration approach was chosen by whoever built the first interface, and the cost of those decisions will land in eighteen months.
Ideal client
A CTO, technical director, or programme owner at the start of a significant Salesforce build, or facing a rebuild of something that has stopped scaling.
What this covers
- Data modelling — objects, relationships, and the reasoning behind each
- Integration landscape and system context design
- Declarative versus programmatic decisions, recorded with rationale
- Security and sharing model design
- Large data volume and scalability planning
- Architecture decision records and phased delivery planning
Approach
- 01Start from the operational decisions the system exists to support.
- 02Model the data to describe the business, not to mirror the current screens.
- 03Identify which logic must be deterministic and auditable, and place it accordingly.
- 04Decide declarative versus programmatic per requirement, with the reason recorded.
- 05Write down the trade-offs taken and what would justify revisiting them.
Deliverables
- Data model with objects, relationships, and the reasoning behind each
- System context and integration landscape diagram
- Architecture decision records covering options, choice, and trade-off
- Security and sharing model design
- Phased delivery plan with dependencies made explicit
What to expect
- A design a delivery team can build against without re-litigating basics
- Decisions recorded with their trade-offs, so future changes are informed
- Structural problems found while they are still cheap to fix
Production Support & Optimisation
Find the actual constraint, then fix it.
Work on an org that is already live and carrying load — diagnosing what is genuinely slow or failing, fixing it at the cause rather than moving it to a queue, and closing the gap between what the platform was bought to do and what it currently does.
The problem
Pages take too long, batch jobs miss their window, or the org is hitting governor limits under normal load. Elsewhere the implementation is live but underused — adoption is low, data quality is poor, and the reports leadership needs are rebuilt by hand each month. Nothing is broken enough to escalate, and nothing works well enough to rely on.
Ideal client
Organisations with real data volume where slowness or limit failures have become an operational constraint, or teams one to three years past go-live operating well below what the platform was bought to do.
What this covers
- Production incident diagnosis and resolution
- Query, SOQL, and data-access optimisation
- Governor limit and large data volume remediation
- Consolidating automation that has accumulated in layers
- Data quality fixes at the point of entry
- Before-and-after measurement, and monitoring so regressions surface
Approach
- 01Measure first — debug logs, event monitoring, query plans — and find the real constraint.
- 02Fix the query and data-access pattern before touching architecture.
- 03Review indexing, selectivity, and skew on large objects.
- 04Reduce the work done per transaction rather than moving it to a queue.
- 05Look at what users actually do, including the workarounds outside the system.
- 06Re-measure and record the before-and-after.
Deliverables
- Performance analysis with the measured bottleneck identified
- Optimised queries, Apex, and component data flow
- Large data volume recommendations, including indexing and archival
- Consolidated and documented automation
- Reports and dashboards aligned to the decisions being made
- Before-and-after measurements, and monitoring recommendations
What to expect
- The genuine bottleneck identified and addressed
- Measured improvement rather than a claimed one
- Fewer workarounds outside the system
- A monitoring baseline to detect the next regression
Technical Consulting
A senior second opinion, written down.
Advisory work where the deliverable is a judgement rather than code: what is actually in the org you inherited, whether the work being delivered is sound, and whether Salesforce should own the requirement at all — including when the answer is that it should not.
The problem
You have taken ownership of an org — through a new role, an acquisition, or a departing implementation partner — and nobody can tell you what is in it or what is load-bearing. Or work is being delivered by a partner with nobody senior enough to review it, so quality is taken on trust and problems are found in production.
Ideal client
A new technical owner, an acquiring organisation, a team outsourcing Salesforce delivery, or a founder who needs a technical opinion that is not incentivised toward the largest possible build.
What this covers
- Architecture reviews against explicit criteria
- Org assessments — inventory, technical debt, single points of failure
- Code review with findings by severity, defect separated from preference
- Build / configure / buy recommendations with reasoning
- Best-practice and coding-standard definition
- Solution planning and scoped options with relative effort
Approach
- 01Inventory the org: objects, automation, integrations, custom code, technical debt.
- 02Trace the critical business processes end to end through the metadata.
- 03Review against explicit criteria: correctness, security, limits, testability, maintainability.
- 04Read the tests as carefully as the implementation — coverage is not proof.
- 05Separate genuine defects from stylistic preference, and say which is which.
- 06Rank findings by business risk, not by how easy they are to fix.
- 07Say plainly when a requirement is not worth what it will cost to build.
Deliverables
- Written assessment with findings ranked by risk and severity
- Current-state architecture and integration map
- Technical debt register with estimated effort per item
- Security, sharing, and test-quality assessment
- Build / configure / buy recommendation with reasoning
- Prioritised remediation roadmap and a walkthrough session
What to expect
- A factual picture of the current state, including the uncomfortable parts
- Risks named and ranked before they become incidents
- Defects found before release rather than after
- A recommendation that includes what not to build
Working together
How to start, and what I will tell you before you commit
The first conversation is diagnostic, not a pitch. If the honest answer is that you do not need me, or that a smaller piece of work would solve it, that is what you will hear.
Engagement shapes
- Fixed-scope project
- A defined integration, build, or assessment with agreed deliverables and a written handover.
- Ongoing development capacity
- Senior development against your backlog, working within your team’s process and review standards.
- Advisory / architecture review
- Short, focused engagements on a decision, a design, or an inherited org.
- Permanent roles
- Open to senior Salesforce positions where integration and solution design are central.