ISLANDandMAIN
Todd VanHouten todd@islandandmain.com
Several brands.
The same job, done
four different ways.
I map what you actually have, decide what it should be, and set the order to get there, then stay while it gets built.
One job, several ways to do it
Taking an order
Hosted cart Custom cart Payment links
One cart
Customer record
CRM ERP contacts Spreadsheet
One record
Fulfillment handoff
Nightly export Re-keyed by hand
One integration
Reporting
BI tool Exports Nothing
One source
Nobody chose this. Each brand solved the same problem on its own, and the count is what it costs to run four answers instead of one.
The situation
Companies that grew by acquisition end up with several websites, several ways to take an order, and the same job done differently in every brand. Nothing is broken. It just doesn't add up to one business.
Sometimes the platform decision is already made and the question is purely how to get there. Sometimes making that call is the first thing I am here for. Either way the work is the same: what you have, what it should be, in what order, and what has to be true underneath before anyone builds. The first deliverable is a plan, not a system.
Who this is for
PE-backed portfolio companies consolidating technology across acquired companies. Usually the portfolio CTO, sometimes the firm's operating partner.
Multi-brand organizations on fragmented systems, whoever owns them: franchise groups, associations, multi-campus institutions, family holding companies.
The through-line is multiplicity, not ownership structure. Two brands doing checkout two different ways is the problem, whether a firm bought them or one company grew them.
What the work is
Every plan is made of four moves. They are never a menu.
01
Connect
Integrate systems that grew up separately and were never meant to talk.
02
Consolidate
Several systems doing one job, reduced to one of them. Not replacement: nothing new is bought; what is already there absorbs the rest.
03
Replace
A new system stands up, the old one retires, and a transition plan carries the business between them.
04
Introduce
A capability that does not exist yet, designed to be connected from the start.
How they pair
Introducing and connecting always happen together. Replacing and consolidating usually do. Consolidation is more often the reason for a project than an action in it. The redundant systems fall away as you add and connect.
A client who believes they are just replacing the cart is describing one move out of four that are already in play. Seeing all four, and the order they have to happen in, is the service.
What you engage me for
Discovery and system mapping
What you actually have, how it connects, where the same job is being done three different ways, and what that costs you.
Architecture and sequencing
The target state and the order to get there, sequenced against your own priorities. Platform and vendor selection lives here, and so does build versus buy.
Technical representation through delivery
I hold the architecture and the decisions while your team or a partner builds. Optional, and described below.
Pre-acquisition technical due diligence
A read on a target's stack before the deal closes: what you are buying, what it will cost to fold in, and what you would have to retire.
Discovery
Not a canned report. Depth is a sliding scale, and we set it together.
Assess and recommend
Platform direction, build vs buy, how it should fit together
Specify to build against
Services, contracts between them, integration detail for a team
Sizing
Each engagement is bounded differently. Duration follows scope, deliberately. There is no standard length, because your technical maturity, legacy systems, budget and priorities are not standard.
Fees
Fixed fee for discovery, so you are buying a bounded thing. Time and materials where that genuinely fits better. Representation through delivery is a monthly retainer.
What you get, and when
A written document you keep, plus a working session where I walk it with your people. It ideally ends with a scope of work for the next phase.
These are what a discovery produces. Which ones it produces, and how far each is taken, follows the scope. The last two are deep-end work and earn their place only when the plan calls for them.
Current-state map
Scoped to what the project touches, usually only as detailed as the systems connected or adjacent to what we are adding or improving. You are not billed to map systems the work will never reach.
Always
Target-state architecture
What it should be, at the level of detail the decision in front of you requires.
Always
Sequenced plan
The order to do things in, ordered against your own priorities, usually the relative revenue of each brand.
Always
Findings and recommendations
Build versus buy, platform calls, and what to stop doing.
Always
Transition and retirement plan
How the business gets from one system to the next without a gap.
Deep end
Service-level specification
The services, the contracts between them, and integration detail a team can build against.
Deep end
Through delivery
If you want it, I stay on as the technical owner while the build runs.
This is not project management. Nobody needs another schedule-keeper. It is representation of the business inside the delivery: the person in the room who knows what was decided and why, so that when a tradeoff comes up mid-build it gets made intelligently instead of expediently.
I hold the architecture, the sequencing, and the decisions as they meet reality. Accountable for the outcome, not reselling resources.
If your in-house team is thin, I bring in design and build partners I have worked with and brief them against the architecture. They are subcontracted to deliver it, and I stay accountable for what they deliver.
Retainer Monthly, and only for as long as it is useful
Todd VanHouten
Twenty years building the systems I now plan.
Two ecommerce and custom software agencies, then enterprise system transitions through five acquisitions and mergers. I have been on both sides of the table: twice as the acquirer folding a company in, three times as the company being folded.
Commerce systems mostly, but also apps, portals, utilities and automations. I am not theorising about post-acquisition integration; I have lived it from the inside while it was happening to me.
One I drove
An education company acquired another education company. I was the primary driver of folding it into every business system: a second commerce site stood up alongside the first, and the ERP integrations consolidated behind both. Introduce, connect and consolidate, all at once.
Why the recommendation is worth paying for
Twelve years of making build versus buy versus open source calls, daily, for companies across many industries. The point of all of it is that somebody's job gets easier. A system map is not the outcome; a person no longer re-keying the same order into two systems is the outcome.
Start with a conversation
todd@islandandmain.com
ISLANDandMAIN
Charted before it's built.