History game, built solo
Terra Tempus
A daily history game I built and publish on my own. Its core is a content system that turns sourced historical events into playable rounds on iOS, Android, and the web.
- Year
- 2026
- Role
- Solo product owner & engineer
- Status
- Live

At a glance
- 450+sourced historical events450+ sourced historical events are live in the catalog.
- 3platformsiOS, Android, and web share the same product and content system.
- 2round axesEvery round asks the player to place history in space and in time.
Problem
A history game only works if the history is right. Terra Tempus had to solve for content integrity before it could worry about progression, polish, or scale. Coordinates and dates needed clear provenance, while original clues and explanations needed editorial grounding. That made the content pipeline as important as the game loop itself.
Result
Terra Tempus applies the same product discipline to a different problem: keeping historical content trustworthy while making it playable.
- 450+
sourced historical events
The catalog is large enough to show the publishing workflow in regular use.
- 3
platforms live
iOS, Android, and web all ship the same core product and content system.
- 2
scoring dimensions per round
Every round asks the player to reason about both geography and chronology, which gives the product its shape.
- 2 sources
with distinct roles
Wikidata supplies coordinates and dates; English Wikipedia grounds original clues and explanations.
Role
I owned both the product and the system that made the content trustworthy:
- Content system designDefined the sourcing, review, and publishing flow for the live catalog.
- Cross-platform implementationBuilt the app, the web experience, the API layer, and the content pipeline that feeds them.
- Editorial guardrailsSeparated structured facts from clue writing so provenance and presentation could each be checked on their own terms.
- Operational follow-throughHandled release, catalog QA, and the day-to-day mechanics of keeping the product live across three surfaces.
Constraints & Decisions
Several decisions kept the product honest and playable:
- Wikidata as the factual spineCoordinates and dates come from Wikidata (CC0) so the scoreable parts of the game have provenance.
- Grounded clue writingOriginal clues and explanations are grounded in English Wikipedia (CC BY-SA).
- Ongoing editorial reviewThe editorial review pass is ongoing as the catalog evolves.
- One product across three surfacesThe app and web builds share the same content and round logic so players do not experience different versions of history.
Lessons
- A wrong fact is worse than a missing oneIn a history game, one confidently wrong date can damage trust in the whole catalog, which is why provenance and ongoing review matter so much.
- Content systems are product systemsThe admin and review flow are not back-office extras. They are part of whether the player-facing product is credible.
- Shared scaffolds help, but drift is realReusing the Verdict rails made a second product feasible, but the forks still need deliberate maintenance and cross-porting.
- Cross-platform means more than renderingMaps, accessibility, content QA, and environment handling all behave differently across mobile and web, even when the product looks unified.
More work
Let's talk.
Planning an interactive or cross-platform product? I bring product planning and hands-on engineering together, from the core mechanic through release and ongoing maintenance.


