Feed
I'm a solo founder building Reverse Efficient Frontier, a portfolio app that that inverts Modern Portfolio Theory — instead of picking stocks and hoping, you set a target return and risk tolerance and it finds the stock blend that matches. React Native/Expo frontend, Azure Functions + Blob Storage backend, Databricks for the optimization, Claude API for the plain-English explanations. Live on both stores.
I want to write up the architectural mistake that nearly killed it, because it's a flavor of "I did not think about scale" that I haven't seen described much.
The mistake: I assumed I could solve the optimization on demand, when the user moves the slider.
Classic portfolio optimization runs forward. You hand it a set of stocks, it solves for the optimal weights. That's a convex problem — fast, well-behaved, solvable in milliseconds. I'd read the papers, I understood the math, I felt good.
What I actually needed was the inverse: given a target return and risk, find which stocks and their weights. Those are not the same problem. Selecting k stocks from a universe of N is combinatorial, and each candidate set needs its own optimization run before you can even compare them. For 10-stock portfolios that's a number with more zeros than there are stars in the galaxy. My v1 fired off an optimizer on slider change like it was a database query. It worked beautifully in testing — because in testing my universe was twelve tickers.
Everything is obvious in hindsight.
What I rebuilt, three layers:
-
Sample instead of enumerate. I stopped trying to find the optimal portfolio and started building a dense point cloud of good ones. Randomly sample thousands of k-stock subsets, optimize each one properly, keep the result. It's an approximation of the true efficient frontier, not the thing itself — and being honest about that in the app matters more to me than pretending otherwise.
-
Multi-start optimization with weight bounds. Single-start SLSQP kept converging to garbage — 97% in one ticker, dust positions everywhere. Fixed it with multiple randomized starting points per subset and hard bounds on individual weights, so you can't get a "diversified" portfolio that's secretly one stock.
-
Precompute and park. The whole thing moved to a scheduled Databricks job that writes results as JSON to Azure Blob behind a CDN. The phone doesn't optimize anything anymore. It does a nearest-neighbor lookup in return/risk space against precomputed results. All the expensive math happens once, on a schedule, away from the user.
Result: query time went from "architecturally impossible" to under a second on a mid-range phone, and compute became a fixed predictable cost instead of scaling with every slider drag. Same pattern now runs everything I build — if it's expensive, compute it on a schedule and let the app read the answer.
The app's live on [Google Play] and the [App Store] if anyone wants to poke at it ( https://frontier.chosenhomeland.com ). You get 3 free portfolio lookups, no signup, no card — enough to see whether the idea holds up.
Happy to answer anything about the optimization approach, running scipy on Databricks, precompute-and-park as a pattern, or building fintech solo. Also genuinely want feedback on the first-run experience — whether the value proposition lands before you've done anything, since that's my current bottleneck.
(Not financial advice — it's an analytical tool, and it says so in the app.)
-
Notice the faint gray around the boxes? It is more noticeable in real life than this picture