At Guesswork, we are a team of four engineers with no background in sales or marketing. So, we had to figure out a way to get customers without relying on any of those skills. That led us, through trial and error, to a surprising approach: we call it "Build a Cannon to Kill a Mosquito." Using this methodology, we’ve acquired over 4,500 customers. In my talk at Lean culture, I explained how we did it, and why this counterintuitive strategy works especially well for technical founders. This is a refined version of that talk.



Three Startup Archetypes

Most startups fall into one of two categories:

  • Technology breakthroughs like OpenAI and the iPhone push the boundaries of what’s possible. They're hard to build, but once they work, adoption comes in waves.

  • Business model innovations like Uber apply existing technology to real-world problems. They often start with niche users and expand from there.

But there’s a third type: solving a small, overlooked problem in a popular product—a missing feature users are desperate for. Take beautifying Google Forms. For Google, it’s a mosquito not worth swatting. For a third-party developer, solving it means recreating Google Forms’ interface—something you can’t do through standard APIs. It takes enormous effort—like building a cannon to kill that mosquito. But sometimes, that cannon uncovers gold. In our case, it helped us build three successful products.


Our Accidental Discovery

While launching products, I needed a lead form for our website. Google Forms had everything—easy setup, Google Sheets integration—but embedded on our site, it looked like a patchwork. So I restyled it with CSS to match our branding. That CSS hack became Formfacade. What started as a weekend hack turned into thousands of support requests from companies with the same frustration: they needed professional-looking forms that still synced to Google Sheets.

This taught us the mosquito principle: problems too small for big companies to solve, but painful enough that users will pay to make them disappear. The effort required feels disproportionate—rebuilding Google Forms just to change how it looks. But that's exactly why the opportunity exists.


Turning Accident into Playbook

Our second product emerged from Formfacade users. Doctors loved our forms but worried about HIPAA compliance. We studied healthcare regulations and built Hipaache with features like e-signatures, field masking, and intake forms.

But Hipaache didn’t sell on its own. It needed a salesperson to explain its value to doctors. When we split its features into separate add-ons, the signature add-on exploded. We renamed it Formesign and gradually bundled other features back in, creating a DocuSign alternative that lived inside Google Forms.

This became our systematic approach: find tiny problems competitors ignore, then use all your engineering skills to solve them—even if it means building a DocuSign inside an add-on.


Branding Problem with Add-ons

There is one big problem with this approach: churn. Customers treat add-ons as temporary solutions until Google builds it or they migrate to a dedicated solution after initial use. During COVID, restaurants used Google Forms to take online orders but couldn’t calculate totals or manage inventory. We built those features and launched an add-on called Neartail. Businesses loved it and left 5-star reviews, but still switched to Shopify when they grew.

So we pivoted Neartail toward meal prep businesses — a niche that Shopify couldn’t serve well — especially when the menus change every week. We built a custom solution for weekly changing menus and redesigned our entire site around this audience. Today, over 50% of our traffic bypasses Google's marketplace entirely.

This transition required building two products simultaneously: one to solve weekly changing menus for meal prep businesses, another to solve order amount calculation in Google Forms. It’s harder than the traditional business solution archetype, where a founder could have directly built a "Shopify for meal prep," but a technical founding team like ours wouldn’t have known this segment existed without starting with the add-on.


The Two Tests

Every good mosquito problem passes two tests:

  1. It makes you question your life choices. The problem feels beneath you. We went from building AI to styling Google Forms. That embarrassment is exactly why the opportunity existed—nobody else wanted to do it.

  2. It should feel slightly impossible. If standard APIs could solve it, everyone would. Our best ideas involve unconventional approaches that feel like they shouldn’t work—but when they do, users experience magic.


The Spectrum of Risk

Not all platform extensions are equal. Here’s the risk spectrum:

  1. Tail Wagging the Dog: Windsurf started as a VS Code plugin but hit platform limits around AI autocomplete. They forked the entire editor, rebuilt the experience, and forced Microsoft to opensource its vscode & copilot. When your momentum becomes large enough, you can actually reshape the platform.

  2. Disinterested Monopoly: Google Workspace is built for office productivity. It prioritizes co-worker use cases over customer-facing use cases. Their forums overflow with unanswered requests. Great for building on top of, if you're willing to work around missing APIs.

  3. Walled Gardens: Apple and Meta guard their platforms aggressively. When Beeper enabled blue bubble messages from Android, Apple shut it down immediately. Despite EU regulations like the Digital Markets Act, these remain high-risk environments for third-party innovation.

  4. Regulatory Minefields: Government platforms offer massive user frustration but dangerous legal territory. A student in India was jailed for building a better train booking site. The regulatory risk increases significantly as you move east—from the U.S. to Europe to India to China.

Start with disinterested monopolies. If your wave gains momentum, you might become the tail that wags the dog.


Summary

One way to think about this approach is to understate your product when everyone else overstates theirs. Most founders want to be visionaries—like Elon Musk, the real-world Iron Man. But maybe the better strategy is to start as a sidekick. That’s what PayPal did. They were a payment plug-in for eBay. When eBay felt threatened, they tried to compete, failed, and eventually acquired PayPal with a mix of carrot (acquisition offer) and stick (threat to shut them down). But Elon used that money to build Tesla and SpaceX.

While add-ons seem too insignificant and unimpressive, they are an underrated lever behind success stories like PayPal and Windsurf. This approach will become more valuable as AI makes software development cheaper. When any SaaS can be cloned overnight, your greatest leverage becomes distribution. As Nikita Bier observed:

"The entire tech community thinks AI coding will shift power from engineers to idea people. Wrong—it flows to whatever maintains scarcity: those who understand distribution."