3 Things to Consider When Deciding Between Low-Code and Custom Development

Intro 

Today, there are more options than ever before for businesses to build apps or processes to make their business better. The technology landscape has changed dramatically in the last fifteen years, the internet is more accessible, and cloud technology is more widely used than before. 

Modern platforms and operating systems are more capable and better user experiences are being delivered through the web regularly. And now, with no-code/low-code options we have real alternatives that change how we think about building apps for our business. 

If you are considering a low code solution, the three most important things to consider are: 

1. What are you building?

Low-code is not the solution to all problems. Custom software can be built with a variety of frameworks and tools, targeting one or many platforms. There are many options that provide great value when building an app. If you’re considering low-code, first consider what it is that you’re building.

If you have requirements for high performance, high throughput, low latency where a successful transaction relies on split second guaranteed execution, low-code is probably not a good choice. For example, if you’re trying to build applications to execute stock purchases, or facilitate online bidding in an auction, low-code is probably not the best choice. In these cases, the timing and completion of the transaction is key to a successful outcome.

Another scenario where low-code might not be the best choice is if you have a requirement for advanced or highly custom user experience.  

With all the benefits we get from low-code platforms, there are going to be tradeoffs. In order to make it easy for users to create processes and apps without writing code, we have to work within a low-code framework. Low-code frameworks are designed to make it easy for users to build apps using common pre-built user controls. They are WYSIWYG in nature and support simple drag and drop authoring. In order to make this effective, we are giving up control of some things like how we connect to data, or the ability to include advanced controls or a template from a design first process.

2. How do I measure and plan for total cost of ownership?

When considering the cost of a low-code solution there are several things to consider including licensing, initial build, care and feeding, and the cost of making changes.  

In terms of licensing you might ask some questions like: How many people will use my application? Where does the data live? These questions are key.

Where does the data live?

If your data is in SQL Server, and you want to use Power Apps, you’ll probably need a paid Power Apps license for each user. If you only have 5 users, that won't be a huge cost, but if you have 10,000 users, that’s a different story. If your data lives in SQL Server, you’re already paying for a SQL license, so now you might want to weigh the cost of Power Apps licenses against the cost to have someone build a custom .NET application. You might also attack this problem by planning a migration from SQL Server to Dataverse to eliminate the SQL Server license cost. 

What is the cost to build?

The next area to think of in terms of cost is how much you'll spend in building the solution. If you’re thinking of a custom development project, you’re probably using a highly experienced professional development team. They’re also probably pretty expensive. If low-code is an option for you, then you might also look to an outside firm to help you build, but it will be less expensive because the application can be built faster. Or maybe you have some talented folks on your team who can take on the project. This is one of the biggest benefits of a low-code solution. The barrier to entry is much lower. Less time, skill and experience are required to be effective and produce a result.

What's the upkeep?

For the sake of brevity, I’m going to combine the last two areas to consider. Care and feeding and the cost of change are similar in a lot of ways. Both beg the questions: How much does it cost to run this thing? Who will be responsible for fixing bugs? What do we do when technology changes and an update is needed? Ultimately, you need to decide if you’re going to own the answers to these questions or if you’re going to rely on a third party to manage it for you.  

No matter which type of solution, custom or low-code, if you used your own talent to build, then you very likely can manage all of this in house. If so, build it into your long-term plan. If you paid someone else to build it, then you’re likely looking to them to manage this for you. If so, they’ll probably let you know what to plan for in the long-term. 

That said, another great benefit of a low-code option is that much of this is managed at the platform level by the vendor. Microsoft is continually rolling out updates and fixes for the Power Platform. This is a big help in terms of keeping your solutions up to date. For example, when security standards change for data connections, updates to your connectors are handled for you. If you’re using Dataverse or SharePoint to store your data, you never need to worry about the next database or server upgrade. Historically, these scenarios turn into significant projects every couple years for custom apps. 

3. How fast do I need this?

The last question to ask is how fast do you need this thing? Is it critical to have a solution in place in the next week? Or does this fit nicely into your technology strategy in the next fiscal year? 

Often, we are faced with critical challenges that need to be addressed as soon as possible. How many fires have you put out this week? When this happens you probably call an all hands on deck meeting and the team pitches in to get it done no matter what it takes. Someone puts a spreadsheet together to track the process. A few people volunteer to triage the requests from the customer. You come up for air 3 months later and you have the most amazing Excel spreadsheet in the history of Excel spreadsheets. You wouldn’t dream of solving this challenge with a custom application. It’s not feasible. There’s no way to get it done in time. Now that the situation has stabilized, you’re ready to find a couple vendors to give you quotes on a new solution. 

The next time you’re faced with something like this, consider low-code. If it’s really a fire drill, you probably still have the all hands meeting, someone builds a spreadsheet quick, and you create a short term mitigation strategy. But, you pair someone with the person building the spreadsheet to build a Canvas App to track the same data, automate the key pieces of the process with Power Automate, and share it with the team at the end of the first week. 

Challenges & Headwinds

If you’re going to embark on the No-Code/Low-Code journey for your business, there are some challenges you will face. If you want to be good at it, you need to also ask, how might we apply application development process and methodology to No-Code/Low-Code solutions? 

• Can we be agile? What tools and methods can be use to increase effectiveness, collaborate with stakeholders and reflect on our progress? 
• How can we collaborate on No-Code/Low-Code solutions? How do we efficiently and effectively utilize multiple resources to build a solution? What features are built into our low code platform to facilitate collaborative edits? 
• Can we still manage our application lifecycle? The default tendency when building a low-code app is to build, publish, and share. But are we paying enough attention to the lifecycle of our application? Are we taking the right steps to ensure users are not impacted when we roll out changes? 
• How do we track and manage changes? Like anything you create in a business, there is inherent value in the applications that we build. Are we keeping track of this investment? Are we creating the ability to reconcile a change and its impact on the users?

We'll save our thoughts on these questions for another day, but hopefully it gets your thoughts rolling.

Conclusion

To sum things up, there is a commonly held belief that you can’t have Fast and Cheap and Good. I think I’ve seen this most often posted as a sign at a restaurant, but I think this applies to anything in life. And, I think it holds true for business apps as well.

However, I’d like to throw this out there. Maybe, just maybe, a low-code solution can give you Fast, Cheap, and Good Enough.