The tool I built because I got tired of waiting

Every solutions engineer has a version of this Sunday night.

You have a demo on Tuesday. The assets exist, technically. There is a deck on SharePoint, a recording someone shared on Drive, a live environment that may or may not still have the right data, a spreadsheet with the business case numbers that only one person in the region actually understands, and a link to a walkthrough that expired three weeks ago. None of it is in the same place. None of it is in the customer’s language. And when you finally get in front of the buyer, half of what you show has nothing to do with what they asked for.

That is not a tooling problem on the surface. It looks like a coordination problem, and so for years I treated it like one. More folders. Better naming conventions. A Confluence page that nobody read.

DemoStacker started because I stopped pretending that was going to work.

It started very small

The first version was not a platform. It was a cloud savings calculator.

A customer had asked a fair question in a meeting, roughly “what does this actually save us”, and the honest answer was that we had the numbers somewhere but not in a form I could hand over. So I wrote a spec for a small three-step calculator with lead capture and a clean PDF export. One component. One job. Something I could put on a screen without having to apologise for it.

That thing worked. And the moment it worked, the obvious next question arrived: if the business case can live in a browser and travel with the deal, why is everything else still scattered?

So it grew. A multi-format content viewer so a demo, a video, a dashboard and a document could sit under one topic-based navigation. An annotation layer so I could mark up a screen live in front of a customer instead of waving a cursor around. Six languages, because I work with field teams across LATAM, EMEA and APAC and “just present in English” is a quiet way of losing credibility. Admin controls. And the one that surprised people was a USB bundle generator, because I have walked into enough air-gapped and locked-down customer sites to know that “it’s in the cloud” is sometimes the end of the conversation.

None of that was on a roadmap. Each piece got built because a real demo went badly in a way that a small feature would have fixed.

www.demostacker.com

Why I kept going

Here is the thing about presales that I think gets misunderstood outside the discipline.

For the buyer, the demo is the product. They are not evaluating your architecture diagram or your analyst placement. They are evaluating the 20 minutes they spent watching someone try to get your software to answer their question. If those twenty minutes are disorganised, they conclude the product is disorganised. That inference is unfair and it is also completely rational.

So the quality of the demo surface is not a nice-to-have for a sales engineer. It is the job. I got tired of the gap between the standard I hold myself to in a room and the tooling I had to hold it up with.

Where Claude came in, and what it actually did

I should be clear about something, because this is where these stories usually go wrong.

I do not build software for a living. I am a solutions engineer and an advisor. I have spent close to two decades in enterprise data and analytics, which means I have exceptionally strong opinions about what good looks like and a very ordinary ability to hand-write a Next.js app at speed.

Claude closed that gap. Not by being a code vending machine, which is the version of AI-assisted building that produces a demo-quality prototype and then collapses. What actually worked was treating it like a very fast, very literal engineer who needed a proper brief.

My unit of work became the spec, not the code. A markdown document with the concept up front, the context of anything I had already tried and failed at, sequenced build instructions, an explicit list of what was deliberately out of scope, and a testing checklist for each phase. Then Claude Code built against it. I reviewed, tested, sent it back, and refused to move to phase three until phase two was actually working in production.

Two habits did most of the heavy lifting.

The first was writing down what I was choosing not to do. Every spec had a section saying “related pattern, not in scope”. Without it, every review turned into a conversation about oversights that were actually decisions.

The second was slowing down. There was a point where I had video frame extraction working, sort of, and it was producing duplicate frames. The fast option was to ship it and file the annoyance. Instead, we pulled it apart and rebuilt it properly with dense sampling and perceptual deduplication. That is the unglamorous half of vibecoding that nobody posts about, and it is the half that decides whether you end up with a tool or a toy.

The honest summary is that AI gave me build velocity. It did not give me judgment. The judgment came from twenty years of watching demos succeed and fail, and that turns out to be the scarce input.

The part where it stopped being a side project

I never pitched DemoStacker internally. It just kept showing up in other people’s deals.

The comparison came up naturally because the commercial tools in this category are good, and we had looked at several of them. What became apparent in side-by-side use was not that my version was technically superior. It was that it was built by someone who does the job, for the way the job is actually done. The competitive products are built for a generic demo motion. Mine was built for our motion, with our semantic layer behind it, in the six languages our field teams present in, and with an offline path for the customers who cannot take a SaaS URL.

That is a very hard gap for a vendor to close and a very easy one for a practitioner to fill.

Which is how I ended up in conversations about production, not prototypes. The thing that started as a Sunday project is now going through the work that real internal platforms go through: Entra ID single sign-on instead of my own auth, managed Postgres instead of a hosted database, container hosting with infrastructure as code, CI/CD, proper secrets management, and a governance review about which AI provider is allowed to see customer screenshots and where that inference is allowed to run.

That last one deserves its own post. The moment a personal tool becomes an organisational one, the interesting questions stop being technical and start being about decision rights.

Who approves what?

Who is accountable when the tool is wrong?

It is the same question I am now formally researching at the doctoral level, and I did not expect my own side project to become the case study.

What I would tell another practitioner

Three things.

Build for the workflow you personally live inside. Your advantage over a product team is not engineering. It is knowing which fifteen seconds of a demo actually lose the deal.

Specs beat prompts. If you cannot describe the build in a document that another person could execute, the AI will produce something that looks right and behaves badly.

Assume it will become real. The scariest part of this whole project was not the building. It was the day someone asked for the security review, and I had to go and look at what I had made with adult eyes. Build like that day is coming, because if the tool is any good, it is.

DemoStacker is still moving. There is a Chrome capture extension, a demo coach, CRM context flowing in and out. I will write about those as they land.

But the origin story is just this: I had a job I cared about doing well, the tools were in my way, and for the first time, the distance between having an opinion about software and having software was short enough to walk.

~ Mr. Gomez