This article is written by Wasi Mesbahuddin, Strategy & Operations Sprint alum of The Commons.
There may be many times throughout the year when you’ll feel superbly inspired to challenge yourself, to make a difference, or to build something incredible. If that spark happens to bring out the entrepreneur in you and you’re excited about building a digital product/experience, you might run into a very common roadblock – you don’t know how to build software products!
You can hire a developer on Fiverr, or start a company and then hire full time coders, or get someone to do it for free - but that’s hard, time consuming and likely expensive. However, if there’s anything that the tech industry teaches us, it’s the importance of building an MVP - a minimum viable product - that proves to you that the idea can work. An MVP can serve so many purposes. It can give you the momentum/energy you need to explore the idea full force. It can give you the business case and results needed to pitch the idea to business competitions and get funding. It can be a cool project to showcase in your job hunt - how great would it be to be able to interview for product roles and be able to show something you built?
That’s where NoCode comes in. NoCode or Low Code, is a movement that’s matured over the past decade - it’s an ecosystem of tools along with a community of contributors and builders who make it possible to build web apps and software with minimal code or no code at all. It’s perfect for projects that don’t require the complexity or scale of powerful software products - think how tablets or phones address computing needs that you don’t need a full computer for. Simple things like quick photo edits, consuming news/social media, or signing documents / simple word processing - iPads help you do that without getting into more complex desktop applications. NoCode works in a similar way - using drag and drop tools, it simplifies web applications into easy-to-use tools that help design these projects way easier and faster than traditional software development.
In my case, ten months into my MBA, a couple friends and I built a web application entirely on Webflow, a NoCode platform, that made volunteering and tutoring easier - we built a centralized portal where we could schedule, track and conduct tutoring sessions for struggling students. The screenshot below shows a preview of how the designer on Webflow looks for the Togle web app that I was able to build using drag-and-drop website components.
As someone with that spark that I was talking about, a NoCode tool might be a super fast and efficient way for you to build out your idea, and test it out before jumping in full force and pursuing it full time, if at all. I wanted to talk about how my friends and I did it for my own idea - and share a framework that can be used to build and pursue a wide variety of ideas - using a NoCode development system.
A Step-By-Step Guide to Building a NoCode App
Okay so you’ve come up with the big idea, and you’re excited about getting started. But before you start, map out the specific problem the product is solving, the different types of users of your product, and an idea about what the minimum set of features/functionalities that the product must be able to offer to each of those users. A sample product specification document could look something like this, for instance, which shows the document for the popular website for new and interesting products, Product Hunt.
After that, it is important that you get used to a NoCode tool. I recommend looking at a 30 min Webflow basics tutorial like this guide to become familiar with the main interface and the database features.
Another important thing to guarantee success is to pay close attention to your favorite sites, digital tools and experiences. Look for layouts and features they have in common. This will help you design your own app better.
Building it Out
Alright! Time to start building your dream app. Here’s a roadmap of how the build process can play out:
1) Decide on two layers of functionalities: (A) the MVP Layer - consists of the core features you need to build to test the product with users; and (B) the Sneak Peak Layer - the new/changed features that are a part of your version 2.0, once you’ve built the MVP
2) Build out the Data Architecture
3) Build in Webflow
4) Test it out!
The MVP Layer
The MVP layer is the basic features and core attributes of your app such as types of users, core basic functionalities and basic user journeys.
We decided that our core basic functionality would be for: (A) Tutors and Students to view upcoming classes; (B) Tutors and Students to change/edit their schedule; and (C) Administrators to be able to assign and modify assignments
The Sneak Peak Layer
I recommend planning out a quick Version 2.0 of your product so you can visualize how you’ll add on to your core features in the future.
Our Version 2.0 would automate the assignment and scheduling of the sessions, and Version 1.0 (MVP) would involve the administrators providing the initial assignments, but on the platform and not on Google Sheets. We would also incorporate a way to track comments and feedback on each session, which could be viewed on the dashboard later.
Build out the data architecture
An app’s data architecture is the foundation of the entire application. It is important to get this almost 90% right. The better designed this portion is, the faster your development process will be. This tutorial on basic database schema design (the way data is designed to be stored in a database so that it can be used meaningfully and provide desired insights and information) is a great place to get started about thinking of how your idea would need to design its databases.
I’ll explain the process by using the way we built out Togle, the volunteering app I built with my MBA classmates.
The first step is to figure out the users of the app. We identified 3 players - the tutors, the students, and administrators (the Togle team). We built 3 tables for listing out Tutors, Students, and Admin, with details such as their names and contact information, and unique IDs for them.
All this is really easy to do in Webflow’s Content Management System (CMS). You can check out some tutorials about how to play around with the CMS here.
Define the way the users will be able to interact on the application
The purpose of the web application is to enable each user of the application to achieve a set of desired outcomes, be it viewing/searching for information, or creating new information from scratch. These outcomes can be described in terms of interactions where the user performs a task such as clicking a button or providing some input, and the application processes these inputs to perform another task. Togle’s basic interactions provide a good example.
These are the basic ways users will interact on Togle:
- Tutors are Matched to certain Students
- Tutors and Students participate in Sessions
We created 2 tables to reflect each of these interactions.The first table stored tutor-student assignments, and the second stored data about each scheduled tutoring Session.
It is also important to map out each user’s overall journey, and every kind of interaction and functionality that the user should be able to do at each step.
After mapping the journeys conceptually, I suggest sketching out these journeys conceptually using very simple high-level visual mock-ups (also known as a wireframes) to describe each of these interactions - it can be a super low fidelity model of the user journeys.
Describe Each Functionality Using The Tables
After the user journey is mapped out, the next step is to describe each interaction using the tables, and write out each interaction in terms of: (a) input data fields required; (b) what process/logic must be applied to those inputs; and (c) output from the interaction.
These interaction designs will help guide the way you build out the features inside Webflow, and clearly define the data you’ll need to pull to achieve the desired effects.
Start Building In Webflow
Congrats! You’ve now created the foundation needed to bring the wireframes to life, and design the data flow in a way that will achieve your desired functionalities.
The Webflow tutorials earlier should help you build the initial layout of the screens of interest. Prioritize building simpler, basic screens first, and then add on the more complex interactions. Building momentum is important here, and it is incredibly satisfying when the smaller pieces come together to build the entire project.
The following screenshots show the final screens, and how the data architecture above is used to create the desired interactions:
As you build and learn, you’ll get faster. You’ll figure out your velocity, and understand which features you can actually build in the short term. Don’t be shy to use online forums to understand how to plug different tools and integrations into Webflow, depending on your needs. We ended up using MailChimp for coordinating signups, and MemberStack to provide the membership features for each User type. These plugins will depend entirely on your application and its needs, but there’s plenty of content online to help you set the features up.
Keep testing it to make sure it doesn’t break
It is important to keep testing your work - Webflow allows you to publish quickly and test out the functionalities. Make sure you’re viewing the app on different devices and different window sizes. It is important to create a responsive interface and small changes can affect how the front end behaves and rearranges your objects.
Prepare for Launch
Once you’ve developed a reasonable momentum with your application (that is, the basic functionalities are in place and a user could go through the basic flows of operation), and you’re also reasonably good with Webflow (you will be, trust me) you can begin to plan to launch it to a small audience, so that they can start using your app and give feedback. You can make this part fun – write a small post on your socials / post an Instagram story – you want your audience to be excited about it!
Congrats, you’ve launched your product! You should be proud of yourself - you’ve grown and learned so much, and you’ve brought your vision to life. Take some time to see how it responds with to public users. Communicate early and often with your users to get continuous feedback and keep the hype around it alive by posting regularly on whatever marketing channel you have decided to use.
As the product grows older, you will need to think about the next steps. You can slowly build out Version 2.0 - and you can also think longer term about how to scale the application. The Webflow and the NoCode stack certainly has its limitations - adding complex functionalities and growing at scale tends to get more difficult to do compared to building it out from scratch.
Your plans with the project will dictate when to stop building in Webflow, what kind of features to implement, and what the long-term future of the product will be.
In later stages, you can apply stronger product management principles to the product, keep the users center and foremost in your decisions and design, and iteratively apply what you’re learning into the application.
We’re building out Version 2.0 for Togle, and the founding team has gotten so much better at working in NoCode. We have a much clearer idea of what we can and can’t do. We’re excited for where Togle goes and constantly thinking about ways to make it relevant, useful and how it can scale.
I hope this guide was useful, and you realize, like we did, how much easier it is to bring an idea to life, and how so much of what you might want can be possible using NoCode.
Feel free to get in touch with me via LinkedIn if you have any specific questions, and I’d love to share insights about planning out your project, based on whatever I’ve learned in the process.
If you're interested in joining one of the best communities of business generalists in tech - apply to join The Commons here.