This No-code Engineer Uses AI to Protect from AI

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.

In today’s issue:

• 3 Lessons From The No-Code Engineer Who Uses AI To Protect From AI: Brian Jagger’s story

• 7-14 March bubbling on X: @elibeachy notes improved UI at @weweb_io no-code web frontend builder, @levon377 shares a simple guide about Custom GPTs, and four more.

• Don’t Listen To Your Clients When It Comes To How To Build Their App: Petter Amlie’s Optimization Secrets

• What’s the difference: Air Gantt Chart Lite vs. Gantt Timeline Feature and performance comparison.

• Free plugin of the week: A collaborative Rich Text Editor

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

^{STARTUPS ON BUBBLE}

3 Lessons From The No-Code Engineer Who Uses AI To Protect From AI

How do you find a good niche for a business?

Wait.

You know you need a niche before you start a business, right? Not the other way around.

Unless you’re getting paid for failed startups of course. Haha. But that’s a different business model. We’re not covering course-making now 😇.

Back to business.

Brian Jagger - a no-code engineer and CTO at guardrailz.com was asked by his friends to make an app that would protect their kids from the dangers of AI.

You know, just a regular request to a non-technical friend.

We even think this was a joke, but Brian took it seriously.

Just like every other entrepreneur who hasn't given up after the first five years of failure he lost his sense of humor when it comes to business ideas but still had a spark in his heart and believed a little too much in himself.

And it paid off. He built it.

An app that protects from AI using AI.

A “Terminator” bubble app, if you wish.

The kids were safe. The niche - chosen

Now the boring story part.

Whenever we ask people what motivated them to start their business, we rarely hear “money” back.

And we love this because it shows their values. It’s reassuring to know that there are still people whose primary goal is to make the world a better place. There is hope!

And so, concerned with nothing but the safety of kids, and not just kids, but adults too, and not just in the US but worldwide, Brian started working on guardrailz.com - “the ultimate tool for parents and educators looking to provide a safe and secure educational experience for children”.

It started classically.

1. Brian discovered Bubble. 

2. He built an app on it. 

3. It looked ugly, so he bought a course. 

4. And then another one. 

5. And then he felt like procrastinating watching videos. 

6. And so he got back to doing and finally built his dream app within just one month.

At the end of the month, he released his platform for beta testing.

The hamburger stand was ready. The only thing left was to tell the hungry crowd about it.

Right?

Nope.

It’s not that easy! 

The real work starts after you build your product, not before. Seasoned founders know that, and don’t shy away from using all means necessary to get in front of their customers and ask for feedback.

This is the phase when you’re laughed at.

This is the phase where you make or break your dreams.

So after you build your app and start promoting it, you quickly realize a universal truth. Something like “The earth revolves around the sun”, and “Humans are mortals”, but more true.

It’s that nobody cares about your product. (Not even your mom!)

You realize that the only thing people truly care about is what is in it for them.

But by that moment you usually end up either in the majority of “ordinary entrepreneurs” who’ve built an app nobody’s ever gonna use, or you see fast-growing traffic and start thinking about what you would tell the crowd when you’re asked to give a speech at the Stanford Graduation Ceremony.

So what did Brian do?

He started knocking on doors and asking people to use his app.

Reddit, Twitter, Facebook groups, in-person meetings, everything was put into practice.

The result? It worked!

He’s got a solid chunk of early adopters, few partners from the Ed Tech industry, and insights on how to iterate his business further. Which, is a topic for another time.

And so, let’s wholeheartedly wish Brian further success with his project, primarily the energy for pushing his cart further up the hill, until it crosses the top and starts rolling by itself.

And if you happen to be a parent or an educator, go ahead and sign up for a plan at guardrailz.com.

7-14 March - bubbling on X

Don’t Listen to Your Clients When It Comes To How To Build Their App

Let’s explore the two layers that make up an app.

There’s a top layer with the interface your users see and the bottom layer – the technology that keeps the app running.

It’s complex, spread over the network, and packed with all sorts of wizardry – databases, servers, APIs, and more.

The top layer is something we place on the ugly bottom layer to keep users comfortable and tasks running smoothly.

It's the steering wheel that allows them to turn without knowing or seeing the mechanics under the hood.

Hiding the complex stuff is your job as a developer. And to be able to do this efficiently and step up your game you should understand the difference between the data concept and the data type.

Put simply, the data concept is what your user thinks they need.

And the data type is the actual schema of the structures underneath the surface.

For example.

Let’s say that you are building a CRM for a client. Your client wants to manage a list of clients and a list of vendors.

And so the client tells you that there have to be two lists - one for clients, and one for vendors.

But when you look at the structure of each client and vendor, you can see that they are the same.

Each has a Company name, Address, Phone number, and Contact email.

And so you realize that you don’t need two lists for managing them because, at the ground level, they have the same structure.

This is where the data concept and data type differ.

• The data concept is your client’s imagination. They want to see and manage two lists, and conceptually these are different things. You buy stuff from one and deliver stuff to the other.

• The data type is what you actually set up in your database. And we discovered that clients and vendors have everything in common except for one tiny detail.

And so as a smart developer, you choose to create a common data type for both entities, even though they’ll be displayed as two separate lists on the UI.

Not only this gives you fewer things to manage, but it also makes it easier to add additional fields later on.

Because as you might know, the clients tend to ask for additional stuff further down the line, such as ‘can’t a client also be a vendor?’ for example.

Had you had two separate data types you’d have to keep them both updated, make separate searches to find them, and… yuck. It’s giving me a headache just to think about it.

Instead, you’ve set up one data type and separated the entities by a field such as a Company type with an option set of client and vendor.

So the point of this example is not that we should always combine the entities but that the database is yours to design.

The database does not need to reflect the data concept of the client.

The idea is not about combining but making informed decisions, without getting blinded by how your client describes it.

The same can be true for an opposite scenario when you’ll want to divide one data concept into two data types, to make the app perform better.

We’ll get back to that later after discussing another important concept - the data weight.

Data weight

Data weight is how much you store in a single database thing.

As you might know, there is structured and unstructured data.

Structured data is information that is short, to-the-point, and set up in a predictable way.

For example, your phone book contains structured data.

That’s because name, number, and email always contain data in the same format and the fields are easily distinguishable.

Now, let’s say we want to write an article with a biography about that contact.

The article may contain details such as name and number too, but they’ll be hidden somewhere inside a lengthy text that makes up the content.

This is now unstructured data.

It’s harder for both a computer and a human to extract that information. And you wouldn’t expect the user to want to read a full biography just to find the relevant parts.

Now let’s look at this from a technical point of view.

The name Jane Doe contains eight bytes of data: seven letters and a space. A full-length biography might contain something like 2000 words.

Let’s assume that on average a word in English has 6 characters.

This would make the 2000-word article weigh about 12,000 bytes of text.

Quite a bit more than the eight bytes for the Jane Doe name!

This is important because every time your app interacts with the database it sends data back and forth.

In the case of Jane Doe, the user’s device needs to download eight bytes of data.

In the case of the article - 12,000 bytes of text.

From a performance perspective, the former is 14,9900% more performant.

Therefore, the biography article has a high data weight compared to the name.

And even though 12kb is not much, for modern devices, this weight adds up very quickly. Not just performance-wise, but also in terms of data transfer costs.

And so, what can you do if you need to be able to store, search, and download lots of unstructured data efficiently?

Enter satellite data types.

Satellite data types

I introduced Satellite data types in my book The Ultimate Guide to Bubble Performance.

The idea is that any data type can have a secondary, lightweight - satellite data type.

Imagine we are designing an online magazine with lots of articles.

These articles are long, making up a large amount of unstructured data.

In addition, the platform has an advanced search functionality that lets the users easily locate the articles.

This is a classic case of what I call a requirement conflict: on one hand, we need to store the articles with a high data weight, but on the other hand, we need to be able to search for, download, and display them as efficiently as possible.

These two are in direct conflict, but it can be solved using two data types:

• The first would be the data container type. It will hold the full content of the article in HTML or BBCode format. This data type is expected to be heavy as It contains all the information, such as:

  • Title

  • Author

  • and Article
    

• The second type is the satellite. A streamlined version of the article record optimized for search operations. It has only the fields necessary for effective search and display. These include:

  • Title

  • and Author

Thanks to this separation the app can rapidly retrieve information from the lightweight satellite data type when the user searches, and the data container type when the user clicks on an item, making our app both functional and performant.

Other uses of satellite data types

The above was an example of how you can improve the search performance of heavy unstructured data using satellite data types.

But there are also other scenarios where satellite data types are just as useful, but the context and purpose is different. For example:

Site-wide searches

One example highlighted in our book involves site-wide searches.

Consider a platform like TripAdvisor, where a single search bar can find countries, cities, attractions, hotels, and restaurants.

There’s not a search bar for each of those locations, but a single bar that gives results within all categories, just like the Spotlight search bar on a Mac.

One way of creating this would mean setting multiple searches stacked on top of each other, for each entity type; countries, cities, attractions, etc.

But a more performant approach would be to have just one search with a satellite data type for each database thing.

For example, if you have 100 records of each type (country, city, attraction, hotel, and restaurant), the search satellite data type would cover all of those 500 records as one record type with one field of difference between them.

That field would show whether the record is a country, city, or attraction, etc.

And since you have collected all 5 types of entities under a single satellite you can now make just one search to get all of the types in the same search bar with great performance.

Implementing this in Bubble traditionally would mean setting up multiple searches, which is inefficient.

Here, a Satellite Search Data Type combines everything into a single searchable entity, greatly improving site-wide search functionality and user experience.

Thoughtful database design with the UX in mind

The goal of all this ramble was to point out that what your client thinks (data concept) is not necessarily how you should create your app. For many reasons, performance is the first one.

The database should be less of a reflection of the user interface, and more of a behind-the-scenes mechanism, whose goal is to provide a secure, performant, and enjoyable experience for the users.

About the author

Petter Amlie is the founder of Amlie Solutions. He is an active member of the Bubble community, a frequent public speaker, and the author of two influential books: The Ultimate Guide to Bubble Performance and The Ultimate Guide to Bubble Security.

In 2022, Petter collaborated with Bubble, in writing the official user manual available at manual.bubble.io, a testament to his deep understanding of the platform.

You can contact Petter on Twitter, LinkedIn, and the Bubble forum.

^{WHAT’S THE DIFFERENCE}

Air Gantt Chart Lite vs. Gantt Timeline

This week we cover two free plugins for adding Gantt Chart functionality. These could be very useful for internal project management apps or data analysis SAAS.

Air Gantt Chart Lite is developed by Zeroqode and has an overall rating of 4.33 / 5, and the Gantt Timeline is developed by Nocoleb and has a rating of 4 / 5 to date.

Customization Options

Air Gantt Chart Lite: Task type (data type), task source, task color, show column, column name, column width, header background, header color, main view background, main view color, scale X, scale Y.

Gantt Timeline: Projects (data type), projects data source, project name field, task types (data type), tasks data source, task field name, task project parent, subtasks types, subtasks data source, subtask field name, subtask start date, subtask end date, subtask parent task, header background color, header title, header title color, selected tab, highlighted tab, highlighted tab text, timeline background, timeline text.

Performance

Neither of the 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

Air Gantt Chart Lite is good for simpler projects without nested tasks and subtasks. It’s also good to display some additional information about the task such as the description, assignee, percentage of completion, and more, as a table adjacent to the chart.

Gantt Timeline on the other hand is better for more complex projects where you need to show the nested tasks and subtasks and don’t need to display any additional information as a separate table.

You can check the Air Gantt Chart Lite here and the Gantt Timeline here.

^{THE NEW FREE PLUGIN OF THE WEEK}

A Collaborative Rich Text Editor

Rich Text Editor is developed by Rico Trevisan (Tiptap.dev). What’s so good about this plugin is that it supports multi-user editing - a killer feature for modern collaboration apps.

This plugin is a great choice for those building internal editorial apps or websites with blogging functionality.

To install the plugin visit here.

The perk of the week 🎁

More perks are coming up in the next issues of the newsletter, stay subscribed to access the 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 how-to and optimization tips

6. Security tips

7. Something else

Just hit reply and let us know!

Cheers,

In.the.bubble team