A better way to build on AWS
So AWS gives startups $100k in free credits. Google and Azure have similar programs for startups. Then why isn’t every startup CTO starting on the Big Cloud?
The real cost of going with AWS is its complexity. There is hardly anything more important to an early-stage startup than moving fast, but this is exactly where AWS fails startup founders. It is hard to set up and manage, which is the opposite of fast.
This is why simpler tools like Firebase and Vercel are so popular. The speed of experimentation is unmatched. You can go live with a new product in a few clicks. But then you won’t use these tools at scale any bigger than a small experiment. It gets expensive very quickly, and workflows for teams aren’t adequately supported (perhaps because not many teams are willing to pay so much so early).
So startup founders are forced to choose whether to bite the bullet with AWS, or to move fast and pay a premium for tools like Firebase — only to have to rebuild from scratch later anyway. Isn’t that ridiculous?
There must be a better way
At Digger we believe that having to figure security groups, access controls and networking before your app can see the light of day is plain wrong. It should be the other way around — go live first, fine tune later. We believe in meaningful defaults, not hard limitations. Complexity should be optional, but still accessible if needed.
We are building a radically better developer experience for your cloud infrastructure. Instead of locking you into an oversimplified model like Heroku we manage your AWS account and give your team self-service tools to launch new stacks, manage environments and deploy your apps and services. Engineers can move as fast as in the early days while also retaining full control over the internals with Terraform and AWS CLI.
If you ever worked for a big tech company you probably know what I’m talking about, because most of them have built in-house tooling on top of their AWS, Google or Azure setups. We certainly did at Palantir, Amazon and Fitbit — without it we would barely ship anything. We had to build it, otherwise developers and DevOps engineers would block each other all the time. But there is no reason why only big tech should benefit from this kind of next-generation tooling; so we left our jobs and started Digger.
One may ask, aren’t things like Elastic Beanstalk and Google App Engine solving this problem? Not really. On paper maybe, but in practice they are worse than Heroku — expensive, limiting and you have to rebuild from scratch eventually. Kubernetes, managed containers and Serverless are around for ages in every cloud provider, and yet if you want a modern future-proof stack the only way so far has been the hard way. Not anymore!
It is still early days for us. Our small team is based out of London, we are backed by EF. We strongly believe that the developer experience gap is the industry bottleneck today, and bridging it will have transformative impact.
If this excites you, do get in touch. We are looking for early adopters as well as to grow the team.
PS
Join me on Slack — it’s a faster, simpler way to work. Sign up here, from any device: https://join.slack.com/t/diggertalk/shared_invite/zt-jzvf8cs4-AkeuEcESmAKleSu8J1OhZw
