You're running a stack nobody chose on purpose, and nobody can say what it costs you.
I map what you're actually running: the tools, the spend, the licenses nobody owns, and the places two systems do the same job badly. You get a written recommendation at the end.
What the assessment covers.
Three things, and they are inseparable in practice. The software you buy. The platforms that have to talk to each other. The processes sitting on top of both.
Most of what I find isn't a software problem. It's a process that grew around a tool nobody picked deliberately, which is why an assessment that only inventories licenses tells you what you spend and nothing about why. Replacing a system without changing the process around it reproduces the same problem on a new platform.
I've led custom software, CMS, and CRM implementations from first scope to live, so I know where they stall long before it shows. That is the same judgment applied earlier, before you have committed to a direction.
What you leave with.
-
Stack auditEvery tool you pay for, what it costs, who owns it, and which renewals are coming. Including the licenses nobody has looked at since the person who bought them left.
-
Process mappingHow work actually moves through those tools, as opposed to how it was designed to. This is where the redundancy shows up.
-
Cost and redundancyThe places two systems do the same job badly, and what consolidating them is worth against what it costs to do.
-
Written roadmapWhat to keep, what to cut, what to replace, and the order to do it in. A document you can act on, take to a board, or hand to whoever runs the work next.
Took a team off a platform they rented and gave them one they own outright.
An organization was paying seven figures a year to license the platform running its entire intake and assessment pipeline, matching at scale with no way to change how the matching worked. With the renewal date fixed, I led a 95-page spec, a working prototype, and a hard line on scope: only what had to exist by go-live. Six months later they were off the vendor and on a custom system built to their own rubrics and guardrails.
$1M+ a year, gone Licensing eliminated. Two weeks live, and every internal and external user is on it.Questions I get asked before this one starts.
-
What do I actually get at the end?
A written recommendation: what to keep, what to cut, what to replace, and the order to do it in. It is a document you can act on, take to a board, or hand to whoever runs the work next, not a slide deck of observations.
-
What if the problem turns out not to be the software?
That is the usual finding. Most of what an assessment turns up is not a software problem, it is a process that grew around a tool nobody picked deliberately.
The recommendation covers the process as well as the tools, because replacing a system without changing the process around it reproduces the same problem on a new platform.
-
Do you write the code, or run the implementation afterwards?
Not the code. The role is steering the team that builds it and answering for whether it ships.
An assessment often leads into running the implementation it recommends, and that is a separate engagement you decide on after you have the recommendation, not something committed to up front.
-
Is this a fixed-fee project or a retainer?
Either. Every engagement takes one of two shapes, a fixed-fee project or a defined-term retainer, and which one depends on the work rather than on which service you came in through. Either way you get a written scope and a price before anything starts.
Not sure an assessment is what you need? Say so on the call.
Thirty minutes, no pitch, no slides. We talk through what's going sideways and whether I'm the right person to help. If I'm not, I'll say so.