Discover more from Data Operations
What do you need to know to build a good "no-code" application?
It's not hard to start building a no-code app. But it can be hard to give it the kind of polish you expect from a production app. Read: "Everything Starts Out Looking Like a Toy" #157
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? is a post that grew into Data & Ops, a team to help you with product, data, and operations.
This week’s toy: A website to experience television from the 1990s. One under-appreciated feature of old-school television? You didn’t have as many choices for the content you watched, and part of the joy of channel-flipping was the search for the unexpected. Edition 157 of this newsletter is here - it’s August 7, 2023.
Data Operations (“Everything Starts Out Looking Like a Toy”) is a reader-supported publication. Please consider subscribing.
The Big Idea
A short long-form essay about data things
⚙️ What do you need to know to build a good "no-code" application?
There’s a lot of promise in a no-code environment.
No-code development lets you abstract the building blocks of an application or its services into a series of steps or flows that don’t require technical ability to complete. When this works, someone who doesn’t have deep coding experience can build an application without needing an app developer.
The basics of no-code application design are very similar to any application design:
A basic application flow that describes screens and a way to create a link that takes you to a different screen
Certain base services like authentication are table stakes (whether it’s a user name/password or another auth mechanism, you need to login)
A way to hold data in memory and also to take data input from the user; you might also need to push that data into long-term storage like a database
If your app handles different collections of data (like “people” and “companies”, store different attributes of data with a unique key (ID) to handle simple CRUD (create, read, update, and delete) options
It’s important to be able to edit and deploy your app and document how it works
Why build a no-code app? There are a few key benefits primarily due to the short time-to-market and lack of wait for a developer.
Advantages of no-code development
If you know what you want to build, a no-code environment makes a great choice to balance the complexity of app development with time to market.
Here are some typical advantages of no-code app development:
Speed - no-code apps are really fast to build. In a lot of cases, you might be able to find a prototype for what you want to do that’s already built (see the template libraries at Retool and Airtable and Bubble), and the end goal at that point is to customize the prototype rather than build something from scratch.
Accessibility - you don’t need a web developer to build one of these apps - you need someone who understands the logic of the flows you’re trying to build, the data that needs to be stored and retrieved, and the primary key or identifier of each object.
Infrastructure - this is the best part about no-code apps in my opinion. You don’t have to worry about how they scale or maintain a level of service - you just send them information and most of the time, for most apps, they do just fine.
Components - no-code apps are created with building blocks like Lists, Forms, Buttons, and more. In a lot of ways, this mirrors the modern method of building components with React.
No-code templates help you to avoid the blank page situation, but they’re not always easy to customize. The flexibility built into these tools makes it possible to find solutions, but they may not behave the way you think they will.
Some no-code drawbacks
One thing you’ll find when building a no-code application is that they are not perfect. They work really well for a “vanilla” situation and are less good at handling exceptions out of the box unless you build specific exception flows.
Think like a developer - no-code apps are running code underneath the runtime they are presenting to you. That means that if you want to do something not specifically included, you can use simplified logic to get it done. It could be as simple as using a true/false field to drive exception behavior.
Customization may be harder than you think - a benefit of using a component-driven approach is that the options are easy to find. The disadvantages of this approach are that if the way you want the component to behave is different than an available option, it may not be possible to customize it.
Scale/performance - this is less of a problem than it used to be, but if you have complicated logic, very fast response time or a large number of users, the standard tier of performance might not be enough.
Documentation - “change that form” could mean lots of things unless you have a diagram or other documentation that tells you which form you’re trying to update. Good luck updating your customer journey when it depends upon forms built in a completely different system.
Versioning and deployment - no code tools don’t always have sophisticated versioning. I’m not talking about “undo” to fix problems - but instead, the ability to create branches, deploy to production, support multiple developers, and roll back code when necessary. Bubble recently released a feature that looks a lot more like using Github. It’s not CI/CD, but it’s getting closer.
Ideas for improving no-code development
Here are some simple ideas to improve no-code development. Think of each of these features as code “glue”, meaning they add the ability to put complex logic into a no-code system when it’s needed, without making the whole thing complex.
A low-code layer - sometimes, you need a code snippet. Whether it’s a library that helps you calculate date differences, a function that only works in your environment, or some edge case that no one would build except for your team, a low-code layer really helps.
Object schema - sometimes called a model, having a pre-set container to build objects and attributes gives you huge flexibility when building an application. If you’ve ever worked in Salesforce or Hubspot, having a custom object seems obvious.
Auto-generated documentation - tools like Marp, Mermaid, and more have the ability to generate templated documentation based on a structured format. What if you could build this automatically every time a change happens?
API integration and hooks - now that you have arbitrary code to execute and a way to store data flexibly in objects, having an external API to call features in your no-code app is also a really handy tool.
Warehouse connectors - local storage for your no-code app is great. The ability to push and pull data from your warehouse (or database) is even better. You probably don’t want to store all of your operational data in Snowflake for a consumer app, but for an internal app it could totally work.
Building a good no-code application is … a lot like building an application
I’m not sure what the ratio of planning to coding looks like in a typical application. It would be nice to think that “no-code” meant that you didn’t have to do any organization and planning, either. But the most important work you’ll be doing when you build a no-code app is planning how the pieces fit together, sharing that plan with your team, and dealing with exceptions when your expectations are not met.
That sounds … a lot like building an application. Since there is a lot of well-trodden ground around the engineering practices for building applications, I’d suggest: get really good at understanding the inputs, the desired outputs, and the flows that move information around in your application.
Whether you end up describing these tasks to a software engineer or building them in a no-code system, you’ll be ahead of the game.
What’s the takeaway? Building a no-code application should be like … building an application. That means thinking about improvements in a product backlog or Kanban, following at least a semblance of a testing and deployment process, and documenting what it does so that someone has a clue about what kind of application you built.
Links for Reading and Sharing
These are links that caught my 👀
1/ What’s a data product? - This is a concise description of a data product. Data as a product is a bit hard to describe because it includes the schema of the data, the delivery schedule, and the actual data itself. (It might also include a self-governing set of thresholds to let you know when the data product is low quality). Data products are more than just delivery - they are the process that includes documenting, ingesting, instrumenting, remediating, transforming, and delivering data.
2/ Using color selectively in dataviz - When you limit the color palette for data visualization, the use of color really stands out.
You’re used to seeing this tactic in weather reports like the one below, and it’s an important tactic to take to other kinds of data visualization.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon