Part of our series: The People Behind the Research
Gaugius publishes more than 12,000 industry reports across over 120 industries, alongside software Best Lists built around a question most comparisons skip: will the company behind this tool still be a good partner in three years?
Niamh, you're the Research Lead, and your background is demography. That's not the usual route into software research.
Niamh Norwood: It's closer than people think. I have a Master's in Demography and a Bachelor's in Sociology, and I spent five years as a demographic researcher at an independent population studies advisory firm in Brussels before working freelance as a demographic analyst. Demography is fundamentally the study of who arrives, who survives and who leaves. Software markets behave the same way. Every year a cohort of vendors enters a category; some get acquired, some quietly stop shipping, some grow into the incumbents. When a buyer signs a three-year contract, they are making a bet on survival, whether they think of it that way or not. At Gaugius I still cover demographic trends, migration statistics and urbanization data, but as Research Lead I'm responsible for how we assess vendors, and that assessment is basically a survival analysis done with documents instead of census tables.
Ebba, you're the analyst on many of the Best Lists, and your own field is construction economics. How does that translate?
Ebba Mäkinen: In construction, nobody judges a building on opening day. I hold a Master's in Civil Engineering and a Bachelor's in Economics, and I spent six years as a construction researcher at an independent infrastructure advisory firm in Boston. A lot of that work was about the gap between what something costs to build and what it costs to own over decades: maintenance, materials that age badly, contractors who are no longer around when the warranty claim comes in. Software has exactly the same gap. The demo shows the building on opening day. Our job is to look at the maintenance record. At Gaugius I report on construction economics, building materials pricing and infrastructure pipelines, and on the Best Lists I'm the one asking whether the vendor's documentation and release history support what the product page says.
Ama, you cover cybersecurity, where vendor stability is a security issue in itself.
Ama Owusu: Exactly. A security product that stops being maintained isn't just inconvenient; it becomes a liability. I have a Master's in Cybersecurity and a Bachelor's in Computer Science, and I spent five years as a cybersecurity researcher at an independent information security advisory firm in Buenos Aires before freelancing as a cybersecurity analyst. Security is also one of the most consolidation-heavy markets in software. Products get acquired, folded into platforms, renamed, and sometimes put on a slow path to end-of-life. If you only read the feature list, you miss all of that. At Gaugius I cover cybersecurity markets, threat intelligence and enterprise risk management, and I spend a lot of time on release histories and support policies, because that is where a vendor's real commitment to a product shows up.
Kajsa, your beat is marketing technology. What's the vendor question there?
Kajsa Halonen: Leaving. I have a Master's in Marketing Analytics and a Bachelor's in Statistics, and I spent five years as a marketing technology researcher at an independent martech advisory firm in Budapest, then worked freelance. CRM platforms, marketing automation, customer data platforms: these systems end up holding a company's entire customer history. Buyers spend weeks comparing features to get in and almost no time asking how they would get out. So when I assess a vendor, the migration path matters as much as the onboarding: what can be exported, in what format, and what you lose along the way. A tool that is easy to adopt and hard to leave is a different proposition from one that is easy on both ends.
---
What does "vendor-level assessment" actually cover?
Niamh: Four things on top of features and usability. Vendor stability and track record: how long the company and the product have been around, and what has happened to them. Support quality: which support tiers exist, what the SLAs say, and what you actually get at the price you pay. Release cadence and roadmap: whether the product is visibly maintained. And the migration path in and out. Those four decide whether a tool is still the right choice three years after you buy it.
Ebba: And we name maturity risks plainly. If a product is young, or the release history has gone quiet, we say so. It's not a judgement on the product's quality; it's information a buyer needs before signing a multi-year commitment.
Ama: The point is to describe the risk, not to punish newcomers. Plenty of the best tools in a category are young. A buyer just deserves to know they are accepting that risk.
Walk us through how a Best List gets checked.
Ebba: It starts with a shortlist: an analyst writes down which products the page will compare. Then a source pass collects the vendor documentation and the changelog for each product. AI is genuinely useful there because it is fast at retrieving and organising large amounts of documentation, but it doesn't make the judgement. Then analysts read each claim on the page next to those documents. If the page says a product supports something, the documentation or the changelog has to show it.
Kajsa: Independent reviews only come in when the review itself is the thing being cited. We don't use reviews as a substitute for checking the documentation.
Niamh: On a statistics report, the equivalent is retrieving the original publication and listing each figure next to the section it was printed in. That sounds tedious, and it is. It's also how you catch a percentage that was correct in the original and wrong three citations later.
Ama: Every claim then gets a band. "Documentation-backed" means we matched it in the vendor documentation or the changelog, or, for a statistic, in the original publication. "Thinner dates" means the documents agree in direction but the dating is weaker. "Single document" means only one document has been opened so far, and the changelog or an independent review is still missing. Readers can see exactly how much support sits behind a line.
Why do you put so much weight on changelogs?
Ama: Because a changelog is the closest thing software has to a maintenance record. Marketing pages describe intentions. Changelogs describe what actually shipped and when. A product with a steady release history is telling you something real about the company behind it.
Kajsa: It's also where you find what vendors don't put on the homepage: deprecated features, changed limits, an API version that is being retired. Those are exactly the details that matter when you're planning a migration.
---
Gaugius also publishes vendor-funded studies. How do you keep funding from shaping the results?
Niamh: By deciding everything that matters before anyone knows who will come out well. Vendors fund our studies because they want rigorous, comparable research on their market to exist. Each study is co-funded by several of the vendors it assesses; no single vendor ever funds one. Funders may propose the market to be studied, and that is the full extent of their role. They don't choose which vendors are included, they don't set or weight criteria, and they don't approve findings.
Ebba: Before research begins, an editor fixes the market definition, the inclusion rules that determine the vendor set, and the evaluation criteria and their weights. That protocol is published with the study and doesn't change once research has started.
Kajsa: Equal treatment is the part I care most about. Every vendor in scope, funder or not, is assessed against the same criteria and offered the same factual-accuracy check on its own products before publication. And the bar for changes is the one we use everywhere: we change something only where documentation supports it. A vendor saying "that's not right" isn't enough. A vendor showing us the documentation is.
Ama: What vendors can't do is review findings, scores or statements about other vendors. Every completed study is published as found, labelled as vendor-funded at the top of the page, with a funding statement in its methodology. Studies go through the same pipeline, source checks and exclusion rules as everything else, but they are kept apart from the rest of our work: they are never cited as evidence in our statistics reports or Best Lists, and they have no effect on rankings.
---
What's the most common mistake you see buyers make?
Kajsa: Treating onboarding as the whole decision. The exit costs are where the surprises are.
Ama: Treating a funding announcement as proof of stability. Money raised tells you a company can spend. It doesn't tell you it will keep maintaining the product you bought.
Ebba: Comparing products at a single point in time. Two tools can look identical today and be heading in completely different directions. The release history usually tells you which way.
Niamh: Reading a roadmap as a commitment. A roadmap is a statement of intent. We treat it as context, never as evidence.
Last question: what should readers understand about Gaugius?
Ebba: That we're trying to answer the question buyers ask a year after the purchase, not the one they ask in the demo.
Ama: That "documentation-backed" means someone actually opened the documentation. It's a short phrase with a lot of reading behind it.
Kajsa: That we take the unglamorous parts of a vendor seriously, such as support tiers, export formats and deprecation notices, because that's where most of the real cost lives.
Niamh: That a recommendation is a forecast. We try to base it on the best evidence available about how a vendor has behaved over time, and to be honest about how much evidence there is.
---
Gaugius.com publishes more than 12,000 free research reports and software Best Lists across over 120 industries. Explore the library at gaugius.com/topics/ and read the full methodology at gaugius.com/editorial-process/.