Why I built it
I built Build Heartopia as a fan-made reference for Heartopia, a game. I wanted players to be able to find an answer without having to piece it together from scattered information.
Each record can carry a type, rarity, availability or where to get it, a collection, an image, or event information. Game information can change and may be incomplete, out of date, or wrong, so I have to build search and links, test details, make corrections, and keep the catalog maintained.
What it does
Build Heartopia is a fan-made reference for Heartopia, a game. An item is an individual thing in the game. A collection groups related items.
Players can search for an item, browse collections, check current and upcoming in-game events and their dates, and save items to Favorites, a list stored on their device. Item pages can show type and rarity, availability and where to get an item; collections keep related items together.
As of August 23, 2026, the reference listed 14,508 published items across 273 collections and 14 visible categories. That describes the work’s scope, not popularity or success.
I keep the interface focused on helping a player find an answer and then follow the relevant link.
- Item pages, collections, and event information
- Favorites saved on a visitor’s device
- Catalog counts are a dated public snapshot, not a guarantee of permanent completeness.
- Point-in-time public checks are not uptime or performance monitoring.
What I did
I conceived, designed, built, deployed, and maintain Build Heartopia as a solo project. Codex is my development environment: it supports planning and execution, while product decisions, verification, deployment, and ongoing responsibility remain with me.
I decide what belongs in the reference, organize the information, design the public interface, build the product, put it online, and keep it up to date.
- Product concept and scope
- Information architecture and interaction design
- Frontend and backend implementation
- Deployment and public operation
- Ongoing catalog and product maintenance
- Privacy-preserving measurement and feedback loop
Recorded use
This short, privacy-preserving measurement window recorded activity beyond the homepage, including item, collection, and event pages. These are recorded events and inferred visits, not identified people.
Observed August 15, 2026 at 2:13:41 AM through August 23, 2026 at 2:48:35 PM EDT — the first 8 days and 12 hours of trustworthy privacy-preserving measurement.
- 1,424
- recorded page views
- 270
- inferred visits
- 5.27
- pages per inferred visit
- 129
- multi-page inferred visits
- Recorded page views and inferred visits are not unique people.
- Owner and test traffic cannot be removed.
- The observation window is short and includes partial boundary days.
- Bot filtering is heuristic.
- Feedback volume does not establish satisfaction or resolution.
The records include item-page, collection, and event-page activity, along with inferred visits that contain more than one recorded page view. They do not establish unique audience size, usefulness, retention, satisfaction, or product-market fit.
- 855 recorded item-page views
- 273 recorded collection views
- 56 recorded event-page views
The private feedback mechanism recorded 14 reports between July 19 and August 16, 2026. The audit counted reports without reading or publishing their private text.
About the numbers
Measurement method and further limitations
Page views are raw stored view events. Inferred visits are reconstructed with a 30-minute inactivity threshold on a month-scoped pseudonymous identifier. Multi-page inferred visits contain more than one recorded page view. Pages per inferred visit is 1,424 divided by 270, rounded to 5.27.
Known bot, crawler, monitor, preview, command-line, and browser-automation user agents are discarded before storage; unusual user agents are excluded from normal reporting. This is heuristic filtering, not proof that every retained request was human.
The privacy model cannot identify or remove my own activity, administrative checks, or other test traffic. It also cannot turn a visitor-day estimate into a unique-person count or support durable retention analysis.
The window is short and both boundary days are partial. This is a dated observation, not a growth trend or a normalized daily rate.