Building big apps in small steps with low-code

Often the customer stories we hear from Microsoft on the success achieved through Power Platform share a common structure. They talk about citizen developers who used to struggle with legacy systems and manual processes, then discovered a way to build a working solution on their own. This then leads to more people within the organization realizing the potential of low-code tools, thus laying the foundation for wider adoption and a long-term vision for how digital transformation could be achieved in practice.

Starting small is the smartest way to build up the organization’s capabilities to solve problems via creating low-code based digital tools. Yet sometimes there isn’t adequate time available to learn and validate the Power Platform technologies in simple scenarios first. There might be external factors or internal goals that push the organization to dive head first into developing an app that will manage critical business processes and have a wide user base from day one.

If you’re faced with a “big bang” target for Power Apps without having much (or any) experience on low-code development projects, you should be cautious when navigating through this uncharted territory. First of all, it’s not feasible to try and run things exactly the same way as a traditional software development project. Second, you’ll need the ability to “think like a citizen” at times, to reap the benefits of low-code application development platforms.

Here are my five lessons learned from working in real life low-code projects with an ambitious goal:

1. Learn to know your data before building the UI.
2. Team development isn’t always the fastest way.
3. Business users can move faster than professional developers.
4. Balance your UX and technical ambitions.
5. You don’t know what you need until you build it.

Let’s discuss each of them in more detail.

1. Learn to know your data before building the UI

The simple graphical tools available to a Canvas app maker may encourage you to jump straight in to planning the future user interface: what buttons, menus, fields and lists should we have. This is often the fun part where people find they can unleash their creativity. Yet it’s only the final visible layer of an actual working business solution.

Apps are nothing without data. With Canvas apps, the true superpowers of the low-code platform are in its ability to tap into almost any existing data source via connectors. However, this isn’t always as much fun as the UI design, since your ability to be creative is restricted with what data actually is available and in which format. A nice looking information card in the app UI may need data from A) multiple systems, B) calculations or other transformations, C) brand new app specific data that doesn’t exist yet.

In the process of designing a new app, data has a strong ability of reminding you about the real world – the “as is” state. While your “to be” state can definitely be more far reaching, you won’t know how exactly to get there before you find your current position on the map. Another clear risk is that you can make wrong assumptions about data and develop features in your app that won’t make sense when connected with production data rather than demo records.

2. Team development isn’t always the fastest way

Microsoft talks about how “everyone can be a developer” when using the low-code tools of Power Platform. Great! So we have a huge crowd of potential developers in the organization now! This can surely remove bottlenecks from business app delivery, right? If we assign five people to work on our app, I guess we can have the results in before the end of the week and go live on the next one…

Being productive in Canvas app development work as a team isn’t very easy. In fact, I would argue that the Mythical Man-Month lesson from 1975 can be applied to low-code development as well: adding manpower to a late project makes it later.

“Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.”

There are specific factors in Canvas apps that will highlight the challenge of splitting work across the team. Today there isn’t any co-authoring support for multiple app makers within the Power Apps Studio. In practice you’d need to find a way to either have just a single app developer work in the Studio at any given time – or resort to copy-pasting screens across copies of the app. But then we get to the dependencies of the app features – which can take more time to resolve than to actually develop the feature.

3. Business users can move faster than professional developers

One major dilemma with low-code today is that we’re often talking about it with the “less code, less problems” mentality. Of course code in itself isn’t good or bad. Low-code is all about creating useful new abstractions that allow organizations to make better use of the underlying code (because deep down, it’s still code).

Another problem related to the terminology we use is in classifying programmers who write code as “professional developers”. This creates an assumption that the creators of low-code apps would somehow be “non-professional” – which will increasingly not be the case.

When thinking about building big apps with high business impact, there’s definitely a place for experienced software developers. Microsoft is actively working on creating a better Fusion Teams story around Power Apps. The important part about this story is to understand where the natural roles for team members with different backgrounds will in practice be.

In the current MS storyline, the software development professionals are often assigned the role of enabling connectivity to existing data sources and legacy systems. Making custom APIs available via Azure API Management (APIM). Building the necessary Azure Functions to simplify working with the data. These are a logical fit for persons with experience on the code-first developer story.

When it comes to the more visible side of the application, the client side features, too much code-first experience can be a disadvantage. Power Apps have fairly little to do with how custom web apps are developed, instead they are intentionally very close to how PowerPoint and Excel operate. This introduces both great advantages & disadvantages into the workflow of the app maker. If you’re a person who normally “ships” documents instead of code, you’re on the winning side here. If you’re someone who spends more time in VS Code than Office – this may not be your ideal working environment.

The reason why tech savvy business users with little or no coding background can be better in quickly creating rough yet working versions of Power Apps is this: they don’t worry about what they don’t know. In a constrained environment that revolves around GUI based options and Excel style formulas, these users get a sandbox that’s just the right size for them to unleash their ideas and turn them into reality. They can grow new skills and deliver results that weren’t within their reach earlier.

For someone who’s got experience in doing things “the right way” with custom code development tools and practices, the story is different. Yes, a growing number of developers may be starting to see how low-code platforms can reduce the effort needed in delivering the end results. However, this transition must be allowed to happen on their terms. You shouldn’t onboard seasoned programmers into this world via the same path as the Office power users. Trying to force the code-first developers into using graphical tools that take away their possibility leverage their knowledge and programming skills isn’t the right approach.

4. Balance your UX and technical ambitions

The target with low-code development shouldn’t be in trying to produce the exact same end result as traditional software development. There’s no silver bullet in Power Platform or any other similar technology that would make everything better everywhere. Just like with cloud computing where you gave away the keys to your server room and accepted that your systems now run on someone else’s computer, low-code inevitably means giving up some level of control you used to have.

It’s true that with low-code you can get more for less: more working apps with less time and money invested in building them. However, it also requires you to settle for a bit less. Less code means less options to choose from, which is why the whole team needs to understand the business rationale for why this “less” is A) good enough and B) better ROI. Because if you aim for the perfect result instead, you end up in destroying the ROI. It’s all about the balance: seeing it early on when establishing the app vision, as well as continuously preserving it throughout the project.

UX is the trickiest area. After all, the user experience of a business application is critical, just like it is with apps targeted at consumers. This makes it difficult to say “you should worry less about UX”, yet that may be exactly what you should say in the beginning. See lesson number 1. The idea is not to claim UX wouldn’t matter – instead it’s all about stopping the team from overinvesting in UX at the start of the project.

This doesn’t mean you should intentionally stick to “amateur” app makers for the design of your app. On the contrary, it could be very helpful for everyone involved if the resources of professional UX designers would be leveraged in establishing a baseline for the core layouts and elements in your app. Starting from a blank canvas can lead to far more time spent in arguing about the how app should work and what it needs to look like.

There’s a caveat with this approach, though. You should keep in mind that what a professional designer might create will not always be technically feasible to implement in Power Apps. Not all of the generic web app capabilities used in today’s commercial applications (especially the consumer facing ones) will exist nor be supported when working in a low-code environment. Remember your target: maintaining balance.

Sometimes there are aspects to your app that would technically be supported, yet you should still use caution when adopting them to avoid making things more complex than necessary. One example in Power Apps is the ability to build responsive Canvas apps, instead of choosing a fixed layout for either phone or tablet screens. With the latter option, Power Apps offers a WYSIWYG experience for app makers that is very familiar to anyone who’s been creating PowerPoint slides.

Creating responsive layouts in Canvas apps, on the other hand, is considerably more complex task than WYSIWYG drag & drop design. The effort required to build the first version of your app, and every subsequent iteration of it, will be higher. Therefore you shouldn’t choose the responsive option “just in case we need it” but rather when you know you actually need it.

Another example worth mentioning in this context is components. At first, Canvas app components seem to offer a nice, logical way to create reusability into your app elements. They can also help in improving the app runtime performance, since the controls are not unique to every page but are instead loaded to client memory only once. Yet if you immediately jump into creating every bit of you Canvas app in a reusable way, then just as with responsive layouts, you’ll end up spending your time in tweaking the technical architecture of your app upfront. Before you really even know whether the thing you’re building will ever need to be reused.

There’s a time and place for investing in the fit and finish of your low-code solution. That place is not at the very start of your project. Also, your reason for adopting the most advanced features and patterns of Power Apps should not be just to see how close low-code can get to pro-code development practices. You need to do it the other way around: results first.

5. You don’t know what you need until you build it

It should come as no surprise for anyone having worked with business applications that the requirements will always change along the way. Teams and vendors responsible for delivering working systems under such fluctuating conditions have long been shifting towards ever more agile project management methods, to try and keep things somehow under control. This applies not only to custom software development but increasingly also deliveries done on top of packaged cloud application products like Dynamics 365.

The fact still remains that users and business owners can change their minds faster than you can change the implementation of a sophisticated app architecture. Somewhere along the road the organization may even come to the conclusion that the grand vision used for selling the idea of the app has been invalid. It wasn’t what the users or the business wanted, when confronted with how that vision translates into the physical world as you get into the nitty-gritty of the problem.

The bigger the scope is for your app, the more changes it will have to endure during its delivery phase. There will be more upfront design complexity you’ll feel the need to tackle before being able to present a draft version to the users and validate that it truly is what the business needs. If instead you would do things “the citizen way” and build something very basic and with limited feature set expected from any single app, you could gather user feedback and refine the requirements with very rapid iterations.

Perhaps this should have been the very first rule of this “building big apps” article, but let’s put it out there now: don’t build a big app. Even if it would be technically possible, this isn’t ultimately where low-code applications give you the best bang for the buck. Power Platform is more about how you can connect things together and make different digital tools work in a harmonious way, with your current and future data, ready to be aligned with the ever evolving business requirements.

Throughout the ~20 years I’ve worked with business applications revolving around customer data, there has been this Fallacy of One that has consistently appeared in many bold statements made by either software vendors or business owners of systems implemented on top of said software. “All in one screen”, “a single pane of glass”, “just one click” and so on. It might sound pretty cool when thrown on a PowerPoint slide, but there are a couple of big problems with it:

1. It’s never the everyday reality of the actual people using the system. Different screens, buttons and options often exist for a legitimate reason. Different apps for different purposes can be a good thing. The same way you wouldn’t replace MS Word with MS Excel just because both can be used for producings lines of text on a screen, having just one business app for everything may well offer suboptimal experiences to everyone.
2. It leads your development project towards an unattainable and ultimately irrelevant goal. Instead of laying out a vision statement that ties into a specific UI design choice, try to draw more attention to the business outcomes that should be made possible thanks to the apps & automations you’re developing. Time spent by users on a common task, responsiveness to customer requests, number of different people needed to make X happen, cost reduction thanks to removing systems Y and Z.

Do yourself a favor and don’t use the word “app” to describe something that will in reality be a complex Management Information System consisting of several components that can (and possibly should) be developed and iterated on independently. Instead, aim to use any number of small and innovative apps to get things done faster and in a more flexible way than a traditional enterprise monolith ever could.