Mani Doraisamy offered an excellent perspective for technical founders how to bootstrap a product using a product led growth model.
Build a Cannon to Kill a Mosquito with Mani Doraisamy
Mani Doraisamy’s Lean Startup example began with a simple Google Forms add-on to calculate order totals—functionality users needed but Forms lacked. This drew in food businesses like meal prep companies. As they added more features, many users upgraded to Shopify, causing churn. But one segment—meal prep businesses—stayed. Unsupported by Shopify, they needed weekly-changing menus. Realizing this niche need, Mani built Neartail, a dedicated product tailored to food businesses with dynamic menus. The pivot came from observing usage patterns and solving real user problems. What began as a technical tool evolved into a focused solution by identifying a sticky user segment with unmet needs.
In the full video, Mani Doraisamy, discusses how his company Guesswork built a successful business by creating niche products that solve specific problems overlooked by larger tech companies. Key points:
- Guesswork started by building a tool to style Google Forms, after finding that Google’s offering lacked customization features. This initial “accidental” product grew into a full-time business.
- The company then used a “build a canon to kill a mosquito” approach, splitting larger product ideas into narrowly-focused add-ons that could be easily discovered by users searching for specific features.
- This allowed Guesswork to build a customer base of over 4,500 users without traditional sales or marketing, by focusing on technical solutions to underserved needs.
- The company was able to turn successful add-ons into standalone products, like a HIPAA-compliant form tool for healthcare providers, by identifying specific user segments with high retention.
- The key is to find “tiny problems that competitors ignore” and use strong engineering skills to build a better solution than the larger platforms, even if it means going beyond the intended use of their APIs.
Full Video
There are two kinds of startup ideas that succeed:
- Business ideas like Uber that solve real-world problems, starting with niche users and expanding over time.
- Technology breakthroughs like OpenAI that push the frontier of intelligence. They’re hard to build but see massive adoption once achieved.
But there’s a third kind: solving a small, overlooked problem in a popular product—a missing feature many users desperately need. Something like beautifying Google Forms. For Google, it’s a mosquito not worth swatting. For a third-party developer, solving it requires recreating Google Forms’ interface, since it’s not available through standard APIs. It takes enormous effort—more like building a cannon to kill that mosquito. But sometimes, that cannon reveals gold.
About Mani Doraisamy
Mani writes meta code (AI, rule engine, middleware). He has been building tools for Google Workspace customers for over 15 years and enjoys creating products for them.
- https://guesswork.co/support/our-mission.html
- https://manidoraisamy.com/developer-forever/posts.html
Introduction
Mani Doraisamy is a developer-turned-founder who still writes code for a living. He loves to write meta code: AI, rule engine, and middleware. He has been building products for Google Workspace customers for over 15 years. He currently supports four products for Google Forms users:
- Formfacade – Google Forms is awesome, but its UI sucks. Formfacade enhances its UI and turns it into a CRM.
- Neartail – Shopify for food businesses. Restaurants and meal prep companies use it to take online orders for their weekly changing menus.
- Formesign – Docusign meets Google Forms. Adds eSignature and HIPAA compliance to Google Forms. Simplifies compliance for healthcare companies.
- Promptrepo – Converts unstructured conversation into structured response in Google Forms using AI. You can also build your own AI models using Google Sheets data.
He is also a mentor for Google Startup Accelerator (Europe) and a Google Developer Expert (GDE).
Edited Transcript Build a Cannon to Kill a Mosquito by Mani Doraisamy
Slides for this talk: https://docs.google.com/presentation/d/1EzRnsEslC6xQEAHwji2mQRf7SE7E8WTWzUpNmZ6ctMg/edit?usp=sharing
Sean Murphy: We’re fortunate today at Lean Culture to have a briefing by Mani Doraisamy, who’s going to talk about taking a narrow focus and actually building a number of niche products. He writes Meta code, which includes AI, rule engine and middleware. He’s been building tools for Google Workspace customers for over 15 years and enjoys creating products for him. His firm’s website is guesswork.co and lists four products: Formfacade, Neartail, Formesign, PromptRepo, that turn conversations into structured data.
Mani Doraisamy: Thank you for the invite, Sean. So, at Guesswork, we have four engineers and no marketing. We had to figure out a way to find customers without any sales or marketing skills. Initially, we did that by trial and error, and over a period of time, we found a methodology that continuously works, and we call that approach to build a Canon to kill a mosquito. We now have more than 4,500 using this methodology. In this talk, I hope to explain how that methodology works and how it helped us build not just one product but four products. I’ll use three of these products as examples. As we go along, please feel free to stop me whenever you have any questions.
If you look at the startups and the products that they build, there are typically three product architectures.
A second set of products comes along whenever there is a technology breakthrough. For example, Uber is possible because the iPhone has become ubiquitous, and people can order taxis from the iPhone. These start with niche users, like, for example, San Francisco techies, and then it goes from one city to another and gets adapted to more and more people. This second set is typically suited for non-tech. These are the two main archetypes around which startups are created and the funding in Silicon Valley and all around the world happens.
However, there is a third type of startup that’s not often explored, which is what I will try to explain today. It’s more like a missing feature in a popular product. For example, Google Forms is built for office productivity. It’s a competitor to Microsoft Office, where coworkers can use spreadsheets or Google Forms to collect data from other coworkers. But if you want to use Google Forms to collect data from customers, the branding is not all that great. So, if you need to style Google Forms, then it is very hard to use Google Forms, especially six years ago when I was trying to launch different products during the early stages of my startup. I was creating a new MVP and launching every week, and I didn’t have a way to collect leads. I didn’t have much money, so I didn’t want to invest in A CRM.
Extending Google Forms Looked Like a Weekend Project
Mani Doraisamy: I wanted to use Google Forms, but it looked very amateurish when I embedded it in my website. It looked like a patchwork. So I thought, how would it be if I could style Google Forms? And then I did that on a weekend. I thought it would be a weekend project that I could launch as an add-on. And suddenly, I found that a lot of users were facing the same problems. So people started asking me for more and more features, and I realized that these users were already asking this feature in Google Support Forum and Stack Overflow about changing the style to match their website. All these users started using this product and giving me this feedback. And initially, I thought this would be a side project. So, instead of using it full-time, I thought I’d just put it as an add-on, and then I would do my book.
But as it turned out, it became a full-time job because all these people asked for it. That is how I started investing effort into Google Forms and rebuilding all of them. The problem is that these APIs were not available for runtime. So, some of these APIs were partly available, and most APAs weren’t that good. I ended up rebuilding the entirety of Google Forms in my product to get the look and feel that it is better than Google Forms.
And if I had known earlier, I would’ve never built this add-on. I would’ve used Typeform, or I would’ve used HubSpot, and I would’ve not spent one month or one year trying to rebuild Google Forms. But that idea allowed us to build two more products.
Making Basic Forms HIPAA Compliant
Mani Doraisamy: For example, in the second product, many doctors were using the Form Facade to collect patient information, but they were asking me if the Form Facade or Google Forms were HIPAA compliant.
So, I studied HIPAA compliance and found out that there were many requirements to satisfy for Google Forms to be HIPAA compliant. One of the requirements was to collect e-signatures from the patients for consent before admitting them to the hospitals. The other one is that it must be masked when you collect personally identifiable information, which in healthcare is called Personal Health Information, PHI. It has to be masked whenever you send it as an email, store it in a Google Sheet, or share it with your coworkers. Similarly, you should be able to have a way to get signatures from multiple people for the signature workflow. So we built all these features, and we launched a product called Hipaache because we thought it was going to be useful for healthcare companies to use Google Forms and make sure it was HIPAA compliant, but it turned out that there was no traction.
So, I had more conversations with the doctors who gave us these requirements and found that I had to explain what HIPAA means. There are three things: getting an e-signature, sending for approvals, and then having to mask this information. But explaining this to new prospects would require a salesperson to close the deal, and our team only has engineers. We decided to use a product-led growth model to attract doctors who were using Google Forms. We split the Hipaache product into three different add-ons for Google Forms: Form E-Sign, Signature Workflow, and Email Masking. We launched them as different add-ons for Google Forms and suddenly the traction again came back very similar to Form Facade.
Complex Products Require a Salesperson, Simple Products Do Not
Mani Doraisamy: We realized that when you have a bundled product, you need a salesperson to explain what the product does in terms of features to sell it. But when you split it into individual features and then release them as add-ons, people searching for it in Google Forms Marketplace or Google Search could easily find it. Once their immediate need for e-signature is satisfied, they find the next feature, Signature Workflow, and then they go on to the next feature, masking health information, and so on. It got traction and exposed each feature as an individual product; therefore, each feature was tested thoroughly. When we looked at the top add-on with the most traction, it was Form E-Sign. So we renamed the product from Hipaache to Form E-sign, bundled Signature Workflow and Masking around it, and used the traction from Form E-Sign to sell all three.
That is how we built a DocuSign competitor using Google Forms. Most doctors were very comfortable with Google Forms and Google Sheets, but they did not have a way to use them in the healthcare setting. So they had to go from a $38 plan to thousands of dollars for DocuSign, which did not even integrate with Google Sheets or Google Drive. So, that ability to get a signature and sync it to Google Drive and Google Sheets became our primary value proposition for attracting DocuSign users to our platform. We recently signed up a big Mexican group, and now they’re rolling out to 17 of their group companies. So we are slowly seeing, even though it is an add-on, we could go on to get much bigger companies along the way, but that is one big problem with this add-on approach and that branding because the biggest problem is the customers who use this add-on think that this is a temporary fix until Google rolls out that feature in Forms or they move on to a dedicated SaaS solutions once they graduate out of Google Forms.
Reduce Churn With A Clear Focus on Core Customer
Mani Doraisamy:The churn in the case of some of these products was very high. For example, during COVID, we launched an add-on called NearTail because a lot of people did not have a way to take online orders. So they were using Google Forms to take orders, but they did not have a way to calculate the order amount because Google Forms did not have any calculation functionality at all. Users were asking for it in forums, so we added the calculation functionality and gave it to those users. Those users were very happy and started coming up with new requirements like adding cart payment integration and so on. Even though we added all of these features, users would give a five-star review and then say that we are now upgrading to Shopify because we think the business is scaling.
Churn became a big problem. We started looking at each of the segments of NearTail users and found one segment of users who were not moving to Shopify: meal prep companies. Meal prep companies take online orders from people who are office workers or fitness enthusiasts and prepare meals specifically for their needs. They usually offer a menu that changes every week, which Shopify does not easily support. Shopify is about publishing a product as an individual webpage and ensuring it’s SEO optimized. In the case of a meal prep or food business, the menu is ephemeral; it changes every week.
These customers stuck with the add-on, so we created a product for customers in food businesses. Today, more than half of the customers in a food business come directly to our websites instead of the add-on. It feels like we had to build two different products: one where the pain point was how to calculate the order amount in Google Forms, and the other where the pain point was how to have a weekly changing menu in Shopify.
Without the add-on business, we wouldn’t have found these meal prep businesses that want to change their menus every week. We could build a separate product for them because we had insight into the different segments, which had the lowest churn and which had the highest retention.
A Simple Products and Ongoing Experimentation Will Yield Business Insights
Mani Doraisamy: Maybe if we had a non-technical founder who had an insight into that particular business because they had run a meal prep business, we could have aimed at it directly. But we were all technical founders. We had to get everyone, find the needle in the haystack, and build another product. So that’s the challenge. I’m not saying that this is easy. I’m saying that the lack of business insight can be compensated by building a simple tool that solves one problem, figuring out the needle from the haystack, and building a separate product only for the food business.
Over time, as we created these products, we developed this playbook from the initial accident of building Form Facade, which is basically styling Google Sheets. We now have an internal guideline: whenever we launch a feature, we try to make it into a product. We look for a tiny problem that competitors ignore and use all of our engineering prowess to solve it.
A founder building the next Shopify will not consider building an add-on for Google Forms. It feels beneath them. That’s the kind of tiny problem we are looking for. It should be hard to solve, so most developers will not attempt to solve it or give up, but we can solve it if we use all of our engineering prowess.
To quantify this tiny concept more clearly, it should make you question your life choices. For example, in 2014, we launched Guesswork as a machine-learning platform for customer information. We wanted to democratize machine learning and AI. In 2017, we were invited to France to run the AI company because they were very excited about building AI here, and the president named my cofounder and me India-France young leaders. In 2020, we were fixing CSS for Google Forms. I was asking myself, “What am I doing with my life?” So that is the first test.
Second, it should feel slightly illegal: all developers should not have access to this technology or the API. For example, Google Forms will slow down or hang when you have more than 200 feeds, but it is very common for e-commerce online shops to have 200 products or two or 300 products.
We recreated Google Forms and rebuilt the runtime and the editor. Some of these e-commerce companies moved to Neartail because Google Forms no longer worked for them after they had scaled up. So we had this really smooth editor, and we were making these API calls to Google Forms to create the underlying Google Forms using asynchronous calls, and we made the experience very smooth. But at 400 fields, even Google Forms API did not work. So I filed a bug in the issue tracker, and Google asked, “How are you managing the UX issues with such a large form?”
To put it in perspective, the amount of engineering effort should be so good that it is better than Google, let alone other developers. When you don’t have the marketing or sales skills to sell it to all customers, you have to compensate with the engineering skills.
How Far Can You Go?
Mani Doraisamy: So this might sound exciting, but the question is, how far can you go? At some point, Google might retaliate if you go beyond what their API is supposed to give access to.
I’ll look at four scenarios, from the best to the worst. This plugin or add-on approach is not new: PayPal started as a payment plugin for eBay because most of the businesses selling on eBay in the early 2000s did not have a way to collect money from their customers. The PayPal plugin solved this problem. Then eBay tried to create a competitor because they thought the business was very lucrative, but it didn’t work as well as PayPal.
Then eBay used a carrot-and-stick approach: the carrot was “We will acquire you for billions of dollars,” and the stick was “If you don’t accept, you will shut you down.” So, eBay acquired PayPal. While the PayPal founders, people like Elon Musk, Peter Thiel, and the rest of the PayPal Mafia, went on to do big things, they could not create a business like Stripe. That is why investors see these kinds of startups as acquisition plays rather than moonshots and may not fund them. I used to think that investors were right, but now I think of this as a spectrum with at least four architectures:
- Tail Wagging the Dog: VS Code Extension
- Disinterested Monopoly: Google Form Add-on
- Walled Garden: iPhone Messenger
- Regulatory Minefield: IRCTC Hack
Tail Wagging the Dog
Mani Doraisamy: The first one being the add-ons or extensions on top of open source projects like vsco, for example, Cursor and Windsurf started as Visual Studio (VS) code extension.
When Microsoft launched Copilot, they had these VS code-related enhancements that were only for Copilot, especially for auto-complete of the code for Cursor and Windsurf kinds of operations. So, Cursor and Windsurf forked the VS code and created their own editor. Because the underlying platform was open source, they could fork it and build their own platform, even though the initial traction came from VS code extensions. That forced Microsoft to open source the Copilot code as well as the VS code. Because Microsoft has seen this story earlier with the Microsoft phone–if you remember, there are only two places in any of the technology breakthroughs. You can be an iPhone or an Android. One is premium, and the other one is mass market. So they knew if GitHub Copilot couldn’t be the iPhone of vibe coding, then at least they wanted to make sure it is the Android of vibe coding.
So that’s why they decided that they will open source the entire VS code. This is a case of the tail wagging the dog, right? Which means Cursor and Windsurf are now dictating how the VS code platform evolves. That’s the best case scenario for a startup.
Disinterested Monopoly
Mani Doraisamy: The second one is a disinterested monopoly. Form Facade falls under this one. Google Forms is meant to be an office productivity tool designed to collect information from your coworkers, not for customers.
So when users ask for CSS enhancements to make Google Forms as good as Typeform, their requests fall on deaf ears because that’s not a priority for Google. So that is a good kind of gap for products like Form Facade because you can go and look into Google’s support forums and see people crying for help, “Somebody please give me this feature.”
The request will have 2000 stars or 3000 stars on the support forum, and Google will never answer these questions because that’s not their priority. So that is a good starting point for products like Form Facade and other extensions. The challenge is that if Google is not responding to their users, they’re unlikely to respond to outside requests. If we ask for an enhancement, they will never reply. You must be willing to hack, to go beyond what is possible with the API to build in an unconventional way–perhaps scraping to get to the last mile to make the add-on useful for the users.
Walled Garden
Mani Doraisamy: The third kind is Walled Garden. For example, Apple and Facebook are very protective about their users because their entire value is in locking their users within this ecosystem.
Beeper is an example of this kind of company. I know Eric Migicovsky, the founder; he was a YC partner. Beeper allowed Android users to send messages to the iPhone with a blue tick, and Apple immediately shut the product down. There was a big tussle. They went to Congress to testify and try to get Apple to open up their platform. But you cannot convince Apple to open up. The Europeans have been trying to do that for a long time, but to no avail. Eventually, Beeper was acquired by Automatic, the WordPress company, and merged into another chat app they had.
Regulatory Minefield
Mani Doraisamy: The fourth is the regulatory minefield. Governments websites are famously bad, terrible at UX, terrible at serving their customers. So one of the sites in India is called the IRCTC (https://www.irctc.co.in/) for Indian Railway Catering and Tourism Corporation, it’s a travel booking site. So an IIT graduate tried to build a “Super TATKAL booking” site on top of IRCC by scraping the website and bypassing the captcha, and he got arrested because apparently it is against law to scrape the website.
This might be OK in the US but as you go from US to Europe to India to China the regulatory minefield becomes more and more dangerous so you have to be really careful with it.
In my opinion, you have to start with a disinterested monopoly where you have an opportunity to serve the users and tail wagging the dog is not really in your control. Sometimes a wave like vibe coding takes over and then suddenly the add-ons dictate, or the extensions dictate what the platform should do next.
Every Founder Wants to Aim for the Stars
Mani Doraisamy: My summary is that this is really about the psychology of founders. Every founder wants to be a visionary. So they build a canon and claim that it can shoot down stars. But your job as a founder is to stand apart. So you can also say, “I built a canon that can shoot down a mosquito,” which is immediately relatable and immediately trustworthy. In a world where everybody is over-rating their product, you underrate your product willfully, creating the first kind of traction you can get from the initial set of users.
The PayPal founders, Peter Thiel and Elon Musk, now say they want to make America great again and make humans an interplanetary species. But they started as an extension company for eBay. Their ability to build PayPal as an extension, sell it, take that money, and then invest in SpaceX or Palantir is what made them succeed.
Sometimes We Rewrite History
Mani Doraisamy: Sometimes, we rewrite history when we tell the story of how a company got started. We start by saying that the founders were visionaries from day one. It feels less successful to say that we were an add-on for eBay, and eBay could’ve shut us down at any point in time.
In other words, it seems like every founder wants to be a superhero like Iron Man. But maybe in order to achieve that, your first step is to be a sidekick for a popular product.
“The entire tech community is under the impression that AI coding will result in power flowing from engineers to ‘idea guys.’
Wrong– it will always flow to whatever has scarcity: those who know how to get distribution.”
Nikita Bier
So that I think this quote is a good summary for my talk because the distribution is the most important thing that we are already facing, and it will become more important in the future. If an entire software product can be cloned by a single prompt using AI, then what is the scarcity? As Nikita says, the entire tech community is under the impression that AI quoting will result in power flowing from engineers to the idea guys. It’ll always flow to whatever still has the scarcity, those who know how to get distribution.
End of Prepared Remarks
Related Blog Posts
- Wolfgang Huber Describes Bootstrapping Matrix Requirements
- Roger Cauvin: Unlocking the Power of Product Strategy
- Frank Tisellano: “Business First” Product Management
- Sean Murphy How to Bootstrap a Startup
- Alex Panait on Current Trends and Possible Futures for AI
- Matt Trifiro on Lessons Learned using AI for Marketing
Thanks for sharing the useful blog with valuable information.