What It Actually Took: Five Months of Building JobIntel in Public
I spent five months and a little over $35,000 building a fully featured software company by myself. I can tell you every line of code, every dollar, and every mistake.
What I cannot tell you is whether it becomes a profitable business. Those are two different things, and most building-in-public content pretends they are the same thing. This article is the first half of the story - the half I can prove. The honest frame for everything below is this: a working technical implementation is not product-market fit.
With that said, here is all of it.
Forty-eight hours, then twenty-four days
The idea arrived on February 13. By February 15 there was an LLC and a first git commit, about two hours apart. Twenty-four days after the idea - twenty-two after that first commit - JobIntel went live to the public: 110,000 lines of code, 236 API endpoints, 4,869 automated tests, 53 database migrations.
I want to be careful with that sentence, because it is the kind of sentence that gets screenshot into AI hype threads. The first three days alone closed fourteen "sprints" - but an AI-assisted sprint is a much smaller unit of work than what a conventional team calls a sprint. The velocity was real. The comparison to a ten-person engineering org is not. Both of those statements matter.
What is fair to say: one person, directing AI agents, shipped a real product - authentication, billing, job ingestion from a dozen sources, deduplication, skill matching, credibility scoring - in under a month. Five years ago that sentence would have been fiction.
One human
Let me get the "solopreneur" label right, because it hides the most interesting part.
JobIntel is built by one person. It is also built by more than twenty defined AI agent roles - an orchestrator, an architect, backend and frontend engineers, a billing specialist that is the only role allowed to touch Stripe code, a DevOps agent, QA, a read-only code reviewer, three adversarial red-team agents, and a separate eight-agent team that produces the content you are reading right now.
So what do I actually do all day? I decide. I review. I approve every production deploy personally - that is a hard stop in the process, not a courtesy. I catch the things the system cannot catch, and later in this article I will show you a case where that mattered. The agents write the code, run the tests, file the tickets, and draft the documentation. I am the editor-in-chief of a very fast, very literal engineering organization that never sleeps and occasionally does something spectacularly wrong at scale.
One night in April, the system filed 47 tickets and shipped eight architecture fixes to main while I slept. I woke up, read the log, and approved the ones that held up. That is the actual job now.
The numbers, as of July 19
The simple truth is that the codebase is now four to five times bigger than what launched.
- ~566,000 lines of code across the stack: about 229,700 lines of application code, 290,500 lines of test code, and 45,800 lines of infrastructure and CI code.
- Read that middle number again: there is more test code than application code - about 1.26 lines of test for every line of app. That ratio is not an accident. It is the only reason one person can operate this.
- 3,025 commits, 864 merged pull requests, 636 release tags.
- 481 API endpoints, 192 database migrations, 109 frontend pages, 257 React components.
- ~12,300 automated test cases: 7,786 backend tests, ~3,054 frontend unit tests, ~1,535 end-to-end browser tests.
- 26 production deployments since launch, 1,873 Jira issues filed, 1,737 of them done. 589 were bugs. I will get to those.
Five repositories, not one: the main product, a browser extension for nine job boards, a standalone enterprise pipeline, an internal workflow editor, and the content system.
The stack is boring on purpose
A fair question at this point: is this a real system or a demo wearing a trench coat?
It is a deliberately boring, enterprise-grade stack. Python and FastAPI on the backend. TypeScript, React, and Next.js on the frontend. PostgreSQL as the single source of truth - with pgvector for semantic matching and 192 versioned schema migrations behind it. All of it runs on AWS in containers, fronted by a load balancer and a CDN, and every change passes through two deployed environments - Test, then a production mirror - before anything touches production. Every piece of that infrastructure is defined in code: 15,000 lines of Terraform, 33 CI workflows, a twelve-service local stack that mirrors what runs in the cloud.
The security posture is the same story: Argon2id password hashing, MFA, passkeys, magic links, GDPR-grade data export and erasure. Not because a solo project needs to impress an auditor, but because the agents build to the standard you set on day one, and retrofitting standards is the most expensive work in software.
Nothing in that list is exotic. That is the point. The novelty in this project is who is writing the code and how it is verified - not the technology. Boring stacks are what let you sleep while a robot ships architecture fixes.
The process is the product
Before anything clever, the foundation: I follow the software engineering best practices that predate AI by decades, and I follow them more strictly than most human teams I have worked with can afford to. Test-driven development. Behavior-driven development - the requirements live as 436 executable scenarios that run with every build, not as a wiki nobody updates. Twelve-factor app principles: configuration in the environment, stateless processes, dev-prod parity across three environments. Code review on every change, continuous integration on every push, infrastructure as code, versioned database migrations. None of this is novel. What is novel is that agents never get tired of it - the practices humans abandon under deadline pressure are precisely the ones a machine applies on the ten-thousandth change with the same rigor as the first.
That foundation is what the rest of this section builds on, because none of the volume above works without process, and the process is where most of the real invention went.
Four tiers of validation. Every change passes a seven-minute local gate before push, a fifteen-minute blocking gate before merge, an overnight tier that runs the expensive suites - fuzzing, stress tests, security scans, accessibility - and files its own Jira tickets when something fails, and a rollup gate at every phase boundary. Production deploys are a separate protocol with my explicit approval, every time.
Progressive stabilization, environment by environment. A change earns its way to production by proving itself in progressively more realistic worlds. It starts on a Mac, in local Docker runners that mostly run in memory with external APIs mocked - deliberately unrealistic and blazingly fast, so thousands of tests finish in minutes and a broken idea dies seconds after it is typed. What survives moves to AWS-hosted test environments that mirror production - real containers behind a real load balancer, the real database engine, live integrations, the same infrastructure code that runs the live site. Only what survives that gets considered for production, through the deploy protocol with my sign-off. Each stage trades speed for realism, and each catches what the previous one cannot: the mocked suite catches logic errors for pennies, the mirror catches the configuration and integration failures that mocks are structurally blind to. The one time this discipline slipped - CI quietly testing a different engine configuration than production ran - it produced the worst bug in the failures section. Progressive stabilization is not a nice-to-have; it is what makes 26 production deploys by one person survivable.
And this focus on testing is not free - it is visible in two numbers you have already read. The 290,500 lines of test code that outweigh the application itself, and a meaningful share of that Anthropic line in the cost table: a large part of those tokens is agents writing tests, running tests, and arguing with failing tests. Quality is not a virtue here. It is a line item, and I pay it on purpose.
The clock never stops, and nothing waits. Most of a human team's cycle time is not work - it is waiting. Waiting for the reviewer to get out of a meeting, for the one specialist who is out sick this week, for Monday. Agents do not wait, and they do not make anyone else wait: review follows implementation in minutes, the fix follows the failing test the moment it exists, the handoff happens the second the previous step completes. A well-designed process runs at close to its ideal cycle time, because the agents simply execute it - step after step, without the coordination tax that quietly eats a human team's weeks. The operational rhythm is fixed and relentless: production monitoring every three hours, the full nightly test battery while I sleep, and every morning opens with a review of the Jira tickets the night shift filed. The factory runs around the clock; my day starts by reading its logs.
Test-first as a hard gate, not a value statement. A failing test must be committed before the implementation that makes it pass, and the gate checks the git history to prove it. If code lands without its failing test first, the sprint fails. This sounds bureaucratic. It is the immune system.
The documentation writes itself, literally. Tutorial videos are generated from markdown scripts: a pipeline takes screenshots of the live product with a headless browser, synthesizes narration - including a cloned version of my voice for some formats - and renders finished MP4s. When a flow changes, the videos regenerate. The user guide, FAQ, and their German, Spanish, and French translations are held in sync by CI checks that fail when they drift.
The system catches its own mistakes. The preview test suite once refused to go green on an authentication change that would have locked every admin out of production. A publishing gate once stopped a blog post with 23 unfilled placeholders from going live. These are not hypotheticals; they are logged saves.
Fail loudly, never silently. Half the failures later in this article share a single root cause: something broke quietly and kept smiling. A validation suite that stopped reporting and looked identical to healthy. A pipeline that returned success while writing nothing to the database. The doctrine that came out of those scars is simple: silence is never evidence of health. Every check in the system is now designed to scream - gates fail hard when they go stale, pipelines assert that real data actually moved instead of just returning 200 OK, and monitors alarm on absence, not just on error. A loud failure costs an hour of attention. A silent one costs three days and a user's trust. Choosing loud over silent is the single highest-leverage quality decision in this entire system.
Is it perfect? No, and the failures section below is longer than the bragging section above. That is deliberate.
The money
Here is what five and a half months actually cost, January 1 through July 18, in the five buckets that matter plus one honest catch-all.
| Category | Spend |
|---|---|
| AI - Anthropic (the agents) + OpenAI (embeddings, research) | $11,597 |
| AWS hosting | $4,545 |
| Social, marketing, design, and media | $4,765 |
| Domain names and DNS | $3,895 |
| Hardware | $3,723 |
| Everything else it takes - dev tooling, legal and LLC formation, job-data APIs, business insurance, contractor help | $6,495 |
| Total | ~$35,020 |
Some honesty about that table before the observations.
First, the number my personal-finance software reports for the "JobIntel" tag is $54,630. That larger figure sweeps in things like health insurance, airfare, and a coaching program - real money I spent, but not what it costs to build a SaaS, and I am not going to pad the headline with it. The table above is the business.
Second, the observations that matter:
The AI is the single biggest line item, and it is accelerating. Anthropic spend went $25 in January, $355 in February, $1,014 in March, $1,784 in April, $2,581 in May, $3,217 in June. That curve is the cost of the engineering team. For comparison, that entire June bill is roughly one week of a single mid-level engineer's loaded cost.
Hosting scaled nearly 8x in four months. AWS went from $167 in March to $1,269 in July as real users, real data, and real traffic arrived. Nobody puts the second number in their launch thread.
Domains cost more than you think. Nearly $3,900, most of it in one February week of registering the portfolio. A dumb tax, paid once, that everyone pays.
The recurring floor is real. Strip out the one-time costs - formation, logo, domain portfolio - and JobIntel's steady monthly burn is roughly $5,000-6,000 at current pace, dominated by AI and AWS. That is the number a solo founder actually has to reckon with, because it arrives every month whether or not customers do.
The napkin math against a human team. What would this have cost the old way? Back of the napkin: to build what shipped in these five months, I would have needed roughly five engineers for five months. Twenty-five person-months at a loaded cost of $12,500 a month is $312,500 - before hosting, before tooling, before anyone writes a test. Against $35,020 all-in, that is about a 9x difference. Call it the 10x everyone keeps promising; for once the meme number is roughly honest. It is a napkin, not an audit - my own time is not in either column, and a five-person team brings things an agent team does not. But the order of magnitude is the story, and it survives any reasonable adjustment to the assumptions.
The line item that is not in the table
There is one cost the table above does not capture, and leaving it out would make this article a lie of omission.
The entrepreneur part of this did not get automated. Seven-day weeks are the norm here, and eighteen-hour days happen more often than I planned for. That part of the story is as old as starting companies: you trade comfort for ownership of the outcome, with no guarantee the outcome is worth owning. I knew that trade going in. I signed up for it, and I am not asking for sympathy on a deal I chose.
What I did not fully anticipate is the version of it that agent teams create.
A human team goes home. The work has a natural cadence: things happen during working hours, and the night is quiet. Agent teams do not go home. The pipeline runs at 3 a.m. The nightly tier files tickets while I sleep. There is always a finished piece of work waiting for a decision, always a queue that got longer, not shorter, while I was away from the desk. And when your team works around the clock, there is a real gravitational pull to match it - because every hour I am not deciding, the machine is idling below capacity, and I can feel it.
The bottleneck in this way of working is not code. It is judgment. On a normal day I am the decision point for multiple teams at once - approve this deploy, reject that architecture, rule on this edge case, triage those nightly failures - dozens of calls a day, many of them consequential, all of them mine alone. That is a kind of cognitive load that writing code never produced in me. Code tires your focus. Being the sole judge of a tireless organization tires something deeper, and no amount of test coverage catches a bad decision made by an exhausted human at hour sixteen.
I do not have a neat fix to report. I have the honest observation: the tools removed the ceiling on how much one person can build, and in doing so they quietly removed the floor on how much one person can convince themselves they should be doing. Anyone selling you the solo-founder-with-agents dream without mentioning this is selling you half the story.
What went wrong
Everything above is the highlight reel. This section is why you should believe any of it.
I nearly locked in a $59,500-a-year AI bill with one CI misconfiguration. In April, my 30-day Anthropic spend hit $2,639 with essentially zero paying customers - about $163 a day. Hours of forensics traced most of it to an automated security-review workflow that ran on every single push. The fix took five minutes: run it on release tags only. The lesson took longer: I now run five separate API keys - production, staging, test, automation, laptop - so the next runaway shows up with a name tag. Saved about $1,000 a month.
A green pipeline did not mean production worked. In June, a fully green CI run coexisted with a bug that gave users 0% match scores. Three safety nets had failed silently at once: CI was testing a different matching engine than production ran; a validation suite had been failing for five days and then stopped reporting entirely, which looked identical to healthy; and the checks asserted that jobs existed rather than that they were scored. The rebuild after that one - config parity checks, gates that fail loudly when stale, assertions on outcomes instead of existence - changed how I think about the word "green."
A bug destroyed user data quietly for three days, and a user found it before I did. An over-broad exception handler in the enrichment pipeline quietly discarded database writes the rest of the system believed it had made, while the logs cheerfully reported success. A user emailed that his job descriptions were blank. The logs said everything was fine. The logs were wrong. If you want one story that summarizes operating software alone, it is reading "enrichment succeeded" while looking at the empty rows it did not write.
Checkout was silently broken in test environments for two months. The configuration held live-mode Stripe price IDs against test-mode keys - and the key in question authenticated to a sandbox account nobody realized was load-bearing. It was masked because monetization launched dormant and the unit tests mocked the payment SDK. Found in May, two months after the mistake. The pre-flip checklist that exists now exists because of this.
I built an entire enterprise module and then deleted it. A full enterprise-outplacement product - admin invites, white-labeling, GDPR controls, employer reports - shipped in mid-March and was removed over seven sprints in April, after the B2B strategy consolidated around career coaches and a security review found bugs on an attack surface nobody was using. Weeks of build, reversed. It survives as a standalone lead-gen pipeline, which is a polite way of saying I was wrong about who the customer was.
I built a robot that filed 133 bad tickets, and I turned it off. An automated UX-audit pipeline reviewed screenshots and filed issues. 88% of them were false positives. It could not be patched - the failure was architectural - so I shut it down, closed 128 tickets as won't-do, and kept the five real findings. Sometimes the honest move with a tool you built is to admit it does not work yet.
There are nine more of these in my lessons-learned file, which is 2,890 lines long and growing. The point is not the individual failures. The point is that every one of them now has a structural fix - a gate, a hook, a checklist item - and that the failures cost real money and real days, and nobody's launch thread mentions theirs.
The real unlock is failing fast
Put the napkin math and the failure list together and you get the actual headline of this era, and it is not "AI writes code."
In the old world, finding out whether a product had a market was itself a six-figure experiment. Five people, six months, $300,000 or more of salary and runway - just to put a first real version in front of strangers and learn whether anyone cared. That price tag is why startups were painful and slow, why founders needed permission from investors to even ask the question, and why so many ideas died in pitch decks instead of in production where they belong.
That constraint is gone. I put a working product in front of the market for the price of a used car, in twenty-four days, and I have been getting real answers ever since - some encouraging, some not, all of them cheap by historical standards. When I got an answer I did not like, I acted on it at the same speed: the enterprise module from the failures section is exactly this philosophy at the feature level. Build it for real, learn you were wrong about the customer, delete it, move on. Weeks, not quarters.
Fail fast used to be a slogan on a poster. Now it is a line item you can afford. If the market says no to JobIntel, I will know quickly, it will have cost $35,000 and five months instead of $300,000 and two years, and the next attempt starts from everything this one taught me. That trade is the single biggest change in what it means to start a company right now.
What $35,000 and 566,000 lines of code does not buy you
Here is the part that matters more than everything above.
JobIntel works. It ingests jobs from thirteen sources in nine countries, scores them for credibility, matches them against your skills, and does it fast - as of the May measurement, median response time was 10 milliseconds and uptime was 99.965%. It charges real money: $8.99 a month or $89.90 a year after a four-week trial. The engineering is real, the discipline is real, and the bills are real.
And none of that is product-market fit.
Product-market fit is people you have never met choosing to pay for the thing, month after month, because it solves a problem they would otherwise pay for in time or anxiety. No amount of test coverage produces that. No agent team ships it overnight. The napkin math above says building is now roughly ten times cheaper than it was - which means the technical implementation is no longer the moat, the proof, or the finish line. It is the entry fee.
That is the truth about building in public in 2026: the building part is increasingly the easy half, and I say that as someone who just showed you fifteen ways it went wrong.
I started this to answer a question I could not stop asking: could one person, working with AI the way an editor works with a newsroom, ship and operate software at a scale that used to take a team? The answer so far is yes.
What comes next is already decided: the next major development effort is a native iOS app. It is the right test of everything this article claims - a new platform, a new toolchain, the same one-human-plus-agents process - and when it ships, I will publish the same accounting for it that you just read: the timeline, the dollars, the mistakes, all of it, as its own case study.
Whether the whole thing becomes a business - that is the next retrospective. I will publish the numbers either way.
This is the follow-up to 3 Months of JobIntel: A Retrospective, and the origin story is in Building JobIntel with AI. If you are job searching and want the product all of this built: JobIntel - see every job, know if you fit.
Ready to take control of your job search?
Sign up for JobIntel — free.
Get Started Free