For two years, I have been working on Astrobase, a platform for streamlining B2B SaaS deployments. It has been an awesome, learning filled experience. I built cool software, had product critiques from friends and connections at Tesla, Amazon, Google, and various startups, and met many other entrepreneurs. All of this has helped me grow as an engineer and entrepreneur.
While working on Astrobase, I found myself stretched. I felt that my attention was, and still is, pulled in many directions. Between my primary job, Astrobase, music, and open source, this began to stress myself and others around me. I often found myself questioning whether Astrobase is the right company for me to be bootstrapping now.
I recently came home from a few weeks in Europe where I took the opportunity to completely unplug and consider this situation. No emailing, committing code, or even keeping up with podcasts. That trip gave me the space and time I needed to refocus on what matters, reflect on what I've learned so far, and decide what I should do with my time and energy as I go into the second half of 2022 and beyond.
Product Learnings
Build Tools for Repeatable Cloud Environments
In 2019 I identified a gap in the world of software.
Teams of developers were designing, building, and maintaining massive "jobs platforms", what people are now calling "MLOps platforms", on Kubernetes. These systems were expensive, fragile, and home-grown. There were not many cost-effective platforms that would increase developer productivity, with a simple developer experience, and a public community, so I built and tested an MVP with a few friends and connections to see if I could create the right product to fill this gap.
The result of that experiment was that developers didn't want a fully managed platform, instead they wanted a tool to create and manage repeatable environments with low overhead in any cloud.
Astrobase was born. A platform for creating multiple repeatable cloud environments, on Kubernetes, with a simple developer experience.
Don't Ask Too Much From Developers
Astrobase's first product iteration was a cli-server based tool that could create and delete managed Kubernetes clusters on Google Cloud, AWS, and Azure and apply and delete Kubernetes resources, all in one simple workflow with one tool.
Users loved the streamlined experience of creating clusters as it was far simpler than using terraform or managing their own home-grown solution.
However, Astrobase required developers to re-work their kubernetes resource definitions to fit Astrobase's deployment requirements.
This was almost always a blocker for developers. Asking developers to re-work something critical in their deployment stack is not a way to quickly get adoption, let alone product market fit.
Integrate Feedback
I then refactored Astrobase into what it is today.
A simple, open-source tool for creating and managing Kubernetes clusters on Google Cloud, AWS, and Microsoft Azure. The focus of the refactor was to open-source the core product value, a simple workflow for creating Kubernetes clusters anywhere, and then offer a SaaS to enable seamless IAM across clouds, one of the biggest pain-points I gathered from interviewing potential customers and advisors.
This cross-cloud IAM was supposed to be a significant innovation because any user on Astrobase could be given permissions to any Kubernetes cluster that was created by Astrobase. Permissions and cluster access permissions (RBAC) would be designated by the cluster owner or owners. This was the answer to one large core problem that Astrobase was founded for – make cloud development simple, secure, and fast.
I groomed my growing backlog based on feedback and on what I was learning about in the general Kubernetes/ cloud-native ecosystem. In doing so I learned that a lot of this functionality and developer experience already existed in similar developer SaaS platforms already; Google Cloud Platform, Heroku, Fly.io, Vercel, Planetscale, GitHub, to name a few. It started to feel like I was about to play a serious game of catch up.
Be Critical About Product Market Fit
These platforms already offer so much; monitoring, deployments, APIs, comprehensive IAM management, et cetera. If those platforms start offering things like compliance-by-default, automatic SOC2 and HIPAA, multi-region availability, et cetera, all with the click of a button, it would be a no-brainer to use these over something like Astrobase, which is already lagging behind in feature availability, and objectively provides the same outcome as any other platform.
Take this example. Suppose two organizations want to collaborate on a shared Figma board.
Once each org confirms that Figma is compliant with whatever standards and security both parties need, content can be shared across companies and another deployment of Figma for either tenant isn't necessary unless special networking is required. I'm not in the business of only doing special solutions, air gapped, tech-services company. Not my vibe, nor the vibe of Astrobase.
Why not just use Figma when these compliance issues are solved instead of building a new platform? Save your time and energy for adding value.
I took a step back and asked myself, Given all of this, does the world really need something like Astrobase now?.
For the first time in two years, I said to myself, "No. Not right now."
Know When To Change Things Up
Astrobase was creating so much work for me such that I could not build what I wanted to in the time-frame I wanted to keep a product like Astrobase relevant and competitive without hiring. I'll get to why I decided to not hire later.
I found that companies can generate the same value that Astrobase provides with GitHub Actions and use of cloud provider CLI's.
How did I figure this out? Well, I challenged myself to not use Astrobase at my primary job, and I was able to do so.
This demotivated me at first but it opened my eyes to alternative approaches to creating repeatable, secure environments. This company took off in terms of platform deployments across multiple clouds with a simple workflow and barely any time spent on deployment. Overall, very good vibes. We even raised a Series A with a big reason for raising being our rate of enterprise customer adoption. The more shots you get, the more you can make.
The cloud and Kubernetes ecosystem is so rich, and improving every day. The best products out there prevent you and your team from smashing rocks together, and instead provide an amazing developer experience.
Focusing on things like Kubernetes Resource Model (KRM), Google Cloud's approach to IAM, and the developer experiences of Vercel, Planetscale, and Fly.io will help guide you to build products well in the B2B and B2C SaaS space.
The world of B2B and B2C SaaS has so much to offer already, and I have a lot more to offer too, in more areas than just SaaS. So, for now, Astrobase will be taking a backseat as I don't want to burn out in a red ocean.
Technical Decision Making
Don't Reinvent the Wheel
As a technical director and developer in startups and larger organizations, it is important to definitively know your core product value add.
Anything that you and your team build that does not improve that core product value add is a waste of time and should be outsourced to the best SaaS for the job.
Think server monitoring. If you're not a server monitoring company building server monitoring software, then why the heck are you building and maintaining it? Use DataDog, Heroku, Google Cloud's built in services. This is true for 99% of teams and products, there are definitely times when you'll have to do it all yourself. Believe me.
Embrace Developer Experience
Just because your customers are using different services and providers does not mean that you must cater to those specifications. Doing this further distracts from core product value add.
Often this will happen to B2B SaaS companies when their customers are using different cloud providers. Your company thinks they have to build the entire platform such that every single component can be run anywhere for any customer. However, in reality, your company simply needs to be compliant and have proper IAM for almost all types of customers. The rest is mostly implementation decisions.
Those implementation details follow along properly if you avoid products and platforms that make you and your team smash rocks together and instead embrace tools with incredible developer experience.
I FREAKING TOLD YOU! https://t.co/HBVxBB3vKp
— Corey Quinn (@QuinnyPig) June 3, 2022
Google Cloud Platform is miles ahead of the competition with IAM, Workload Identity, native KRM feature extensions, Cloud Sync, and Config Connector. Meanwhile AWS takes 30+ minutes to provision an EKS cluster, and Azure has difficulty with security patches.
The choice is yours, however, if your team is looking for one platform for everything and you're using Kubernetes, please use Google Cloud. Especially if you're using Workspace already. Otherwise, I would suggest a combo of Vercel, Fly.io, Planetscale, and Supabase, et cetera, over platforms like AWS and Azure.
Credits are great, but think about peace of mind, and creating something truly unique and valuable. Credits don't help you build something well, scale something well, or create something truly unique and valuable. People, skills, and learning do.
Use the Kubernetes Resource Model over a DSL
I would suggest using Skaffold and Kustomize to create and manage Kubernetes resources over Helm because Skaffold and Kustomize follow Kubernetes Resource Model and avoid in-resource definition DSL which, I believe, is an easy way to accumulate technical debt and create more bugs for yourself and your team over time.
For more on KRM, please read this blog series to learn how you can use KRM for managing Kubernetes resources and Google Cloud resources too.
Do you even need Kubernetes?
The short answer is, probably not.
Why not? Well Kubernetes is great for deploying, scheduling, and managing workloads, but it requires far more work than simply using Google Cloud Run, Vercel, or Heroku.
If you and your team are building software for Kubernetes, things like operators, storage management systems, networking frameworks, data platforms, et cetera – use kubernetes.
In situations where you only have a few internal environments to manage, like most SaaS software companies, you should probably save yourself and your team time and energy and use other managed services that abstract the orchestrator away from you so you can focus on building the core product value add.
GitHub is a Goldmine
GitHub is so feature rich that you can basically run everything you need with GitHub Actions.
Routing all commits for infrastructure and product servicing development through GitHub Actions, as well as scheduled tasks has been a huge win for me especially in terms of cost savings and preserving history.
Paying for an "ops" cluster and not monitoring and logging user actions taken on infrastructure are things of the past.
Use Languages and Frameworks with DevX in mind
A framework that automatically documents your code, while you code, while validating types automatically, and can seamlessly support REST as well as gRPC are things to look for.
Some of the ecosystems I've worked with recently have been with Python and FastAPI, while others have been with Go and gRPC Gateway. gRPC Gateway needs some more boilerplate to get going but if you're working in the go world, it's a great place to start.
Growing as an Entrepreneur
Be Soulful
While working on Astrobase over the past two years, I've learned that as a combo entrepreneur and software engineer, I have to resonate with the following;
- The industry I'm in
- The problem that I'm solving
- The product that I'm building
- The people I'm working with
- The people I'm working for
- My skills are uniquely suited to get the job done well
That's a mouthful, so I think I can summarize it this way; I want to be a soulful entrepreneur.
I've been following Matt Gray recently and I really like his blog on this topic. In particular, I'm honing in on my Ikigai.
This breakdown for me looks like:
- What I love: Music and technology.
- What I am good at: Building software, teams, and companies.
- What I can be paid for: Building software, teams, and companies.
- The world needs: 🤔
I'm still working on that last one. So I'd rather explore the question of what the world needs rather than continue as-is with Astrobase because of what I've already stated before; I don't think the world really needs something like Astrobase now.
Revenue First
For Astrobase, I received more interest from venture capitalists and angel investors than I did potential hires, co-founders, and customers.
I could have raised $1-2M in seed funding to grow Astrobase and hire people to help, but that isn't what I wanted to work towards as an entrepreneur. I'm looking for a way to generate revenue because that means my customer is excited to pay my company so that it can continue doing things for someone else too. I will only take capital post revenue, for specific needs.
Furthermore, I did not have a ton of interest from top co-founder candidates. Most of my go-tos were already enjoying their jobs and didn't want to make the switch. Even after many conversations, their resonance stayed constant; happy to engage for a little and give feedback over a call or two, but not go in for the long haul.
Overall I think I made the right decision by sticking to my values here. I don't want to get out over my skis by raising too much money and hiring people who weren't quite infected by the problem Astrobase was solving and were not completely invested in pursuing the vision and mission of Astrobase full-time with me.
Strengths and Weaknesses
The past couple of years helped me identify some of my own strengths and weaknesses as an entrepreneur and engineer. These don't all completely relate to Astrobase directly, some of these learnings came from my primary job and other endeavors too.
Strengths:
- I'm great at building scalable software and systems on Kubernetes.
- I'm great at hiring people for engineering, design, product, and sales.
- I'm great at building teams.
- I'm great at creating connections in the music industry.
Weaknesses:
- I can convince myself that something is working when it isn't.
- I can resist rest because I want to "clear the decks".
- I can build too much before doing the necessary market research and user interviews.
- I can find it difficult to decide on one specific thing to work on due to my different interests. "No person can serve two masters."
I've learned that if I want to test a product idea that I have, I should keep it open source, bootstrapped, and dammit, don't buy the domain until I absolutely need it.
You are the easiest person to convince when you're convincing yourself.
Refocus and Invest
Experience is what you get when you didn't get what you wanted.
– Randy Pausch
I've decided to make Astrobase a personally sponsored, fully open-sourced project rather than a company for the time being.
I want to focus on honing my Ikigai and spend more time combining my interests and skills with the right problem in the right place.
There is so much out there to learn, build, and ship. There are so many people to connect with and learn from. There are so many ways to build wealth without having to risk burnout again and again.
Instead of entering a vicious cycle, I want to enter a virtuous cycle.
I'm very exited to take this next step for Astrobase and myself.
If you'd like to connect and chat with me about anything I've written in here or about anything at all, please reach out to me on Twitter. Cheers!