Yesterday I shipped Talent Manager (the career-bot I've been building since the layoff) into actual production. Three daemons running, dashboard up locally, and a deeply stupid configuration bug that ate more time than I want to admit. Building in public means writing the embarrassing parts down too, so here we are.
What's actually running
Talent Manager is the system I'm using to run my own job search. Three daemons are alive in production as of April 16: one watching for new opportunities, one handling enrichment and scoring, and one keeping the pipeline state honest. The dashboard runs locally for now because I don't need a public surface for a tool that exists to serve exactly one user (me). If you've been wondering what I've been heads-down on for weeks, this is it. A career agent that does the parts of job searching I find soul-crushing, so I can spend my time on the parts that actually matter (talking to humans, writing, shipping).
The daemons are boring, which is what I wanted. They tick over, they write logs nobody reads, they haven't fallen over yet. Fine. The deploy was the embarrassing part.
The DB URL and env var thing that ate my afternoon
Here's the failure, named and specific: my local .env had the database URL in one format, and the production environment expected a slightly different one. Different enough that the daemons booted, reported healthy, and then quietly failed to do anything useful because they couldn't actually reach the DB. No loud crash. No red banner. Three processes humming along pretending to work.
Nobody warns you about this with daemonized background workers. A silent failure looks identical to a working system right up until you check the data an hour later and realize nothing's been written. I burned most of an afternoon on "is it the connection string, is it the env var name, is it how the daemon loads its config." Turns out it was all three at once, which is the answer I was hoping it wasn't.
The fix was unglamorous. I renamed the env var so local and prod stop disagreeing, made the daemon refuse to boot if it can't actually open a DB connection, and ripped out the silent fallback to defaults that was masking the whole problem in the first place. Should've done that on day one. I didn't, because when you're solo you tell yourself "config validation can wait," and later turns into the moment you're staring at three daemons that are lying to your face.
Why I'm shipping a tool for one user
A small contrarian take, since this is where people push back: not every personal project needs to become a SaaS. Talent Manager is for me. It's tuned to my job search, my preferences, my pipeline. If I tried to generalize it for "anyone looking for a job" right now, I'd spend the next three months building auth and billing and a settings page instead of, you know, actually finding a job.
The tool earns its keep by being useful to exactly one person on day one. If it turns out to be useful to other people later, fine, I'll deal with it then. But the urge to product-ize every working script is, in my experience, how AI builders end up with twelve half-finished platforms and nothing they actually use themselves. Build it for yourself, and stop there until "yourself" is genuinely getting value.
What I'm doing next
Hardening, mostly. The lesson from the env var disaster is that "process is running" is not a health check, it's a vibe. I want real checks: can the daemon actually reach its DB, is it actually consuming from the queue, has it written anything in the last N minutes. A daemon that's up but disconnected is worse than one that crashed, because at least the crash is honest with you. I also want better observability on the scoring daemon specifically, because that's the one whose output I act on.
If you're building agent systems and you haven't put loud, opinionated config validation at the top of every entrypoint, go do it now. Future you, staring at silently-broken daemons at 4pm on a Tuesday, will thank you. Past me would have.