No-Code for Businesses

Table of Contents:

‍

Common No-Code Use Cases for Businesses

While startups were the early adopters of the latest no-code technologies, existing businesses are quickly catching up and using these technologies to get ahead of their competitors. Here are just a few examples of the most common use cases we see businesses use no-code for:

Process automation

Every organization has its processes, and many processes can be made easier and more organized with custom software. Project management, approvals, and general communication protocols can be built into simple tools using no-code, sometimes in just a few hours.

Customer portals

A really common use case we see is when an organization has a bunch of data stored somewhere (e.g. Salesforce, internal databases, etc.) and they need to expose that data to their customers. In those cases you can use no-code tools to build a custom portal which plugs into the data source to retrieve and update data as needed.

Middleware integration

Another common enterprise use case is tying two disparate systems together. Sometimes while building a middle layer that transforms the data in some way before sending it from one system to another. There are many no-code tools that allow you to build integrations like this, some better suited for very simple integrations, and some for much more complex ones.

More scalable spreadsheet

A common theme that we see in business use cases is that companies that depended on Excel spreadsheets to manage a process are migrating to no-code applications. That’s because spreadsheets can be incredibly powerful, but they still lack features that certain processes need in order to be scalable. These are features like user authentication, version control, external integrations to data sources, and more.

How No-Code is Changing the Build vs. Buy Dilemma for Businesses

A common decision that businesses face is whether to purchase an existing, one-size-fits-all solution from a vendor, or build an expensive custom software solution in-house. No-code is changing the factors that go into that decision by providing a third option.

While SaaS solutions offer many advantages – ease of use, centrally managed upgrades, and (sometimes) lower pricing – there are big benefits to building your own software. The most notable benefit is custom functionality. SaaS solutions are optimized to meet the needs of the larger audience and may not fully meet your company’s needs, while custom software is designed to address specific technical challenges and business use cases.

However, it’s widely understood that building custom software is expensive and often disruptive. Fortunately, the no-code revolution is changing the dynamics of this debate. It has dramatically lowered the cost to build custom products, which has tipped the scales toward "build" for a growing number of organizations and use cases.

So how does a company think about whether to build or buy? Here are 4 key factors to evaluate:

1. Financial: This is the single most important and nuanced consideration. Will your total cost of ownership be lower with a software build vs. buy? To answer this question, we recommend you evaluate the following dimensions around cost:

+ Upfront build costs: what will it take to build a tool from scratch – whether that be through traditional programming or no-code? Is it possible to customize your existing SaaS tool to fit your needs, and if so, how much will that cost?

+ Ongoing software costs: how much do you expect to pay in licensing fees (given how much you plan to grow)? How does that compare to ongoing maintenance costs from owning your solution? Clearly if you expect many more users, and/or if you plan to hit SaaS limits that bump you to a higher per-user tier, your ongoing costs can get high. With an owned solution, you’re typically paying a much lower hosting fee. No-code tools handle basic technical maintenance for you just like a SaaS tool, but you may need developer support for ongoing feature tweaks and fixes.

+ Ongoing business costs: often the build vs. buy options result in slightly different software solutions, which means different costs/revenue for your business. For example, if a non-custom SaaS tool requires a full-time, in-house staff member to manually execute processes, then their cost is attributed to your cost of owning the SaaS tool. Or if your SaaS-based client portal is causing poor experiences and churn that you could address from a custom solution, that loss of revenue should also factor into your cost of ownership.

+ Migration costs/timing: migrating your existing data and operations from one tool to another can have a wide range of costs. Some functions are easily portable (just flip the switch), whereas others require extensive data migration, retraining of staff, piloting (i.e, running both tools simultaneously), etc.

+ Selling your software: in some cases, businesses want to turn their cost into revenue by selling their software to other businesses as a SaaS tool. If you have this in mind, you can imagine offsetting some of the other costs associated with the build option.

2. The value of owning your software: for some organizations, developing and owning a software that solves their unique business problems is a strategic move. It empowers them to unlock new opportunities to compete – in ways where commercial off-the-shelf SaaS products will always lag with its one-size-fits-all functionality.

For example, custom software can allow you to offer a better client experience (and market against that), be more nimble in an industry that evolves quickly, or have the option to swim against the current (which SaaS tools always follow).

3. Business risk: there is risk to both build and buy. With the SaaS buy, the risk is that you’ll suddenly hit a limitation that you need to overcome quickly and can’t. With custom build, the risk is that you’ll build the software in a poor way and it won’t deliver on its original promise. The key to the latter is working with the right software development partner and taking the right approach to the build.

4. Focus: engaging in a software build can be a big effort and very distracting from other parts of the business. You should only take that on if you have the right people and a clear enough vision for what you want.

What No-Code Means for Business Innovation

Most organizations are used to software development being a centralized function. It makes sense – if software projects end up costing millions of dollars, they should be carefully controlled and executed. After all, organizations can’t afford to spin up lots of software projects and have them fail. But there are downsides to this approach. First of all, it’s slow and cumbersome, resulting in multi-year projects and long queues of products that never get built. And secondly, it doesn’t allow for tech innovation at the lower levels of an organization.

No-code changes the equation for businesses. When software development becomes 10x+ easier/faster/cheaper, then organizations all of a sudden can try a decentralized approach to developing lots of projects and be comfortable with some of them failing, resulting in greater overall innovation.

But this approach can be messy if not done properly, so we recommend the following best practices:

Having a central approach to company data, with internal APIs and different levels of permissions that need to be approved. This ensures that every application getting built is using the right data and there aren’t a bunch of data silos being created.
Having a review and approval process that each application goes through after it’s built to ensure that it’s built according to best practices and in a secure way. Adding transparency to all software projects in the organization, so that there isn’t an overlap in people’s efforts and that they can collaborate when appropriate.

If done properly, no-code can enable companies to move faster, eliminate inefficiencies, and innovate on multiple fronts at once.

No-Code Careers