Why I Rejected "Vibe Coding" and SOC2 Bloat to Build a 38,000 Ticker Engine
The current "Vibe Coding" era is dangerous for fintech. While everyone is busy letting LLMs "vibrate" code into existence, we are losing the mental models of the systems we build.
When I set out to build DividendFlow—a tax-aware compounding engine for 38,000+ US tickers—I realized that "probabilistic" logic is a death sentence for financial tools.
Here is how I built a high-scale utility while avoiding the three biggest traps in modern dev: AI-math hallucinations, the SOC2 compliance nightmare, and Frontend bloat.
1. The "Vibe Coding" Trap: Why LLMs Can't Compound
On Hacker News, everyone is arguing about whether Anthropic is doing too much "vibe coding." In my experience, AI is great for boilerplate but lethal for domain math.
A 0.1% error in a dividend yield or a miscalculated tax bracket doesn't just look "slightly off." In a 20-year compounding simulation, it creates a $50,000+ discrepancy.
The Solution: I stripped out all AI-generated logic from the core calculation. I moved to a strictly deterministic TypeScript engine running on Next.js 15 Server Components.
- Recursive Math: The compounding loop handles 240+ iterations (20 years monthly) on the server.
- Data Normalization: I built a custom filter to strip "Special Dividends" from institutional APIs—something an LLM would consistently mistake for recurring yield.
2. Avoiding the SOC2 Nightmare: The "Zero-Data" Architecture
The #1 thread on HN right now is "How to be SOC2 compliant as a solo founder."
My answer: Don't collect the data in the first place.
By building a "No-Login" system, I bypassed the entire compliance tax:
- No Database: User scenarios are encoded into URL parameters.
- No Auth: No Clerk, no NextAuth, no passwords to leak.
- No Privacy Liability: Since I don't link actual bank accounts (rejecting the Yodlee/SnapTrade model), I don't need a $15k/year compliance platform.
In 2026, Privacy is an Architectural Feature. By designing for anonymity, I can focus on math instead of security audits.
3. The "No-JS" Philosophy with Next.js 15
We saw the thread about Java realtime apps without JavaScript. The sentiment is clear: we are tired of 50MB node_modules for a simple button.
I leveraged Next.js 15 Server Components to keep the client-side bundle near zero. The heavy lifting of the tax-logic (Federal, State, UK ISA, Canadian TFSA) happens at the Edge. The browser only receives the coordinates for the graph. It’s fast, it’s lean, and it doesn't feel like a "spaceship in a browser."
The Result: 25% Higher Organic Retention
By removing the "Auth Wall" and focusing on deterministic math over "AI vibes," the return visitor rate is higher than any "Link your bank" project I've ever shipped.
Users in the FIRE community don't want an "AI Assistant." They want a high-speed calculator they can trust with their life savings projections.
Technical Takeaway:
Stop over-engineering for the sake of VC-friendly buzzwords. Sometimes the most "senior" move is to ship a deterministic, no-login utility that just works.
Check the engine architecture in action:
👉 DividendFlow.org
Are you struggling with SOC2 or AI-math hallucinations? Let's talk architecture in the comments.
Top comments (1)
@alexv_data the zero-data choice is what I find most interesting. Remove stored user state and compliance collapses while the problem becomes deterministic. Harder personalization, but for a calc engine it works.
Sorry if my English sounds weird!!