Bubble and your capstone project

Meeting Bubble, a second no-code platform

You have built a whole app in Adalo, so you already know the no-code way of working: drag components onto a screen, store information in collections, and wire up actions. Bubble.io is a second platform that works in the same spirit, and seeing it helps you understand that no-code is a family of tools, not one product.

Bubble is a no-code framework for designing, hosting and scaling web applications without writing any code. Its engine is written in JavaScript, and today it runs hundreds of thousands of apps, from weekend projects to apps used by large companies and universities. Where Adalo leans towards mobile, Bubble leans towards the web, so the two are worth knowing side by side rather than as rivals.

You will not build a full app in Bubble here. The goal is narrower and more useful at this stage: recognise what kind of tool it is, learn what it can and cannot do, and see how it thinks about data, so that when you pick a platform for a real project you choose with open eyes.

Saving and changing data in Bubble

Adalo talks about records in collections. Bubble uses slightly different words for the same idea: a piece of stored data is a thing, and every thing has a type and a set of fields. Once you translate the vocabulary, the mental model is one you already carry.

In Adalo	In Bubble
Collection	Type of thing
Record	A thing
Property	Field
Action	Workflow

Creating, changing and deleting things happens inside workflows, which are Bubble's version of actions. There are three you will use constantly:

1. Create a new thing. You pick the type, for example a Trip or a Message, then fill in the fields. A field's value can be typed in directly or pulled from somewhere dynamic, such as what the user just entered. If you create a thing without filling a field, the thing still exists, just with that field empty, and you can set it later.
2. Modify a thing. You point at a thing that already exists, for example the Current User, and change some of its fields. You do not pick a type here, because the thing already has one.
3. Delete a thing. This removes it from the database entirely. A workflow cannot undo a delete, so it is worth a second thought before you wire that action to a button.

Here is one of those in context. To post a message in a trip chat, you would use Create a new thing: set the type to Message, its text field to what the user just typed, its sender field to the Current User, and its trip field to the current trip. That is the very same shape as the Adalo chat you built two lessons ago, said in Bubble's words.

Bubble can also work on a whole list of things at once, so you can modify, delete or copy many records in one step. For example, if messages have a "read" field, you can mark every message for one user as read together. These bulk jobs run in the background and are not instant, so a workflow should not expect an immediate answer. Copying a list is capped at fifty items for stability.

Your capstone project

The capstone is the point of the whole course: one app that you design, build and present. It pulls together everything you have practised, the database, lists and filtering, user input, visibility, payments and chat, into a single working product. You may work alone or in a group, and the idea can be your own. If you do not have one yet, that is fine; the programme team will help you shape a topic that is realistic to finish.

You do not have to invent a build order, because the features you already know suggest one. Treat these as milestones and do them roughly in this order:

1. Design first. Sketch the screens on paper and decide what the app is for in one sentence. A clear sentence is worth more than a clever screen.
2. Model the data. Create your collections and the relationships between them before you build any screen. Getting Trips, Users and their links right early saves hours of rework later.
3. Build the core screens. A home list, a details screen, and a form to add a record. This is the skeleton every feature hangs on.
4. Add one real feature. Choose the one that matters most for your idea, for example filtering, a chat, or checkout with payments, and finish it fully before starting another.
5. Polish and test. Walk through the app as a first-time user. Fix the confusing labels, the empty screens and the buttons that go nowhere.

Keep the scope honest. A small app that works from start to finish is a far better project, and a far better thing to present, than an ambitious one that breaks on the second tap.

Here is one idea run through those milestones, to make the shape concrete. Say you build a small app for a study group:

1. Design. One sentence: a place for my class to post and find study sessions.
2. Data. Two collections, Sessions (title, subject, date) and Users, linked so that each session has a host.
3. Core screens. A list of upcoming sessions, a session details screen, and a form to add one.
4. One feature. A filter that shows only the sessions for the subject the user picks.
5. Polish. An empty-state message for when there are no sessions yet, and clear button labels.

That app is small, finishable, and uses nothing you have not already built.

On the final day you present the app to the group. Show it running on a real screen, walk through the main path, and be ready to say what was hard and what you would change. That honesty is part of the work, and it is the part that visiting guests and mentors tend to remember.

Put the whole course to work

You have built an app and met a second platform. Before the capstone, make the choice the course has been pointing at all along, for a situation with real limits rather than a tidy one.

Course practice · 20 to 25 min

Choose a platform, then defend it when the constraints move

You have built a whole app and met a second platform. This is where you choose between them for a real situation. Your work stays in this browser: nothing is uploaded, graded or kept.

Plan and platform facts below were checked against Adalo and Bubble on 26 August 2026. Vendors change these often, so check them again before you rely on them.

1 · Choose, for the job as it stands

A youth centre in Shkoder wants an app where members post weekend hikes and others join them. About 60 members. There is no money for it this term, so a free account only. The centre says members must be able to use it on their phones.

Read that last sentence carefully before you choose. "On their phones" and "in the app stores" are not the same requirement.

Which would you build it in?

Build it in Adalo on the free planWhat you have used all course. Mobile-shaped editor, publishes to the web on an Adalo subdomain.Build it in Bubble on the free planWeb first and strongly responsive, so it fits a phone screen through the browser.

In one line, why? Name the constraint that decided it.Commit this choice

If you are stuck, start from what is fixed

Do not start from the tools. Start from what cannot move. Write down two things: how much money there is and whether it comes back next year, and where the app has to run for the people who will use it.

Then ask of each tool only one question: what does it give me inside those two limits? Most platform arguments dissolve at that point, because the answer usually turns out not to depend on the tool at all.

The trap in this brief is the word "phones". A web app in a phone browser is on a phone. A store listing is a way of being found, which is a different thing worth a different amount of money. Separating those two is most of the work.

If that was straightforward

When is the free web app the professional answer, rather than the poor one? More often than it looks, and the reason is not technical.

A store listing is a subscription in disguise. It costs the platform plan plus the developer fees, every year, and the moment an organisation stops paying, the app vanishes from the stores and members who installed it are left with something that quietly stops working. A youth centre that funds itself grant by grant is being asked to take on a recurring cost with non-recurring money. Recommending that without saying so out loud is a real failure of advice, even if the app is excellent.

There is also a cost nobody puts on the invoice: someone has to maintain the store listings, renew the certificates, and answer the review rejections. In a small organisation that person is usually the volunteer who built it, and they will not be there forever.

Your turn: think of an organisation you actually know. Write down what would happen to their app in the third year, after the grant that paid for it has ended and the person who built it has moved on. Then say whether your recommendation changes.

Reset this practiceThis device remembers only which stage you reached and which options you picked.

Found something unclear, outdated or improvable? Suggest an improvement

Check yourself

1. Bubble and Adalo are both no-code platforms. Name one thing Bubble is well suited to and one thing it cannot do, and say why that matters when you pick a platform for a real project.
2. In Bubble, what is the difference between creating a thing, modifying a thing, and deleting a thing, and why is delete the one to be careful with?
3. Look at the capstone milestones. Why is modelling your data placed before building the screens, and what goes wrong if you skip that order?