🧮 Check out my new Reverse DCF calculator
⚠️ Disclaimer: this is a hobby project I built for fun, not financial advice — please don't make investment decisions based on it.
← Back to the app
Build Story

How Glenn's Stock Value Finder Got Built

Written by Glenn, the guy who built it — with a lot of help from Claude.

Here's a little something I built, and I want to be upfront about what that actually means, because "I used AI to build an app" gets read very differently depending on how you tell it.

I'm not a full-stack engineer by trade. My background is IT and cloud infrastructure, plus a finance degree I went back and earned because I've always loved analyzing stocks and companies. What I don't have is years of writing production application code by hand (a couple of college courses in C and Python, and, for what it's worth, a BASIC class I took as a kid in 1983, don't ask). What I do have is a solid grasp of how systems, infrastructure, and security are supposed to work, and that turned out to matter a lot more than raw syntax knowledge.

So here's what actually happened: I used Claude as an execution engine, not an architect. I directed the product. The weighted scoring model (ROIC, margins, P/B, P/S, PEG, free cash flow, Morningstar fair value) is built around how I actually evaluate stocks, from the finance side, not something an AI decided on its own. I made every infrastructure call myself, and I can tell you why I made each one: DigitalOcean over a couple of alternatives, because I wanted a guaranteed US region without chasing down inconsistent data center availability. Caddy over Nginx, because automatic HTTPS with less config complexity was the right tradeoff for a solo-maintained box. A dedicated, read-only deploy key for pulling code onto the server, and a completely separate write-only key for backups, because a compromised key should only ever be able to do one narrow thing, not everything.

Delegating the boilerplate (routine Flask routes, front-end plumbing) to AI freed me up to focus on the parts that actually matter: the data model, the scoring logic, and, once it was live, keeping it secure.

Because here's the part I didn't expect going in: shipping it exposed real problems that never showed up locally. Twice. One was a database that silently never initialized correctly under my production server config. The other was a slow request getting killed by a timeout I didn't know existed. Neither got fixed by guessing. Both got root-caused the same way any real debugging works: I read the actual server logs, found the exact failing line, and fixed that specific thing.

I also caught, correctly, that a fully public app with zero authentication was a liability the moment real traffic could reach it. So it's now gated behind a proper login, with secrets (session keys, the admin password) generated securely and stored in a permission-locked config file on the server, never in source control, never exposed anywhere they shouldn't be.

None of that is "AI built my app for me." That's directing a build, owning the architecture, and validating the output, using a genuinely powerful tool to move a lot faster than I would have otherwise. I'd put it this way: combining domain expertise with modern AI tooling compresses time-to-market in a way that would've been hard to believe a few years ago. That's the part worth paying attention to, not the idea that the thinking is optional now. It isn't.

One more thing worth saying plainly: this is a hobby project I built for myself, not financial advice. Please don't go make investment decisions based on my scoring weights.

It's live: deepvaluelab.net