Clavix
See what changed overnight without reading the whole market.
Fintech
iOS product
Role
Product, design, iOS, backend
Timeline
2025 - current
team
Independent build
platform
iOS and API

The Real Problem
Every morning, my dad spent 30-60 minutes reading the market just to understand what had changed around the positions he owned. The problem was not access to news. It was deciding which two stories in a crowded feed actually mattered to his portfolio.
I built the first version with him beside me, going back and forth on what was useful and what still felt like work. General market apps rewarded more scrolling, while broker feeds mixed meaningful signals with duplicate coverage and broad commentary. We wanted one dependable answer to a smaller question: what changed overnight for the things I own?
The useful unit was not another article. It was a ranked explanation tied to a real holding.

Finding the Fix
The first fix was a morning report instead of a live feed. Clavix connected holdings to relevant coverage, weighed the likely downside, and assembled one brief that could be understood quickly.
Then my dad asked a better question: what if he wanted to inspect a stock before buying it? I added search. After that came the watchlist, so a risky stock could stay visible until its conditions improved.
Morning report: explain what changed overnight for real positions.
Search: run the same risk system before acting on a stock.
Watchlist: notice when a risky setup improves without starting over.
Evidence: keep the score connected to the underlying reporting.

What Actually Happened
Building the full system solo made every product decision architectural. The SwiftUI client handles onboarding, holdings, the daily brief, and StoreKit 2 subscriptions. A FastAPI service on a self-hosted VPS runs the data pipeline and serves normalized results backed by Supabase and PostgreSQL.
The scoring pipeline went through several versions. Early attempts treated every matching headline as useful. The better system first removes duplicates and broad market chatter, then scores what remains against the user's actual exposure.

What Changed
The product moved from a news reader toward a risk workflow. The home screen stopped trying to summarize the entire market and focused on the portfolio. Explanations became as important as scores. Search and watchlists turned the same system into something useful before and after a decision.
The result is a clearer promise: open it once, understand what deserves attention, and get on with the day. Clavix is preparing for TestFlight now; it is not presented here as already launched.

What I Had to Work With
Clavix is self-funded and built by one person. There is no separate design team, data team, or operations team. Cost, latency, App Store policy, data quality, and public market information all shape the product.
Those constraints forced a small surface area, a visible evidence trail, and infrastructure I can understand and operate without ceremony.

What I'd Do Differently
I would define the scoring evaluation set earlier. The first versions were tuned through manual reading, which was useful but difficult to compare over time. A stable set of portfolios, events, and expected rankings would have made iteration more deliberate.
I would also prototype onboarding around the first useful brief before building the surrounding settings.
What I Learned
Information products need an opinion about what can be ignored. Relevance is not a cosmetic filter. It is the core product.
I also learned that calm interfaces require more backend work, not less. Every simple sentence on screen depends on deduplication, ranking, fallbacks, and an honest treatment of uncertainty behind it.
