Building for developers, SDKs and the future of IT

Building for developers, SDKs and the future of IT

Businesses have traditionally had two options for application development: buy a pre-built app from a third-party vendor or create one from the ground up using skilled developers and coders. Pre-built apps are more affordable but less flexible, making option two the route of choice for most forward-thinking organizations.

In-house app development has evolved rapidly in recent years thanks to the advent of tools like low-code/no-code platforms, cloud-native services, and agile methodologies. As a result, app development today is faster and more efficient than ever before. In turn, expectations about the speed of delivery have risen to unprecedented levels.

Low-code is being positioned by some as the end state of app development and
potentially the future of coding and programming. The popular narrative states AI will be used to generate code elements and end users will be able to build any widget or
component they need. It is a compelling concept, but it relies heavily on future advances that, as of yet, haven’t manifested. AI code is still buggy and it is not suitable for someone without coding expertise to review it. This means AI-generated code needs to be perfect, a development that is still some way off.

Arguably the greatest barrier to entry for low-code is that one-size-fits-all solutions tend to fit no one perfectly. Low or no-code development is analogous to flat pack furniture, standardized, but constrained by its format.

Bridging the gap with Flex

At Luzmo, we have long specialized in the provision of drag-and-drop tools that enable users (predominantly product managers) to create dashboards for data visualization purposes. The process, though, is not that simple. From a user perspective there isn’t much room for user error. Data sources are connected and the user selects the metrics they want to monitor. The solution then provides a selection of potential formats for the data.

A key challenge we have encountered with this offering has been the lack of end-user
flexibility. Low-code solutions have a great many uses, but company requirements are
prone to change, and can sometimes outpace what low-code solutions can offer.

We realized that there was a need to bridge the gap between low-code and pro-code and give businesses access to a solution that would have the benefits of a low-code
solution but with enough flexibility to enable input from developers. So we went back to the drawing board and started to build a software development kit (SDK) that would leverage the existing platform and the back-end solutions that we had built but allow for a much greater level of front-end customisation.

It was a substantial leap in product offering but one that matched the increased
specificity of the businesses that were using our existing solutions.

The process of designing tools – what to leave in and what to cut

The natural first step to take in building our new SDK was to establish what developers needed to build new data experiences and what we could simplify. The end goal throughout was to keep the process of building new apps as simple and fast as possible. Data infrastructure and initial set up was the most obvious thing to manage on the back end. Internally the team broke down each stage of building a data product and separated the aspects which introduced complexity from those which made the overall application more flexible and dynamic.

It became clear early in the development process that cutting some of the unnecessary complexity from building data products was producing the most substantive time and cost savings when trying to bring a product to market. The factors that drove up development times by far the most were establishing connections to fast, performant databases, writing queries, adding user customisations and making the outputs and data visualizations easily interactable for users. Simplifying these steps substantially compressed not only the time for development, but also the resources required. By the end of testing, a single developer was able to build a unique product in one or two days.

However, in order to offer value to customers, not everything can be simplified down. Otherwise you are back at square one with teams bumping into the limits of low-code
solutions. Customers still ultimately want live, updating dashboards with interactive and easily customisable widgets. Delivering those features requires developer input, but by borrowing the best parts of low-code and pro-code you can deliver a superior experience for the end user, while maximizing the impact of developers. This is not only more cost efficient but also mitigates the opportunity cost of putting a team of developers onto a project for weeks or months.

API-first design the key to keeping the solution flexible

Most AI solutions at present run via an API, and for various reasons our tools are built
around APIs as the most convenient way to make a modular solution that would remain viable in the future. For AI, basing the connection around an API means that while the default integration is with OpenAI, businesses can connect whichever LLM they prefer. Crucially, it also leaves room for future app integrations as they become available.

One of the challenges with AI and data is that Generative AI is non-deterministic. In
essence, this means that the same question phrased two different ways can return
different answers. To manage this aspect of LLMs, we focused on adding features that would ensure users could trust AI generated outputs.

Already, we have seen AI developers adding references and links to sources into results generated by AI. In a data and analytics context this means users need to be able to understand how a data visualization was constructed and when necessary, be able to correct or adapt that chart within the app. These are all features which aim to close the gap between the user’s prompt and the desired outcome. Fortunately, AI is also self improving so this gap closes the more the tool is used.

In theory, this means a developer could implement strict enough guardrails that a
prompt always returns the same output. However, the tighter the guardrails, the less
dynamic and engaging the potential output. For each context the developer needs to
manage the tension between the two extremes of too much variance and too little.

While low-code/no-code platforms have undoubtedly made significant strides in
simplifying development, they still fall short of meeting the increasingly complex
demands of modern businesses. The gap between the flexibility developers need and the ease that low-code promises is real, and it cannot be ignored. Solutions like our Flex SDK aim to bridge this gap by providing a toolkit that combines the ease of low-code with the depth and flexibility that pro developers require. By focusing on making life easier for developers, without sacrificing customizability, we’re not just preparing for the future of IT , we’re building it.

Karel Callens, Luzmo

Karel Callens

Karel Callens is CEO of Luzmo, an embedded analytics platform, purpose-built for SaaS companies.

Author

Scroll to Top

SUBSCRIBE

SUBSCRIBE