Today, I tried Xano, a backend-as-a-service platform enabling users to build apps without writing code. With it, you can create a REST API powered by a fully-fledged database and connect it to other services like Airtable, Webflow, or your own frontend or APIs.
I tried Xano because I want to build a habit of discovering and testing new products. As a CTO, you have to keep track of what’s going on in the industry and keep aware of various tools that are gaining popularity. There are a lot of new products and services, and if you actively try them out, your technology decisions will be much better informed.
Exploring these new tools firsthand is essential. For example, Xano claims to let you build apps without code through its intuitive drag-and-drop interface. After testing it out today, I found the interface extremely easy to use. I could quickly build and connect my API to a database (which is built into Xano but can be synced with an external instance) and a Webflow frontend. However, there are still some limitations around customization that more complex apps would require coding for. Hands-on experience revealed pros and cons I wouldn’t have understood otherwise.
I want to continue this practice of identifying and quickly testing new products. Even short 15–30 minute trials can provide valuable insights compared to just reading about the tools. Staying on top of emerging solutions will allow me to make better recommendations for our development team. It helps ensure we choose technologies that best fit our needs rather than just going with the latest hype. While some experimentation takes time, it ultimately allows me to be a more informed CTO.
So, back to Xano. I think it’s great — with just a few clicks, you can have a working, deployed API that can get input from the user or a 3rd-party service, process it, write it to the database, and return a request. Is it revolutionary? Well, it depends.
For example, we have AWS lambdas and Google Cloud functions. They are simple enough, but you need to know how to code a function and study the documentation to figure out how to deploy it and add a database. Compared to Xano, they require plenty of technical knowledge. With Xano, on the other hand, you don’t need any coding skills.
The critical advantage of Xano is that it lowers the barriers to building APIs and connecting services. For someone without a technical background, Xano provides an easy way to create an API from scratch and have it hosted in the cloud. The visual interface lets you set up workflows and integrations without touching code. Of course, Xano may provide a much lower control or customization level than coding your API functions. However, it opens up API creation to a much broader audience.
In that sense, Xano does bring something new to the table. It puts the power of APIs and cloud services into non-developers’ hands. For example, a digital marketing agency could use Xano to quickly build custom APIs for clients without engineering resources. An entrepreneur could prototype and test API ideas without learning to code. While experienced developers will stick to their existing workflows, Xano unlocks API capabilities for a whole new segment of users.
The no-code approach of Xano also lends itself well to building integrations between SaaS apps and services. Connecting platforms like Salesforce, Twilio, and Slack could be done without traditional development skills. Of course, some pre-built integrations between common apps exist, but Xano allows you to create custom logic and workflows.
Overall, the ease and speed of Xano have the potential to open up API creation and automation to a wider range of users. It may not be a revolution for developers, but for non-technical people, it enables some powerful capabilities that were previously out of reach. And there’s definitely something exciting about making APIs more accessible. Xano’s simplified API and app development approach is appealing, even if technical experts like me may want more control.
Xano Use Cases
What was especially interesting is that background tasks that can be triggered by events or run on a schedule are also super easy to add with Xano. With just a few clicks, you can add them quickly and intuitively. In contrast, setting this up in AWS or Google Cloud would take some time.
Now, I don’t think you can do anything overly complex in no-code tools in general. It would be best to have unit tests, proper version control, etc. But quickly hacking together an API to prototype a feature? That’s a breeze with no-code.
Another excellent use for no-code tools like Xano is onboarding and training engineers. When building a complex system, at some point, it becomes challenging to onboard even mid-level engineers because of the overall system complexity. Their code also needs thorough reviewing since they get full access to the app’s code, and there are often no limits to changes in just the subsystem they’re working with — everything is interconnected. We have safeguards, but still.
Xano solves this issue because you can ask a junior engineer to quickly prototype a feature in a separate environment. They can create fully working backends much faster than the traditional way without relying on DevOps or senior developers. Of course, this doesn’t work for mission-critical tasks or production-ready features, but you often need just a quick and dirty solution initially.
This is especially true for internal tools. More often than not, you need a quick way to test out a process. Pairing Xano with something like Retool, you can quickly build powerful apps. Retool provides an interface, while Xano offers a complete backend to work with the data.
Is It a Good Fit for Our Team?
A while ago, we tried using Make to create automation. The idea was that we would build no-code scenarios for managers to maintain independently without involving engineers. It never panned out. Engineers first had to painfully create those scenarios because it was much more complicated than just writing code (anyone who has tried working with arrays in Make knows what I mean). Then, they had to support and painfully update those scenarios, as it was still too complex for managers to grasp.
Our team using Xano will likely face similar challenges. Xano may work for simple, one-off apps, but experienced engineers can implement the same functionality more efficiently using a set of cloud functions, for example. If you lack coding skills, you can build an app in Xano initially. However, as complexity increases, you will likely need to bring engineers on board anyway. Anything beyond a solo project will require transitioning off of Xano.
My second concern is that tools like Xano make establishing a manageable development process difficult. How do you know when someone makes changes? How do you review those changes? How do you set up multiple environments for testing? How do you generate dummy data for those test environments? How do you automate testing? The list of challenges is extensive for any no-code platform.
In summary, while visual no-code tools like Make and Xano seem promising for non-technical users at first glance, they often create more problems than they solve for real-world production applications. Their limitations make it hard to scale development teams and processes around them. Having engineers implement solutions programmatically is often more practical for all but the simplest use cases or prototypes.
The area of nocode keeps evolving. We’ll see a lot of development in this space. Tools like Xano are amazing for entrepreneurs and intrapreneurs who want to learn more about building apps and do things themselves. For example, Xano has a lot of educational materials on their website and gives a lot of guidance when you try to create something on their platform. But for engineering teams, the value is questionable.
I will keep using no-code tools for a few things, and my perspective may change after gaining more hands-on experience. Nocode definitely helps focus on just the business logic, at least initially. It allows you to skip much of the boilerplate work required in traditional coding.
Originally published on Medium.com