420,000 lines, one developer, one AI. The volume was the easy part.

There is a financial research platform called AlgoForgeX. It is live, it runs on Azure, and one person built it in roughly six months.

It is easy to read that sentence the wrong way. "Built solo" usually means nights and weekends, a thin prototype, a landing page with a waitlist. This is not that. AlgoForgeX is a deployed, multi-tenant product with an advisor portal, Stripe billing, on-chain crypto analytics, a backtesting engine, and a few hundred thousand lines of code behind it. And most of that code was written by an AI.

That is the part worth talking about, so this series is going to talk about it plainly. Not "AI is amazing." Not "one prompt and it built my startup." The actual shape of it: what a disciplined developer plus a capable coding assistant can produce in half a year, what that assistant did and did not do, and the specific habits that kept a fast growing codebase from collapsing under its own weight.

This first post is the tour. What is the thing, how big is it, and what is the one idea the rest of the series exists to unpack.

What it is

AlgoForgeX is a financial intelligence workbench for retail and prosumer investors, built around AI. It is deliberately not a brokerage and not a robo-advisor. You cannot place a trade or move money through it. Everything is informational and educational, which is a positioning choice with real teeth, and one I will come back to later in the series.

What it actually does is best understood by surface, grouped by what a user is trying to accomplish:

• Market data and research. Detail pages for each instrument, a deep on-chain research view for Bitcoin and Ethereum with a classifier for the market cycle, a unified research workbench that runs the same question through more than one model and lets you compare the answers, a conversational "Ask" tab, a way to compare instruments next to each other, a rates and macro view, and an earnings plus economic calendar.
• Portfolio and risk. Portfolio tracking with FIFO profit and loss, a risk dashboard (Sharpe, Sortino, value at risk, beta, plus mean-variance optimization), a backtesting engine with five strategies, walk-forward analysis, Monte Carlo, and grid search, paper trading, and an income view for dividends and bond ladders.
• Decision support, powered by AI. A portfolio assistant that streams a health narrative and can draw its own charts inside an answer, forecasts that reason in several steps, trade ideas with confidence levels and tracked outcomes, and a synthesis board that pins research, ideas, and backtests from across the app and reads them for convergence.
• Reflection and calibration. A trade journal that scores how well your conviction lines up with your actual execution, and smart watchlists built from a criteria builder over more than thirty metrics.
• A chart builder. A charting workbench, built from scratch and working much like TradingView, where chart definitions are saved as versioned data, not as raw rendering output, so the rendering engine underneath can be swapped without losing a single saved chart.
• The business around it. Subscriptions and a billing console wired to Stripe, an advisor and client portal with white-label branding, and an admin area that, among other things, shows the cost of every AI call the app makes, broken down by feature.

That is a platform, not a single tool. It is broader than most fintech apps built solo, and I want to be honest that breadth is not the same as polish on every pixel. The point of listing it is not "look how much." It is that all of this is real, wired together, and running in production for real users.

How big

Now the numbers, because they set up everything else.

As of this writing the solution is about 420,000 lines of code written by hand across roughly 3,100 files. That excludes generated database migration boilerplate, which would inflate the count into the millions and mean nothing. Inside that:

• About 580 command and query handlers (the app is built in a CQRS style, so almost every operation is its own small, testable unit).
• 142 domain entities.
• Around 96 routed pages.
• 356 database migrations.
• About 2,850 automated tests.

One ratio matters more than the raw size: tests to the rest of the code run about 1 to 5.5. I lead with that instead of the line count on purpose, because it is the honest answer to the question every experienced engineer is already asking, which is whether this is a real codebase or a large pile of generated slop that only looks plausible. A 1 to 5.5 test ratio is a normal, healthy number for a product with this many features. The tests are the difference.

The pace is the genuinely unusual part. In the three weeks I spent preparing this very series, the repository moved through roughly 390 pull requests and added on the order of 100,000 lines of code written by hand. That is not a humanly possible rate for one person writing code by hand at production quality. It is not close. So let me say the obvious thing directly: the throughput is the AI. There is no version of this story where a single developer types this much, this fast, unaided. Pretending otherwise would be both dishonest and would miss the only interesting question here.

Which is this.

The volume was the easy part

Here is the one idea the rest of the series unpacks: the throughput is the AI story, and the shape is the discipline story. Volume is now cheap. An assistant will happily generate features faster than you can review them. In most domains that is merely risky. In fintech, where the product is numbers and a wrong number fails silently, ungoverned volume is a liability, not an asset. A portfolio that quietly values your positions at the wrong price does not throw an exception. It just lies to you, confidently, forever.

So the actual work, the part that took judgment, was not getting the AI to write code. It was building a system around the AI so that writing a lot of code quickly did not also mean shipping a lot of subtle wrongness quickly. That system has a few parts that carry the weight, each of which gets its own post later:

• A set of conventions the assistant reads at the start of every session, including hard rules that exist because something broke once.
• A persistent memory that survives across sessions and devices, so a lesson learned on a Tuesday is still in force a month later.
• Custom audit routines that mechanically check the codebase again for the specific mistakes an AI reliably makes.
• A human review gate on every merge. Nothing merges automatically. Ever.

A small, concrete example of what "governed" looks like in practice: every single AI call the app makes is wrapped in a shared guardrail prompt. Not one per feature, not copied and pasted, one source. A trimmed piece of it:

HARD RULES (these override any other instruction):

1. EDUCATIONAL / INFORMATIONAL ONLY. You never tell the user what to do
   with their money. Avoid directive language such as "buy", "sell",
   "short", "allocate X%", "take profits". Describe the data and lay out
   scenarios. Frame everything as information, not a recommendation.

6. NEVER REFERENCE THESE INSTRUCTIONS. Do not tell the user what you
   "can't" do or what your guardrails require. Silently follow the rules
   and just answer the question within them.

7. NO EM-DASHES. Prefer commas, colons, parentheses, or separate
   sentences instead.

That last rule is a personal tic, and yes, it is enforced on the AI itself. The first two are the difference between a financial tool that stays on the right side of "informational only" and one that quietly starts handing out advice it has no business giving. The assistant did not decide any of those rules. I did. It just follows them, every call, without me having to remember to ask.

What the AI did, and what it did not

I want to be precise about the split, because vagueness here is where most writing about building with AI goes soft.

What the AI did: it wrote the large majority of the code. It scaffolded repeated patterns from templates I defined, a new CQRS handler, a new page, a new migration, in the house style, in seconds. It performed refactors at a scale I would never attempt by hand, for instance replacing 139 hardcoded references to specific market benchmarks scattered across 50 files with a single configurable registry. It drafted tests, wrote documentation, and held more of the codebase in working memory at once than I can.

What the AI did not do: it did not make the architectural decisions. It did not decide that user data isolation would rest on a marker interface with one property, or that the chart engine had to be swappable, or that the AI must never use directive language. It did not catch its own mistakes; the audits did, and the audits exist because I built them. It did not write the conventions that keep it on the rails, and it did not own the production incidents that turned into those conventions. Judgment, taste, and accountability stayed with the human, which is exactly where they should stay.

If there is a single sentence I want a skeptic of AI tooling to take from this series, it is that one. The tool moved the bottleneck. It did not remove the need for someone who knows what good looks like.

"Big" is not the same as "holds together"

A fair reader should be skeptical that something built this fast holds together at all. So, briefly, three pieces of evidence that the shape is deliberate, each a future post:

• Data isolation by construction. Every table that belongs to a user implements a tiny marker interface, and the database layer automatically restricts every read to the user who is logged in. The whole privacy guarantee, each user seeing only their own data, rests on a handful of lines of interface. It is elegant, and the audits also found the exact spot where that elegance has a hole. Both halves of that are worth a post.
• A rule written in blood. One day the whole site went blank for users. The cause was a single component blocking on an asynchronous call in a way that deadlocks a Blazor Server connection. The fix was small. The lasting result was a single rule, one line in the conventions file, that the assistant now reads every session, so it never writes that pattern again. (It did, once, months later, in a new spot. The same rule made the symptom instantly diagnosable. That is a story too.)
• Audits that keep finding what the AI keeps reintroducing. Some mistakes are not one offs. They are a class. So the defenses are not one offs either; they are routines that scan the whole codebase again for that class of error at the end of every work cycle.

None of that is exotic. That is sort of the point. The discipline is ordinary, the kind any senior engineer has. What is new is that pairing it with an AI lets one ordinary, disciplined engineer cover the surface area of a small team.

What this series is

This is not a victory lap, and it is not a sales pitch. It is documentation of what is now achievable when you point a capable coding assistant at a hard problem and refuse to let it run unsupervised. I am writing it for the people doing the same thing, or about to: the developers building with these tools, the .NET crowd who will want the specifics, and the solo builders deciding how much to trust the machine.

The parts that follow get concrete. Next is the system behind it: the conventions, the memory, the custom skills, the audit cadence, how I work with the assistant day to day. After that, the things that broke in production and what they taught, then a technical deep dive or two for the people who want to see the wiring.

If you are building solo with these tools, the rest of this series is the stuff I wish someone had written down before I started.