We will not name a platform until we know what the work is
Buy, build, or leave it alone, decided on what the thing costs to own over years. That includes the cost of getting out when a vendor changes its pricing, which is the number almost nobody puts in the comparison.
In short: We compare buying, building and doing nothing on the full cost of ownership: license, integration work, the people who keep it running, and what it would take to move off it later. The recommendation comes after we understand the process. Never before.
Choosing the platform first is the standard mistake in this market
It happens in a predictable order. Someone sees a demo. The demo is excellent, because demos are built to be excellent. A platform gets bought in January on the strength of it, and by June the team is redesigning how they work so the tool has something to do. Nobody ever writes down that the process was bent to fit the software, but that is what happened.
The order that works is dull. Understand the work first. Write down what actually has to be true: the volume, the inputs, where the output has to land, who signs off, what happens when it is wrong. Only then does a tool comparison mean anything, because you finally have something to compare against. Ask us to name a platform before that and the honest answer is that we do not know yet, which is not a satisfying thing to hear in a sales conversation and is the reason we put it on the page.
The license is the smallest line
Around it sits integration engineering, data cleanup before anything can be connected, the internal owner’s hours every week, retraining people when the vendor ships a redesign, and a seat or usage count that grows with adoption. The pricing page shows you one of those.
Switching cost, priced before you sign
Vendors change pricing. Per-seat becomes per-message, a generous tier quietly closes, a feature you depend on moves to the enterprise plan. So we ask how hard it would be to leave before you arrive: can you export your data in a form that is still useful, is the logic portable, and how much of your process only exists inside their interface.
Build only where it is yours
Building something a vendor already sells as a subscription is an expensive way to own a maintenance burden. Building makes sense in two situations: the capability is the thing you compete on, or the data cannot go to a third party for a reason a lawyer would recognize. Otherwise, buy it and spend the engineering elsewhere.
Doing nothing gets costed too
Keeping the current manual process is a real option and it belongs in the comparison with a real number next to it, including its own risks. Sometimes it wins, particularly at low volumes. A comparison that only contains things you can buy is not a decision, it is a shopping list.
How we test a vendor
On your data, with your ugly cases. Not the demo dataset, which has been curated until it behaves. We take the awkward examples the team keeps mentioning: the scanned document, the customer with two accounts under slightly different names, the request that arrives as a photograph of a handwritten note. Tools separate quickly under that kind of input, and they separate in ways no feature grid predicts.
Alongside that, we ask the questions vendors answer slowly. What happens to your data, where does it sit, how long is it kept, and is it used for training. What notice you get when the underlying model changes, and whether outputs you have tuned will still behave afterwards. What export looks like in practice, not in the contract. Whether support exists in your working hours. What happens on acquisition, which in this market is not a hypothetical.
Reference calls are worth doing, with one adjustment: ask the vendor for a customer who left, or find one yourself. Happy references tell you the product works on a good day. The company that churned tells you what it costs to run on a bad one, and that conversation is usually the most useful twenty minutes of the whole evaluation.
The answer is often a seam, not a side
Buy versus build is presented as a fork. Most of the time the right answer sits across it: buy the commodity layer, build the thin piece that is specific to you, and keep the boundary between them clean enough that either half can be replaced without touching the other.
That boundary is worth designing deliberately. Keep your prompts, rules and business logic in your own repository rather than pasted into a vendor console. Keep a copy of what goes in and what comes out, so that a future migration has something to test against. Route calls through one place you control, so swapping a provider is a configuration change and not a project. None of it is difficult. It is just easier to skip when you are excited, and it is the difference between a vendor’s price rise being annoying and being an emergency. Where the built half is substantial, that work overlaps with integration and automation.
What we won’t do
Take a referral fee or reseller margin on anything we recommend
Not from the platform, not from a cloud provider, not from an implementation partner. If we have worked with a vendor before, we tell you, because familiarity is a bias even when money is not involved. You can ask us to state our position on any tool in writing and we will.
Recommend a tool we have not run on your data
A recommendation based on documentation and a sales call is an opinion about a website. If we cannot get a trial, a sandbox or an evaluation license for a shortlisted tool, that goes in the report as a gap rather than being smoothed over with a confident paragraph.
Run a twelve-vendor bake-off
A matrix with fourteen columns looks rigorous and functions as a way to postpone the decision for another month. We shortlist three at most, and we defend the exclusions in writing so you can challenge them. If you want the long grid for a procurement process, we will say no and explain why to whoever is asking for it.
Sat through three demos and still not sure?
Tell us what the work is and what you have been shown. We will tell you what is missing from the comparison, and whether the decision is even ready to be made yet.
Not without knowing the work, and anyone who answers that question cold is selling something. The tool that suits a team handling a few hundred structured requests a week is the wrong tool for a team handling messy documents at low volume. Give us the process and we will give you a recommendation with the reasoning attached, so you can disagree with the reasoning rather than the conclusion.
Do you take commission from vendors?
No. No referral fees, no reseller margin, no partner rebates on anything we recommend. Where we have hands-on experience with a vendor we say so, because that is a bias worth naming even though no money changes hands. You are paying us for the recommendation, which is the only way it can be worth having.
We already bought something. Is this still useful?
Often more useful. The first thing we check is what you have, and a common finding is that the platform is fine and the integration around it is the problem, which is a much cheaper fix than replacing it. If the tool genuinely is wrong, we will price the move and the cost of staying, and let you compare them without the sunk cost doing the arguing.
How do you calculate total cost without knowing our volumes exactly?
We build the estimate from your own records rather than a guess, then present cost as a range with every assumption written next to it. Change the assumption and you can see the number move. That matters most for usage-based pricing, where a modest rise in adoption can move the annual bill more than the choice between two vendors does.
