As a software engineer turned tech entrepreneur, I founded and scaled two venture-backed SaaS companies with over $100 million of Silicon Valley venture capital raised between them.
The problem was that these ventures had burned mountains of cash by building complex, single-instance, multi-tenant software systems that required sales and implementation people to propel them forward and keep them running. So in 2017, I founded 8base.
8base’s thesis is that there’s an enormous unmet need for tools and platforms that make software development faster, better, and cheaper. 8base now offers a production-ready and straightforward software framework, and our architecture is incredibly important. Why? It’s not only our own tech stack, but also becomes our customer’s as well.
Given our team’s experience as SaaS operators, we had strong opinions that drove our architectural thinking. Some of these include:
- API-First — Computing infrastructure, data, and business logic should be abstracted into a back end and provisioned via a single, dynamic API.
- Elasticity — Computing infrastructure should be made available as a fully elastic service to a running application.
- Front-end flexibility — Software is more art than science these days as companies express themselves technologically to their customers. Builders must be able to design and build user interfaces in any style and across a myriad of form factors.
With that in mind, here is what 8base is built upon.
The 8base tech stack
First, we chose Amazon Web Services (AWS) as our computing infrastructure. It’s the market leader in cloud computing services. We utilize many AWS services, including:
-
serverless computing using AWS Lambda. Applications built using 8base utilize Lambda as well. Serverless is a relatively new model of computing that runs code in response to events while automatically managing required computing resources. Lambda fulfills computing needs like your power company: via a microunit-based, fully elastic, and metered service. It also minimizes the need for DevOps personnel, which translates to less cost for startups.
-
AWS Aurora MySQL and MongoDB Atlas as databases. Both are hosted databases-as-a-service, which makes them fast, redundant, fault-tolerant, managed, and scalable. 8base also provisions a dedicated Aurora MySQL instance to each developer workspace.
-
AWS S3 (Simple Storage Service) for object storage service. However, 8base also does the difficult work of exposing S3 to workspaces and front-end applications. It makes it super easy to store documents, pictures, voice/video files, and more. 8base also uses FileStack so that developers can easily connect their cloud storage, social, and other accounts. We chose S3 because it is inexpensive, fast, reliable, and virtually infinite in its storage capacity.
-
AWS's API Gateway is utilized by the 8base engine and is automatically provisioned for 8base-built apps as a service for creating, publishing, and securing REST and WebSocket APIs.
8base built an incredibly powerful GraphQL API engine as part of the platform. GraphQL is a standard developed by Facebook and was open sourced in 2015. It exposes a single endpoint that allows for dynamic communication between the back end and front end. GraphQL lets front-end developers work very quickly without depending upon back-end developers for specific resources. This API technology helps 8base and teams using 8base to move faster!
We support applications built using any front-end technology; however, 8base itself is made using React. React is an open-source JavaScript library maintained by Facebook and a community of developers. It's optimal for fetching rapidly changing data. React is incredibly popular today and also offers React Native, a framework for building native apps on iOS and Android.
Finally, we chose Auth0 as our authentication provider and as the default for apps backed by 8base. Developers can very easily integrate Auth0 into their apps while still being able to utilize other authentication providers. Auth0 delivers integration with over 30 social and enterprise identity providers, in addition to multi-factor authentication and other powerful features.
Advice for indie hackers
Architect for scale
The "lean startup" approach is often practiced by slapping together a software product so that founders can immediately begin pursuing product-market fit. I encourage founders to consider how much trouble they might find themselves in if their products need to be rewritten once product-market fit is found.
It’s better to build on a solid foundation with the ability to iterate on a product without ever having to sacrifice the ability to scale. We did this at 8base and it’s paying dividends now because we are spending our time incrementally improving our product rather than working on technical upgrades or rewrites, which are essentially invisible to our customers.
Be wary of developers that build products for startups without thinking through the data model
Some of the back ends that exist today allow front-end developers, especially mobile developers, to simply dump data into them without considering any schema or structure. For some apps, that’s fine. For most apps, it’s not. Make sure that you're choosing an unstructured data approach because it’s the right choice, not the easy choice. Otherwise, your data will be as organized and maintainable as spaghetti...when cooked.
If you are a non-technical founder and use an agency to help you, ask them the following eight questions.
Agencies are generally in business to provide professional services for as long as they can. Their incentives do not always align with those of the founder. Some key due-diligence questions should include:
-
Do you approach software development as a design-first or engineering-first exercise?
-
Do my early deliverables consist of high-fidelity prototypes, wireframes, or both?
-
What startups have you helped that achieved product-market fit and became financially sustainable?
-
How do you architect applications to ensure I never need to rewrite them?
-
Will I be able to hire developers that aren’t you?
-
Will my software scale when the time comes?
-
What happens during the project when we are altering our designs based upon new market information?
-
What resources will be needed to support our product once it’s built and goes live?
Building tech products is a never-ending journey for an entrepreneur, but table stakes in terms of what will make a venture successful. The early decisions of what, who, and how can make the difference between success and failure. These decisions include who is deciding what the product does, who is designing and building it, and what underlying technologies are utilized.
Sticking the landing on these three decisions gives an entrepreneur a fighting chance. Making a mistake in any of the three can mean delays, added costs, and perhaps failure.
Thanks for reading! Feel free to add comments or reach out to me with questions at albert@8base.com.
Gotta push back a little on the advice to "think about scale". In the early days you need to think about validation. The vast majority of startups fail to get any traction at all, so while the bad news is that if you just throw something together without thinking about scale, you may run into scaling issues (truth is, if you ever hit real scale you're probably going to find yourself re-architecting multiple times anyway), but it's better than to build a scalable, robust and really well thought out architecture for an app that nobody actually ever ends up using,.
You don't need to go out of your way to pick technologies that won't scale (either by load or by number of developers working on them), but I wouldn't materially slow down the launch of something to make sure it is scalable unless I had definitive proof that people actually wanted the thing you're making.
Makes sense. I don't see why one can't take a balanced approach. I may find myself concerned more with the technology as I am an engineering founder - so I may have some bias.
However, I would say the more you can make sure the foundation for the product is stable then you don't have to worry about rewriting the thing - which could take a year +.
If you can mitigate it as much as possible you could end up saving 6+ months. I would agree that it's important to do things that don't scale at first. If you have a little control upfront towards making the right tech decisions then there is nothing wrong with a balanced approach.
If you're a founder who has no tech expertise then fine it's out of your control, unless you find someone who can advise you, which could be a good idea. I would say that should only be 20% importance. The 80% is validating and finding product-market fit. Nothing wrong with being a little prepared though IMO.
Just my 2 cents. Thanks for reading. I could be totally wrong. I am a completely new founder for https://storycreatorapp.com/ and am learning every day.
Hey Peter! Great to hear from you and thanks for the push back. I do/don't agree with your push back.
You're absolutely right that the majority of startups fail to get any traction. Also, you're absolutely right that in the early day's founds need to think about validation.
That said, what is validation? At what point do you start building a product? When you start building a product, should you build it to later throw away? Is "re-architecting multiple times" an indicator of good or bad decision making?
I agree with materially slowing down the launch of something, early on, to make it is scalable isn't a good strategy. That's why we built 8base. It materially speeds up the launch of something, while simultaneously handling future proof scalability issues. There are no absolutes. And, hopefully, you can accomplish both.
The approach is going to vary by company, product, and entrepreneur. For instance, a technical founder pursuing a new venture as a side hustle can take more liberties in this area because they aren't missing any meals, can pivot quickly and potentially have the skills to re-platform as necessary. Today, these people are the exception, as most founders are non-technical.
The ventures I have been in have been very unforgiving of flimsy MVPs. Both Avisena and CareCloud dealt with physicians getting paid and managing clinical transactions. These use cases required products to be mature before you could evaluate success -- Trying to validate too early poisoned the experiment. The same is true of 8base. Additionally, it can be extremely difficult to rip out bad architecture for a production product.
There is also a difference between young people with few commitments becoming entrepreneurs and middle-aged non-technical founders who may be walking away from big salaries, investing their life savings and putting their careers and families at risk. There is no time for rewrites that cause delays in traction, compensation, and exits.
But don't take it from me. In speaking with accelerators and venture capitalists all the time the problem of nice-looking products that fall apart under load or simply can't comprehensively support the needs of the startup has become universal. Michael Seibel / Y-Combinator recently tweeted about his concern.
I feel strongly enough about this that 8base was founded to help solve this problem. I think every entrepreneur must use their gut to figure out the right balance of solving for scale for themselves. And, it's not a binary decision. In some areas of their business is might be a trivial issue and in some others, it could be table-stakes.
Have to say I agree. #1 problem in a startup is validation, which is achieved through speed of learning. Engineering for scale needs to be done at some point, but not from the outset. Start designing+building high scalability technology too early and it'll just slow down validation and burn up runway, increasing the likelihood that the whole venture will fail. That doesn't mean don't design at all, but design for validation speed, iteration speed, and don't be married to what you build at first because it'll probably be wrong - both for your customer and for your eventually scaling.