vampiregrey

Backend/infra engineer, was employee ~10 at a startup that grew to 500, want to do it again

I joined a startup when it was about 10 people and stayed through the growth to roughly 500. Most of that time I was on backend and infra.

Right now I'm at a large enterprise. I've learned a lot about systems that have to survive years and many owners, but I miss being able to ship something on a Tuesday because it needed to exist.

Stuff I've built: backend services and the infra, scraping and automation pipelines, AI-driven outreach and data enrichment.

Looking for seed to Series A, small team, close to the founders.

Location: Remote, or Open for Relocation

Portfolio/Resume: https://zerobitflip.com

Email: [email protected]

I've been using Claude Code as my primary agent orchestration tool for a few weeks now. Running cron-style loops for browser automation through a remote Playwright instance. Haven't tried Codex at this depth yet, but from what I've seen it's more focused on code generation while Claude Code is more of a general-purpose agent runtime. The things that make Claude Code powerful for me are the persistent session with tool access, the ability to run background tasks on schedules, and the hook/skill system for customization. If Codex matches that plus adds better async execution (Claude Code's scheduled tasks die when the session ends), it could be compelling. But for now Claude Code handles my use case better than anything else I've tried.

Interesting approach. I've been running a similar setup using Slack as the control plane for browser automation agents. The main challenge with messaging apps as control planes is handling long-running tasks and state management. Telegram's bot API is actually nicer than Slack's for this since you get more granular message editing.

Thank you !

Well deserved! this is a huge win for TS backend stack

I am still waiting for Mac Mini with M5

Location: India (Remote)

Remote: Yes

Willing to relocate: Yes

Technologies: Go, Node.js/NestJS, Python, AWS, Docker, PostgreSQL, Playwright, React/Next.js

Résumé/CV: https://zerobitflip.com

Email: [email protected]

Senior Backend Engineer with 5+ years building scalable systems across FinTech, EdTech, and AI. Currently at British Council architecting exam platforms for millions of concurrent users. Solo-built a Go-based scraping engine that extracts structured data from 200M+ company records, and an AI interview prep platform with 100K+ users (ProTechStack.com). No over-engineered stacks — Go, PostgreSQL, Playwright, and headless Chrome. Looking for early-stage roles.

Hey HN,

I’ve been building Solidclaw, a small local credential broker + model proxy for OpenClaw.

I started it because I was increasingly uncomfortable with:

API keys living in random .env files

Provider keys sitting inside OpenClaw configs

Tool secrets bundled directly into plugins

Credentials duplicated across services

It felt messy and fragile — especially when experimenting with multiple providers and tools.

So Solidclaw sits in front and handles:

Keeping provider keys out of OpenClaw

Isolating tool secrets

Scoping model access via tokens

Injecting secrets only at runtime

The idea is simple: clean separation between orchestration and secrets. Less key sprawl. Smaller blast radius. More explicit access control.

It’s very early stage and evolving fast. I’m iterating based on real usage while building AI infra tools.

If you're working with OpenClaw — or generally building local-first AI infra — I’d genuinely appreciate feedback, criticism, or ideas.

Happy to share architecture details if there’s interest.

I’m not sure I buy this framing.

I agree that reading every dependency isn’t realistic. But “not reading the code” as a principle feels risky.

In my experience, abstractions hold until they don’t. The first time you hit a production incident and the docs stop helping, reading the source stops being academic and starts being survival.

We once had a performance issue caused by a library making assumptions about concurrency that weren’t obvious from the API. The fix only became clear after stepping through the source.

I think the real skill isn’t avoiding reading code, it’s knowing when to escalate from trust to understanding.

For glue code or low stakes utilities, sure. For auth, billing, or core infra, I’d argue reading at least the critical paths pays dividends.

So last week I tried Gemini pro 3, Opus 4.6, GLM 5, Kimi2.5 so far using Kimi2.5 yeilded the best results (in terms of cost/performance) for me in a mid size Go project. Curious to know what others think ?

Majorly work with consumers.

Insights on this cat-and-mouse game are spot on. As AI evolves, watermarking might be a viable countermeasure. what detection methods/tools have you found most reliable in practice? I want to be able to detect and automatically block AI generated comments under my posts.

Great breakdown of the less-discussed downsides. In my experience with web auth, user education is key.

I just checked out Forgejo. I think i start with it, looks clean and lightweight. For my homelab I don’t have very large requirements. Might be a good starting point for me.

I think i will slowly start moving to self hosted git intra at my homelab.

At this point, GitHub outages feel closer to cloud provider outages than a SaaS blip. Curious how many people here still run self-hosted Git (GitLab / Gitea) vs fully outsourcing version control.

Software engineer who scaled a startup from 10→500, seeking early-stage roles

Location: India

Remote: Yes

Willing to relocate: Open

Technologies: Backend-heavy systems nodejs & go, distributed systems, infra & tooling, scraping and browser automation, AI-based outreach & enrichment pipelines, full-stack (backend-first), production systems at scale

Experience: Joined a startup early (~10 people) and worked through growth to ~500 employees. Currently working in a large enterprise environment, gaining experience with scale, process, and long-lived systems. Prefer early-stage teams where ownership and speed matter more.

Looking for: Early-stage startups (seed–Series A), ideally working closely with founders and owning systems from zero to one.

Résumé/CV: Available on request

Portfolio: https://zerobitflip.com

Email: [email protected]

Thanks for this!