DEV Community

Solomon Amos
Solomon Amos

Posted on • Originally published at taptax.co.uk

I scraped all 122 products on HMRC's MTD software directory. 71% cannot finish a tax return.

I scraped all 122 products on HMRC's MTD software directory. 71% cannot finish a tax return.

By Solomon Amos, Founder of TapTax

The UK is in the middle of the biggest change to its tax system in a generation. From April 2026, self-employed people and landlords over an income threshold have to keep digital records and file quarterly through software. HMRC runs a directory of products that work with it.

I build one of these products, so I wanted to know what the field actually looks like. Not the marketing. The graded feature tables HMRC publishes for every listed product.

So on 5 August 2026 I scraped the whole thing. All 122 products, every axis HMRC grades. Here is the method, and then the finding that genuinely surprised me.

The shape of the source

HMRC's find-software service is a wizard, not a table. You answer questions about your situation and it filters a list. That is friendly for a taxpayer and useless for analysis, because you cannot see the whole field at once and you cannot compare products on an axis the wizard did not ask about.

But underneath it, every product has a detail page with a full feature table in three states. HMRC's own vocabulary:

  • Ready now - the vendor says it works today
  • In development - the vendor has committed to having it ready for the 2026-27 return
  • Not included - it does not do this

The table covers three groups: software features (free version, digital record keeping, bridging, agent software, HMRC Assist, standard and calendar update periods), income sources (sole trader, UK property, foreign property), and 16 individual tax-return items (employment, dividends, pension income, capital gains, CIS, Marriage Allowance, and so on).

That is a genuinely rich matrix. 122 products by roughly 30 graded attributes, and I could not find a published compilation of it anywhere.

The walk

The scrape itself is unglamorous, which is the point. Playwright, walk the wizard to enumerate product URLs, then hit each detail page and parse the feature table into a normalised record:

type FeatureStatus = 'Ready now' | 'In development' | 'Not included';

interface MtdProduct {
  name: string;
  slug: string;
  softwareType: string; // "Web browser" | "Desktop application" | ...
  mobileApp: string; // vendor-declared, e.g. "Android; Apple iOS"
  // ...every graded key, each a FeatureStatus
  readyReturnItems: number; // derived: how many of the 16 are Ready now
}
Enter fullscreen mode Exit fullscreen mode

Two things I would do again on any scrape of a government service.

Do not trust the count. I wrote the parser to tolerate the product count changing rather than asserting 122, because it will change. The directory is live and vendors join it. A scraper that hard-codes the expected number is a scraper that breaks silently the moment the thing it measures moves.

Derive, never transcribe. readyReturnItems is computed from the 16 graded keys at parse time, not copied from anywhere. Every statistic downstream is a function of the raw grades. That matters more than it sounds, and it is the whole subject of a separate post.

The raw output is one JSON snapshot stamped with a scrape date. Everything else is derived from it.

The finding

I expected the field to be crowded. It is: 122 products for one statutory obligation.

I did not expect it to be this shallow.

87 of the 122 products, 71% of the directory, have zero of the 16 tax-return items ready. They can send HMRC a quarterly update. When you reach the end of the year and have to pull in your employment income, your bank interest, your dividends, your student loan plan and your pension contributions, they have nothing.

The distribution is not a distribution. It is a cliff:

Return items ready Products
0 87
2 to 4 8
9 to 10 5
13 to 15 19
16 3

Three products out of 122 can do the whole return. Meanwhile 94 products carry at least one "in development" promise, and many list all 16. The 2026-27 season is going to sort the roadmaps from the shipped code.

Per item, coverage is remarkably flat: 15 of the 16 items are ready in only 20 to 32 products each. The exception is partnership income, ready in 5 products in the entire directory.

The other axes, briefly

  • Free is a real category now. 31 products list a free version. Several give away the complete legal obligation, quarterly updates and the year-end declaration, at no cost.
  • Foreign property is the cliff edge. Sole trader income is ready in 109 products and UK property in 107, but foreign property in only 60. Just 56 products cover all three income sources.
  • Mobile is the minority. 52 products list a mobile app, 45 on both platforms. 73 run in a web browser only.
  • Bridging is huge. 65 products bridge from a spreadsheet, and 23 of those do bridging only.

Then the query I actually cared about. Free, apps on both stores, keeps records natively, covers all three income sources. Four filters, and the field goes 122 to 31 to 13 to 3.

The near-miss is my favourite row in the dataset. One product is free, on both app stores, and covers all three income sources with 15 of 16 return items ready, and it still drops out, because it is bridging-only: it files from your spreadsheet rather than keeping the records itself. Whether that disqualifies it depends entirely on whether you are a spreadsheet person, which is not something a boolean captures.

The caveat that matters

Every flag in this dataset is vendor-declared. HMRC publishes what each vendor says about its own product.

I found rows that argue with the vendor's own website in both directions: one product listed without a mobile app that ships a dedicated one, another listed with apps on both platforms whose site presents a web-only tool. Treat any single flag as a claim to verify, not a fact. That caveat is attached to every number I publish from this data.

And the honest disclosure, since I build in this market: TapTax was not on the directory on the scrape date. We are MTD-compatible, built on HMRC's APIs, and going through HMRC's recognition process. On the 16 return items we are mid-pack, roughly 6 to 8 ready, which is well above the median listed product (zero) and well below the leaders (15 or 16). I would rather publish the version of the analysis where I come out mid-pack than the version where the dataset is bent to make me the answer.

The full graded dataset is public and filterable at taptax.co.uk/mtd-software-directory, including an embeddable version if you want the table on your own page. It re-scrapes monthly, so the numbers move when the directory moves.

If you are scraping a government service for something similar: derive everything, date everything, and assume the shape will change under you.


Solomon Amos is the founder of TapTax, a Making Tax Digital app for UK sole traders. He built TapTax's HMRC integration, spent two years embedded in HMRC's digital programmes, and holds a PhD in machine learning. This is a software and data perspective, not tax advice. LinkedIn

Top comments (0)