Building a Security Startup by Myself

There's no team page for G8KEPR. There's no team. G8KEPR, Inc. is me, a laptop, and whatever hours are left after a full-time job, which in practice means evenings and weekends.

That shapes almost every decision in this series, so it seemed worth writing down plainly before getting into the rest.

The paperwork part

I formed the company as a Delaware C-Corp through Stripe Atlas. If you haven't seen it, Atlas walks you through incorporating in Delaware, getting the company's basic paperwork in order, and setting up the pieces you need to actually operate. For a solo founder, the appeal is obvious: it turns a stack of legal chores into a guided form, and I'd rather spend my limited hours on the product than on figuring out which filing comes first.

That's about all I'll say about the legal side. It was a means to an end. The end is the software.

How big it's gotten

I ran cloc against the repo in September 2026. The numbers, rounded:

What	Lines
Source	≈ 1.0 million
Tests	≈ 1.39 million
Tests per line of source	≈ 1.4

A million lines of anything is a lot for one person to own. I want to be careful with that number, though, because line counts are one of the easiest metrics in software to misread. They tell you how much text exists. They don't tell you whether any of it is good, whether it's all still needed, or whether a customer would pay for it. A bloated codebase and a thorough one can have the same count.

Note

A big line count isn't a feature. Nobody buys a security product because the repo is large. The number is here because it explains the shape of the work, not because it proves anything about its value.

Why there's more test than code

The part of that table I actually find interesting is the ratio. There are more lines of tests than lines of the thing being tested.

Here's how I read that about myself.

There's no second reviewer. On a team, somebody else reads your pull request. They ask why a function exists, notice the edge case you skipped, or point out that the "quick fix" breaks something three folders over. When you work alone, that person doesn't exist. The closest substitute I have is a test suite that remembers every assumption I've made and complains loudly when I break one.

Security software has a worse failure mode than most. If a to-do app has a bug, a task shows up twice. If a security check has a bug, it either blocks legitimate traffic or quietly lets bad traffic through, and the quiet version is the dangerous one. The product claims specific behavior, like a SHA-256 fingerprint of each MCP tool definition that's re-checked on every call, or a WAF with nine built-in block rules. Each claim like that is a promise, and a promise I can't test is one I shouldn't be making.

A lot of the building happens with AI agents. I build G8KEPR with three Claude Code agents running at once, and I supervise until the work is done and tested. That "and tested" is carrying a lot of weight. When code arrives faster than one person can read it line by line, the tests are how I hold it to the same standard as code I typed myself. They're the contract the agents have to satisfy, not an afterthought.

Time comes in small pieces. An evening here, a Saturday morning there. Nobody keeps a million lines in their head across a week of not touching them. Tests let me come back cold, run the suite, and know where things stand before I change anything.

What this costs

Test code is still code. It has to be maintained, it can be wrong, and a test suite that's larger than the product can slow you down when you want to change direction. That matters most when the direction changes, as it did when I narrowed G8KEPR into a correlation engine. Change what a product is, and some of its tests may now describe behavior you no longer care about.

I don't think there's a clean answer to that. The trade I've made is to lean heavily toward being able to trust what's there, and accept that the pile is big.

What being solo actually means for decisions

The honest upside of doing this alone is speed of decision. There's no meeting to schedule. I decided to go open source one day and reversed it the next, and the only person who needed convincing was me.

The downside is the same fact from the other side. Nobody pushes back unless I build something that does. The tests push back on the code. The scorecard pushes back on how good I think the product is. And a list of priorities in Todoist pushes back on how I spend the hours.

None of that replaces a co-founder. It's the scaffolding I've put up in place of one.