Hacker News Reader

Comment by EncoreApp | Hacker News Reader

I understand Digger's philosophy of "always keep launching". You guys launch products on what seems like a weekly basis to see what might stick. All the products lead back to Digger. That being said, how is this specifically different than using Terraform modules? Is the big selling point just being able to click and generate terraform code? Is it different than what Brainboard is doing?

View on HN

Yes indeed, we are launching lots of new things, sometimes brand new UIs altogether, or significantly reworked frontend plus big changes on the backend at a minimum. Our biggest fear is to build something that no one needs. Launches allow us to roll it backwards from the top of the funnel to mid-funnel (retention) to revenue and narrow down the value prop further and further. So it's not so much a monte carlo search, more of a binary search where each launch cuts off an entire family of potential directions our product could take. So if there are 10M possible solutions then it'd only take us 23 launches to zero in on the right one.

With Terrabook our hunch is that Terraform can be made much easier if it's generated in small chunks. The language itself is trivial, lightweight json basically. Nothing to learn there. But the AWS part is hard. What are the options? What should you write? And then having spoken to many users from previous launches we learned that people google TF snippets and copy-pasting them and tweaking just a bit. It's much easier to change if the bulk is already there. So we made this snipped generation pice with a UI inspired by Jupyter / Google Colab / Replit to basically lower the entry barrier into Terraform.

why not just terraform snippets... in the snippet manager of your IDE?

The way it works for me is that I Google the TF module to get to the TF docs, it's faster to get to the exact resource... soni can see the docs for a field or see all available options. The snippet is not the main reason people google TF, I suspect

hmm yes you are right, I've never thought of it this way actually.

my thinking with Terrabook was like, what stops non-devops-savvy developers from starting to use TF? And the hypothesis is that it's a bunch of things that need to be set up prior to getting to something working, like a VPC and so on. And then having that, how do I get a database? The fastest way seems to be just find someone's github and copy from there, assuming I'm not familiar with the TF world. So I thought, why not build this right into the tool

The harder part for non-devops is not the TF side, but the cloud architecture and known best practices in design. After that the TF is pretty easy and mechanical

Another point to consider is that most devs don't want yet another tool / SaaS to do a bit of bootstrapping. Also, the move towards exposing non-devops to devops without guidelines / constraints is ill-advised. So many cost / security issues to clean up after by the devops team

> my thinking with Terrabook was like, what stops non-devops-savvy developers from starting to use TF?

That they can provision using a GUI console without having to understand all of the underlying AWS components required behind the scenes for a common setup.

I've seen a few takes at tools that attempt to "export your live infra to resources using standard providers in HCL files" but I haven't seen anything that's really good at that yet. Hmm...

I am curious about your ROI for all those products you have launched.

On one hand it might devalue a lot your brand if users find the products halfbaked or somewhat bad on the other one you might capture some market and increase your revenue.

I am definitely more interested in the economics of all of this.

Reply on news.ycombinator.com