Test the Data Before You Build the App: A Content Density Gate

The most expensive way to discover your app has no content is to finish building it first.

Content-driven apps — quizzes, learning tools, daily puzzles, recommendation feeds — share a failure mode that has nothing to do with code. You build the engine, polish the UI, ship to the store, and then find that your data source supports about six weeks of decent content before it starts repeating.

So on Cineladder, a daily Indian-cinema quiz with weekly leagues, we wrote one script before any app code. It answers a single question: is there enough data here to make a good puzzle every day, for years, in every language we plan to support?

We called it the density gate.

Prefer to watch? The eight-minute version walks through the gate and the result.

The gate: three thresholds, decided before we looked

The puzzle format needs films, the people in them, and the connections between them. So we set three minimums per language track, and we set them before running anything:

Requirement	Threshold	Why
Films	≥ 200	Enough distinct subjects to avoid weekly repetition
Actors	≥ 500	Puzzle variety comes from people, not titles
Edges (film↔person links)	≥ 2,000	The connections are the puzzle

Setting the numbers first matters more than the numbers themselves. If you run the query and then decide what counts as enough, you will find a way to be satisfied by whatever you got. That is not a gate, it is a rationalisation.

The result

We pulled Tamil, Hindi and Telugu from Wikidata:

Track	Films	Actors	Edges	Passed
Tamil	4,651	1,980	11,740	[x]
Hindi	6,001	3,162	21,502	[x]
Telugu	3,411	1,558	12,588	[x]
Threshold	200	500	2,000

All three cleared, between roughly 6x and 30x over the bar. The largest project risk — “we build this and run out of content” — was retired before we wrote a screen.

The margin is the real finding. Passing at 1.2x would have meant proceeding nervously and rationing content. Passing at 6x minimum means the format has headroom for decades and we can afford to discard weak material rather than pad with it.

Then we built one slice for real

Aggregate counts can hide unusable data. A film row with no cast attached contributes to the film count and nothing to the puzzle. So the second step was to build one real content slice end to end — Tamil, 1980–89 — and inspect it:

• 303 films / 166 actors / 654 edges, shipping as 18 KB gzipped
• Coverage: director 92%, music 94%, producer 30%
• Person coverage: born 92%, birthplace 89%, aliases 60%
• Spot-checked against names any Tamil filmgoer would recognise — Kamal Haasan, Rajinikanth, Ilaiyaraaja

That 18 KB figure decided the whole distribution architecture. At that size, slices download on demand over any connection, and the app works offline afterwards. Had a decade weighed 5 MB, we would have needed streaming, caching and a very different onboarding flow.

What the slice killed

Two things did not survive contact with the real data:

Songs were dropped. Music is central to Indian cinema and would have made excellent puzzle material. Wikidata does not carry it with any consistency. Rather than build a feature on a field that is empty most of the time, we cut it.

Editor, cinematographer and screenwriter roles were dropped — not for coverage reasons, but because they are not memorable. A quiz question is only fair if a reasonable fan could answer it. We kept actor, director, music director and producer.

That second cut is the one worth copying. The data supported those roles perfectly well. The player did not. Data availability and question quality are different tests and you have to run both.

Producer coverage at 30%, and what we did about it

Director sits at 92% and music at 94% — both usable as primary puzzle material. Producer sits at 30%.

We did not drop producer. We demoted it: producer can appear as supporting detail, never as the answer. A question whose answer is missing for seven films in ten is not a hard question, it is a broken one.

Knowing a field’s coverage number lets you make that call. Knowing only that the field “exists” does not.

The method, generalised

If you are building anything content-driven, run this before the app:

1. Write down your minimums first. Before any query. Otherwise you will grade your own homework.
2. Count the connections, not just the records. 6,001 films with no cast attached is not a quiz, it is a list.
3. Build one real slice end to end. Aggregates hide empty fields; a real slice surfaces them.
4. Measure the artefact size. It decides your distribution architecture, and it is much cheaper to learn now.
5. Check per-field coverage, not just presence. 30% and 94% are both “the field exists”.
6. Apply the human test separately. Available ≠ memorable ≠ fair.

The whole gate is one script and a JSON file of results committed to the repo. It cost a fraction of a day and retired the single largest risk in the project.

---

Frequently Asked Questions

What is a content density gate?

A pre-build check that measures whether your data source can actually sustain your product’s content demands, against thresholds you set before looking at the data. It converts “we think there’s enough content” into a number you can act on.

Why Wikidata rather than a commercial film database?

Licensing and cost, mostly. Wikidata is openly licensed and queryable, which suits an app with no monetisation in phase one. The trade-off is uneven coverage — which is exactly what the gate measures, rather than assumes.

How big should a content slice be?

Small enough to download without ceremony. Ours came in at 18 KB gzipped per decade, which means a user picks a preference at onboarding and the content is there before they finish reading the next screen. If your slices are measured in megabytes, the architecture question changes.

What if the gate fails?

Then you have learned it for the cost of one script instead of one build. The options are: lower the content ambition, find a richer source, narrow scope to the tracks that pass, or stop. All four are cheaper before you have an app.

Do you run this on client projects?

On anything content-driven, yes. It is a small piece of work that regularly changes scope decisions — and occasionally stops a project that would have failed for reasons no amount of good engineering could have fixed.

---

If your app idea depends on data you do not control, the same question applies to your web presence — Cosmos Web Tech builds the sites that content strategies actually run on.

Ash Ganda writes on building with AI and data pipelines, including where automated ingestion quietly produces confident, empty results.

Part of the Ganda Tech Services family, Awesome Apps builds iOS and Android applications for Australian businesses from Bella Vista, NSW.