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.
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.
I mostly use claude code for coding purposes. According to my experience, claude code is unbeatable in terms of coding and UI. But I feel like chat gpt is better for architectural decisions. But I haven't tried codex, BUT I am listening a lot now that its limits are far better than claude code and that it is good in terms of value for money.
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.
agreed. the long-running tasks i handle with immediate-background and continually edit message with updates, along with fork-and-reconcile semantics so you don't have to queue messages. also having a supergroup with separate topics for different sessions works really well.
the separate topics approach along with allowing other processes to enqueue messages into the session stream solves state pretty tidily, see "the session as decision-maker" in the linked report
Backend Engineer at British Council, architecting Agentic AI systems for one of the world's largest cultural organizations. Building AI agent orchestration layers and LLM-powered backend services that automate complex examination workflows across 100+ countries. Previously built a FinTech SaaS from zero at Marquee Equity and solo-shipped an AI-powered interview prep platform (ProTechStack.com)
I’ve always felt they weren’t really worth it for performance per dollar spent. For C++ work I just use a non-Mac workstation. For lighter workloads the Mac Mini is very capable already.
The Studio (Stud IO™) is the new Mac Pro - it's not "worth it" unless you need the most performance period - or you have money to spare.
Or you really, really need to drive eight displays from a single machine.
For "home user" stuff a Mac mini or MacBook is going to do everything you ever need (in fact, they have the problem where the M1 systems are still perfectly capable, six years later).
You think they will skip M4 ultra? May be they slowly plan to launch ultra chips alternate years since the development costs are high and demand is niche.
If they do a 1TB m5 ultra, I too would be configuring one for sure.
I hope so! I already have the M4 mini pro - would like to bump up the prompt processing time and the memory bandwidth at the same time with the new M5 matmul changes.
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.
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.
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: shubham.maurya.co@outlook.com
reply