Skip to main content
Cross-platform builderiOS + Android + Web

Terra Tempus

Year2026
RoleSolo product owner & engineer
StatusLive

A cross-platform history product I built and publish solo. Its core system turns sourced historical events into playable rounds across iOS, Android, and the web.

450+
Human-reviewed events
3
Platforms
2
Scoring axes
Play in Browser

At a glance

450+
Wikidata-grounded, human-reviewed events

450+ Wikidata-grounded, human-reviewed events are live in the catalog.

3
platforms

iOS, Android, and web share the same product and content system.

2
round axes

Every round asks the player to place history in space and in time.

Terra Tempus daily history map game
A clue, the year guess, and the round score

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, clues needed editorial grounding, and nothing half-vetted could quietly slip into the live catalog. 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+

Wikidata-grounded, human-reviewed 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.

CC0 + review

licensing and trust stay aligned

Facts, clue writing, and publishing claims remain inside what the system can honestly support.

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 structured source data so the scoreable parts of the game have provenance.
Grounded clue writingOriginal clues stay anchored to source material that can be checked during review.
Review before publishOnly reviewed material can enter the live catalog.
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 review gates 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 Projects

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.