This Bubble startup raised $10M and other no-code stories

Welcome to “In The Bubble” - a weekly newsletter for bubble.io users where we digest expert insights, tips, and trends for building, scaling and monetizing no-code startups.

Here’s what you can expect every week:

• Special offers and deals on Bubble related courses, templates and other products

• Case studies and interviews with successful no-code startups built on Bubble, 

• Insights on building, growing and scaling no-code apps

• Pro-tips on keeping your bubble application secure

• And much more.

Enjoy.

In today’s issue:

• Lessons from a solo founder who raised $10M for their startup built on Bubble (in 2 weekends!)

• 1-7 Mar 24 bubbling on X: @mneary0 asks where to find companies unaware of No code but could benefit, @levon377 suggests favorite no-code tools balancing user experience and functionality and 3 more.

• What’s the difference: Alert Toast Message Notify or myAlerts! is right for your app?  Feature and performance comparison.

• Free plugins of the week: A new AI image analysis plugin

• Perk of the week 🎁: A hidden nugget somewhere in between. 

• Weekly bubble security tip: 2 ways to check if your app is leaking privacy

^{STARTUPS ON BUBBLE}

Built Over 2 Weekends - Raised $10M - 3 Lessons From Cuure

Cuure.com is a personalized supplements business built on Bubble.io by Hugo Facchin and Jules Marcilhacy.

It came into life in 2 weekends but with a smart twist. The app was actually not working. But it was so by design, not like it happens to many of us.

The purpose of the app was to check the demand and if it was worth spending more time on it. This was important as both founders were broke and had to find a job if it didn’t work out.

And so the failing learning part had to be done fast.

That’s why in just one weekend Jules set up the prototype with a single sign-up form and a bunch of stock images.

Then they quickly ran a few Facebook ads and realized that it’s it - their million-dollar opportunity.

But they were wrong.

The opportunity was actually 10 million dollars (What a terrible mistake!).

The test was done. The decision was made. Jules takes a loan from his mom (allegedly) and they start building the business.

Another crazy drag-n-drop ‘coding’ marathon and the site was now a functional MVP with a workflow-driven supplement recommendation engine.

But in addition to that, their site had one big advantage over all other e-commerce websites. It could have almost any custom functionality they wanted. Something you can’t get from Shopify, Wix or Wordpress.

Time went by, and Jules and Hugo grew from 1 order a month to 100k USD in revenue.

Hugo by the way was the second founder. No one knows exactly what he was doing, but apparently, he was helping Jules.

Or the other way around.

And so they went to the rich. To CAPAGRO to be exact.

A few hours later Jules and Hugo walked away with their pockets filled with cash and a dedication to get a Lamborghini expand beyond France.

So what would you think? You have money and a team. Now it’s time to switch gears, hire some smart devs, and get that fancy last-model custom-built node js backend, right?

Nope.

Jules and Hugo didn’t think that way.

They decided to stick to what’s working, and their one-person-two-weekends-built app was still working perfectly fine (Don’t take my word for it, maybe they’ve invested some more time into the app since the launch, but even if so, it was still one-amateur-person-built-alone-on-bubble type of app).

Bubble was already taking care of their business, and they had perfect control over it. So instead of throwing money on fire, they decided to invest it in better logistics, warehousing, and ads.

Smart. Very smart decision.

Fast forward to today. Jules and Hugo have over 240k monthly website visitors on their bubble app.

Their site looks awesome, and works seamlessly, handling tens of thousands of orders from all over Europe.

And even though the team now has more than 30 people it’s still Jules who is wrangling with the debugger at nights (allegedly). Because he just can’t resist it.

He fell in love with Bubble (like the rest of us)

1-7 Mar bubbling on X

^{WHAT’S THE DIFFERENCE}

Alert Toast Message Notify vs. myAlerts!

This week’s what the difference covers  two popular free alerts plugins. They allow you to add a flyout type of alert a.k.a. toast alerts to your bubble app.

Alert Toast Message Notify is developed by Renato Asse and has an overall rating of 3.96 / 5, while myAlerts! is developed by Zeroqode and has a rating of 4.4 / 5 to date.

Customization Options

Alert Toast Message Notify: Title, message, timeout, background color, position, animation in, animation out, font name (title), font name (message), font weight (message), font weight (title), font color (message), font color (title), font size message, font size title, show progress bar, progress bar color, icon, icon color, image url, image width.

myAlerts!: Title, message, title color, title size, message color, message size, max width, icon, icon color, position, target, duration, progress bar, progress bar color, balloon form, big layout, rtl direction, dark theme, animate inside, pause on hover, restart on hover, animation in, animation out, animation in mobile, animation out mobile, close button, close using esc, close when pressed, swipe to close.

Performance

Neither of plugins demonstrated a measurable impact on site speed by Google Page Speed Index, beyond the standard deviation, making both safe to install performance-wise.

Conclusion

Both plugins are battle tested, having thousands of installs. Alert Toast Message Notify is a little simpler to setup, while myAlerts! Boosts with a better overall user experience and more customization features. 

You can check the myAlerts! here and Alert Toast Message Notify here.

^{THE NEW FREE PLUGIN OF THE WEEK}

AI Image Analyzer

Open AI - GPT - Image analysis is developed by Ketan Khamgaonkar and let’s you send an image to OpenAI for analysis. It uses GPT-4 Vision model to understand the image and returns it’s description as text.

This plugin is a great addition for a variety of image-based apps such as a cooking recipe apps where the user would upload a picture of a dish and get the instructions for it’s preparation. Or an app for interior design suggestions based on the uploaded image. 

To install the plugin visit this link.

2 Ways To Check If Your App Is Leaking Privacy

As of today, a lot of Bubble apps have security issues.

That's not because Bubble is not secure, it actually is.

It's because Bubble developers don't know that no-code cybersecurity is quite a serious thing.

Today, I'd like to introduce you to the biggest security issue you can find on a Bubble app.

It's about having public API Tokens in your API calls.

What's the Public API Token Issue?

This issue happens when you create a new API Call and add a parameter or a header that is supposed to be private.

Most of the time, it's about an authentication key to communicate with a 3rd-party service.

As an example, let's say we want to integrate the Stripe API.

To communicate with Stripe from my Bubble app, I need to add an "Authorization" header to all of my calls so that Stripe knows I'm allowed to retrieve data from them.

To add an authentication header to our API Call, this is how we would do it:

But the problem here is that this header will be publicly accessible to every single User using my app.

And you don't want any visitor to be able to access your Stripe private data.

What are the risks of having a public API Token on my app?

Depending on the service you're trying to integrate, having an accessible Authentication Key can be more or less critical.

But one thing's sure: whatever the service is, if you need an API Key, then it means you're going to access data that needs authentication.

So there's always a risk.

In our case (Stripe), it is really critical.

With our Authentication Key, one could:

• See all our customers and how much they paid

• See our discount codes

• See all the invoices

• See our financial data (MRR, Revenue, ...)

• Create more API Keys for their personal use

• Initiate Payouts

• Refund Customers

• ... and so on

I won't talk about the legal risks here, but obviously, it is illegal to have a leaking Authentication Key on your app.

How can I know if I have a Public API Token on my app?

Option 1:

Well, please do not use this technique on apps you do not own.

In order to find leaking API Keys, you'll have to dig down into the famous "app" JSON object.

1. First of all, open your app in "Preview mode".

2. Then, open the Chrome DevTools Console (CMD+OPTION+J on Mac, SHIFT+CTRL+J on Windows)

3. Once your console is opened, type in the following line:

4. "app["settings"]["client_safe"]["apiconnector2"]"

5. You should see something similar to this:

This is the JSON representation of your "API Connector" plugin.

And see the value inside the red square?

Yes, this is our API Token that is leaking.

No specific rights are needed to access this. Every visitor on your app can see it.

Now, you need to manually go through every single API Call of your app to see if there's no Authentication Key that is leaking.

Yes, it is time-consuming but it's definitely worth it.

Option 2:

The other option is to use the Flusk software.

Flusk is a tool that runs automated security audits specifically designed for Bubble apps.

It covers 23 security checkpoints, and one of them is called "Sensitive Parameter in API Call".

What Flusk does is the following:

1. It scrapes all the public data from your app (especially this JSON "app" object).

2. For every single API Call, it checks if there is something that looks like an Authentication Key to a 3rd-party service.

3. If it finds one, you will find it in your Flusk Dashboard with all the context you need to resolve it.

Here is the Flusk Documentation about Public API Keys.

How to protect my API Keys from being public?

Luckily, this issue is quite easy to resolve.

For non-dynamic API Keys (when you don't use OAuth 2), so for 90% of the use cases, you just need to check the "Private" checkbox next to the parameter. 

Now, here's what our JSON "app" looks like after checking the Private checkbox: Our header is now private and not accessible to the public anymore.

Issue fixed!

A few notes that might be helpful:

• Shared parameters and headers are private by default

• If the authentication you're using is dynamic (coming from a database value for OAuth 2 tokens for example), then you just need to remove the initialization value to fix the issue. You don't need to make it private.

If you're using an authentication key in your URL (for example https://api.stripe.com/v1/subscriptions?api_key=XXX) then you might want to define your key as a parameter and make this parameter private

Perk of the week 🎁

More perks are coming up in the next issues of the newsletter, stay subscribed to access best deals from the bubble.io universe

What should we focus on more?

We try to make this newsletter valuable. What type of content would you like to see more?

1. More startup stories

2. More tweet analysis

3. More plugin comparisons

4. More free plugins

5. More security tips

6. Something else

Just hit reply and let us know!

Cheers,

In.the.bubble team