Terminal

The job was not “implement the design”

On March 26 the product was still a conventional dashboard. Two days later JY (PM) shared a GameFi-like map direction. Pan and zoom, node discovery, fog of war, sign-in, points, Weekly Apps (apps selected for a weekly points boost), Recap (a weekly points summary) and notifications kept arriving while the launch window stayed fixed.

Every ambiguous word had to become product behavior

“The map should zoom” still leaves 100%, cover versus contain, default view, zoom anchor, inputs, refresh behavior and constraints undefined. Filter, Live Soon, Pin and What’s New also required explicit state priority, close behavior and trigger order before design, engineering and acceptance could mean the same thing.

• Map size = 2400×1599 × baseScale × zoom
• 100% always covers the viewport without empty edges
• Wheel, pinch, buttons and keyboard share one constraint model

Filter changed the map result; it was not a highlight

JY (PM) confirmed that Filter should leave only matching apps rather than highlight matches while keeping every other node. I then clarified what closing AppList should do: if the filter remained active with no visible indicator, apps would appear to disappear for no reason. Closing AppList therefore clears Filter and restores every node. The film demonstrates all three states using the actual Terminal interface.

• Open APPS and click the Filter icon beside search
• Choose Consumer DeFi to leave only matching map nodes
• Close AppList to clear Filter and restore every node

Guest sign-in was not just moving a modal later

The original design required users to finish sign-in before interacting with the map. Changing that to “explore without signing in” did not add one button; it rewired Splash / Get Started, profile clicks, the auth gate, guest map state, cancellation, wallet switching, localStorage and backend replay. That created substantial implementation and integration work. I proposed Lazy Discover so visitors receive value first, reveal locally, then replay pending work after sign-in.

• Up to 50 pending items persisted in localStorage
• One sign-in prompt after three discoveries per session
• Retry after 30 seconds; clear ownership on wallet change

Weekly App: users validated the rule conflict

I first clarified whether Boost depended on time locked. JY (PM) defined the feature as full-week Boost for any selection locked before points settlement, while also preventing changes for the rest of that week. If timing did not affect rewards, the no-edits rule had no coherent product rationale. Users pushed back strongly after launch, and the rule was corrected so selections could still be adjusted during the week.

• Question: was Boost proportional to time locked?
• Initial rule: full Boost before settlement, but no weekly edits
• Final rule: users could continue adjusting selections during the week

The signature effects needed real mechanisms

Fog of war uses an inverse SVG mask, feTurbulence and displacement for irregular edges, and spring-driven reveal radii. App Detail uses a FLIP transition from a map node to the full panel, then closes back to the node’s current coordinates.

PostHog was not a one-night integration

Features were still arriving while the test window kept shrinking. PostHog was not one SDK call: business tracking entered core paths such as sign-in, discovery, detail, error reporting and privacy redaction. I therefore made feature freeze and a staging validation window explicit instead of treating a cross-flow change as risk-free overnight work.

• Roughly 2,000–3,000 feature lines were still arriving per day
• Full manual business tracking could add roughly 2,000 more lines
• Bug fixes only before launch, followed by at least two staging days

The role fit now; future growth needed planning

JY (PM) relayed that operations liked Terminal and wanted it to take on Rabbithole’s Featured Apps and discovery role. Both products already used the same apps, so taking on the role was not a problem. I needed to flag that continued app growth and heavier per-node interactions would make map rendering and DOM costs increasingly expensive.

• More than 40 apps were the feasible baseline at the time
• 100 apps was a scenario for estimating future map pressure
• Tooltips on every node could add roughly 2,400 DOM nodes

Staging was not the end

The build reached staging on April 28 and received “even the haters like Terminal” feedback the next day. Work continued on notification and recap order, third-party image 404s, the BFF proxy, hover behavior and label readability. The outcome is a repeatable way to converge a product under rapid change, not one final screenshot.