How to Build an App Without Code

1. Welcome to the Course: Today, you no longer need to be a programmer to build an app. With no code tools, anyone can create software faster than ever. But if you're trying to build useful functional software quickly, knowing where to start can be tricky. In this course, I'll get you started off with a simple project that covers all the fundamentals for building great business software. Whether you're entrepreneur, freelancer, or business owner looking to streamline your operations, I'll guide you step by step on the best way to approach your project. In this course, I'll cover the fundamentals of no code. How to plan and structure your app with real world business data, how to design a professional interface, how to automate workflows, trigger AI powered actions, and integrate with external tools, and finally, how to publish and share your app with your team or customers in minutes. We're not going to just cover theory in this course. You'll build the foundation of a functional business app from scratch. You'll see every step in action, from planning to publishing, so you can apply the same approach to your own projects. There's no technical skills required for this course, just a willingness to learn and get stuck in. I'll see you inside the course. 2. What is No Code App Development?: Software is everywhere from traffic systems to medical devices to your bank. When humans want to do something more effectively, we usually try to build a tool with computers to help us. But how do you make software if you haven't done it before? Well, in this video, I'm going to give you an overview of no code development, a powerful way to create new software without experience in engineering or design. Now, if you know about no code already, you can skip straight to the next video where we'll walk through a build together. All software is really just layers of instructions, each building upon the previous to create complex functional systems. At the lowest level, you have the machine level instructions, which are the raw parts that run the hardware. Today, developers typically use high level programming languages to write software. These languages provide a more human readable way to instruct the computer. So you might think that programming therefore means using code to make software. But actually, at its core, programming is just giving a computer instructions. It doesn't matter how you give those instructions. For example, imagine you have a thermostat. This comes with capabilities, but doesn't do anything if you don't program it. You have to say when it will come on and when it will go off. But of course, this is a very simple example. It's not really programming. It's just giving one instruction. You can't build new things with the controls on a thermostat. Visual development tools or no code software, give you a user interface in which you can program new software without having to deal with the intricacies of text based programming. Now, there are pros and cons to each way of building software. Traditional text based programming offers basically limitless control over what it is that you're trying to build, but it usually takes a long time to learn and even takes a long time to create small, simple applications. On the other hand, low code or no code tools abstract away a lot of the low level decisions that traditional developers have to make, speeding you up tremendously and letting you focus on what it is that you want the software to do. Now, all NOC development platforms have to make decisions when they're being designed about which parts of the development process they'll give you control over and which parts that they will handle automatically for you. Now, because of this balance between power and ease, different no code platforms approach this in fairly different ways. Some are very complex and hard to learn, but are incredibly flexible. And then at the other end of the spectrum, others are very simple, easy to learn, but only let you build certain types of functionality. And of course, there are many in between. In this course, we're going to be using Glide, a platform for building web apps that combines a spreadsheet like way of managing your back end with a visual programming interface for layout and action. 3. Defining the Problem: So before we start developing anything, we first have to decide what problem we're going to solve. Whether you're developing for a client or building something for yourself or your business, it's really essential to start by understanding why you're trying to build that solution and all of the aspects of that problem. So in this course, we're going to work with a fictional client so we can focus our efforts around specific needs. This person needs a dashboard for their inventory operations. Now, dashboards and portals are some of the most common types of apps that businesses need. Take lots of different forms, but largely speaking, a dashboard is an internal tool that displays information like financial, administrative reports, KPIs, and things like that. And a portal is an external tool for customers, clients, employees, or investors to access information or perform tasks. Now, if you're not interested in specifically building a dashboard or a portal, don't worry because we've chosen these examples specifically because they have a lot of very common functionality that you're likely going to need in the app that you're building. So there are many ways that you can go about planning your project, both in terms of what you plan and how you plan it. You could write a detailed document outlining all of the areas. You could do a scrappy whiteboard plan, or you could simply make a few notes on a piece of paper. It's totally up to you, but the following things are really important components to consider if you want a really comprehensive plan. So firstly, you need to understand the high level functionality. In other words, you need to determine roughly what it is that the users can see and do. Secondly, you need to decide the user roles. This means determining the types of users that are going to be in your project and roughly what they can do. For example, are there Admins? Are there editors or guests, things like that? The third thing is designing the data structure. This is where we establish the kind of structure and data hierarchy or the relationships between the different collections of data in your project. For example, the main tables like inventory categories, users, orders, things like that. And then any other tables like comments or statuses. Then we need to map our user experiences. So you need to detail the kind of specific user experiences and functionalities that you might want like uploading an item or editing inventory and things like that. And then you can get into the detailed planning, like outlining the workflows and actions or the navigation. You could do this through wire framing, specifications, or just simple bullet points. So to make this all a little bit more concrete, let's look at how we would do this with our fictional client. So our fictional client is Sarah Thompson, who works for Ascent EV. Sarah oversees the supply chain operations, and she sent us this brief. We need a better way to manage our inventory and audits. We're currently using Google Sheets, and our field agents often have to call in or check spreadsheets on their phones, which is far from ideal. We've tried using custom software before, but our processes change so much, we've stuck with spreadsheets. We need an app that gives us live inventory tracking, alerts for low stock, and a streamlined order management process, and management also need basic dashboards with keymetrics to help us make better decisions. So, with a little bit of thinking and possibly some conversation with the client, we can draw some top level ideas about this project. Firstly, the client's needs and problems include inventory management. They're using outdated methods like Google Sheets, which is leading to overstocking or stockouts. They need to manage order fulfillment. So there's inefficiencies currently or delays due to manual tracking. There's potentially an issue around data visibility. They have a lack of live data or they want to make more informed decisions on that data. And then, of course, they have field agents. They really rely on people out in the field, and they're currently relying on, like, phone calls or updating spreadsheets, which is far from ideal. So we can then think about the key features in this app. We're going to need a dashboard, which is the kind of total sales or stock values or any other kind of KPIs that they want to see on the top level. We're going to need a page about inventory management, which is not just detailed inventory listings, but also allows them to restock and maybe get alerts if things are low. And then you're also going to need to have something about order management. So tracking orders with customers and status and any more details that they need there. So obviously, in this video, I've put these in fairly simple, clear bullet points because I've kind of thought about this before I've done the video. For you, you're going to be brainstorming and writing stuff down and then be organizing it into a set of requirements. It's really important to just initially capture everything that's important to the project. Thing that you think of and don't worry too much about putting it in a formal specification right away. So here's an example of how this might work in your process. Firstly, you might have a bunch of sticky notes like this with lots and lots of different ideas, and then you might formalize this into things like tables, screens, functionality, and things like that. Here, we're using FIG Jam, a really cool tool for whiteboarding and brainstorming. But you can use anything you like, whatever helps you think deeply about this project. And you can see here that we've decided on our four tables. So let's talk about that in the next lesson on designing data structure. 4. Data Modeling: Glide is a very data driven software design platform, but what do we mean by data driven design? Well, as we saw in the first video, software is built on many layers of technologies, right down to the ones and zeros of machine code. While all of this is technically data, when we talk about data, what we're really meaning is the data that's specific to your app, I, the information that's seen in the user interface and responds to users actions. Glide, there are three areas. At building starts with your data in the data editor. Next, you design your layout in the layout editor and map that data to components. And then finally, if needed, you can build actions and integrations on top. Now, naturally, as you're building, you're going to be moving back and forth between these stages. But before you start building, it's actually really important to get your data structure in order. So if you're coming from the world of spreadsheets, you may be used to organizing your data very freely. But glide is a little different to this. Glide works a little bit more like a database where your data needs to be neatly structured in rows and columns with every column having a header. Now, if you're building your tables from scratch in Glide, this shouldn't be a problem, but if you're sinking your data from an existing Google Sheet, then you might need to think about restructuring that data a little bit. So we want to be really smart about how we're organizing our data. We're not just going to make one huge table with 1 million columns, and we also don't want to make 1 million tables for everything that we can think of. When you first start building, you want to have just a few different tables that break out the main parts of your process. You can always add new tables later. So let's return to our plan for a second. Now, I already know how many tables this app is going to need because I've built apps before. I know it's going to need inventory items, orders, suppliers, and people. But if you're just starting out, you might have this kind of brainstorm of sticky notes about screens, functionality, actions, data, rows, properties. Oh, much, much more. And it therefore might not be clear yet what tables you need. So if you're feeling like this, it's really important to focus in the beginning on what is most essential. You can, of course, build a lot very quickly with no code, but at the beginning of this project for you, stick with around three to five tables maximum of data and no more than that. So also, as you're thinking about this, to simplify, try to think about three key questions. Number one, really, what are the main or most important objects or types of things in your app? Here, we're not talking about functionality or screens. Just think about the categories of data that go behind everything, like people, projects, orders, customers, appointments, or suppliers, things like that. Each of these things could have a dedicated table with rows of data. Two, can these items be combined into a single category or can some be properties of others? For example, an inventory item has a price, an SKU, a name, a description, stock level, and potentially many other properties. Therefore, an inventory item clearly needs its own table because it's going to have many different columns, but an instruction manual will probably just be a property of an inventory item rather than an entire separate table. Number three, does this item need its own table or can it be something that's built on top of an existing table? So for example, just because you want a screen for a specific function like adding inventory items, it doesn't mean you need a separate table. For example, the add inventory screen can use the existing inventory table rather than requiring a new table. So by asking these questions, you can hopefully distill your huge brainstorm of notes into the most essential tables, making your data structure much more clearer and manageable. Now, before you add your data, you need to start a blank project in Glide. You can actually get Glide to build a default app based on your existing data structure, but because we're learning things from scratch here, we're going to choose a blank project and head to the data editor once it's created. Now, if your data already exists somewhere else and you want to sync it with glide, you can add a new table in the data editor and pick your data source. You'll be able to see the tables appear on the left here and you'll now be able to edit your data in glide, and changes you make in glide will sync and vice versa. Alternatively, though, you can export your data from that data source and upload it and host it in glide table. Now, if you're building your app and data from scratch, after you've added the columns in your tables, you can just add a few rows of data just so that you have something to be working with. Then as users start using the app, they can start populating this data through the different screens that we build, and I'll show you how to do this in the next video. Now, we'll touch on this next, but Glide's Data Editor is incredibly powerful and adds an entirely new layer on top of your existing data. You can enhance your data with powerful computations and work directly with AI all without complex formulas or code. 5. Designing the App Interface: Now it's time to create the front facing side of the app, the user interface or the UI. This is what users will see and interact with every time they use the app, and it will be connected directly to your data, wherever that is, whether it's in glide or whether it's sinking from somewhere else. So the app that we're going to be building from scratch in this course is actually already a fully built template that you can copy for free. So if you did any wire framing or mapping of user experiences, now's the time to take out those plans and use them as you get going in the layout editor. Now, we've already got our tables. Glide automatically adds a user's table to all new apps, and we've added our other three here. Now, in my plan, I said I wanted to start with three main screens and these seven core features. But in this short course, we're just going to tackle two screens and one feature. We'll tackle the inventory screen. The order screen and then the low stock alert. The dashboard is quite a bit more involved and requires all of these features that we've got planned here and FIG Jam to be built first. But you can, of course, explore this later by looking at the template and deconstructing how it's been made. To add a screen, we click here. You can create blank screens, form screens, and pre built screens. But what we're going to do is build a screen from our data. So we're going to click our inventory table. By default, Glide builds a screen for us with one collection component on it, and that collection has this style here. We can change different styles here and alter the settings for that collection. Now each item here represents a row of information from our table. If we click into one of those items, we can see the whole row represented in visual components. Let's go back to the top level screen and open up the data panel. The data panel is like a mini data editor. And while you navigate around the layout editor, the data panel will show you all of the data that's behind anything that's currently selected. For example, if we create a new screen from a different table, like, say, the orders table, we're going to see because we've selected the orders screen, all of the order data in and if we change one of the values here in the data tab, we're going to see that reflect in the UI. So let's just delete this screen and go back to the inventory screen that we just created. Now, the first row in our table here is shown as the first item. And if we click into that item in the UI, we see the whole of that row represented in components. Each column in our table is mapped automatically to a component on the screen. No manual hooking up from us is required. And this is the basic core pattern of glides to get your head around. Collections show many rows of data, and an item or a detailed screen shows an entire row from our table. Now, if you want, you can pause the video here and just have a play around with all of this. Add loads of screens, add and delete components, change the data that they're displaying. Like, everything can be deleted and you can just start from scratch again and again. It's really important to just mess around and get comfortable here. Next, though, we're going to cover editing and deleting. Now, you probably saw in my plan this word Krud. If you don't know about it, Krud is an acronym used a lot in software development, and it means create, read, update, delete. And this is really the most common set of features that software needs, particularly business focused software. And Glide let's do this right out of the box. When a collection is added to a table, adding and editing is on by default, but you can turn them off. And, of course, you can allow people to delete, as well. And this is what is so powerful about no code without virtually any effort we have an built on top of our data that we can ship and publish to our users in just a few more clicks. Now, this screen might not be quite right for you. So Glide, of course, gives you controls to customize this starting point. So let's dive into that now. So we're looking at a top level screen here, and it's got one component on it, a collection. If we click on that collection, we can change the data that's displayed and more details about its style. But we can also add other components to this top level screen. Let's add a title component, and we'll drag it above our collection. Now, the title component has a few different styles, and I'm going to choose this cover style. By default, Glide maps this component to show some of the data from the top row of our table. That's because this screen that we're on is built on top of the inventory table, but we actually don't want this. We want to enter custom values here. Values and value types are a really important concept to understanding glide because you're continually mapping values from your data or using custom values that you enter in the layout editor. For example, here, this title component is currently showing the top row in our table, and we can see that the title, subtitle, and image properties have been mapped to the data that's in that row. We can of course swap the properties that it's displaying to other columns in that row, but we actually don't want a column value pulled from our data here. We actually want a custom value that's not mapped to our data. And for that, you just type it in to the field. We'll also remove the subtitle and choose a stock image to represent this screen. Now this component is not mapped to a row in our table, but simply represents what we want to show in this specific place. Now, we've got this repetition here of titles, so I'm going to go into the collection component and remove the title so that we just have the screen title in the title component. Right, so that's the basics of our top level screen. Our Ad screen is actually already automatically set up for us by glide, and so is the Edit screen. And and edit screens are built with entry components, allowing users to enter data when they submit those changes either as a new row on the Ad screen or edits to an existing row on the Edit screen. Now, you can of course, turn this off globally, or you can change which components people have the ability to edit. All you need to do is just remove some of the components from that screen that are mapped to the columns that you don't want people to edit. Then they'll be able to add or edit items, but only for the columns that you show in that screen. When you click into an item, you navigate to that items detail screen. Detail screens are similar to top level screens, except they always show the context of a single row. For example, if we were to reopen the data tab here, we could see that if we switch between the different items, we see just a single different row each time. Also, whatever you do to one items detail screen in a collection will apply to all the other items, detail screens in that collection. For example, if we add a notes component to this screen and map it to the notes column, we'll see when we go to the other items that all of them also get a notes component but mapped to the data in that row. So that's our inventory screen. Let's quickly set up the order screen in the same way. We'll add a new screen, pick our orders table, and switch the layout to be a Cvan. We'll dive deeper into the collection settings and group it by status. Now we can drag our orders around and change their status visually. So you already know how to customize the detail screens here, so we're going to skip that. We're going to move on to our next two features, which are fairly simple features, a pending orders list and a low stock highlight. So let's create a new custom screen for the dashboard and add a collection component to it with the table style. We'll change this data source to be the orders table. So what we want to show in this collection are really all of the order items that have an order status of pending. So what we need for this collection is a filter. To do this, we'll head to the options of that component and under the filter data section, we'll add a new filter where the order status is in progress. Now we have a collection that shows us all orders that are pending. We could, of course, improve this a bit. Let's choose a style that's more compact and add the order ID. The customer, the quantity, and the order value. And we'll change the title of the collection to be pending orders. Also, we don't want people to be able to add items here. We just want this to be a collection that displays a specific set of things. So we'll head to the Actions tab and turn off add and edit. So another way to change what appears in your UI is actually to do this first in the data editor to create essentially a computed column in the data editor that changes depending on certain criteria. This way, if the stock drops below a certain level, a new value will appear, which we can then display in the layout editor. To do this, we're going to use the if then else column, which looks at other columns to determine what values it outputs. In the first condition, we'll say if current stock is less or equal to ten, then output the value low stock. And we can put an emoji here, and then we can just leave this else part blank. Now in the layout editor, we can add this to the meta property, and now only the items with low stock will show this value. So that's a look at the layout editor. We have lots more information on all the different components in our documentation, and I really encourage you to dive deep into the finished template to understand and poke around and explore how all of this actually works. In the next video, we're going to look at how we can start to extend our app with the power of workflows and glide AI. 6. Extending the Power of Your App with Workflows, Automations, and AI: So far we've covered the data and the layout of our app, but there's one more layer to building software that's really important, and that's the actions that an app can perform, whether it's sending an email, alerting the user with a notification or even triggering a workflow in the background without the user being involved. Actually, understanding how to make your app do things is really important. And for this app, we're going to focus on features that really speed up the order processing process for our client and remove the kind of manual work for the team. So the app we've been working on already has a lot of useful functionality that's just resulted by building the UI. We have create, read, update, and delete on inventory and orders, and we have the start of a basic dashboard with our pending orders in it. Now, when you're talking about actions and workflows, it's really important to break this category down into two areas. First, there are the actions that occur when users initiate them like tapping a button or completing a step. And then there are the workflows that run silently in the background without user's interaction. For example, data might be updated every Monday at 9:00 A.M. Or something external like an email could trigger an event in your app that updates something. Let's go through a few examples now to give you a sense of what's possible. Now, you may have already set up some standalone actions as you were adding components. These are one off actions. When a user interacts with them, they do one thing. For example, here we added a button block that has the action email and call on each button. And when we click each of these, it automatically triggers an email or a call to our customer. But these are just single actions. The workflow editor lets you create multi step workflows that can do a wide variety of things. Workflows start with a trigger. After the workflow is triggered, the steps within that workflow begin to run on their own. These workflows can be triggered in a variety of ways without a user doing anything. Incoming triggers like emails and webhooks can kick off the whole process. So let's return briefly to the initial requirements that our client gave us at the beginning of this course. They mentioned that they need an app that gives them live inventory tracking, alerts for low stock, and a streamlined order management process. Now, the app is already helping them streamline their workflows a lot, but there are a few other ways that we can help them. We can allow their customers to email in their orders and make a workflow that automatically creates an order based on the contents of that email. And we can also create a workflow that allows the internal team to take photos and upload their paper form process and then extract the data from that and create a new order from it. We're going to go through the first example in this course, but we'll show you briefly at the end how you could adapt this for a paper based scenario. Let's imagine that our client allows their customers to email in using an email form, and the emails that they receive look like this. Now, in reality, this is a somewhat simplified example because customers might well, very likely would order multiple units of different parts in one email. But for the sake of this course and being the first time that you've played around with workflow, we're going to keep this simple and assume that each customer will only order for one particular part at one time. So before we create our workflow, let's head to the data editor to see where our new rows will be added. This is the orders table, which is currently being populated by our app manually when internal team members use it. We want our workflow to add the customer email, the customer name, the customer address, the part ordered, the number of units, the vehicle model, the order date, and the status. These are just internal notes for our team, so we don't need that, and the rest will automatically be populated by our app and people using it. Now, we're going to make our workflow automatically extract this data. But we also want to allow room for human oversight on this so someone can double check that the order was correctly created. We'll add a new column here called email body, and this will be where our workflow will also copy in the entire contents of the email that was received just for a human to check. Let's head to the workflow editor now and create a new workflow with an email as the trigger. Now, the workflow already starts with an Ad R action. This is the default for all new workflows because it's a very common thing that you want to do. And we can already start populating the fields here with the values that come through from the email trigger. Now, if we click on the menu here and go to trigger, we can access all of the different properties that come along with an email when it's received. For the customer email, we want it to be the from email value. For the customer, we want the from name value. For the email body column, we want plain body, and we can also add in the current date and time for the order date. And this is basically just whenever the workflow runs, the date and time that the workflow runs will be added here. So let's send a test email to our workflow to actually see what this looks. Great. Okay. So that created a new row with all of these parts extracted from the email, but we haven't been able to extract the customer address, the part quantity, et cetera, because we need AI to do this because it's a little bit more complex. So I'm going to add in a new step here before the Ad Row action because we need to process the email with AI first and extract these bits before we finally add the row. So I'll go down to the AI section here and choose generate text, and then I'll right click on this and rename it to part ordered. And this just helps me keep track of what each action is doing as I build out my workflow. Now the generate text action has two parts. There's the instructions, which is where you're telling the AI what to do, and then the input. For the input, we're going to want to pull in the whole email that's received, which is the plane body from our trigger. Then we can tell the AI what we want to output or extract from that email. But now, we're just going to say only list what part they have asked for, nothing else, for example, control module. Do not list the number of units or anything else. Prompt makes it really specific to the AI what we want it to do and prevents it from adding more content than we need. Don't be afraid to experiment with your prompts and change things. You do need to iterate sometimes to make sure that this particular step of AI outputs exactly what you want in your workflows. Right. I'm going to right click on this action and duplicate it and adapt it then for the address. And I'll do this again to extract the vehicle model. And then in our final step, I'm going to add a different kind of AI action, which is very similar, but is specific for outputting numbers only. This is the text to number AI action. And in here, I'll put the instructions. Please extract the number of units that this person has ordered. We'll then head back to the ADR action, and in the customer address field, we can now see we can select the address that's output from the address action, and we can do this with the other fields as well. Right, let's send another test email. And we can now see that our workflow, which included four different AI steps has extracted everything we need from that customer or email to populate a new row in the orders table. If we wanted, we could add a final step here, like an integration to notify someone with GML or in a slack channel. And if we wanted to adapt this workflow to help them input their paper based forms, that kind of process that I mentioned earlier, it might look something like this. In this workflow, we're using an app interaction trigger which triggers after someone uploads a form. The workflow then extracts the text from that image in the form, and then all of the following AI steps that we had earlier simply do the same, but they're extracting more specific text from the text that was extracted from the image. So we're now at the final step. In the next video, you're going to learn how to publish your app and share it with your user. 7. Publishing & Sharing Your Solution: We're now in the last steps before publishing and sharing with our users, and all of this is done in the settings area of Glide. Let's start with the most important thing, and that's the privacy and access. By default, all apps that you create are private, meaning that only you and other members of your glide team will be able to access it. If you've just signed up to Glide and you don't have any other developers in your team, this means it will only be accessible by you. If you want to add users who are not developers in your glide team, then you're going to want to switch this to the user's table. This means that anyone with a profile in the user profiles table will be able to sign into your app. Now, if you're using any kind of private data in your app, you must keep the access to your app private. However, if you're building a public facing app that's got non sensitive data in it, then you can change this to public. When you do this, you have different options about whether or not you allow your users to sign in or not. Now, there are pros and cons to enabling sign in on public apps. So check out our user profile basics video in Glide University. Next, you can tweak the name and icon of your app and the appearance. These controls here give you high level theming options for your app. I personally like the top style of navigation here, but you can also add one on the left. I also like to set my environment to be auto so that if the user's device is in dark mode, the app will also change to reflect that. So we are ready to publish. You can see here that our app has been given a default domain. Now, you can change this so long as the URL is available, but after we hit Publish, we can also add a custom domain if we have one. Now, I'm going to leave this as is and hit Publish. And that's it. Our app is now live with the privacy settings we configured, and we can visit it in our browser here by copying the link or scanning this with your phone, and we can also add it to our phone's home screen. You can also quickly invite new users here, and they'll be added to the user's table automatically. So, that's it. If you've been following along, you've hopefully now built and published your first app. And if you make changes after this, whether it's in the data editor, the layout editor or actions, these will update immediately for your users. So you can keep iterating and improving this app over time without having to worry about redeploying or publishing it. However, if you want to work on features and wait until they're ready before these changes go live to your users, you can change that setting here. And so that is it. You've come to the end of the course. Remember, you can download the fully finished template and discover more about how it was made. You'll find this also in the course resources.