DEV Community

Igor Zalutski
Igor Zalutski

Posted on

I built a tool that analyses your code and configures AWS to run it

Here it is: flywheel.sh

Almost 2 years ago my cofounder and I started building Digger. It took us a year, and last summer we have finally shown it to the world. We launched Digger quite successfully on ProductHunt as well as and on HackerNews. But it wasn’t instant product-market fit we hoped for. More like, different people were using Digger for different reasons.

Then we launched a few follow-up products with more focused value propositions like UI (Lemon), or multi-cloud (Alicorn), or databases (Hippobase). We learned a lot from the early adopters (thank you!!). The biggest learning was that we were trying to solve too many problems at once, and that confused our users a great deal.

So we went back to the drawing board. We have radically simplified the UI, especially onboarding. We asked ourselves - what is the one thing our users care about most? And we started launching what we thought were features as separate products. Some of them flopped (remember Serverful?) - and so we killed the feature. Others succeeded, like one-click sample app setup (AWS Bootstrap) and most recently Terragen that automatically generates infrastructure-as-code.

And then we wondered: is there something in common with the products that were received warmly? Turns out, there is - speed. In hindsight it is obvious that speed matters a great deal. Because it is not uncommon to spend more time on setting up AWS infrastructure for your app than building the app itself.

Then we thought, what would the fastest developer experience with AWS infrastructure look like? Making each step as fast as possible seemed like a good start:

  • the fastest way to get the code

  • the fastest way to determine what infrastructure is needed

  • the fastest way to provision that infrastructure on AWS

.#1 can be solved by one-click Github repository connection, like in Vercel. It doesn’t get much faster than that

.#3 can be solved by generating and running Terraform (this is what Terragen does)

.#2 presents the biggest challenge. How do we know what kind of infrastructure is needed?

After a great deal of not making much progress we realised something: all the information is already in the code! Because if you show your app to a DevOps engineer they wouldn’t need to ask many questions, they would just see the code and instantly know whether it’s a front-end (then it would require an S3 bucket and a CDN) or a back-end or a lambda function.

We can easily detect the language and the framework, Dockerfile, lambda handler, read package.json, things like that. Then we can feed it into the Terraform generator, then run terraform apply on our servers against user’s AWS account. This makes the entire flow completely seamless: connect your github repo → connect your AWS account → click “Deploy”. As simple as that.

And this is Flywheel. Give it a try!

Top comments (0)