Shipping 22 products to find the true product - Utpal from Digger.dev
Utpal Nadiger and his co-founders launched around 22 products in two years before Digger found traction. He shares how fast shipping, unusually candid open-source users and a move to San Francisco helped the team survive its lowest point and discover what to build next.
Utpal Nadiger is the co-founder of Digger, an open-source infrastructure-as-code orchestrator, and Infrabase, an AI DevOps agent that reviews infrastructure changes in pull requests.
We talk about using repeated small launches as a search strategy, detecting demand by temporarily removing a demo link, separating open-source adoption from monetization, building from individual hackers toward enterprise buyers, and staying focused when startup signals swing between extremes.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Why move the company to San Francisco?
The feedback loops are faster. Customers are vocal and willing to explain what they need, there is deep experience with commercial open source, and founders openly share failures and advice. The kinds of customers you win also influence the customers who follow, so proximity to the right early community matters. At difficult moments, people in San Francisco gave us perspective and introductions that materially helped the company survive.
What makes open-source users valuable during product discovery?
They are unusually willing to talk. We ask what they would change with a magic wand and look for the same problem appearing across conversations. That feedback is grounded in real use: Digger has had about half a million downloads, 4,500 GitHub stars and roughly 300 organizations using it daily, with usage growing more than two-and-a-half times over a period of months.
How did the team divide responsibilities?
The three founders had complementary strengths. Mo focused deeply on the technical system, Igor combined product and engineering, and I concentrated on users and growth. That division let us keep a small team while covering infrastructure, product judgment and distribution without pretending every founder had the same skill set.
What happened at the company’s lowest point?
Money was running low and the signals were confusing, but users kept adopting the open-source product. Michael Grinich told us that many founders would love to have what we already had and that we should focus on Digger. That outside perspective mattered: when you are inside the company, genuine traction can be hard to see through the stress.
How did removing the demo link become a demand test?
We removed the obvious demo link from the landing page. Despite that friction, two or three prospects still found a hidden route and booked calls, while weekly deployments reached a record. People were working to contact us, which was stronger evidence of demand than clicks on a prominent call to action.
What is difficult about monetizing commercial open source?
There is a timing trap. Push monetization too early and the project has too few advocates; wait too long and changing the license or closing features feels like a rug pull. We think of the usage loop and the monetization loop separately. First, make the open-source product valuable enough to spread, then add a commercial path that serves a distinct need rather than punishing the community for adoption.
Why launch roughly 22 products in two years?
Each launch was a cheap experiment in finding a problem people cared about. If an idea could not ship in a day, we reduced the scope; the first version of Digger took about a week and barely worked, but people used it. The cadence built our ability to learn and prevented us from spending months polishing an idea before receiving a market signal.
How does Digger expand from early developers toward enterprise use?
We think in layers. First make the individual hacker successful, then solve the manager's coordination problems, then meet the enterprise buyer's security and governance requirements. The foundation has to remain useful while each new layer is added. Digger began by automating Terraform in pull requests for developers who were not infrastructure specialists and can grow outward from that workflow.
Where do Digger and Infrabase go next?
The broad vision is to make infrastructure work feel modern across any infrastructure-as-code system and any CI provider. GitHub Actions is the mature path today, with GitLab and Bitbucket earlier. Infrabase explores an AI agent that can review infrastructure pull requests, but security and reliability questions are still open, so we are treating that as discovery rather than pretending the final shape is known.
What has the journey taught you about founder psychology?
Keep the long vision, but focus emotionally on the next ten minutes and the next few actions. Startup validation swings from exciting to disastrous too quickly to make every signal a referendum on the company. Keep doing the reps, speak honestly in marketing and remember that even a product in a commodity category can win through execution and a clear point of view.