Why BaaS is Targeting Frontend Developers

A member of the engineering team leadership at a B2B SaaS company recently told me that there is no sense in marketing to frontend (FE) engineers; real spend is attached to the backend. Managed services, storage, serverless, and observability all amount to costly tools and services that VPs and Directors of Engineering purchase to support their platform and Ops teams. FE developers are rarely consulted before committing to these purchases because it makes little difference which hyperscale cloud provider hosts the app, or whether the team uses, say, DataDog or New Relic to track site performance. This is the conventional story that PLG and buyer-led strategic marketing and sales teams are laboring under. Yet many of the savviest tech leaders I have spoken with understand that FE developers should not be discounted in sales and marketing strategy because the FE is where innovation happens.

Supabase clearly didn’t get the memo that FE engineers do not represent a buyer profile worth attracting. When asked what market this BaaS is targeting on a recent episode of The Changelog Podcast, Paul Copplestone, CEO of Supabase, replied:

Definitely JAMstack… Eventually we’ll target more established full stack developers, even people who really enjoy Postgres already. Maybe we’ll win them over with our role based security.

The who, what, where, when, why, and how of marketing to frontend developers is a huge topic, and not one I can adequately cover in a single post. Therefore, I limit this discussion to several vendors in the platform and Backend as a Service (BaaS) space—Vercel, AWS Amplify, Firebase, Appwrite, and Supabase—because they are all deliberately marketing to the FE and full stack buyer (some more directly than others). I will highlight strategies currently being used to target FE engineers, and discuss the significance of these maneuvers.

 

Lowering the Barrier

The first tactic that dominates marketing targeted to FE engineers concerns lowering the barrier for technology adoption.

Vendors put pressure on the ostensibly “low” skill levels of the FE buyer. According to Ali Spittel, Developer Advocate for AWS’s Amplify, in a recent episode of the AWS Developers podcast: “We’re working on lowering that barrier” to adoption by marketing this product as a:

lower code backend. Without having to write too much code yourself you can integrate it just into your FE.

Spittel’s word choice invokes the low code/ no code movement, although the term “lower” is a political hedge likely intended to appease the anti-low/no code crowd.

The idea of lowering barriers brings with it connotations of altruism and DEI. Difficult engineering tasks are equated with gatekeeping and exclusivity. She connects Amplify’s “lower code” positioning to the larger objective of bringing more developers into the tech industry and eliminating imposter syndrome:

We are going to enable FE developers to build full stack applications without needing to know all this logic behind that, and also not needing to know all of the nitty gritty AWS services.

Copplestone echoes Spittel’s language of inclusion. As a suite of services wrapped around a database, empowering users less familiar with data management is essential to Supabase’s strategy for driving adoption:

We want to have people who probably aren’t so familiar with databases. In general we just make it ridiculously easy for these people.

Finally, the promise of Appwrite centers on how well it creates a seamless experience for FE and mobile developers. In addition to making their open source story a central tenant of their developer-first positioning, this backend server enables developers to build apps without writing backend code by abstracting, and thereby simplifying, common REST API tasks. Although it is intended to support, and not replace, backend engineers, this Dev.to article positions Appwrite as a “back end server for front-end and mobile developers.” Once again, by lowering the barrier this BaaS vendor has tailored their marketing strategy to the perceived needs of FE developers.

 

Opinionated

Which leads me to my next point. BaaSs are opinionated: a fact which is excellent for FE developers that don’t want to wrestle with the backend, and an absolute windfall for BaaS vendors.

The way in which AWS’s BaaS lowers barriers is by abstracting away decision making. Spittel mentions services including S3, DynamoDB, and Lambda as numbering among those pre-integrated through Amplify:

Instead of [typing] Amplify add S3, it’s Amplify add storage

Now, bundling alleviates the pain of choosing products from within AWS’s voluminous offerings. For consumers uninterested in and uncertain about how to set up a backend, this is a tremendous service. However, this solution does become a black box. For instance, Amplify allows users to set up authentication through the UI, but the service providing this functionality, Amazon Cognito, is not disclosed on the Amplify UI itself (although it will appear on their AWS bill).

This move seems to contradict the strategy Werner Vogels, VP & CTO at Amazon, characterizes as “Primitives, not frameworks.” In fact, my colleague Stephen O’Grady has written about Amplify’s seeming dissonance within AWS’s primitive-heavy portfolio:

It has been clear for some time that the demand for higher level abstractions is not an academic theory but a market reality. If AWS’ own product announcements from Amplify to App Runner were not enough evidence of this, all that’s required is listening to what forward looking, thoughtful developers are saying…

Companies like AWS benefit from these well packaged solutions which lock in consumers at every tier of the stack. But customer enablement by means of education also comes to play a tremendous part in the sales and marketing strategy of these BaaSs. Vendors must educate users about why they need the bevy of services on offer. The danger, of course, is that product pricing is notoriously unclear for managed services. Much like our healthcare system in the US, consumers have no idea what anything costs because nobody will tell you up front. There are discounts on some services if you invoke the correct combination of occult words, so that in the end you hope the bill won’t bankrupt you because it is for a thing you really needed (my thanks to KellyAnn Fitzpatrick for this analogy).

 

Excellent Developer Experience

BaaS vendors have worked extra hard to make FE engineers feel welcome by curating an excellent developer experience.

In a sense the current crop of BaaS products are all responses to Google Firebase (which, incidentally, positions itself as “an app development platform” rather than a BaaS), and what made Firebase so sticky is its excellent developer experience. Importantly, Supabase found success after changing its positioning from “Realtime Postgres” to “The open source Firebase alternative.” When Supabse took on Firebase directly, it made developers on Hacker News—among other places—sit up and take notice. Although database type is a significant differentiator between these two BaaSs (Supabase’s Postgres and Firebase’s NoSQL), this distinction is minimized for marketing purposes.

For FE developers that want to focus on writing business logic, quick onboarding, excellent docs, a robust community and a slick UI are all a must. As Lee Robinson, VP of Developer Experience at Vercel, reflected in a 2020 blog post, focusing on DX for FE is a priority:

Empowering the frontend developer: Whether it’s ~40k developers in the Next.js Discord community or hyper-local groups of 40 JavaScript developers, we’re helping educate and enable the next generation of developers.

It is worth pausing to note that Vercel, like Firebase, positions itself as a platform rather than a BaaS, although one of its products is a sibling Thin Backend: a “server to automatically get a fully featured web application backend.”

When it launched in 2012, Firebase caught on among developers for providing an excellent developer experience. Over a decade later, BaaSs that make databases central to their offerings, including some DBaaSs such as MongoDB Atlas, recognize the importance of this developer-first mentality for continuing to successfully target FE practitioners.

 

While I leave the not insignificant task of contextualizing this move to target FE developer buyers in the BaaS space for a future post (the identity crisis between FE and full stack development merits extended discussion on this issue), I outline some noteworthy trends to get the conversation started.

Disclosure: AWS, Google Cloud (Firebase), MongoDB, and Vercel are RedMonk clients.