How Blastra reads reviews

A reading of what buyers have already written about software, in public, on the review platforms where those buyers go. Blastra does not run its own review programme, does not survey anyone, and does not accept vendor-supplied data about a product. Every input is text a member of the public can go and read, and every platform that contributes to a reading is linked from the product it belongs to.

What Blastra adds is the reading. What reviewers wrote already exists; a reading of it across platforms, resolved onto seven named aspect bands, does not. The position on the board is a separate synthesis, of rating and review volume.

Every product is profiled on the same seven aspects, in the same order. Their initials spell BLASTRA, which is how the star is laid out: one ray per aspect, always in this sequence, so the same shape means the same thing on every product in every category.

• Broad: Whether the product delivers the scope it SELLS, at the tier a buyer can actually reach. This is claim-relative on purpose: a deliberately narrow tool that positions narrow and delivers narrow is Confirmed, while a suite that sells everything and gates half of it behind a higher tier is not. Capability you cannot reach does not count, which is why a large product can read Mixed and a small one Confirmed.
• Learnable: How quickly a team gets productive, and how easily the product is handed to the next person. Complaints about configuring advanced behaviour are read separately from complaints about getting started.
• AI-ready: Whether the product is reachable by the AI tools a team already uses, and whether the AI it ships does real work. Read from things that are checkable rather than argued: a public API and public docs, connectors and webhooks, whether data can get out, and which tier the AI sits behind. Reviewers answer the part a vendor cannot, which is whether any of it is useful rather than decorative.
• Scalable: Whether it still works as the team and the data grow. Read from what buyers report about performance at volume, and about what happened when they outgrew the plan they started on.
• Tunable: How far the product bends to the way a team already works: custom objects and fields, workflow, and layouts. Configurability only. What carries work in and out of the product is read under AI-ready, because that is what makes a product reachable.
• Reliable: Whether the product can be depended on, by machine and by person: it stays up and keeps the data intact, and when something does go wrong a human helps in time. Support is read here rather than as its own aspect, so a vendor whose help does not arrive is not depended upon whatever its uptime says. Scored differently from the others, for the reason set out below.
• Affordable: What the product costs relative to what it does, as the buyer meets it. Published tiers are the vendor claim; whether buyers experience the cost as fair, surprising or escalating is the check. Billing surprises and charges that were not expected are read here, because an unexpected charge is a cost whatever else it also is.

Each aspect resolves to one of four bands: Confirmed, Mixed, Pushback, or No signal. They are bands and not numbers on purpose, and the difference is not cosmetic. A band is a claim we can defend against the evidence; a number implies a precision the evidence does not carry.

Every band answers one question, and it is not whether the product is good. It asks whether the vendor's own account of itself survives contact with what buyers wrote on platforms the vendor does not control. The claim comes from the vendor's published pages, and the check comes from the reviews.

Confirmed means reviewers bear the claim out, consistently rather than merely warmly. Mixed means some bear it out and some report otherwise, which is a finding in itself and not a failure to decide. Pushback means buyers report something other than what the vendor presents. It is not a verdict that the product is bad, and a product can meet pushback on a claim it should probably not have made while being perfectly good at the thing it does. No signal means we have not read enough to say, and it is a statement about our evidence, never about the product.

A remark counts for or against a claim according to where the reviewer filed it, not according to how warm the wording sounds read alone. And a reviewer who raises the same point repeatedly counts once, so a claim is weighed by how many buyers raise it and not by how emphatically any one of them does.

Two aspects are read against silence instead of volume, because nobody writes a review to say they were billed what they were quoted or that the software stayed up. Where a vendor publishes a clear claim and a substantial body of buyers raises nothing against it, that is Confirmed. Where the corpus is too thin for an absence to mean anything, it is not.

Reliable is the one aspect nobody writes a review to praise. Buyers enthuse about features and damn a support team, but almost no one posts to say the software stayed up. They post when it did not. Scoring it on the balance of praise against complaint therefore measures how loudly a category talks about uptime, not whether anything can be depended on, and it returns No signal almost everywhere.

So it is read from two things instead: the vendor's own status page, which is a dated artifact they publish and we did not write, and whether buyers reach for outages, data loss or performance. A product whose status page reports a healthy period, with no buyer raising an outage, is Confirmed and not simply unread. Where a status page could not be read, that is our limitation and is said as such; where a vendor publishes none at all, that is a fact about the vendor and is said as that instead. The two are never scored the same way.

Reliable also covers whether help arrives. A product you cannot depend on because nobody answers is not dependable, whatever its uptime says, so support is read here and not as an aspect of its own. This makes the reading heavier than a separate support line would be, and it is stated here for that reason: when Reliable reads Pushback, it may be the system, it may be the help, and the sentence beside it says which.

Blastra ranks internally in order to sort the board, and does not publish that number. A composite like “78 out of 100” invites an argument it cannot win, about weights that are ultimately editorial judgement, and it flattens seven things a buyer cares about into one figure that hides all of them.

The ordering is synthesized from each product's rating and review volume on every platform the reading covers, weighted by source; it does not read sentiment, which belongs to the bands. What we publish and will defend is the ordering, which says this product stands ahead of that one with reviewers, and the seven bands, which say where each product is confirmed, mixed, met with pushback, or simply not read enough to call. The weighting behind the ordering stays internal deliberately: published weights are a specification for gaming them.

The reading covers publicly accessible reviews on independent B2B software review platforms, and each product links to its own review pages on them. We read only platforms whose terms, as we read them, permit it, and attribution is made once for the whole board and not per datapoint: the bands are synthesized from a corpus, never copied from any one listing.

Review volumes are published as rounded bands, never as a platform's exact figure. Ratings are shown on the platform's own scale, so a site scoring out of ten appears out of ten. Movement between readings is published as a direction and a rounded percentage. Directory badges and awards are not inputs, and neither is page traffic or search demand.

Blastra editorially selects roughly ten products per category that hold leadership positions across at least three of the platforms we read. The category itself is also an editorial choice and does not match any single directory's taxonomy. Where a vendor sells several products, only the listings and counts belonging to the product in that category are read.

Inclusion is not for sale. No vendor can buy a place on the board, a higher position, or a better band, and nothing a vendor pays for changes what reviewers said about it.

Beneath each ranked product there is a second lane, for newer products positioned against it. Some entries in that lane are paid placements; others are Blastra's own reading of a newer product's public positioning. Each says which.

It exists because the board is otherwise closed. A category whose median product carries thousands of reviews across nearly every platform cannot be entered by a product released last year, however good it is: reviewer standing is accumulated, and accumulation takes years. Without a second lane the Observatory would only ever describe incumbency. The lane lets a newcomer be seen beside the incumbent it is actually competing with, for one narrow case.

The rules are what keep the two lanes honest, and they are absolute:

• A paid entry is the vendor's own claim, in the vendor's words, about one narrow case where it says it wins. Blastra does not assess it, does not endorse it, and does not say it is better.
• A paid entry carries no rank, no bands and no star. It is not measured, and it is not presented as though it were.
• Money buys placement beside an incumbent. It never buys a position on the board, a band, a rank, or a change to any measured product's reading. It buys no reviews and no review activity of any kind: Blastra neither writes, solicits, incentivises nor rewards a review on any platform, for a paying vendor or anyone else.
• Where an entry is Blastra's own editorial characterization and not a paid placement, it is marked as such and the vendor has neither paid nor written it.
• A challenger that accumulates enough reviewed listings becomes eligible for the measured board at a later observation, where it is read like everything else on it. Nothing on the measured board pays to be there.

Some products on the board are Blastra customers and some are not. A product's position is set only by its standing with reviewers on the independent platforms we read. Blastra does not review its own customers and does not engage in inauthentic review gathering.

If a band, a figure or a characterization is wrong, write to ceo@blastra.io naming the product, the aspect and what the evidence actually says. Disputes about a band are resolved against the corpus, not against the vendor's positioning, and a correction that changes a reading is applied at the next observation and noted.

Readings are dated, and each category page states when it was observed, what it was measured against, and when it is next due to be read.