Digger.dev - Pivoting four times, OpenTofu & ThePrimeagen
Digger tried to make "all of AWS great again," then narrowed to infrastructure automation, then to deploying Terraform — and realized they'd built a worse version of Terraform Cloud. The fix wasn't a new idea. It was open-sourcing the same idea and running it on CI people already had.
Igor Zalutski and Utpal Nadiger are the co-founders of Digger.dev, an open-source tool for orchestrating Terraform and OpenTofu inside your existing CI/CD system. Jack briefly worked with them roughly two years before this conversation, when Digger was still trying to be a Heroku-like experience on top of AWS.
We get into the four pivots it took to get from that original idea to something people actually stuck with, why they now treat 'are people still around after ten users' as the only signal that matters, and the genuinely random-feeling convergence of a Reddit post, a reaction video from ThePrimeagen, and a Hacker News submission that took their GitHub stars from around 500 to 1,500 in a single week.
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.
You started out trying to make 'all of AWS great again.' How did that narrow down over time?
The biggest lesson was that if an idea only exists in your head, it's probably not a real thing — you can only find out by actually going and trying to sell it and get people to use it. We started with 'make AWS great again,' which, realistically, a seven-person startup cannot actually deliver on, so we started shaving off scope. First we said we wouldn't touch application deployment and ended up with an infrastructure automation tool built on top of Terraform — which, looking back, was itself a bit of overengineering. Then we asked why we were even touching the application layer at all, and just focused on deploying people's Terraform directly — at which point we realized we'd built an inferior version of Terraform Cloud. Every step was us proving, by actually shipping, that the previous version of the idea wasn't the right one.
What was the actual insight that turned that 'inferior Terraform Cloud' into something that worked?
We asked whether we could make it better, and realized yes — by making it open source and not running it on our own servers at all, which would have been expensive. Instead we reused the CI people already had and put together a scrappy GitHub Action. It took about a week to build, we posted it on Reddit, and a couple hundred people engaged with it almost immediately. That gave us enough confidence to double down, and we later rewrote it in Go over a couple of weeks — a decision several users had actually been asking us to make.
Was that 'ship something big in a week' approach something you'd always had, or did it change?
It was there before, but it improved — that motto of trying to make a big splash with something shippable in a week is probably the reason we're still around, because it keeps you honest. If you can't generate real traction in a week or two, you have to acknowledge your underlying beliefs might be wrong; there's no way around that. Doing that repeatedly is actually what led us to a real moment of desperation — we'd shipped essentially everything we could think of within the original idea and proved to ourselves it wasn't the right idea. That's a genuinely miserable place to be: you've checked every box on the list and nothing is working.
How do you know the difference between 'this needs more marketing' and 'this fundamentally doesn't work'?
It can be known within days, not months. If you trace the funnel all the way down to retention and people simply aren't sticking around, that's the answer — there's nothing you can fix at the top of the funnel that solves a retention problem. Concretely: most launches, even bad ones, get you around ten users. The question is whether those same ten people are still around and generating any usage a bit later, even anonymized by hash ID. If the answer is no for all ten, you don't need a bigger launch to know something's wrong — they just don't come back, and that's the answer. Digger's early iterations got real buzz, Hacker News, Product of the Day, plenty of traffic — but people weren't sticking around, and that's what actually mattered.
Why did the current version of Digger get people to stick around when earlier ones didn't?
By removing parts of the product, we shrank the number of points of failure. In earlier versions, we'd do demos and walk someone through the whole journey, and the point where it broke down was different every time, because with a small team shipping fast, corners get cut in different places throughout the product. Narrowing the product down limited how many of those failure points could exist at all — it's the intersection of 'fewer places to fail' and 'something people actually wanted.' The deeper lesson, which is written everywhere and which we refused to believe applied to us, is: do one thing well. Our original product bundled together functions, containers, databases, deployment, infrastructure — each one was really a different problem for a different person at a different time, not a single coherent product. That's not a product, it's a bag of features, and you can't launch a bag of features and expect success.
What did the actual week of building and launching the version that worked look like?
There were four or five of us, and everyone was tasked with independently building a version of what an open-source Terraform-orchestration tool could look like, taking inspiration from Atlantis, an existing open-source competitor used by some large organizations, plus looking at how commercial vendors approached it. It was almost like a hackathon inside the company. By the end of the week we had one lightweight implementation running inside GitHub Actions, originally called TF Run, and we went directly to people using Terraform Cloud and asked why they were paying for it when this existed. People had strong opinions immediately — what Terraform Cloud does well, what Atlantis does well, what's missing from each — and that thread is still active and useful to us more than a year later.
How did you know people were actually using it, this early, with no formal analytics in place?
We had no telemetry or analytics set up at that point — the real signal was people joining Slack to complain when something broke, or to ask for a specific feature like drift detection or state management, or to contribute code because something they needed didn't exist yet. None of that was something we understood yet, since neither of us had maintained an open-source project before. But you could see it plainly in the Slack member graph: there's a clear inflection point in February 2023, right when TF Run launched, and the growth rate of the community changed permanently from that point on.
What's the minimum viable analytics setup you'd actually recommend, given you started with almost none?
You don't need a full analytics suite with Segment and all the trimmings, even though that's a fine thing to have eventually. What's actually non-negotiable is a way to find out, quickly, that you're fundamentally wrong — and there's always a way to know that within a week or a month; if it takes longer than a month, you're not looking hard enough. We started by literally posting user action events into a Slack channel and manually compiling weekly and monthly numbers by hand, with zero real analytics infrastructure. That was enough to tell us usage was growing — and if it hadn't been growing, that would have been the answer that we'd built another piece of the wrong thing.
You had a huge growth spike around the OpenTofu fork and a ThePrimeagen video. How did that actually happen?
It started about a month before the OpenTofu fork, when Igor wrote an article about rewriting the product in Go in a week and posted it to Reddit. ThePrimeagen picked it up and reacted to the whole article on YouTube, agreeing with essentially every point — which was the first time we'd seen the power of YouTube as a growth channel at all, since we'd never intentionally tried it before. Over a weekend, GitHub stars started climbing from a baseline of around 400-500; by Monday they were climbing by 600 a day, and within about a week we'd gone from roughly 500 to 1,500 stars. On top of the Reddit post going viral and the video, we also submitted a Show HN, and all three converged — Igor's read Charlie Munger's writing on 'Lollapalooza effects,' multiple forces compounding together, and that's exactly what this felt like. A meaningful share of the users who joined in that specific cohort are still active users of Digger today.
Was writing that Go rewrite article a deliberate growth bet, or did it just work out?
Looking back, it feels very different from what was actually going on in my head at the time — most of the time it feels like you don't know what you're doing, you're trying a lot of things somewhat desperately, and every so often one of them takes off. Rewriting a product from one language to another is conventional-wisdom-bad advice; most experienced engineers will tell you tools don't matter as much as people think, you just pick something and build, and you can rebuild later once you've created real value. We went against that, and it felt like the decision needed explaining rather than just doing quietly — which is really the whole idea behind writing content worth reading: it should create some new piece of knowledge or take a real position people might disagree with, not just be mechanical word generation for its own sake.
Is that kind of viral growth event something you can actually try to recreate?
It's closer to poker than roulette, in the sense that skill matters, but replication is still extremely hard — we've tried to recreate that same 'Lollapalooza' convergence since, and it just doesn't happen on command; the pieces have to fall into place mostly on their own. Part of why it worked the first time is precisely that we weren't trying to engineer virality, we were just sharing something we'd genuinely done and had a real, debatable opinion about.
If you could go back and talk to yourselves two years ago, what would you tell them?
Don't live inside your own head — just listen. Users and other signals are already telling you when you're wrong; you don't even need to dig for it, it's sitting right there on the surface. Just listen more.