In part 1 of this two-part series on building vs buying a development platform, we looked at what to consider when building your technology stack in-house. In part 2 of this series, we’ll take a look at a second option: using a high-productivity app platform.
A subcategory of high-productivity application platforms (hpaPaaS) is low-code app development platforms.
Low-code app development platforms have taken the market by storm in the last few years, and it seems this trend will only continue: Gartner forecasts that by 2024, three-quarters of large enterprises will be using at least four low-code development tools, and that low-code application development will be responsible for more than 65% of application development activity.
High-productivity app platforms can provide huge benefits to enterprises: compared to using traditional “pro-code” development tools (i.e. “hand-coding” apps from scratch — putting together your own technology stack), high-productivity app platforms take away large swaths of the complexity involved in building apps.
Using a High-Productivity App Platform
Part 1 of this series highlighted the significant risks involved with a decision to build a technology stack in-house.
However, selecting a high-productivity app platform is not without its challenges. One of the biggest challenges on this path is determining the right evaluation criteria with which to select a platform. Certainly, not all platforms are created equal, and a careful analysis of various aspects of each platform is critical.
Over the last 10 years at JourneyApps, we have gained deep experience from working with many customers who were weighing this decision. We have seen where it has gone wrong, and where it has been highly successful. Based on that experience, we can share our insights regarding which evaluation criteria to use.
Evaluation Criteria for Selecting a Development Platform
The Learning Curve:
Understand who the platform is aimed at: Is it optimized for “citizen developers” (business people who build their own apps) or software developers? Will it be easy for developers to learn how to use the platform? Is it based on common technologies that developers are already comfortable with? Some platforms may require development teams to undergo extensive re-training, potentially to learn highly proprietary development methodologies.
Development Experience:
The development experience is a broad, and very important, aspect to consider when evaluating platforms. A platform needs to make the development team more productive compared to the traditional development tools that they are already familiar with. Aspects such as whether it is easy or difficult to set up the development environment, to model data, to build the UI, to create custom logic, to test an app and to debug an app should be considered.
Developer Buy-In:
Developers should be happy to adopt the new platform, and should not consider it to be a “resume killer” since it’s based on proprietary technology, or based on visual development rather than coding. Furthermore, a platform should boost software development productivity and not be a hindrance to developers accomplishing their objectives.
Infrastructure Setup and Scalability:
It should not be difficult to set up the cloud infrastructure required to deploy an app into multiple different environments. The best platforms allow environments to be provisioned with a few clicks and support elastic scalability. Aspects such as whether the platform provides indexing for the database in the cloud and for the database on user devices should be investigated.
Specialized Functionality:
A good platform will support seamlessly syncing data to user devices that are often offline. Be wary here: many platforms claim to support apps that “work offline”, but there is a whole spectrum of different breeds of offline functionality — and most platforms have debilitating limitations. The specifics are really important.
Another important functionality is the ability to interface with hardware devices, such as printing to thermal printers, reading or writing from or to RFID or NFC tags, ingesting measurements from Bluetooth sensor & measurement devices, or accepting input from a laser barcode scanner.
Deployment Complexity / DevOps:
Is it easy or difficult to deploy a new version of an app to end-users? It is important here for the user experience to be simple, avoiding the need for end-users to follow potentially error-prone steps.
Integration:
It should be relatively easy to develop custom integrations for apps built on a platform, the same goes for bi-directional integrations. Platforms should support event-based integration patterns such as Webhooks and pub/sub patterns and provide monitoring, logging and audit trails for integration events.
Security and Compliance:
Security and compliance is a critical consideration when evaluating development platforms. On the security side, important questions to ask include:
- Does the platform encrypt data at rest in the cloud?
- Does the platform encrypt data on user devices, across all supported operating systems? (iOS, Android, Windows, etc.)
- Does the platform encrypt all network communications by default?
- Does the platform provide a SOC 2 Type 2 report to attest to its security measures?
On the compliance side, an important question is: Does the platform provide data retention management tools to allow for regulatory and data privacy compliance, e.g. GDPR or the California Consumer Privacy Act?
Operating System Compatibility / “Write Once, Run Anywhere”:
A good platform should allow the building of apps that run as true mobile apps on iOS and Android, true desktop apps on Windows, Linux and Mac, as well as as web apps. True “write once, run anywhere” capability should not require any further configuration before an app can run on different operating systems.
Backups, Redundancy and Disaster Recovery:
A platform should have built-in database and application server redundancy and built-in automated backups. Neither of these should require manual set up.
Extensibility:
The platform that you choose should allow you to build custom UI components and create custom logic within apps while allowing you to build custom backend functionality in the cloud.
Vendor Lock-In:
It should be possible to retrieve readable code for your apps from the platform and to port code for your app from the platform to another platform. It should be easy for you to extract your data if you choose to move to a different vendor.
Support and Diagnostics:
The platform should provide functionality allowing you to debug issues occurring on user devices (e.g. diagnostic reports or logs) while it should be easy to retrieve diagnostic reports or logs from users.
Data Analysis, Data Maintenance Tooling and BI Integration:
Finally, it should be easy to access your data using a SQL interface, so that you can easily pull the data into the BI platform of your choice. Also, it should be easy to do bulk manipulation of data on the platform.
In Conclusion
In this two-part series we have looked at the two options companies need to consider in terms of their digital app development strategy. They can either choose to build their own technology stack, or use a high-productivity app platform on which to build their digital business apps. Using an already-built platform is often the wiser choice, but once a company has decided to go this route, they need to evaluate available platforms. Evaluating app development platforms can be a complex and time-consuming exercise. Having evaluation criteria as a guide can be helpful in showing that a company (such as JourneyApps) ticks all the correct boxes as a low-code app development platform.
