Chapter 2: Disco Debt
After engaging with over 100 clients on greenfield projects in the past two years, I want to outline a macro trend that we consistently see leading to abandoned or grossly miscalculated projects: the misalignment of scope, timelines, and costs. I’ll give some context on our journey as a company and the ebb and flow of our progression.
When Tim and I started the company back in our dorm room, like anyone else, we had no idea what we were doing. A lot of our learning happened on the job. One of my biggest mistakes was explicitly saying to our team — and this was about a year ago now — “Just do whatever they want.” What a terrible idea. We were strapped for cash and had to take a back foot in the relationships, but this caused multi-month-long issues that cost us and our clients in the long run. In good faith, we — and the utmost credit to our team here — worked tirelessly to bring these projects to completion, foregoing payment and in some cases providing refunds. But man, did we learn a lot. Perhaps above all, and I think this translates to life as well: being the “nice” consultant was being the bad consultant. We should have given more pushback on scope early on. We should have taken harder stances. We didn’t, and all we could do was operate in good faith.
Now that this issue is clear to us, we encourage having those tough conversations up front with clients. We value honesty. We value transparency. And, being a true midwestern company, we value standing on our word. I’ll be extremely clear: if we can’t commit to something, we don’t. If we kick the can down the road, it will inevitably create problems for us but, most importantly, for our clients. We can’t and won’t commit to anything we can’t confidently deliver. Out of protection to our clients and ourselves, it is incredibly important to be — in some cases brutally — honest about what we can commit to. This is a value I aim to protect as we grow.
That said, this has become excruciatingly hard to uphold, mainly due to AI.
We are seeing a massive trend of projects coming in with pre-written requirements, as many clients formulate their requirements with AI. As mentioned in the previous chapter, these tools are downstream of the person orchestrating them — and they are ridiculously convincing. Many clients are coming in gaslit by AI into believing unrealistic expectations. The research backs this up: LLM hallucination — the generation of content that appears fluent and coherent but is factually incorrect or entirely fabricated — remains a persistent and well-documented problem [6]. A 2025 study in npj Digital Medicine found GPT-4o hallucinated at a rate of 53% on medical queries before prompt-based mitigation was applied [7]. OpenAI’s own September 2025 research paper acknowledged that current training objectives and evaluation benchmarks actively incentivize confident guessing over calibrated uncertainty, meaning models are trained to bluff rather than admit ignorance [8]. In legal contexts alone, judges worldwide issued hundreds of decisions in 2025 addressing AI hallucinations in legal filings — roughly 90% of all known cases of this problem to date [9].
I think this is best outlined with an example. I’m going to ask Anthropic’s Opus 4.5 how I should go about building a medical company that can get bought by Epic Systems.
Before I provide the example: I used to work for Epic. They have never bought a company. They never will. They specifically state that a core reason for their prominence is that they have never acquired a company and keep everything internal. This is formalized in Epic’s “10 Commandments,” prominently displayed throughout their campus, which include: “Do not go public. Do not acquire or be acquired” [26].
Me: How should I build a medical company that can get bought by Epic Systems?
Opus 4.5: Building a company that Epic Systems would want to acquire is a challenging but achievable goal. Here’s how to think about it strategically: Understand Epic’s Acquisition Philosophy. Epic has historically been very conservative about acquisitions — they prefer to build internally. When they do acquire, it’s typically for specialized technology, talent, or capabilities that would take too long to develop in-house. This means you need to build something genuinely differentiated…
The Disco Debt Cascade: How AI Misinformation Snowballs
┌──────────────────────────────┐ │ │ │ Client asks AI a question │ │ │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ │ │ AI gives a confident but │ Hallucination rate: up to │ incorrect answer │◄─── 53% on complex queries [7] │ │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ │ │ Client builds on false │ Hours of planning invested │ premise (snowball begins) │◄─── on a faulty foundation │ │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ │ │ Each follow-up compounds │ AI doesn't flag its own │ the original error │◄─── prior mistakes │ │ └──────────────┬───────────────┘ │ ▼ ┌──────────────────────────────┐ │ │ │ Client arrives with │ Emotionally & financially │ detailed but fundamentally │◄─── invested in wrong direction │ flawed plan │ │ │ └──────────────────────────────┘
I rest my case. “Achievable” — give me a break. “When they do acquire” — come on. Verifiably incorrect knowledge, and it snowballs. We’re seeing a massive influx of clients coming in completely misguided by AI, and you can often pinpoint the discrepancies because of the underlying technology. AI only knows what it’s trained on, and it’s only trained on public information. In the Epic example, the only place online I could find this information publicly documented was in the transcript of the Acquired podcast [27]. AI just took a guess — a fundamentally incorrect one.
In full transparency, AI does a decent job most of the time. That’s why we are an AI-native company. But the issue is that these conversations snowball. Take the above and assume you took Opus at its word. You could spend ten hours developing a business plan around an Epic acquisition — sinking time, emotions, and effort into a misguided goal — and then you bring it to us and we have to say it’s just not possible. We encounter this regularly: half-built vibe-coded prototypes that need to be scrapped, PRDs that are completely unfeasible, and frankly, a lot of wasted time. The term “vibe coding” — coined by Andrej Karpathy in a viral tweet on February 2, 2025, to describe the practice of letting AI generate code from natural language prompts without human review [25] — has exploded in adoption. Y Combinator reported that 25% of startups in its Winter 2025 batch had codebases that were 95% AI-generated [10]. But the risks are well documented: a Veracode study in 2025 found that 45% of AI-generated code contains security vulnerabilities [11], and a study of 120 UK tech firms found teams spent 41% more time debugging AI-generated code in systems exceeding 50,000 lines [12]. Mind you, the above example uses the most intelligent model on the market right now. If you use the free version of ChatGPT or a shady third-party company, these problems only get worse.
On top of that, a slight hiccup in your conversation cascades and compounds. For example: you’re planning a software implementation to aggregate logistics APIs together, but one of the APIs is not public, and you have to meet with the development team to get access to their documentation. In your conversation, the AI doesn’t flag this. It continues planning the application and allocates one week for that portion of development. Let’s also say a couple other core features depend on this API integration. So you go through the process thinking you have a solid timeline and plan — and of course it looks good and is convincing. But in reality, it’s going to take two weeks of back-and-forth just to get access to the private API. Then you might find that the dependent features are no longer possible because the API didn’t provide all the data you needed, or it costs $30K a month. By utilizing AI without guidance, you’re a hundred miles in the wrong direction. Pre-AI, you wouldn’t have been convinced to go there in the first place.
It’s a tough problem to solve all around. All we can do as a company is preface with clients that there’s a solid chance their documentation and planning is useless — which is still rough to deliver because of the misguided emotional and time investment.
Now perhaps the roughest part: when trust degrades in a relationship, clients can always turn to their forever-affirming AI companion to push back against our recommendations. And there’s always a consultancy down the block that will consume these ridiculous requirements, accept them, and enter into an impossible-to-complete project. Sometimes I find myself thinking that it would be a hell of a lot easier to just feed into the validation loop and bill monthly forever. But that’s not going to make me feel any better about myself, and that’s not good business. I would rather get into a screaming match with someone over an impossible project than bend. It always boils down to: we’re not in the business of taking people for rides. You want to spend $500K on an impossible project? Be my guest, but that’s not going to happen here.
So how this manifests into our process: a potentially abrasive expectation-setting process early on. Clear communication that most project assets we haven’t specifically curated are useless, and we typically have to start from a blank slate. If any client AI-planned documents are given to us, we might be able to use them to get a general idea of what they’re trying to build. And lastly, we make it clear: whoever owns the spec owns the project. It’s our job to get you to — or on the path to — your goal within your budget. If you think you know better than us, that’s fine. We can place a full-time member on your team that you manage, but we will not take ownership of the project.
Warning Signs: AI-Generated Client Documentation
Watch for these red flags when reviewing client-provided plans and requirements:
I’ll wrap this up by consolidating what these accumulated issues boil down to. The point of discovery is to determine what to build within budgetary and time constraints. Clients outline their vision and the problems that need solving. We take the reins from there. AI is pushing implementation and roadblock discovery closer to instantaneous, so we key in on the what.
If no discovery process takes place, you’re driving a race car into foggy terrain with no understanding of the landscape or whether you can even reach your destination. Unlike the horse-and-buggy era, you now run the risk of hitting a tree at 100 mph — spending months being gaslit into believing a project is feasible when it’s not. This is fun and exciting if you’re riding a go-kart with no cost or time implications. You’ll learn a lot. But it’s not recommended if there are real stakes.
If a non-expert-led discovery process takes place using AI for guidance, this is arguably worse. You’re given, in an extremely convincing manner, what the race track looks like — and it’s 85% correct, especially at the beginning. You start racing. You’re excited. Then there’s a tree stump that wasn’t on the map. No big deal. You start seeing a couple more weird curves. Still interesting. Then you drive off a cliff. As you fall into the abyss, you catch a glimpse of the other side of the ravine, and it’s exactly what the map showed. You were lied to.
If you go through an expert-led discovery process, that ravine is identified. At the very least, you know you can’t take that route. You discover an alternative path that takes an extra couple miles around the ravine. But it’s not a big deal, because you’re in an F1 car.
The Three Paths: A Visual Comparison
| No Discovery | AI-Guided (No Expert) | Expert-Led Discovery | |
|---|---|---|---|
| Metaphor | Driving blind in fog | Following a mostly-correct but flawed map | Roadmap with verified terrain |
| Speed | Fast start | Fast start | Slower start, fast execution |
| Risk | Unknown — could be fine, could be fatal | Hidden — 85% correct, 15% cliff | Identified — navigate around obstacles |
| Emotional State | Anxious but moving | Confident (falsely) | Informed and prepared |
| Outcome | Unpredictable | Predictable failure at scale | Predictable path to success |
| Best For | Side projects, no stakes | Never recommended | Real stakes, real budgets |
PATH 1: PATH 2: PATH 3: No Discovery AI-Guided Expert-Led ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ START │ │ START │ │ START │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ ▼ ▼ ▼ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ??? │ │ Looks │ │ Ravine │ │ (fog) │ │ great! │ │ found! │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ ▼ ▼ ▼ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ??? │ │ CLIFF │ │ Alternate │ │ │ │ │ │ route │ └─────────────┘ └─────────────┘ └──────┬──────┘ │ Unknown outcome. Predictable failure. ▼ ┌─────────────┐ │ FINISH │ └─────────────┘
Amongst our company, we’ve come to understand that we don’t care or judge what route our clients want to take. Some people just want to drive fast — nothing wrong with that at all. But then there’s no need for discovery. Let’s just get you a car and send you off by placing a full-time developer on your team that you fully manage. So long as they understand they can run off a cliff, go for it. But if you want that roadmap, we have to build the spec. We have to own discovery. Our client’s failure will not be on our hands.