Engagements

The work, and how it actually goes

Sixteen engagements I take on regularly — what the situation usually looks like, how I'd approach it, and the part that tends to cause trouble. A few include the case for not doing the project at all, because that's sometimes the right answer.

These describe project types rather than specific clients. The patterns, constraints and failure modes come from a decade of enterprise architecture work; client engagements themselves stay confidential. On a call I can go considerably deeper on anything relevant to your situation.

Commerce & Integration
B2B suppliers selling into large enterprises· 6–10 weeks elapsed, less than half of it build

Punchout, so enterprise buyers can order without leaving their procurement system

The situation

A large customer says they can only buy through Ariba or Coupa, and procurement will not raise manual purchase orders. Without punchout the account either does not open or quietly shrinks to whatever can be bought off-contract. Someone forwards a copy of the cXML specification and it looks like a fortnight of work.

How I'd approach it

Three flows, not one. The setup request arrives server to server and is authenticated on a shared secret; the buyer then shops in your catalogue under an identity derived from that request; the cart returns as a form post through their browser. Separately — and this is the part that gets missed — the actual purchase order arrives later as a cXML OrderRequest once their internal approval clears. Buyer-specific contract pricing and catalogue restriction usually need building too, because a storefront written for public retail pricing cannot express either.

What usually bites

The edit operation. Buyers reopen requisitions to change them, and the setup request comes back carrying the previously returned lines. Rebuilding that cart from current prices rather than the prices originally quoted produces a silently different requisition and breaks the buyer’s approval trail. It is almost never caught before joint UAT, which is the most expensive place to find it.

What I'd cut first

Live inventory in the punchout catalogue. Approval takes days regardless, so stock at requisition time is not the number that matters, and the dependency buys nothing. Handle availability when the order actually arrives.

When I'd tell you not to

If one customer is asking and the contract is small, a hosted catalogue file may satisfy them for a fraction of the effort. Punchout earns its cost when several enterprise buyers want it, or when the account is large enough that procurement friction is costing real revenue.

cXML.NETAriba / CoupaAzure App ServiceAzure SQLApplication Insights
Commerce & Integration
Multi-tenant B2B commerce, wholesale, distribution· 12–16 weeks

Modernizing a multi-tenant commerce platform while it keeps trading

The situation

A platform serving many customers from one codebase, running on .NET Framework with a front end nobody wants to touch. It works, it earns, and it cannot be paused. Integrations have accumulated around it — payment gateways, identity, procurement, a handful of third-party APIs of varying quality — and each one is a reason the rewrite everyone keeps proposing never starts.

How I'd approach it

Move in slices, with the integration boundaries as the seams. Retarget to .NET and lift configuration and secrets out of the codebase first, then replace the front end area by area in Angular behind the existing routes so tenants migrate a screen at a time rather than overnight. Tenant isolation gets revisited deliberately during this — it is the one thing that is far cheaper to correct mid-modernization than after — and identity moves to OAuth with the older mechanism running alongside until traffic has actually shifted.

What usually bites

Tenant-specific behaviour that was never designed, only accumulated. Conditional logic keyed on a customer identifier, a config flag that one tenant depends on, a report only one account uses. Every such branch is a migration risk and none of them are documented. Finding them is discovery work that belongs in the estimate rather than in week six.

What I'd cut first

Redesigning the UI while re-platforming it. Port the screens as they are, get tenants onto the new stack, then improve the interface as a separate piece of work — otherwise every rendering difference becomes an argument about whether it is a bug or the new design.

.NETAngularOAuth / OIDCAzure App ServiceAzure SQLAzure Front Door

What drives the number

Why two similar projects quote differently

Four variables account for most of the difference. Understanding them is also how you reduce the number — several are things you control.

How many systems have to talk

One system in, one system out is straightforward. Each additional integration adds its own auth, its own failure modes, and its own vendor documentation of variable quality. This is the single biggest driver on most projects.

The state of the data

Clean, consistently structured source data makes a build predictable. Twelve years of inconsistent records, duplicate masters and undocumented columns turns a five-week project into an eight-week one — and that work happens whether or not it was scoped.

Which decisions are already made

If your team already agrees what an active customer is, or how a sync conflict resolves, the build starts immediately. If not, that agreement has to be reached first, and it needs a decision-maker rather than an engineer.

Who takes it over

Handing to an internal team who will maintain it is cheaper than building something that has to run untouched for two years. The latter needs more documentation, more defensive handling, and more thought about the failure modes nobody will be watching for.

I quote a fixed price after the mapping session, not before. An estimate given without seeing your systems is a guess with a margin baked in for being wrong, and you end up paying for that margin whether or not it was needed. Indicative starting points for each type of engagement are on the pricing page.

The engagement model

Four phases, no surprises

Same shape whether it's a three-week automation or a fourteen-week application build. Each phase has a defined output you can hold me to.

01

Map the actual problem

A working session on your process — where time goes, where errors creep in, what a fix is worth. You leave with a written opportunity map whether or not we go further.

→Opportunity map + rough effort estimate
02

Scope one narrow thing

One workflow, one measurable outcome, fixed price. Deliberately small — a scope you can judge in weeks beats a roadmap you have to take on faith.

→Fixed-price proposal + success metric agreed upfront
03

Build in the open

Weekly working software, not status decks. You see the real thing in your own environment and redirect while it's still cheap to redirect.

→Working system in production, deployed to your infra
04

Hand over properly

Documentation, a walkthrough with your team, and source in your repository. You are never locked into me — that constraint keeps the work honest.

→Docs, handover session, full source ownership

What you own at the end

Full source code in your own repository. Infrastructure in your own cloud account, under your billing. Documentation written for the next engineer, not for me. No proprietary runtime, no per-seat licence, no dependency on my continued involvement.

If you want ongoing support afterwards, that's a separate conversation — never a condition of the build.

Recognise your situation in one of these?

The mapping session is free and yields something useful even if we never work together.

Book a Free Consultation