Services
Work scoped around the problem, not the headcount.
We engage as technical architects on programmes that are already large enough to have gone wrong in interesting ways. Each engagement is defined by a constraint to remove or a decision to settle, and ends with the client team able to carry the work forward.
Building
New capability
Work that adds something that was not there before, or moves something that was somewhere else.
01 New implementations and custom applications Six to sixteen weeks depending on scope A new business line, product, or internal application needs building on Salesforce. The risk is not whether it can be built. It is that it gets built beside the existing org rather than within it, arriving as another silo with its own objects, its own integrations, and its own conventions. The opposite failure is as common: heavy customisation where configuration would have held, or configuration forced onto a requirement that genuinely needed code.
A build against configure assessment made explicitly and recorded, then design that reuses the existing model where reuse is right and stays separate where separation is right. Delivery is packaged, using unlocked packages where the boundary is clean, so the work can be versioned and deployed independently rather than merging into an undifferentiated org. Add-ons and extensions to existing capability are treated the same way, since the question of what belongs in the core and what belongs alongside it is the same question.
Working capability delivered incrementally, a written build against configure decision with the reasoning, and a packaging structure that keeps it maintainable after handover.
02 Migrating functionality Eight to twenty weeks depending on scope Functionality has to move. A legacy system is being retired, two orgs are being consolidated after an acquisition, Classic is finally being left behind, or a custom build is moving onto standard functionality. The difficulty is rarely the target design. It is that nobody has a reliable inventory of what the current system actually does, users have built undocumented workarounds that the migration will break, and a single cutover carries more risk than the business will accept.
Start with what is genuinely used rather than what exists, since the gap between the two is usually large and is where the schedule is won. Then a phased cutover with parallel running where the risk justifies it, data migration with reconciliation that proves the target matches the source, and a decommissioning plan for the origin system so it does not quietly stay alive for another two years.
Migrated functionality with documented parity against the original, reconciliation evidence for the data, a cutover run in stages rather than in one weekend, and a decommissioning path for the system being replaced.
Fixing and scaling
Work on what already exists
These problems recur across banking, insurance, telecoms, public sector, and maritime programmes. They are rarely caused by the feature being built at the time.
03 Architecture review and rescue Two to four weeks The org has accumulated years of decisions made under delivery pressure. Automation overlaps, ownership is unclear, and no single person can predict the effect of a change. Estimates have become unreliable and confidence has gone.
A structured read of the org, its integrations, the delivery process, and the backlog, followed by a ranked assessment of what is actually wrong. Findings carry effort and risk, and are sequenced so that the first items unblock the rest.
A target architecture, a prioritised remediation plan, and a written record of the decisions behind both.
04 Integration architecture Six to twelve weeks Interfaces were built one at a time to meet individual deadlines. There is no shared contract, retries are inconsistent, failures tend to reach users before monitoring reports them, and volume growth is starting to break things that used to hold.
Interfaces redesigned around explicit contracts, idempotency, replay, and observable failure. Delivery is incremental, so existing interfaces are replaced in a sequence the business can absorb rather than in a single cutover.
Documented interface contracts, a staged migration path, reference implementations, and monitoring that surfaces failure before the business does.
05 Data model and multi country scale Four to ten weeks A data model that suited the first market now constrains the next four. Sharing and visibility rules have grown to compensate, record volumes are affecting performance, and each new country requires exceptions that make the model harder still.
Assessment of the model against the operating structure it now has to serve, including sharing architecture, large data volume behaviour, and the localisation the business genuinely needs as opposed to what has accumulated.
A model that supports the current footprint, a migration approach for existing data, and a sharing design that performs at volume.
06 Duplicate records and customer identity Three to eight weeks The same customer exists several times over. Records arrived from web forms, a call centre, a marketing list, and an acquired business unit, each with a slightly different spelling. Matching rules were never tuned past the defaults, or were switched off because they blocked agents. Reporting counts the same person more than once, marketing contacts them twice, service agents work from whichever record they happened to open, and a data subject request cannot be answered with confidence because nobody can prove they found every copy.
Measure the real duplicate rate before changing anything, because the perceived rate and the actual one rarely agree. Then matching and duplicate rules tuned against your data rather than against the defaults, a survivorship policy that decides which value wins when records merge, and prevention at the point of entry so the backlog stops growing while it is being cleared. Existing duplicates are remediated in controlled batches with the merge history preserved, since a merge is destructive and an unwound merge is worse than the duplicate was. Where the problem spans systems rather than sitting inside one org, identity resolution in Data Cloud is the right layer, and we will say so rather than forcing it into the CRM.
A tuned matching ruleset with a measured false positive and false negative rate, a documented survivorship policy, remediation of the existing backlog, prevention at entry points, and a duplicate rate that can be reported on rather than guessed at.
07 Data Cloud and unified customer data Six to twelve weeks Customer data is spread across systems with no reliable identity resolution. Segmentation is approximate, activation is manual, and Data Cloud consumption cost is either unmodelled or rising faster than expected.
Ingestion, harmonisation, identity resolution, and activation designed for production conditions. Consumption cost and GDPR obligations are treated as design constraints from the outset, since retrofitting either is expensive and occasionally not possible.
A working data model with identity resolution rulesets, defined activation paths, and a cost model that holds as volume grows.
Delivery
How the work gets built
Throughput problems are usually structural. These engagements address the process rather than the backlog.
08 DevOps and release automation Four to eight weeks Several suppliers commit to the same org. Releases are manual, conflicts surface during deployment, environments have drifted apart over time, and the release window has become the constraint on delivery.
Environment and branching strategy defined first, then enforced through the pipeline. Quality gates run on every pull request. Tooling is chosen to match team size and regulatory constraints, using Gearset, Copado, AutoRabbit, or plain SFDX with GitHub Actions where a vendor tool is not justified.
A release process that multiple suppliers can follow, conflict detection before merge rather than during deployment, and a predictable cadence.
09 AI in delivery, and Agentforce where it fits Four to eight weeks There is pressure to adopt AI without a clear view of where it helps. Pilots demonstrate well and stall before production, usually on data handling, governance, or the absence of a use case that survives contact with real volume.
Separating the two cases. Agentforce is assessed for customer and agent facing automation where the topic boundaries are clear. General purpose models are applied inside the delivery pipeline, which is where the reliable gains currently are. EU data handling is settled before anything is embedded.
Working automation in the pipeline, a defensible position on data handling, and a documented view of which use cases were rejected and why.
10 Team capability Ongoing, part time Knowledge is concentrated in one or two people. Standards exist as convention rather than as anything enforced, review is inconsistent, and the same defects recur across teams.
Design review, pairing on live work, and standards written to be followed rather than filed. This runs alongside one of the engagements above rather than as a separate exercise, because capability transfers better through real work than through training.
Reviewed standards, a review practice the team maintains, and reduced dependence on any individual, including us.
11 Second opinion Two to five days A significant decision is pending. A proposed design, a vendor recommendation, a build against configure choice, or an estimate that does not feel right, and no independent view is available internally.
A focused assessment of the specific decision, with the trade offs made explicit and the assumptions tested.
A written position, including the circumstances under which the recommendation would change.
How we work
Principles that show up in the work.
Diagnosis before recommendation
Most recommendations fail because they address the symptom that was easiest to see. The first phase of any engagement is diagnosis, and we would rather report that the problem sits somewhere other than expected.
Design for the failure path
The successful path is the straightforward part. What matters is behaviour when the downstream system is slow, the payload is malformed, or a job runs twice. Systems that behave predictably under those conditions are the ones that last.
Architecture before automation
Applying automation, including AI, to a poorly structured org produces more output of the same quality. The structural work comes first, and the automation then compounds.
Decisions written down
An architecture nobody on the team understands is a liability regardless of its quality. Decisions are recorded with the reasoning, so that the next person can disagree with them on informed grounds.
Practicalities
Where do you work?
Across the EU, remote first, on site when the engagement requires it, such as kickoffs, workshops, and the periods where being in the room changes the outcome. We have delivered on the ground in nine countries.
Which languages?
English and Spanish at working level. Portuguese is sufficient for a working session. French and Catalan are basic.