Confessions of a Reluctant Infra Founder: Staying Focused on What Matters
There’s this voice in my head that keeps whispering: “You know what would be really cool? Building your own container orchestration system. From scratch. With custom networking. Maybe throw in a database layer too.”
I’m here to confess: the temptation to build Layer 2 infrastructure is real, and it’s seductive as hell.
The Two-Layer Trap
Here’s the thing about building developer tools: there are essentially two layers you can focus on.
Layer 1 is agent infrastructure for the full software development lifecycle. We’re talking requirement analysis, coding, building, testing, deploying, monitoring—the whole pipeline. The focus here is on reliability, context engineering, and agent capability. It’s about orchestrating the workflow, not reinventing the wheel.
Layer 2 is the actual infrastructure underneath: headless backends, container management, custom deployment platforms, database provisioning, the works.
Both are legitimately useful. Both have their place. And here’s the kicker: Layer 2 is way more fun to build if you’re an infrastructure nerd (guilty as charged).
Why We’re Deliberately Staying at Layer 1
At JustCopy.ai, we made a deliberate choice: nail Layer 1 first. Make it world-class. Wait for actual customer demand before even thinking about Layer 2.
Why? Because Layer 2 is already solved by people who are really good at it. AWS, GCP, Azure, Netlify, Vercel, Railway, Fly.io—these teams have spent years (decades, in some cases) making their infrastructure bulletproof. They’ve hit every edge case. They’ve optimized for performance. They’ve built support teams.
We’re not going to out-AWS AWS. That’s not hubris talking; that’s just math.
What we can do—and what we’re betting the farm on—is build agents that are legitimately better at wrangling all these tools than a human developer fumbling through documentation at 2 AM.
The Agent Orchestra
Right now, we have 7 specialized agents. Think of them as different members of a development team, each with their own expertise:
- Requirement analyst (figures out what the hell you actually want to build)
- Architect (makes the high-level decisions)
- Developer agents (write the actual code)
- Test engineer (breaks things before users do)
- DevOps specialist (gets it deployed without breaking production)
- Monitor (watches for fires)
- Production support (puts out fires)
The magic—and this is where it gets interesting—is in how they hand off tasks to each other. It’s not just a linear pipeline. The test engineer can kick work back to the developer. The monitor can alert the production agent. The requirement analyst can clarify ambiguities before anyone writes a line of code.
It’s a mesh, not a waterfall. And making that mesh work reliably is hard.
What We’re Actually Working On
Our current obsessions:
Context engineering: How much context does each agent need? Too little and they make mistakes. Too much and they get confused (or your Open Router bill explodes). Finding the sweet spot is part art, part science, and mostly just grinding through iterations.
Agent reliability: When an agent makes a decision, how do we verify it didn’t just hallucinate a function that doesn’t exist? How do we gracefully handle failures? How do we make sure the handoff between agents doesn’t drop critical information?
These aren’t sexy problems. They’re not going to generate breathless TechCrunch articles. But they’re the difference between “neat demo” and “actually useful tool.”
The Learning Mindset
Here’s what I’m discovering: building AI agents is less like traditional software engineering and more like... training a junior dev? You can’t just write specs and expect perfect execution. You need to observe, adjust, give feedback, iterate.
Some days our agents do things that genuinely surprise us in a good way. They find elegant solutions we wouldn’t have thought of. Other days they confidently do something completely boneheaded, and we have to figure out why.
It’s humbling. It’s frustrating. It’s also deeply engaging in a way that’s hard to articulate.
The Layer 2 Question
So when will we build Layer 2? Honestly: maybe never.
If we nail Layer 1—if our agents become legitimately better than humans at orchestrating Vercel and AWS and GitHub Actions—that might be enough. That might be the whole business.
Or maybe six months from now, we’ll have dozens of customers saying “this is great, but we need X custom infrastructure feature,” and we’ll realize there’s genuine demand for Layer 2 built specifically for agent-driven workflows.
The point is: we’re letting customer needs drive the decision, not our engineering egos.
What This Isn’t
This isn’t a “we’re disrupting infrastructure” post. We’re not trying to replace AWS or Vercel. We’re grateful they exist.
This isn’t a “our AI is magical” post. Our agents make mistakes. We’re fixing them daily.
This is a “here’s what we’re learning while trying to build something useful” post. We’re figuring this out as we go, same as everyone else in this space.
The Unsexy Truth
Building developer tools in 2025 means resisting the urge to rebuild everything from scratch. It means integrating with best-of-breed tools, even when building your own would be more fun.
It means focusing on the one thing you can actually do better than anyone else—in our case, agent orchestration and reliability—and being okay with “just” doing that thing really, really well.
The siren song of Layer 2 is still there. Some days it’s louder than others. But for now, we’re stuffing metaphorical wax in our ears and staying focused on making our agents not suck.
That’s the goal: agents that don’t suck. If we can achieve that, everything else is just implementation details.
---
Thoughts? Pushback? Hit me in the comments. Especially if you think we’re totally wrong about the Layer 1/Layer 2 split—I’m genuinely curious to hear other perspectives.