In 2012, we were moving LemonStand from e-commerce software that customers installed on their own servers to a cloud product. My co-founder was our CTO and had built the original version. I trusted him completely on technology. As CEO, I led design and the product roadmap, handled marketing and community, and raised the money.
My co-founder knew our product inside out, but cloud architecture was new territory for him. Then we hired a developer who talked like he’d done it all. Silicon Valley startups. Advising on serious tech. He said he had exactly the experience we were missing.
He took initiative, started building the new version, and volunteered to lead the growing team. He was fun to be around and he gassed me up. We didn’t just hire a developer. We hired relief.
The demos always ran off his laptop. Nobody else could run the code. He explained that the setup was fragile: it combined real commercial services with simulated ones so we wouldn’t have to pay for full production infrastructure during early development. It was supposed to create an isolated environment for each new store and handle things like load balancing and backups.
The transition was a substantial engineering problem for our team. His explanation didn’t sound absurd to me. It sounded like a complicated development setup for a complicated product.
Meanwhile, his personal stories were starting to bother me. He mentioned flying to Boston with his dad for a playoff hockey game in box seats, like it was nothing. His parents supposedly owned multiple luxurious vacation properties. But I later learned his parents weren’t wealthy as he’d claimed. Some of his childhood stories also turned out to be eerily similar to movie plots.
I had reasons to question his credibility that had nothing to do with cloud architecture. But I still thought of him as someone who exaggerated. When I questioned his claims about the product, I imagined something less robust than he promised. I didn’t imagine that the demos themselves were fabricated.
And questioning him wasn’t just a matter of challenging someone who knew more than I did. It meant stepping into my co-founder’s area. I trusted our CTO to catch the technical problems I couldn’t judge. My co-founder, in turn, was relying on the cloud experience this developer claimed to have.
So I settled on what felt like a reasonable explanation. It probably needed more work than he was admitting. Production would expose some gaps. My co-founder would figure them out, and we’d hire someone else to help if we needed to.
I was allowing for exaggeration. I wasn’t allowing for fabrication.
Around month eight, my co-founder dug into the code. There was nothing substantial behind what we’d been shown. The demos were fake: they made it look as though systems were doing work that wasn’t actually happening. The developer quit before we could fire him. Two good engineers quit soon after. I had to tell our investors we had nothing to show for roughly a year of work.
I nearly gave up. The only reason I didn’t, honestly, is that I felt like I had no other options.
Later, I convinced Bruce Alderson to join as CTO, and he helped us rebuild. We eventually shipped, and years later Mailchimp acquired the company. We recovered, but none of that gave us the year back.
What does it mean to trust your gut?
It’s easy to tell this story as “I knew it was all fake and should have trusted my gut.” I didn’t know that. But I had noticed that his stories didn’t add up. I let my lack of technical expertise make me hesitant to question someone whose credibility I already doubted. I expected exaggeration and gaps in the work, not fabricated demos, and I trusted my co-founder to handle whatever needed fixing.
The personal lies weren’t about the product. That didn’t make them irrelevant to whether I should trust what he said about it.
Research on intuition doesn’t justify treating unease as a diagnosis. Daniel Kahneman and Gary Klein argued that reliable intuition depends on an environment with learnable patterns and an opportunity to learn them. Feeling certain isn’t evidence that your judgment is accurate.[1]
There were concrete reasons to investigate. Nobody else could run the product we were paying to build. There was an explanation for that, but we hadn’t independently established what was actually working.
I didn’t need to know the demos were fake to investigate. Even my more charitable interpretation deserved checking: if the product was less ready than he said, how much less ready? What would it take to find out?
That’s the distinction I’d make now. Take a concern seriously enough to investigate it without turning it into a verdict about someone. A plausible explanation can be worth considering without being enough to bet the company on.
Trusting my co-founder wasn’t the mistake
My co-founder was responsible for the technology. I wasn’t supposed to become a second CTO or go around him to manage his team. But I was the CEO, and my concern about the company’s main bet didn’t stop mattering because it crossed into his area.
I treated having someone responsible for the technology as if it meant my concern was already being dealt with. Those weren’t the same thing.
The concern I should have raised with my co-founder was specific: some of this developer’s stories weren’t adding up, and I wasn’t confident the product was as far along as he claimed. What could we independently verify? Where did we need help evaluating it?
The developer was responsible for deceiving us. My responsibility was to make sure my doubts became a question we actually answered, rather than an assumption that my co-founder would catch whatever needed catching.
During hiring, I’d use consistent, job-relevant questions and criteria rather than letting the conversation follow whichever stories impressed me. A 2022 reanalysis by Paul Sackett and colleagues reduced earlier estimates of how well hiring assessments predict performance, but structured interviews still ranked highest among the methods they examined. Useful evidence, not a guarantee.[2]
I’d also want to speak with people who had actually seen the candidate do comparable work. Those claims need to be verified.
But the checking can’t end when the person is hired. For a rebuild the company depended on, I’d agree with my CTO early on what we needed to see working, who would verify it independently, and by when.
If the architecture was outside both our experience, we’d bring in someone qualified to assess it. The point wouldn’t be to overrule the CTO. It would be to give us a better basis for the decision than the account of the person whose work we were evaluating.
None of that requires assuming bad faith. A good engineer can run into a genuinely difficult problem. I would want to know about that too, while there was still time to help.
Don’t stop at the demo
In 2012, he had to do his bullshitting by hand.
Now someone might use AI to produce a demo that genuinely works without understanding the problem it is supposed to solve. That isn’t necessarily dishonesty. Someone can sincerely believe in an answer they haven’t properly questioned.
I use AI to build things myself. It can help me work through a problem and challenge my assumptions. What I don’t want is to accept its decisions without understanding them well enough to question them. A working product is not much use if we haven’t understood what customers need from it.
When someone shows me their work, I want to get into the decisions:
- What customer problem are you solving, and how do you know it matters?
- Why did you choose this approach instead of the alternatives?
- Which constraints shaped the solution, and what did you give up?
- What would make you reconsider it?
A fluent answer isn’t enough. I’d follow it back to a specific decision and ask to see what supported it. Then I’d change a requirement and work through the consequences with them. I’m not looking for someone who knows everything. I’m looking for someone who can reason beyond the explanation they arrived with.
That matters when the work meets reality. If customers don’t respond as expected, can this person work out whether the implementation needs fixing or the original idea was wrong? Can they recognize that the thing they were asked to build might not solve the underlying problem? Asking AI for another version won’t help much if nobody questions what that version is meant to achieve.
This is the concern I explore in What Happens When AI Makes Thinking Optional?. Some of the work we’re tempted to skip is how we discover what we’ve misunderstood. I want AI to help me develop that understanding, not make it easier to get by without it.
Back at LemonStand, I didn’t need to become a cloud architect or go around my co-founder to manage his team. I needed to bring him my concerns and make sure we established what was actually working. The explanation for why the demos were difficult to verify should have been the beginning of that conversation, not the end of it.
I didn’t need to assume the worst. I needed to ask better questions, and make sure we checked the answers.