A demo shows you the product on its best day, driven by the person who knows it best, along the one path that always works. It is a performance, and it is supposed to be. The problem is that most buyers form their opinion of a vendor during that performance — and then discover the ordinary days after the contract is signed.
The short version: before you sit through a single demo, a vendor's public record will tell you most of what the demo is designed not to. The changelog, the status page, the pricing page, the documentation, and the public support surface are all written for existing customers, not for you — which is exactly why they are harder to stage. Learning to read them takes about twenty minutes per vendor, and it will quietly remove a third of most shortlists.
Why the outside read beats the demo
Everything a vendor shows a prospect is curated. Everything a vendor maintains for its existing customers is a habit. Habits are the honest signal, because keeping them up is expensive: a changelog only stays current if the team actually ships, a status page only stays honest if the culture tolerates admitting failure, and documentation only stays deep if someone is paid to care about the customer who is already in.
None of these pages will tell you whether the product fits your workflow — that is what a structured trial is for, and how to run a software trial that actually tells you something covers that stage. The outside read answers a different question: what kind of company will I be dealing with in month eight? That question is nearly impossible to answer from inside a sales process, and nearly impossible to hide from outside it.
Start with the changelog
The release history is the closest thing to a vendor's pulse you can take without permission. Find it — it may be called a changelog, release notes, or "what's new" — and read backwards through several months. You are looking at three things:
- Cadence. Regular entries, at whatever rhythm, mean a team that ships. A gap of many months, or a log that visibly stopped, means the product you are evaluating may already be in maintenance mode — you would be buying the past, not the future.
- Substance. Entries that name real capabilities and real fixes signal an engineering-led log. A log that reads like a marketing feed — vague "improvements and bug fixes", every entry a launch announcement — signals that the log exists for appearances.
- Direction. Are recent releases deepening the core product, or bolting trendy features onto it? A vendor pouring everything into a fashionable add-on while core requests sit still is telling you where its attention will be when you need something unglamorous fixed. If the trendy layer is what is being sold hardest, how to evaluate the AI features in business software is the companion piece.
This is the same discipline you would apply to checking whether a WordPress plugin is still maintained, scaled up to a company: recency, substance, and responsiveness — visible in public, or absent from it.
The status page tells you how they handle bad days
A public status page is a commitment: the vendor has agreed, in advance, to admit its failures in writing. Read the incident history, not the current state.
A credible history contains incidents — because every real system has them — described specifically, updated during the outage, and closed with an explanation of what happened. That pattern tells you that when your Tuesday goes wrong, you will know what is happening and roughly when it will end.
A suspicious history is one of two things: no status page at all, which at any meaningful company size means outages are handled by silence; or a page that has apparently never recorded a problem, which usually means incidents are logged somewhere customers cannot see. Perfect uptime is not the tell people think it is. Honest imperfection is.
The pricing page predicts the relationship
What a pricing page hides is more informative than what it shows.
- Published prices with published limits — seats, contacts, usage caps, feature gates stated per tier — signal a vendor comfortable being compared. You can model your cost at twice your current size before ever speaking to anyone. That modelling matters, because the tier mechanics decide how the bill grows as you do.
- "Contact sales" on every tier predicts negotiated pricing, annual contracts, and a renewal conversation where the price is whatever the account manager believes you will bear. That is not automatically wrong — genuinely complex products price this way — but it belongs at the enterprise end. On a product aimed at small teams, a hidden price is a strategy, and you are on the receiving end of it.
- The tier boundaries themselves are a roadmap of future friction. Look for which capability is held back until the expensive tier: if a thing you consider basic — exports, permissions, an API — sits two tiers above the plan you can afford, you have found the upsell lever that will be applied to you later.
Documentation shows who the vendor writes for
Open the docs and ignore the getting-started guide — every vendor polishes that. Go looking for the unprofitable pages instead: migration guides, export instructions, the troubleshooting section, the edge cases. Then look at the page that documents leaving — how to get your data out, in what format, and what happens to it after you cancel.
A vendor that documents its exits is confident you will stay. A vendor whose documentation gets vague exactly where a departing customer would need it is telling you what the exit will feel like. Depth on the hard paths is expensive to write and worthless for marketing, which is precisely why it is such a reliable signal that the company invests in customers it has already won.
The support surface is visible before you are a customer
You cannot file a ticket yet, but you can usually watch other people's. A public community, forum, or Q&A space shows you three things no sales conversation will: what actually breaks, how long customers wait, and who answers. Threads answered by staff, in reasonable time, with real fixes, are a good sign. Pages of unanswered questions are the support experience you are about to buy. And note the tone of the hardest threads — how a company behaves toward a frustrated customer in public is the ceiling of how it will behave toward you in private.
No public community at all is not damning on its own — plenty of solid vendors support privately. It just means this signal is unavailable and the others have to carry more weight.
Weighting the silences
Not every absence is a warning, and the outside read goes wrong when every missing page becomes a disqualifier. Size and stage set the fair standard:
- A small, young vendor may reasonably lack a community and a formal status page. It may not reasonably lack a changelog — shipping is the one thing a young product must visibly do.
- An established vendor at scale gets no such allowance. At that size, a missing status page or an unfindable exit path is a choice, and the choice is information.
- One weak signal is a question to raise during the trial. Several weak signals pointing the same way — stale changelog, spotless status page, hidden pricing — are a pattern, and patterns from the outside rarely improve on the inside.
The twenty-minute outside check
Run this per vendor, before any demo, and keep notes so the shortlist decisions have reasons attached:
- Changelog — find it; read several months back; note cadence, substance, direction.
- Status page — find it; read the incident history; note whether failure is admitted and explained.
- Pricing page — note what is published, what is gated behind sales, and which capability is held hostage by tier.
- Docs — look up migration, export, and cancellation; rate how honest the hard paths are.
- Public support — skim recent threads; note response time, who answers, and the tone under pressure.
- Verdict — advance, advance-with-questions, or drop. A vendor that fails the outside read has not earned a slot in your trial calendar.
The check slots in ahead of everything in the criteria-first framework for choosing business software: criteria first, outside read second, and only then demos and trials for the vendors still standing.
FAQ
Can a good product come from a vendor that fails the outside check? Yes — and it usually fails you anyway. A strong product behind silent outages, drifting prices, and absent support delivers a weak outcome, because you buy the relationship along with the product. The product is what you trial; the vendor is what you live with.
Is "contact sales" pricing always a red flag? No. For genuinely complex, high-touch products it is normal. It becomes a tell when a product positioned for small teams hides its price anyway — that mismatch between the marketing and the pricing model is the signal, not the model itself.
What if the vendor is too new to have a track record? Then judge the signals a young company can control: a live changelog, honest docs, and responsive public behaviour. Youth excuses a thin record; it does not excuse a curated one.
Does a spotless status page really count against a vendor? A page with no incidents over a long period should raise an eyebrow, not close the file. Ask directly during the trial how the last outage was communicated. A specific answer resolves the doubt; a vague one confirms it.
How many vendors should survive the outside check? Enough to trial properly — usually two or three. The check's job is not to pick the winner; it is to make sure the trials you invest real weeks in are spent on companies that behave well when nobody is selling to them.
The demo is the vendor's best day; the public record is its average one, and you are buying the average. Read the changelog, the status page, the pricing mechanics, the hard paths in the docs, and the support surface before you give anyone an hour of your calendar — then take the survivors to Nexuswoot and compare them side by side against sourced, scored criteria. (Disclosure: Nexuswoot may earn a commission from some of the tools it compares; rankings follow the published criteria, not payouts.)
