03. Build No Code - Low Code MVP

Estimated Time

• Reading: ~14 minutes
• Video: dependent on the video(s) you reference from this section
• Activities: to be completed prior to the next week

Insights

• The MVP development flywheel
• Build the database, create new pages, develop the workflows, test the application, gather feedback, iterate
• Update the database, adjust the pages, develop new workflows, test the new features, collect user feedback, iterate...
• You will be building your MVP, collecting feedback, and iterating on your idea from this point forward as a part of Founder.University
• Let's start building your MVP and kick off this flywheel!
• Note: It is a great idea to refer to previous sections as needed

Bubble Resources

• The main resource referenced throughout this section is the documentation for Bubble known as: The Bubble Docs
• If you are building on Bubble, read these documents and reference back to them throughout your building process at each step
• If you are building on another platform find their documentation, and understand it
• Knowing how to use the products built in features (and more importantly when to use each) will save you time in the long run
• The Bubble Docs walk through the important tools, features, concepts, tips, and often link out to tutorials that help you understand the main capabilities in the tool
• Another great resource is Bubble's YouTube channel
• There is a combination of tutorials, tips, and presentations on this channel
• Searching on YouTube (even beyond Bubble's channel) will surface additional tutorials that are highly valuable
• It is recommended that you bookmark these two resources (Bubble's docs and YouTube channel) and use them early and often when building your MVP
• Another piece of advice: look back at your notes and experience from the activities in the No Code Intro section
• If you didn't try the Bubble lessons in "hard mode", we suggest you do so now as a refresher
• We will also use the wireframe you created during that section
• If you need to finish that up please do so now!
• Remember, there are also a few crash courses that are well worth your time (if you didn't get to them previously):
• Getting Started with Bubble
• The Bubble Fundamentals
• Build Your First Bubble App
• Bubble also writes frequent blog posts
• One of which we'll use to guide us through the initial steps of getting your MVP off the ground

Getting Started with Bubble

• We have already taken care of the first few steps of building an MVP according to the Get Started With Bubble in 10 Days blog
• You completed the initial Bubble tutorials and built a wireframe
• We will reference the "days" from this blog throughout this section
• Keep in mind, part of being a founder is self-assessing regularly and making decisions that are best for your startup
• If at any point you need to revisit any steps or dig deeper into sections please take it upon yourself to review or study beyond the content
• Leverage the "community conversations" for questions and conversations with your cohort
• Note: we will occasionally have representatives from Bubble attend our live sessions to answer platform-specific questions
• Let's shift the focus and start building!

Database

• As you saw in the Bubble Docs when you read them above there is a section on Data Structure and one on Working with Data that are great references
• Build your database
• The database is the foundation for your application
• Almost everything you need to populate in your app will need a spot in the database
• The database is where all of the user data is stored
• When you hear about data leaks online, a bad actor has gotten access to the info stored in the database
• Users don't see the database in the same way they see the content of your application, but it is from this database that much of the content is pulled and displayed
• For example, when a new user signs up they may enter their name and email address
• That information gets stored in the database
• Something like:
• First Name = "Sally"
• Last Name = "Smith"
• Email = "sally@email.com"
• This information is not displayed unless you tell the application to display it
• It is simply being saved in the background (in the database) until you tell the application what to do with it
• Now, if in your application, you code the welcome screen to say: "Welcome {First Name}"
• The application will know to go into the database and look for {First Name} and see that for this user it is equal to "Sally"
• This logged-in user will see "Welcome, Sally" on their welcome screen
• To review, in order for this to happen you needed:
• To have a field in your database that stored "First Name",
• A welcome page had to be designed to display the content, (we'll get to this in a minute)
• A workflow had to be created that said "when they sign up display their name on the welcome screen" (we'll also get to this later on in this section)
• As you can imagine, getting the database right is important to the functionality of your product
• Any piece of information that your user gives you needs a space to be stored and it is up to you to design that
• These two YouTube tutorials from Bubble users provide great visuals of how the database works in Bubble and why it is so important
• Matt Neary in, "Good database design in Bubble" sketches out the relationship with great physical representation on paper before building in Bubble
• It is highly recommended that you plan out your database structure so you can focus on each relationship before building it in Bubble
• This allows you to stay focused on identifying all the important data before worrying about which buttons to push in your no-code platform to create the database
• First lay out all the pieces - then recreate it in Bubble
• Just like you are doing a puzzle
• Once you have it all mapped out - you can use all your focus on creating the database on the platform
• A common mistake is trying to take on too much at once
• Break it down into small simple steps whenever possible so that nothing gets overlooked - and don't skip steps!
• Think about how you might use each piece of data in your application
• For example, do you need to have an individual field for "First Name" and another for "Last Name" because you want to reference them independently rather than simply having one field, "Name" that contains both
• It is a good idea to get your thoughts out of your head and onto paper
• Then you can review if any steps are missing
• And you can refer back to the notes as you debug or iterate on your product
• YouTube user nocodelife explains "How to structure your Bubble.io database" and actually builds a visual representation of the database relationships
• This tutorial allows you to "see" what is happening behind the scenes in a database as you structure your own in Bubble
• Even if you aren't using Bubble this video provides great insight into how to think about your database
• No matter the platform, establishing a solid foundation (the database) will help set you up for success

Creating Application Page(s)

• As you saw in the Bubble Docs when you read them above there is a section on Building a User Interface that is a great reference
• Create reusable elements
• This stage is about moving your wireframes from Figma, Canva, your notebooks, or where ever you created them into Bubble
• These are the pages that the user will see in your application
• Remember the database stores the data behind the scenes
• The application pages are what the user will see
• These application pages in Bubble do not need to function (yet)
• At this point, it is about making sure all the pieces are in place
• We are more worried about how the main pages look rather than if they "work" at this point
• We will connect them to the database and bring them to life later
• Make sure that all of the main pages and main features are represented in your app
• The core features that you identified previously need to have a spot (as designed in your wireframe)
• Depending on the structure of your application you may have several different pages that will eventually link together
• You will want to create a new page in Bubble for each screen the user will see
• For example, a welcome page, a homepage, a page to upload an image, individual user pages, admin portals, login screens, checkouts, etc.
• It is important to have any page that is part of your MVP created before you get into workflows
• Note: if you used Figma to create your wireframe you can upload it into Bubble with some known limitations
• This documentation is worth exploring if you used Figma for the wireframe
• Don't forget to leverage the Marketplace in Bubble when possible
• The marketplace has all kinds of templates available for you to use and tweak to your needs
• Categories such as landing pages, marketplaces, dashboards, blogs, and more
• Several of the templates are free and able to be used in your apps with a few clicks
• These templates can get your pretty far down the road in some cases
• Don't forget there are also tutorials on how to build clones of familiar apps
• If your idea has a similar layout, features, or concepts to a familiar app do a quick search to see if a template exists
• Using these templates as guides can save a lot of time and help you avoid recreating the wheel
• Another thing to keep in mind, even though users don't yet know your app exists, they will expect that it functions in certain ways
• Think about your favorite apps, websites, marketplaces, etc. and incorporate the 'standard' features
• You want your users to feel that they know what to do when they log in for the first time
• For example, in most mobile apps users will look for a menu in one of the corners
• They'll want to be able to update their info in settings or be able to easily search your marketplace from a search bar
• Think about this, if you were designing a world-class sports car you would not switch the gas pedal with the break or invert the steering wheel just to stand out and be different!
• Some things need to function as expected!

Integration and Dynamic Content

• As you saw in the Bubble Docs when you read them above, there is a section on Elements that may assist you here
• Design your elements and set up integrations
• Now that the database is set up and the main pages of your app are in place you are ready to have the two interact
• So the next step is to use different elements in Bubble to dynamically show the content from the database on your pages
• In other words, this is where you'll connect the database (all the info that the users don't see) with the front-end (the pages that the user does see)
• Review the Bubble interactive learning lessons or tutorial videos if needed
• You will also start adding more elements that drive action if you haven't already
• Things like buttons, input fields, images, maps, repeating groups, etc.
• Once the dynamic content is in place you'll be able to start building the workflows that allow users to interact on your app and have it respond (we'll get to that shortly)
• Another concept you may want to include is Conditional Formatting
• This means that certain elements will change based on a specific condition
• Think about where in your app conditional formatting makes sense and begin to implement it
• For example, you saw in one of the crash courses, when a user wants to sort a list of items by "Most Popular, Most Recent, or Alphabetical"
• The list is sorted, the content is changed, based on the condition that the user selects
• Conditional formatting is essentially an extension of the "if this, then that" logic
• Containers are a great way to group data in Bubble
• As you've seen with other elements there are several properties already built-in so that you don't have to completely build from scratch
• Grouping elements makes it easier to style and arrange content on your pages
• For example, the repeating group elements quickly create lists that can pull data from the database
• There are several options for the layouts and how to interact with this content
• So, if you were creating Netflix selection screen, rather than individually placing each movie in a row you could leverage the repeating group feature
• You simply tell Bubble how many movies from the database are in each row and column
• As you saw in the Bubble Docs when you read them above there is a section on Using Plugins and Using The Bubble API that may assist you going forward
• Bubble has made a few plugins with parameters that are worth exploring
• You can quickly integrate with Stripe, DocuSign, MailChimp, and others
• Something else to note from a design perspective; Bubble has the ability to make your app responsive
• This means it can change layouts depending on the type of screen of the user
• You have seen this with a website on a computer browser that may have a navigation bar at the top of the screen with links to help you browse the site
• But when you visit that same website on your phone that navigation bar is in a drop-down menu so as not to take up too much space on your much smaller screen
• Identify if your users are most likely to use your product on a computer browser, phone, tablet, etc. and design accordingly
• You can explore the Responsive Properties built into Bubble or use the Responsive Editor to see how your product will look on various screen sizes
• As you know, an MVP is far from a finished product, but it is still important to make a good first impression with your users
• Recommendation: Focus on how your product looks on the 'main' screen size first
• You can demo from this view and instruct your first users to use it in this format
• Don't 'waste' time designing for an edge case before your app is even fully functioning
• You can add in responsive design later if users are offering that as feedback

Workflows

• Next, you will bring your app to life by implementing workflows!
• Without workflows, you have elements on a page and data in a database but there is no way for those things to interact or talk to each other
• For example, simply adding a button to your page does nothing except take up space until you build the workflow that tells it what to do when it is clicked by a user
• As you saw in the Bubble Docs when you read them above there is a section on Building Workflows that is a great reference
• Link it all together with workflows
• It is a good reminder that computers will only (and always) do exactly what you tell them to do
• Think of the workflows as the directions you are giving the computer to take
• Every interaction your user can take in the application needs a set of directions
• The computer will not assume anything
• You must spell out every action
• For example, after a user submits a form or performs a search, do you want the content to be cleared from the input field? Do you want to redirect the user to a new page?
• If yes, then Bubble needs to know you want to "reset data" at the end of that workflow and which page the user should be shown
• No-code makes this process easier than having to code it yourself, but the concept remains the same in both formats...
• Your application will do exactly what you tell it to do; nothing more and nothing less
• This is why being familiar with the documentation is so valuable
• Which elements are built in to make the process simpler?
• This is another place where your wireframe will be helpful
• Sketching out on paper (or in a design tool) what should happen when a user takes an action helps ensure you don't skip any steps
• Write them down in plain text
• Then worry about how to make it happen in Bubble
• If you are coding from a list it is less likely that you'll forget one of the steps along the way
• The phrase "if this, then that" will be repeated in your head (and in your application) often
• "If a user clicks on this link, then that page will be shown"
• "If a user clicks on this button, then that action will happen"
• Review the Bubble interactive learning lessons or tutorial videos if needed
• Tip: Don't forget that a quick Google or YouTube search for "bubble.io workflows" may surface videos to help with your specific need
• The workflow process can be time-consuming, but is the core to making your app function as expected
• Be careful not to skip steps and test your workflows often

Privacy

• As you saw in the Bubble Docs when you read them above there is a section on Working with Data that is a great reference
• By default, all the data in your application is open to the public
• Perhaps some of the content needs to be publicly available, that is fine
• For example, your username on Twitter needs to be available or no one would know who is tweeting
• However, it is vital to ensure that the data that isn't supposed to be available to everyone is properly protected
• Twitter doesn't want to share the user's password publicly
• To keep user's data safe it is important to protect it by setting up privacy rules
• Make sure to define the rules and permissions for any user data that may be sensitive
• Things like emails, passwords, credit cards, etc are examples of data that you don't want everyone to have access to
• Again, by default user data is not secure - you need to define the rules!

Test, Debug, and Iterate

• As you saw in the Bubble Docs when you read them above there is a section on Testing an Application that is a great reference
• By definition directly from the Bubble Docs:
• "Testing is simply trying out the different steps of your application
• Debugging means observing an unexpected behavior, understanding the root cause, and solving it
• While each case is by definition different, there are a few principles that can guide you in both processes"
• It is important to test out every path of each workflow before pushing it live
• As you test each workflow take notes when you find something out of the normal so that you can investigate and debug
• Bubble has a debugger built-in that allows you to look into each workflow step by step and understand where the data is going astray from your expectations
• Learning how to use the debugger and implementing breakpoints can help you more efficiently solve "problems" within your application
• This will be quite helpful especially as your MVP becomes more robust
• Here is a tutorial from the docs
• The debugger allows you to test what is currently happening in the app
• The server logs allow you to glance back through the past to see what was going on previously and discover how long the problem has been happening
• Diving deeper into previous results can help you better understand what is currently going on and when the problem started
• It is recommended that you do your testing, debugging, and iterating in development mode in Bubble
• Then once you are confident that it is working properly you can push it live

MVP Flywheel

• You will spend the rest of this course (and beyond) working on this MVP flywheel process
• Update the database, adjust the pages, develop new workflows, test the new features, collect user feedback, iterate...
• Even as we shift focus from building this initial MVP in the coming weeks it is important to recognize that you are never done collecting feedback and iterating on your product
• It is the expectation that this MVP flywheel never really stops
• You will always be building, always listening to users, and improving your product
• We will refer back to this section for the next few weeks, and there are activities associated with each week
• Remember the weekly activities are meant as a guide, by all means, work ahead when possible - you do not need to wait until week 5 to jump into workflows if you are ready to build them right now!

Additional Resources

• Bubble Docs
• Bubble Webinar - Talking to the Database
• How I Founded Two No-Code Startups
• How Can Your Bubble App Scale?
• How to Build a Successful Minimum Viable Product (MVP) in 3 Steps

Activity

• Note: we will spend several weeks with this, building an MVP, section. There are activities suggested for each week, but this pace is simply a suggestion.