What an AI-Assisted Spike Taught Us About Selling Software

Earlier this year, we were in conversations with a potential client about a vehicle history lookup tool- a web app where dealers and buyers could enter a VIN and pull up maintenance records, inspection history, and coverage status. To move the conversation forward, we scoped a spike: a focused build to make the concept tangible before anyone committed to a full project. We estimated around 20 hours of developer time.

I built it in five hours as the Software Delivery Manager (not a developer). Here's what made it possible.

We've invested in how we work with AI

Over the past year, Planet Argon has built a library of Claude Code skills designed around our Rails development standards. These cover the decisions that usually slow teams down at the start of a project: how we structure applications, our naming and testing conventions, and the opinionated choices we've made about tooling over years of building Rails apps.

The goal was to make agentic coding consistent and maintainable, not just fast.

When I started the spike, those skills were the starting point. The result wasn't a throwaway prototype. It was a Rails 8 application built to our house standards, with proper data modeling, tests, and a clean Tailwind interface. If this project moves forward, a developer picking it up won't need to untangle experimental code or make guesses about how it was put together. The continuity is already built in.

Discovery work is what gives the AI direction

Before writing any code, we did the preparation that made everything else possible. We aligned on a thin slice, one end-to-end flow worth validating, and wrote it down in a shared document. We researched comparable tools in the space, studying how they present vehicle data and what makes a record feel credible to someone in this industry. We had transcripts from our discovery calls with the client, including the specific language they used to describe their own product.

All of that context went into the build. The interface reflected the client's terminology, the information hierarchy we'd discussed, and the layout patterns we'd seen in competitive research. That level of specificity doesn't happen by accident, and it doesn't come from prompting an AI with a vague brief. The discovery work is what gives the model enough to go on and what separates output that feels considered from output that just feels generated.

A working app changes the sales conversation

We deployed the spike to a public server before our next client call. The client could enter a VIN, see a vehicle image loaded from an external API, scroll through their inspection history, and download a PDF report- all in a real, running application, even if the underlying records were seeded data.

For clients who don't have a technical background, this matters more than most developers realize. Asking someone to evaluate a written proposal or click through a mockup is asking them to imagine something they've never seen. Handing them a working URL removes that entirely. Our conversation moved from "does this sound right?" to "what happens when I do this?" — which is a much more productive place to be in a sales process.

Scope discipline is still the hard part

None of this works if the scope gets away from you. The spike covered one thing: VIN lookup. No user accounts, no admin tools, no reporting. Within that narrow focus, though, every detail was deliberate- the layout, the language, the structure of the inspection timeline- all drawn directly from the discovery work we'd done beforehand.

Claude Code is very good at following specific directions. The house skills give it a strong foundation, and the discovery work gives it the context it needs to produce something that actually reflects a client's vision. Where things go wrong is when that foundation or that context is missing, and the model is left to fill in the gaps on its own.

What's shifting

We scoped this as a 20-hour developer spike. It took five hours, completed by someone who doesn't write production code for a living. That compression is real, and it's going to change how agencies like ours approach the early stages of a sales conversation.

What makes this different from a typical quick prototype, though, is what happens next. Because the spike was built on Planet Argon's house skills and Rails standards, any developer on our team can open this codebase and immediately understand what they're looking at. The structure is familiar, the conventions are ours, and the code is clean enough to stand up to real scrutiny. This isn't a spike that produces exploratory code to be discarded if the project moves forward. It's a starting point that a senior developer could pick up tomorrow and build on with confidence.

That changes the math significantly. We can deliver something tangible early in the sales process, at a fraction of the estimated cost, without creating a liability down the road. Discovery still matters. It may matter even more now than it did before, because the quality of the inputs determines the quality of what gets built. But teams that invest in their AI tooling, hold to their development standards, and do the discovery work carefully are going to find the distance between "here's the idea" and "here's the thing" keeps getting shorter.

If your team is starting to work this way (or wants to), we can help you do it without inheriting a mess. Learn more about our Agentic Coding Enablement service, or get in touch.