Building Shotgun: From First Commit to First Customer in 31 Days

Introduction

In a previous post, I wrote about building Proofs, an AI software development agent that could reliably produce full-stack Shopify POCs. It was solid tech, but the AI coding landscape moved fast. Cursor, Windsurf, Claude Code, and others flooded the space while we were heads-down building. By the time we looked up, we were surrounded by competitors with larger teams and deeper pockets.

The team decided to pivot. Rather than compete in the crowded AI coding agent space, we’d take what we’d learned and build something more focused: Shotgun, a CLI tool for AI-assisted development.

What followed was a lesson in what happens when you over-engineer a pivot, and what happens when you strip everything back and just ship.

Shotgun Alpha: Lessons from the First Attempt

The initial version of Shotgun was built as an Ink (React) CLI frontend paired with a Python API running persistently in the background. To install it, users had to run a script that pulled in Node, nvm, and uv. It was a heavyweight setup for what should have been a simple developer tool.

Enterprise users flat-out refused to install it. Their security policies wouldn’t allow a script that silently installed multiple runtimes and ran a persistent background process. The friction was enormous.

The deeper problem was that the tech stack was driven by team preference rather than user needs. There was no reason for a Python backend; the team just preferred working in Python. The entire codebase was hand-crafted from scratch with no external libraries. Everything was custom, everything was bespoke, and none of it served the end user.

Without a consistent shipping cadence or user feedback loop, the team was building infrastructure that felt foundational and important, but none of it was reaching actual users. Runway was burning.

The “Build Your Own Framework” Trap

This is a pattern I’ve seen repeatedly and it’s worth calling out directly. Engineering teams, especially talented ones, love to build frameworks. It feels like important, high-leverage work. “If we just get the foundation right, everything else will be easy.”

It’s a trap. Here’s what actually happens:

You spend months building a reusable framework
You build a product on top of the framework
The product doesn’t quite fit the framework’s assumptions
You spend more time adapting the framework than you would have spent just building the product
A competitor ships something ugly but functional while you’re still perfecting your abstractions

At a startup, shipping speed is survival. Every week you spend on infrastructure that doesn’t reach users is a week where a competitor is learning from real feedback and you’re not.

Shotgun CLI: My Pivot

After watching the Alpha stall, I pushed for a fundamental rethink. Not an iteration, a clean break. The pitch was simple: build a clear, precise product that reuses existing frameworks instead of reinventing them.

I proposed it, led it, and built it.

The biggest technical decision was adopting Pydantic AI as the agent framework instead of building our own. This one choice eliminated months of infrastructure work and gave us a battle-tested foundation that someone else was maintaining and improving. We could focus entirely on the product layer, which is the thing users actually care about.

The result: first paying customer 31 days after the first commit. Not 31 days after launch. 31 days after git init. The tool has since grown to over 700 developers with 600+ stars on GitHub. Check it out for yourself.

Shipping at High Tempo

Getting to that first customer was just the beginning. What made Shotgun CLI stick was the pace of iteration after launch.

For months, I pushed out one major feature every single week. Not refactors, not internal improvements. User-facing features driven directly by what developers were asking for. Someone would request something on Monday, and it would be in the next release.

On average, I ship a new release every two days. That’s not a sprint. That’s a sustained cadence over months of development.

I do 100% of this development with Claude Code and with Shotgun itself. I use Shotgun to write specs, then hand those specs to Claude Code to implement features on Shotgun. The tool builds itself. That’s a large part of how one person can maintain this kind of output. The combination of a well-scoped product, a solid framework (Pydantic AI), and AI-assisted development means I can move at a pace that would normally require a much larger team.

This is the real unlock: when you keep your product focused and your stack simple, you can actually leverage AI tooling to its full potential. Over-engineered codebases with custom frameworks and layers of abstraction are harder for AI to work with. A clean, straightforward codebase built on well-documented libraries is exactly what AI-assisted development excels at.

The MVP Principles That Made It Work

Looking back, a few principles made the difference between Alpha and CLI:

Optimize for fewer knobs. Every setting you add is something you must support, document, and test. Temperature, top P, top K… do your users actually need to configure those? Every OAuth provider you support doubles your testing surface. The reward function should optimize for fewer buttons, not more.

Verify the problem first. Before building anything, make sure it’s actually a problem. Use the “mom test”: can you explain what you’re building and why to someone non-technical, and does it still sound like it solves a real problem? If you can’t articulate who needs it and why, you’re building for yourself.

Ship 0 to 1 as fast as humanly possible. Accept duct-taped solutions that provide value quickly. A working tool with rough edges beats a polished tool that doesn’t exist. You can always clean it up after you’ve validated that someone actually wants it.

Reuse, don’t rebuild. Pydantic AI gave us a production-ready agent framework. We didn’t need to build our own. The time we saved went directly into product features that users could see and use. Standing on the shoulders of well-maintained open source is not a compromise. It’s a competitive advantage.

Respect competitive pressure. Bigger companies will outship you if you take too long. Smaller companies will go more niche. The window for a startup to establish itself is narrow, and every week spent on internal infrastructure is a week you’re not in the market.

What I Look For When Building a Team

This experience reshaped how I think about hiring engineers. I focus on four traits:

Shipping: Do they deliver quickly? Not “are they fast at coding” but do features actually get into users’ hands?
Listening: This is the most important quality. Can they hear what users and teammates are actually saying, or do they dominate every conversation with their own ideas?
Constraints: Can they work within limitations? Budget, time, scope. Can they build something good within what’s available?
Simplicity: Do they avoid overcomplicating? When given a problem, do they reach for the simplest solution or the most architecturally interesting one?

AI has made building anything possible. Any engineer with the right tools can produce an enormous amount of output. That makes focus and constraint more critical than ever, not less. The bottleneck is no longer “can we build it” but “should we build it, and can we ship it before it stops mattering.”

Conclusion

The difference between Shotgun Alpha and Shotgun CLI wasn’t talent. It was approach. The discipline to reuse instead of rebuild, to ship instead of polish, and to listen to users instead of building what felt important internally.

Sometimes the best engineering decision is to build less. Use the framework someone else is maintaining. Ship the ugly version. Get it into users’ hands and let their feedback tell you what to build next.

Thirty-one days from first commit to first paying customer. One major feature a week. A release every two days. That’s what happens when you stop over-engineering and start shipping. If you want to see the result, give Shotgun a try.