We are industry veterans building a modern alternative to clunky 13F trackers using .NET & AI
Hey Indie Hackers đź‘‹,
We are Ethan Blake and Eric Dean, the co-founders of 13radar.com.
We are writing this post to share how we are bootstrapping a financial analytics platform to compete with established giants like WhaleWisdom, Fintel, and GuruFocus.
This isn't a weekend project. It’s the product of our combined 35 years in the industry.
Ethan (CEO): A serial entrepreneur with nearly 20 years in internet product dev and US equity investing.
Eric (CTO): A data engineer with 15 years of experience specializing in large-scale financial data and intelligent automation.
Together with our small but mighty team of editors and operators, we are on a mission to fix a broken market.
Part 1: The Problem – "The Used Car Lot" of Finance
The data regarding Institutional Holdings (13F) is technically public, but the tools to access it fall into two buckets:
The "Luxury" Tier: Professional terminals costing $20,000+ year.
The "Legacy" Tier: Websites that look like they were built in 2005. They are cluttered with ads, charge
$30 - $50/month, and treat free users like enemies (blurring rows, blocking basic searches).
We hated this. We believe that tracking "Smart Money" shouldn't require a corporate budget or fighting through 10 popups.
So, we built 13Radar. Our goal is to build the Linear of financial data — clean, fast, and delightful to use.
Part 2: The Tech Stack – The CTO’s Bet on .NET
Note from Eric (CTO):
When building a platform to process millions of SEC filing records, the industry default is Python.
We chose ASP.NET Core + PostgreSQL.
This is a contrarian bet in the scraping world, but here is why:
Performance: Processing large-scale financial datasets requires high throughput. ASP.NET Core (on Kestrel) outperforms most Python frameworks in raw benchmarks, allowing us to keep our server costs low while scaling up.
Precision: Dealing with SEC data requires extreme accuracy. Strong typing in C# helps us model complex regulatory structures without the runtime errors common in dynamic languages.
Part 3: The Data Nightmare (Where AI Failed Us)
This is the part nobody tells you about building a data product.
Initially, we thought processing SEC 13F filings would be straightforward. It’s just downloading public XML files and parsing them, right?
We were dead wrong. The data processing turned out to be a nightmare that AI couldn't solve for us.
The SEC doesn't strictly validate the data content, leading to a mess of human errors from the funds themselves:
The Unit Multiplier Error: Some funds report "100" when they mean "$100,000" (forgetting the x1000 multiplier).
The "Zombie" CUSIPs: Funds often report using old, expired CUSIP codes for stocks that have since merged or changed symbols.
Format Shifts: The filing specifications have changed over the years. What worked for 2024 filings breaks for 2015 filings.
We tried asking AI to handle this, but it simply couldn't detect these deep, contextual anomalies.
The result?
We had to rely on our own expertise to build custom entity-resolution engines. We didn't just run the data once; we wiped our database and re-ran the entire calculation pipeline more than 10 times, manually patching these edge cases until the historical lineage was perfect.
This experience proved that while AI is powerful, domain expertise is the real moat.
Part 4: How We Use AI as a Force Multiplier
Once the "dirty data" problem was solved by humans, we unleashed AI on the rest of the stack to move fast.
We estimate that 60% of our product logic and code is AI-assisted.
1. The Architect: Google Gemini
We use Gemini for high-level data architecture, helping us plan storage strategies for linking 13F (Quarterly) with Form 4 (Real-time Insider) data.
2. The Full-Stack Accelerator: Claude Code
Claude Code has been our MVP.
Core Algorithms: It helped us rapidly prototype complex financial math (e.g., portfolio turnover rates).
Backend Efficiency: It accelerated the development of our crawlers, API endpoints, and our internal CMS by 3x. It handles the heavy lifting so we can focus on logic.
3. The Designer & Coder: Readdy.ai
Ethan focuses on product vision, but we aren't frontend specialists.
We use Readdy.ai not just for design mockups, but to export actual frontend code.
This allowed us to skip the "Figma to HTML" translation phase entirely, shipping a modern UI with a fraction of the effort.
Part 5: What We Are Building
We are combining Ethan’s product intuition with Eric’s data engineering to create:
Guru Tracking: A clean, no-nonsense view of what legends like Buffett and Burry are buying.
Institutional Signals: We don't just show data; we show intent. Who is accumulating? Who is dumping?
The "Insider" Edge (In Development):
Eric is currently building this: A module that correlates Hedge Fund buying (13F) with Corporate Insider buying (Form 4).
When a CEO buys their own stock at the same time a Hedge Fund loads up, that’s a signal you shouldn't ignore.
Part 6: Our Pricing Philosophy
We are bootstrapped. We don't have VC investors demanding we squeeze every user for revenue on Day 1.
The incumbents charge $30 - $50 / month.
We want to offer a model that respects the indie investor:
Generous Free Tier: No "login walls" for basic data. You can track the Warren Buffett Portfolio history for free.
Affordable Pro: Advanced screening and real-time alerts at a price point closer to a streaming subscription, not a car payment.
Ask for Feedback
We are building in public because we value the Indie Hackers perspective.
Questions for the community:
Tech Stack: Any other .NET founders here? How do you handle "Scraping at Scale" with C#?
Data Integrity: How do you handle "dirty data" in your projects when AI fails?
Critique: Please roast 13radar.com. Does the UI match our "modern" promise?
Thanks for reading. We’ll be in the comments answering questions about SEC data parsing nightmares, AI workflows, or bootstrapping with a veteran team.
Ethan & Eric
Co-Founders, 13Radar.com
Loved this post — especially the “dirty data” section. It’s a great reality check that AI isn’t magic, and domain-specific cleanup still matters.
I’m working on a different but related problem: making LLM reasoning auditable and less black-box. Seeing teams like yours push usability and transparency forward is energizing. Congrats on shipping, and cheering for you! 🚀
Thank you! The auditable LLM reasoning problem is fascinating—we desperately need that transparency layer, especially in finance where "trust me, the AI said so" doesn't cut it.
Really impressed by how you’re tackling the “public data but locked behind paywalls” problem. Congrats on shipping this.
Honestly, I like how Ethan and Eric are keeping it real here. They’re basically saying: “13F data is public, but the tools to use it either cost a fortune or look like they’re stuck in 2005.” Their pitch for 13Radar feels fresh — clean UI, affordable pricing, and no annoying popups.
The tech angle is interesting too. Most people default to Python for scraping, but they went with .net Core. That’s a bold bet, but it makes sense if performance and strong typing help them avoid messy errors.
The part about “dirty data” was eye‑opening. AI couldn’t fix the weird multipliers, zombie CUSIPs, or format shifts, so they had to brute‑force it with expertise and manual cleanup. That’s not glamorous, but it shows they know their stuff.
I also like their philosophy: generous free tier, pro features priced more like Netflix than Bloomberg. If they can keep the data clean and deliver those insider signals they teased, they might carve out a nice niche with indie investors.
So yeah, feels like two veterans trying to build something modern and user‑friendly in a space that’s been neglected. Curious to see if they can keep scaling once the manual fixes pile up.
I wish I had more to add here except: brilliant. This is exactly the kind of reason startups exist, to take a crappy situation and make it better, and to inspire the "shut up and take my money" instinct. I had to go look up what a 13F even is, but after reading about it and the horror stories of poorly presented data, I get it. It's amazing the competitors have dared to be this bad. I seriously wish you guys luck and I am not at all convinced you'll need much of it.
> We had to rely on our own expertise to build custom entity-resolution engines. We didn't just run the data once; we wiped our database and re-ran the entire calculation pipeline more than 10 times, manually patching these edge cases until the historical lineage was perfect.
This is exactly why AI is not going to replace good engineers. The simplistic takes, that if an LLM can crank out code, there's no more work for humans to do, is ridiculous and absurd, and ignorant. The hard part of coding is not writing the code. It's making the code work the right way and work quickly and efficiently—oh, and to understand subtle nuance like '100' meaning 100,000 in lazy abbreviation. Maybe someday AI will get that good, but I'm skeptical, because this is not actual intelligence; it's an imitation.
Yes, I completely agree—AI cannot replace great engineers, at least not at this stage. I recently tried using AI (Google Gemini 3 Pro Preview, through Trae’s coding tool since I don’t have Claude Code Model) to handle multilingual processing for 13Radar, and I found that it struggles with more complex logic. Sometimes it even makes very silly mistakes. For example, when I asked it to compare line counts across multilingual JSON files (just over 1,000 lines), it took 2–3 rounds of interaction before it could identify and fix the issue, and the speed was much slower than I expected—probably because it was processing line by line.
That said, I can’t deny that AI has significantly boosted our overall efficiency.
Focus on messy, public-but-locked data with a clean, modern approach. Domain expertise is crucial because AI alone cannot fix dirty or inconsistent datasets. Choose a tech stack that prioritizes performance, accuracy, and maintainability. Start with human-led solutions for edge cases and then scale with AI as a force multiplier. Keep the product transparent, affordable, and user-friendly, and use small, deliberate design and UX improvements to stand out in legacy markets.
Super inspiring build. Love how you’re tackling an old, messy data space with a clean, modern approach — and doing it bootstrapped. The part about AI failing on real-world SEC data really resonated; people underestimate how much human domain expertise still matters. Also really impressed by the .NET choice and the reasoning behind it.
Congrats on shipping something this ambitious. Excited to see how 13Radar evolves.
Thanks so much for the encouragement! Totally agree—AI can’t replace great engineers yet. We’ve seen firsthand how it struggles with complex logic, but it still boosts efficiency in a big way. Excited to keep pushing 13Radar forward!
I’ve worked with SaaS teams using Python + FastAPI and placed a lot of remote developers in that ecosystem and it’s great for rapid prototyping.
But for serious API workloads, especially where performance, type-safety, and long-term maintainability matter, nothing really replaces .NET Core.
Your post highlights exactly why: the reliability of the ecosystem, predictable performance under load, mature tooling, and far fewer “mystery edge cases” compared to dynamic stacks.
Most founders underestimate this until they hit scaling or data-quality walls.
.NET’s structure, strong typing, and baked-in performance optimizations save months of engineering pain down the road.
Absolutely agree! Running a financial analytics platform taught me the same lesson. Python's great for MVPs, but once you're handling concurrent requests and financial data integrity, .NET Core's compile-time guarantees are invaluable. That "if it compiles, it probably works" confidence is something dynamic languages just can't match—especially when debugging production issues at 2am!
YOU CAN RECOVER YOUR STOLEN FUNDS WITH THE HELP OF // THE HACK ANGELS RECOVERY EXPERT
The most reputable and trustworthy recovery experts available today. THE HACK ANGELS RECOVERY EXPERT. They can help you retrieve your stolen crypto funds. They have technical expertise resources to track down and recover lost crypto. I had lost ÂŁ973,000 to fraud and at first I thought it was gone for good. I went online to search for recovery, I saw numerous testimonies regarding THE HACK ANGELS RECOVERY EXPERT and how they had assisted other people in getting their money back. I didn't hesitate to contact them, in just a few days the experts returned all my money. They said that they did an investigation and returned my money immediately. They can never ask you for any upfront payment. They can help you track your funds. They are cyber security experts doing great jobs out there. Be wise and do your research to avoid being scammed again. For anyone in a similar situation seeking to recover funds lost to online scams, contact THE HACK ANGELS RECOVERY EXPERT through
WhatsApp +1520200-2320
Really impressed by how you’re tackling the “public data but locked behind paywalls” problem. Congrats on shipping this.
Finally! I've been waiting for someone to disrupt this space. Most existing 13F trackers feel like they haven't updated their UI since 2005. It’s always a pain to browse them on mobile.
I'm curious—how are you handling the visualization of portfolio changes? I’d love a cleaner way to see 'New Buys' vs 'Exits' without digging through spreadsheets.
The mission is noble, but the real question is: How affordable can the 'Pro Tier' be when the founders' 35 years of experience is dedicated to manually cleaning the data AI couldn't fix?
Well, they did mention that very thing, that it took a bunch of grinding, going over the results and getting the code to recognize and fix the problems. They didn't spend 35 years actually cleaning data. They spent that time learning to understand the situation. Once you know the details of a task, you can probably automate it. Not easy, but do-able.