I'm a dragline operator at a coal mine in Wyoming. I work 13 hour shifts running heavy equipment. I've never written a line of code in my life.
Two weeks ago, I built A2Apex — a full testing and certification platform for Google's A2A protocol — from scratch. 15,267 lines of Python and JavaScript. Agent Card validator, live endpoint tester, state machine validator, auth testing, streaming verification, performance benchmarks. Plus a Python SDK, Stripe integration, and a landing page.
Here's the honest truth about how that happened, and what I learned.
The opportunity I saw
Google released A2A (Agent-to-Agent) protocol in April 2025. It's becoming the standard for how AI agents talk to each other. But there was a gap: nobody built tools for developers to test whether their agents actually comply with the spec.
Greg Isenberg (750K followers) posted about this exact gap. He called it “the trust layer” and said whoever owns agent reputation owns the distribution layer for the entire agentic economy. That's a $236B market by 2034.
I saw that post and thought: I can build the picks and shovels.
How a non-coder ships 15K lines
I used AI heavily. Claude, specifically. I described what I wanted, reviewed the output, tested everything manually, caught bugs my AI missed, and iterated fast. My 8-year-old son was asleep by 8pm and I'd build until 2am.
The key insight: I brought domain understanding that AI didn't have. I read the A2A spec front to back. I understood what developers would actually need. AI wrote the code; I architected the product.
What I got wrong
1. Tried to build too many features at once — should have shipped the validator alone first
2. Spent 3 days on logo iterations when a simple mark would have been fine
3. Built a demo mode nobody asked for instead of getting real agents to test
What worked
1. Building in public forced accountability
2. My wife and kids keep me grounded — I don't have unlimited time, so I prioritize ruthlessly
3. Launching on 10 platforms simultaneously for backlinks, not just traffic
4. Pricing at $29/mo for solo devs, $99 for startups, $499 for enterprise — simple tiers
Where I am now
Pre-revenue. 10 platform submissions . BetaList went live . MicroLaunch Thursday. HN this week. Product Hunt next.
I'm not quitting my day job yet. But for the first time, I have something real that I built, that solves a real problem, in a market that's about to explode.
My question for you: For those who've launched dev tools — did you focus on getting the first 10 paying customers through content marketing, direct outreach, or community engagement? What actually moved the needle early on?
The "AI wrote the code; I architected the product" line is the real lesson here. That divide is exactly where prompt quality becomes the bottleneck.
When you're iterating at 2am describing what you want to Claude, the structure of that description determines how much back-and-forth you burn. One thing that helped me: treating each AI request like a spec. Role, objective, constraints, output format as separate blocks rather than one long paragraph. Claude's attention responds to that structure even if the context window doesn't care.
I built flompt (github.com/Nyrok/flompt) around this idea, a visual prompt builder that decomposes prompts into 12 typed blocks and compiles to Claude-optimized XML. Useful for heavy Claude sessions like you described.
On your question about first 10 customers for dev tools: community engagement moved the needle earliest for me. Direct outreach to people actively discussing the problem, not cold DMs.
This is really impressive, especially considering you didn’t come from a coding background. It’s interesting how AI tools are lowering the barrier to building, but your point about domain knowledge still being the key differentiator really stands out. AI can generate code, but it doesn’t necessarily understand what users actually need or what the underlying problem is.
I’m curious how you approached validating the idea while building. Were you talking with developers in that space early on, or did you mostly rely on your understanding of the problem and the gap you saw in the ecosystem? It seems like that kind of feedback loop would be really important for something as technical as a dev tool.