Every launch window does the same thing to me: my clipboard fills up with spec blurbs from a dozen product pages, all formatted differently, half of them mixing marketing claims with actual numbers. Early September was a good example. In the same news cycle I had AOC's Q27U4D monitor page, Lei Jun teasing the Xiaomi 18 Fold's battery, and Horizon Robotics posting shipment milestones. Three completely different categories, three completely different ways of stating numbers, and no clean way to line them up.
So instead of building yet another throwaway spreadsheet, I turned it into a small, reproducible build: a Python parser that eats copy-pasted blurbs, a SQLite table I can hand-edit when the parser gets something wrong, and a hosted HTML page that renders the comparison. Nothing fancy. But it's the kind of thing you can stand up in an afternoon and reuse every launch season.
The real problem isn't parsing, it's trust
Before any code, the thing worth naming: almost everything you scrape during a launch is vendor-stated. The AOC page lists a 0.03ms GtG response time, 1.5M:1 static contrast, and HDR APL 10% brightness of 400 nits. The Xiaomi 18 Fold is announced with a 6000mAh battery, 920Wh/L energy density, and 67W wired plus 50W wireless charging. Horizon says its Journey chips crossed 15 million units shipped, with a claimed 31.94% market share in the first half of 2026.
Those are all numbers a manufacturer put out, not measurements you or a third party confirmed. If you build a comparison tool that silently presents them as fact, you've built a marketing aggregator, not a useful reference. So the first design decision was structural: every row carries a `source` and a `verified` flag, and the default for launch-day specs is `unverified`. That one column changes how honest the whole thing is.
Step one: a parser that turns blurbs into rows
The input is deliberately ugly — I paste the spec paragraph exactly as it appears. The parser's job is to pull out `(attribute, value, unit)` triples using regex patterns for the common shapes: a number followed by a unit (`6000mAh`, `144Hz`, `96W`), ratios (`1.5M:1`), and percentages (`99% DCI-P3`). Anything it can't confidently classify goes into a `raw_unparsed` field rather than getting dropped, so I never lose data I might need later.
I kept the parser small on purpose. It doesn't try to be clever about semantics — it doesn't "know" that mAh is battery capacity. It just extracts and tags, then writes to SQLite. You can run Python online for exactly this kind of job without setting up a local environment, which matters when the whole point is a quick, repeatable pass each time new specs drop.
A rough shape of what each parsed row looks like:
product | category | attribute | value | unit | source | verified
AOC Q27U4D | monitor | response_time | 0.03 | ms | vendor_page | unverified
AOC Q27U4D | monitor | contrast_static | 1500000| ratio | vendor_page | unverified
Xiaomi 18 Fold | phone | battery_capacity | 6000 | mAh | vendor_launch | unverified
Xiaomi 18 Fold | phone | charge_wired | 67 | W | vendor_launch | unverified
Horizon Journey| chip | units_shipped | 15000000| units | vendor_press | unverifiedNotice the normalization: `1.5M:1` becomes `1500000` so it's actually sortable, and units live in their own column so I'm never comparing `mAh` against `Wh/L` by accident.
Step two: SQLite you can hand-fix
The parser will get things wrong. Vendor copy is inconsistent — sometimes a spec is stated as a range, sometimes it bundles two figures in one line (Xiaomi's charging was literally "67W wired + 50W wireless" in one breath). Rather than chase every edge case in code, I lean on being able to open the table directly and correct rows by hand.
That's where a built-in SQLite editor earns its place. When the parser splits the Q27U4D's USB-C entry oddly, or misreads a percentage, I just fix the cell, and when I later confirm a figure against a review, I flip `verified` from `unverified` to whatever I trust. The database is the source of truth; the parser is just a fast way to populate it. Keeping those two roles separate is what makes the build maintainable instead of a brittle scraping script that breaks every time a vendor changes their page layout.
One small schema note that saved me grief: I store `category` per product so the comparison page can group like with like. Trying to put a monitor, a foldable phone, and an automotive chip in one flat table only works if you never actually compare across them — you compare within a category, and you use the table to hold all of them.
Step three: the hosted comparison page
The front end is plain HTML that queries the table and renders a per-category grid, with a filter to show only verified rows when I want the honest view. The `unverified` figures still appear, but visibly flagged, so anyone reading knows the 0.03ms or the 920Wh/L came straight from the manufacturer and hasn't been independently checked.
Getting it in front of people is the part that used to be the most annoying, and here it's the least. With web app hosting I publish the page from the same place the data and parser live, so there's no separate deploy dance — edit the table, refresh, the page reflects it. For a solo builder or a small team, that tight loop is the whole value: input a blurb, correct a few cells, share a link.
Where the boundaries actually sit
A few honest limits, because pretending they don't exist would undercut the whole exercise.
The tool doesn't verify anything for you. It structures and displays claims; the `verified` flag only means *you* checked something, not that the platform did. If you never flip it, everything stays unverified, which is the correct default for launch-day copy.
It also won't fetch pages for you. This build assumes you paste the text in — the parser handles normalization, not crawling. That's a deliberate scope choice, and it keeps the thing simple and legally uncomplicated.
And the comparisons are only as meaningful as the categories you define. Lining up a QD-OLED panel spec against a foldable's battery tells you nothing; grouping three monitors by response time and contrast tells you a lot. The database structure supports the second use and quietly discourages the first.
What you end up with is modest but genuinely reusable: next launch, paste the new blurbs, let the parser do the boring extraction, fix what it botches, mark what you can confirm, and republish. That's the difference between drowning in spec copy every season and having a small machine that turns it into something you can actually query.