417 points on Hacker News. Not for a new framework, not for a benchmark, not for some hot take about AI replacing developers. For a post about a guy who went and killed bugs. Real ones. With chemicals.
The post, titled "I wanted to build vertical SaaS for pest control, so I took a technician job," hit the front page and stayed there. The reason it resonated so deeply with the developer community isn't hard to figure out. Most of us have built software for industries we've never set foot in. We've all felt that quiet dread of realizing, mid-sprint, that we fundamentally misunderstood how the work actually gets done.
I tracked down the founder behind the post to talk about why he chose the hard path, what he learned crawling under houses, and why the vertical SaaS playbook might be broken.
The Conversation
You had the technical skills to start building immediately. Why didn't you?
Because I'd already tried that once. Not in pest control, but in a different vertical. I spent eight months building features that looked great in demos and made zero sense in the field. The technicians hated it , not because it was buggy, but because it added friction to a workflow I didn't understand. I was solving imaginary problems.
So when I decided to go after pest control, I made myself a rule: no code until I could do the job myself.
Five months killing bugs , what made you finally stop and start coding?
About five months. Long enough to get certified, long enough to get stung by wasps more times than I'd like to admit, and long enough to understand why existing software in this space is so bad. The tools these companies use were clearly designed by people who have never ridden in a service truck.
What's the single biggest insight the job gave you that no interview ever could?
Timing. Everything in pest control revolves around timing and routing. The difference between a profitable day and a losing day often comes down to how jobs are sequenced. But here's the thing: the technicians already have this figured out. They've optimized their routes through years of muscle memory. The existing software actively fights that intuition instead of supporting it.
You can't learn that in a customer interview. A technician will tell you "the scheduling tool sucks." They won't tell you *why*, because they don't think in software terms. You have to ride along. You have to feel the frustration of arriving at a job and realizing the dispatch software didn't account for the twenty minutes of setup required for a termite treatment versus a simple spray job.
The Hacker News community responded strongly. Why do you think this hit a nerve?
I think developers are tired of building in the dark. There's this whole lean startup methodology that says "talk to your customers," and that's good advice. But talking is not the same as doing. In the Hacker News discussion, dozens of commenters shared stories of building products for industries they didn't understand. The pattern is always the same: ship something reasonable-looking, watch adoption stall, realize too late that you missed something fundamental about the workflow.
Five months of salary and opportunity cost is steep. Should every vertical SaaS founder do this?
Look, I'm not saying every SaaS founder needs to go get a CDL or a nursing license. But I am saying that the current approach of "ten customer interviews and a prototype" is failing at an alarming rate.
PitchBook data shows vertical SaaS investment surpassed $30 billion in 2025. But the failure rate for vertical SaaS startups hasn't improved meaningfully in a decade. We're pouring more money into the space and getting roughly the same hit rate. Something about the playbook is broken.
My opinion? The broken part is domain immersion. Or rather, the lack of it.
The Gap Between Building For and Building From
Here's where I'll add my own take, because I've watched this pattern repeat across open source too.
The best developer tools , the ones you forget you're using , were built by people who felt the pain firsthand. Git was built by Linus because he needed it. Cargo exists because Rust developers needed a package manager that didn't make them want to throw their laptop. Rails came from Basecamp's actual product work.
Vertical SaaS should follow the same logic. It usually doesn't. Instead, you get MBA graduates scanning Crunchbase for "underserved verticals," building products based on TAM calculations and competitor feature matrices. The resulting software is technically competent and emotionally dead. It checks boxes. It doesn't solve problems.
This founder did something different. He went and lived the problems. And the Hacker News response suggests the developer community is hungry for exactly this approach.
You said existing pest control software is bad. Where does it actually break down?
Most of it treats pest control like generic field service management. You get a calendar, a customer database, maybe some routing. But pest control has specific regulatory requirements that vary by state, by chemical, by pest type. The software either ignores this entirely or handles it with some bolted-on compliance module that nobody uses , because it takes longer to fill out the digital form than to just keep paper records.
The other thing that genuinely surprised me: the sales process in pest control happens almost entirely at the door. The technician shows up for one problem and upsells a different service. But none of the existing tools support in-field sales in a way that feels natural. They all assume selling happens in an office, on a phone.
What's your advice for founders who can't spare five months?
Two weeks minimum. Not interviews. Not ride-alongs where you sit in the truck and take notes. Actually do the work. Get your hands dirty , sometimes literally. If the vertical requires certification, get certified. If it requires physical labor, do the physical labor.
And if you're not willing to do that? Pick a different vertical. Because your competitor will.
Why This Should Reshape How We Fund Vertical SaaS
The vertical SaaS market is massive and growing. According to Crunchbase, vertical SaaS companies raised over $12 billion in the first half of 2025 alone. Investors love the category for its natural moats and predictable revenue. But the dirty secret is that most of these companies plateau at a few million in ARR and never achieve the breakout growth their seed decks promised.
The reason, if this founder's experience is any indication, is that product-market fit in vertical SaaS demands a depth of domain knowledge most founding teams simply don't possess. Customer discovery interviews yield surface-level insights. Working the job gives you the kind of understanding that shows up in a hundred tiny product decisions , the ones that make a technician say "finally, someone gets it."
This isn't a new idea. Paul Graham wrote about "schlep blindness" over a decade ago. But the execution remains rare because it's uncomfortable. It's slower than shipping an MVP. It doesn't photograph well for Twitter threads about founder grindset.
It does, however, appear to work.
Three Things Worth Building On
First, domain immersion is not the same as customer interviews. One gives you what people say. The other gives you what people do. The gap between those two things is where most vertical SaaS products die.
Second, the Hacker News response , over 400 points and hundreds of comments , signals a genuine appetite in the developer community for this kind of founder discipline. People are tired of shallow products built from spreadsheets.
Third, and this is my opinion stated as exactly that: the vertical SaaS market is about to split. Companies built by people who did the work will pull away from companies built by people who read about the work. The software that wins won't be the one with the most features. It'll be the one that disappears into the workflow.
Kind of like the best developer tools. The ones you forget you're using.