We Did Demo Day. Nobody Got Automated.
May 13, 2026 · 6 min read
I flew to California last month to demo three AI tools for my team at DGW. I hadn't been in front of them in person in almost a year. Twelve years as a founder and it was the first time I was nervous walking into the building.
The nervousness wasn't about whether the demos would work. It was about the story the team was already carrying into the room.
The story is in the headlines every week. Thousands laid off. Departments replaced by automation. The word "efficiency" used as a synonym for fewer people. Whether or not anyone on my team had said it out loud, that story was in the room before I was.
DGW is a small team. There is no one to replace. Every person on this team is load-bearing. If I build a tool that replaces someone's function, I haven't gained capacity. I've lost a person and inherited their job.
So before I touched a keyboard, I named it. I told the team this isn't what we're doing here. The goal is not to run the business we have with fewer employees. The goal is to grow the business we have with the employees we have, without anyone burning out or being asked to carry more than they can manage.
The frame is capacity. Not replacement.
The three demos came from months of conversations with the team. I asked what was taking the most time. What information lived in their heads that nobody else could access. Where they were starting from scratch on work they'd done a version of before.
The common thread wasn't process. It wasn't speed. It was context. Institutional knowledge locked inside individual people, scattered across Google Docs, spreadsheets, Slack threads, and email. Too costly to document on a per-project basis, so it never got documented.
That insight reframed the project. The path to capacity in a small team isn't automating tasks. It's sharing context.
The first demo was the simplest. I took everything spread across those surfaces and brought it into one searchable knowledge base. Markdown files. No AI. Just consolidation.
The team's reaction wasn't polite nods. It was ideas. What else could live in there. Vendor notes, decoration costs, preferred pricing. They started filling it before the demo was over.
The second demo was a vendor directory. We have hundreds of vendors. Everyone has their favorites, their go-to products, their preferred decorators. All of it in their heads. The directory surfaced what was scattered: notes, contact info, preferred-vendor status based on volume. A wizard takes garment count, decoration method, and timeline and returns the best decorator for the job.
This one hit harder because sourcing is one of the most time-consuming parts of the business. The team could see the hours.
The third demo was a product search agent. It takes a raw client brief, an email, a conversation, whatever form, and breaks it into product categories, searches vendor databases, and layers on our own team context from the vendor directory. Education accounts sometimes request proposals with thirty different products, each one searched individually. The agent does it in minutes.
That got the biggest response. Not because it was the most technically impressive, but because it touched a daily pain point everyone on the team shared.
Here's what I didn't expect. I showed the three tools as separate demos. Within a couple of hours, I realized they were one system. The knowledge base is the connective tissue. Vendor decisions update the knowledge base. The product search pulls from the vendor directory. Client conversations feed back into notes.
It's not three tools. It's a living layer of shared context that grows with the team.
Capacity is the outcome. Context is the mechanism. You give people hours back by giving them access to what someone else on the team already knows. That's the system, not three demos.
The clearest signal that it worked came days later. Someone in a public Slack channel made a vendor decision and immediately said it should be updated in the knowledge base. Not because I asked. Not because there was a policy. Because the tool had already changed how they think about sharing information.
That's adoption. Not a training session. Not a mandate. A reflex.
The conversation in this industry is about which roles AI can automate. That's the wrong question for most teams. If you run nine people, or fifteen, or fifty, you don't have roles to automate. You have people who are doing too many things and don't have enough hours.
The right question is what each person knows that no one else can get to without asking them. The path to capacity isn't building tools that do what your team does. It's building tools that share what your team knows.
The frame has to be in the build, not just in the demo.
Nobody's role changed. What changed is that the team has access to what used to live in one person's head. The hours they were spending recovering context they didn't have are starting to come back.
The goal was never fewer people. It was more from the people we have.
Your team can tell the difference.
P.S. If you've run a demo day for a small team and watched the room shift, or watched it not shift, I'd like to hear what happened. Reply to this one.
Get new posts delivered to your inbox.
Read more posts →