DEV Community: EVGENII ROMANOV

Two summaries of one pricing page, two different prices

EVGENII ROMANOV — Sun, 25 Oct 2026 01:57:24 +0000

A comparison table needed a competitor's published price. Reading about that page twice gave two answers, and the part they agreed on was the part neither page said.

A public pricing page was fetched twice to build a comparison table. The two summaries disagreed about the price, and both stated that a plan included five users. The page says every plan is for one user, with a separate per-seat fee. The figures were only correct once the page was opened in a browser and read.

What this was for

The pricing page here carries a comparison against buying a seat-priced product, and a comparison is only worth reading if the other side of it is right. That meant one number from a competitor's own published page: what a team of ten actually pays. Nothing exotic, a public page anybody can open.

Two readings, two answers

The page was fetched and summarised twice. The two summaries did not agree on the price. That alone is a reason to stop, but the worse part was where they did agree: both said the mid plan included five users. The page does not say that anywhere, in any form. An invented detail that survives two independent readings looks like corroboration, and it is the opposite.

What the page actually says

Every plan on it carries the label "1 user". The per-seat price is not in the plan cards at all; it sits in a tooltip attached to that label. So the number that decides the whole comparison is the one a summary is least likely to carry, because it is not in the part of the page that looks like the price. Opening it in a browser took two minutes.

What the arithmetic turned into

On the published annual rate, ten people on the mid plan work out to $410 a month, because the plan covers one of them and the other nine are billed per seat at $29. Under the invented rule the same team looked far cheaper, and a comparison built on it would have been wrong in the direction that flatters whoever published it.

Where the number lives now

Competitor prices are in one file with the date they were read, the seat rule quoted word for word rather than paraphrased, and the ten-seat figure computed from the plan price rather than typed. Recomputing it is the difference between a number that can be checked and a number that has to be trusted. The date is published beside it: 16 September 2026.

The rule that came out of it

A figure that will be published is read from the page it comes from, rendered, by a person or a browser. A summary of a page is evidence that the page exists and nothing else. This is the same rule already used here for databases, where a migration is verified by asking the database what it has rather than by reading the file that was meant to change it.

If you are the one buying

Ask any vendor, and any agency quoting you a comparison, for the per-seat rule in the vendor's own words and the date it was read. Both of those are cheap to give and impossible to fake usefully. A comparison table with no date on it is a claim about a page that may have changed months ago, and the person who made it usually does not know either.

Questions

Is this an argument against using AI to research prices?

No. It is an argument against publishing what it hands back. Finding the page, pulling the competitors together, laying the comparison out: all useful. The last step, where a specific figure goes into something a customer will read, is the step that has to touch the source.

Why does the per-seat rule matter so much?

Because it is the whole comparison at any real headcount. A price for one user tells you almost nothing about a crew of ten, and the difference between those two numbers is usually larger than the difference between the products. It is also the detail most often left out of a summary, because it is rarely printed beside the price.

How would I check a comparison somebody showed me?

Open the vendor's pricing page yourself and look for what the plan covers, not what it costs. If the page says one user and the table you were shown says five, the table is not describing that page. Then ask when it was read; a comparison with no date is not checkable at all.

Originally published on the Orium Studios blog: Two summaries of one pricing page, two different prices. Orium Studios is a studio in Sacramento, California, that builds websites, CRM systems and AI receptionists for US service businesses.

The analytics that classified everything and sent nothing

EVGENII ROMANOV — Sun, 25 Oct 2026 01:56:14 +0000

A week of clean code, a dashboard of zeroes, and the two reasons an empty report is the most expensive thing on a screen.

This site classified every click correctly and delivered none of them to Google Analytics. The tag loads late, and an event sent before the tag is configured is discarded without an error. A second bug hid a whole section from its own view counter. Both were invisible to the test suite, because both were true of the browser rather than of the code.

A dashboard of zeroes is not a report

The site had traffic, the pricing page had readers, and the events panel in Google Analytics had nothing in it. That is the single most misleading screen in this trade, because an empty report and a broken pipe look exactly alike, and only one of them is news. The honest reading of a zero is that you have learned nothing yet.

The first fix was real, and changed nothing

The call looked wrong. It was rewritten to the shape the documentation uses, deployed, and checked again the next day. Still nothing. That is worth saying out loud, because a plausible fix that changes nothing is more dangerous than no fix: it closes the question. The only thing that reopened it was going back to the deployed page and watching what the browser actually sent, which was nothing at all.

What was actually wrong

The tag is loaded on idle so it never competes with the page for the first render. That is the right call for the reader and it moves the tag's arrival to a moment nobody controls. A click on a button near the top of a page can happen before that moment. An event sent then is not queued and not rejected: the function it is passed to does not exist yet, so the event is dropped in silence, and by the time the tag is configured the click is gone.

The queue

Now every event goes into a small array first. A tick checks whether the tag has arrived; when it has, the array is flushed in order and the queue goes back to being empty. It gives up after thirty seconds, because a reader who has blocked analytics is not a reader to keep waiting on, and a queue that never drains is a memory leak with a polite name. Fifteen lines, and the events arrived.

The second one was hiding in the same week

One event still never fired: the view counter on the pricing block. It used an intersection observer with a threshold, which sounds like a fraction of the screen and is a fraction of the observed element. The pricing block is taller than a phone screen, so the fraction it asked for could never be reached on the device most readers use. The block was always on screen and the observer was correct to say it had never crossed the line.

Why neither could fail a test

There was a test. It asserted that a click on a call to action produced an event with the right name and the right properties, and it passed, before and after, because the classification was never the broken part. A unit test of a function that sends can only tell you the function was called. It cannot tell you anything about the destination, which is the only part anyone cares about.

What the studio does with this now

Any change to measurement is checked at the destination, on the deployed page, with the network tab open, before it is called done. The same rule already applies to database work here: a migration is verified by asking the database what it has, not by reading the file that was supposed to change it. Measurement had been the exception, and it was the exception because a green dashboard and an empty one look identical from a terminal.

The part worth taking away

If a report you own has been quiet for a week, do not read the quiet as a result. Find out whether anything is arriving at all, and make the two cases print different sentences: nothing happened, and nothing arrived. Every system this studio builds has that distinction written into it somewhere, and it is written in because of weeks like this one.

Questions

Why not just load the analytics tag first?

Because it costs the reader. The tag is not needed to read the page, and loading it early competes with the content for the first render on a phone. Deferring it is the right trade, and it puts the tag's arrival outside anyone's control, which is a thing the code that sends events has to account for rather than assume away.

How would I know this is happening on my own site?

Open your own site on a phone or in a narrow window, open the network tab, and click something you believe is tracked. If no request leaves for your analytics provider, the event does not exist, whatever your code says. This takes about a minute and is the only check that answers the question.

Does an empty analytics report mean nobody is converting?

It means you do not know. An empty report has two causes that look the same: nothing happened, or nothing arrived. Until you have ruled out the second, the first is a guess, and it is the guess that gets acted on because it is the one that sounds like data.

Originally published on the Orium Studios blog: The analytics that classified everything and sent nothing. Orium Studios is a studio in Sacramento, California, that builds websites, CRM systems and AI receptionists for US service businesses.