February 8, 2024
Why Build BaaS?
Backend as a Service unlocks application builder for a new set of business users—a growing category as more businesses become software-first
This story starts at Palantir. We built awesome software. I had never seen such a well-functioning system before, it felt like we were building the computer screens that we see in every spy movie. We made sci-fi real.
After Palantir, I teamed up with a GSBer, James, to build a carsharing company, OXO. Carsharing, as anyone who has dealt with the “real world” will tell you, is remarkably complex. A short list of things we had to build for:
- Squaring up fuel at the end of the day (onboard sensors, spot checks in the garage, images submitted by users)
- Processing tickets and tolls
- Handling red-light and other tickets that required a court date
- Billing the correct user for damage
- Insurance claims
- Day-to-day ensuring the correct driver got into a car, and that they had the paperwork needed in their Lyft or Uber account (we focused on gig drivers)
Each of these operations required a somewhat complicated internal process. All processes started as Google Sheets, then gradually got bigger, and baked into the core application. Our dev team was small, and spent a growing portion of our time building internal tools instead of our core product.
This became doubly true when we were trialing new features, because we needed the backend applications to actually SUPPORT that feature.
This experience is what led me to build Bruinen. We consistently built very similar internal applications. Internal apps in general had these commonalities:
- A list/search view (to look up the customer, ticket, car that you were operating on)
- A single object view (to see all the details about a customer)
- Actions (being able to update a user, process an invoice, etc.)
- Headline stats (what’s our utilization today, how many drivers are on the road)
While frontend development was simplified by Retool, we still had to set up and maintain new database tables, backend endpoints, and even new permissions systems for different types of internal users. As the product grew and these applications began to overlap, maintaining them became our largest job.
To create a cohesive interface across a large set of data sources, we rely on a Data Ontology - the core data asset for the org. The Ontology provides a consistent set of operations, regardless of whether the data is stored in a database, warehouse, or in an external SaaS product. This consistency allows us to abstract away the details of connecting to each of these systems, and instead provide the user with the key building blocks of an application:
- Object lists
- Search and filtering
- Create, update, delete
- External API calls
With just these simple blocks, you can build complex, flexible, and powerful applications.
The Data Ontology allows you to set a model down on top of your data, without having to migrate or change the underlying table. It also crucially models the relationships between different tables, regardless of whether those tables live in the same system.
At OXO, we spent tons of time building and maintaining a Stripe integration to have a perfect record of payments and invoices tied to users in our system. With Bruinen, we wouldn’t need that integration logic, we'd simply connect our database, and our Stripe, and create a relationship between the objects.
Creating relationships across source systems overcomes a core boundary in application-building, the need to have multiple apps to accomplish one task.
Check out more here! https://app.bruinen.co/auth/sign-up