No/Low-Code Versus SDK: What’s the Right Approach?

For developers, it is truly a “buyer’s market.” With the current pace of investment in new frameworks, tool companies, and AI-based solutions, developers now have a cornucopia of affordable options to improve and accelerate their craft. In fact, Gartner predicts that by 2026, “developers outside formal IT departments will account for at least 80% of the user base for low-code development tools”. 

However, despite the rapid adoption of no/low-code solutions on the market today, some developers do question the best use — or even value of — these new (or reimagined) tools. While they are not wrong to do so, the real question is not “if” the approach is viable, but “when”.  

As a career developer and now, engineering leader and startup founder, here are my takeaways on the choices and value between newer approaches like no/low code and more traditional approaches like SDKs when prioritizing both productivity and quality in results.

The Case for SDKs

What Is It?

A Software Development Kit (SDK) contains a collection of development resources, like a compiler, documentation, and an Application Programming Interface (API). It is needed by developers to create or integrate with an application.  

SDKs are not new and represent a more traditional and code-heavy approach. What is newer is the trend towards an API-first approach. Examples of API-first companies include Stripe and Twilio. 

API-first companies make their APIs the central pivot to how they build applications or platforms. They use the APIs to build their product, and then typically offer the same APIs they use internally to third parties via an SDK. This is in direct contrast with building an application and then building an API only when responding to a request or as an afterthought.

Why Use It?

There are many reasons why SDKs continue to be popular resources for developers:

• Simplifies work in an API-first environment that has many APIs and a complex architecture. In these circumstances, a solid SDK typically available in multiple code languages is a must-have.
• Makes it easier to adhere to coding standards and workflows, like GitOps and Integrated Development Environments (IDE).
• Offers a more native experience for developers than learning a new no/low-code tool.
• Gives developers more complete control over the UI/UX and other elements.
• Provides an easier path to end-to-end testing (low/no code usually requires something like Cypress or for the tool to provide dedicated testing and CI/CD resources.)

The Case for No-Code

What Is It?

No-code is a software development approach that does not require any coding knowledge to solve a problem at hand. It has become popular in a range of fields from marketing automation to website building and can be found in services from brand-name companies like Zapier, Workado, and Wix.

Why Use It?

While coding knowledge would seem to define the role of ‘developer’ and indeed, no-code solutions offer tremendous value to non-developers, there is significant value for developers in using this approach:

• Automates away time lost to “busy work” at a low cost. 
• Focuses developers on core product work by abstracting away the complexity of tangential (but still necessary) development tasks.
• Engages lower-skilled developers or even ops teams to help complete work.
• Can improve engagement with non-dev stakeholders like UX, Security, and Product.
• In some cases, it can offer specialized knowledge embedded within the no-code platform itself. 

Simply put from a company and developer perspective – would you rather spend your skilled developer time building your new products, inventions, and core initiatives…or reinventing common functions and processes like authentication, payments, and site hosting every day?

The Case for Low-Code

What Is It?

Low-code is a software development practice that requires some coding knowledge and work. Low-code tools elevate coding from a textual to a visual experience, with a drag-and-drop, click-and-done, workflow-like interface for developers. Some top examples of low-code tools include Retool and Airtable.

Why Use It?

Low-code technologies abstract away the nitty-gritty of the process at hand. 

And like no-code solutions, they can greatly decrease the time, effort, and in some cases, specialized knowledge needed to get work done. But in contrast to no-code, low-code also offers: 

• More balance between control and automation – using the visual interface to more quickly get work done, while retaining the ability to adjust elements as needed.
• Visual representation of workflows that offer a useful tool to even skilled developers.
• More flexibility with features and capabilities than typically offered in no-code solutions.

Scorecard

Looking across the options, we can broadly summarize the benefits and challenges considering elements such as productivity, control, cost, quality, and use cases.

Discussion and Case Study: CIAM

In truth, a compare and contrast chart oversimplifies things a bit. 

In reality, services, applications, and the coding decisions made for them aren’t simple. And when choosing your tools and approach the decision criteria can be complex and at times, conflicting.  Additional questions and context play a large part, such as:

• Company size, stage, engineering budget, tool set, and team skills.
• UX and security requirements based on the type of business and user engagement.
• The need for specialized knowledge.
• The technical and integration ecosystem.
• Deadlines.
• And so on.

Customer Identity and Access Management (CIAM) solutions offer a great case study for this very reason. At Descope, when working with our customers or just seeing CIAM deployments in the world, we often encounter these complex, conflicting drivers, as captured in some real deployment illustrations below. 

Startups can benefit from the costs and speed of using a no/low-code approach…but can also benefit from standardizing on an IDE (and SDKs) to lower productivity cost of tool sprawl.

For example, one of our startup clients in the AI space has solved this dilemma by, like many companies, adopting a mixed approach. They now use a no-code solution for their docs site, while using APIs for their app site due to an easier migration path from another product.

Skilled, enterprise developers often need and value the ability to control and customize that SDKs offer…yet also find use of no/low-code solutions to avoid the issues they encounter e.g., API communications, trying to collaborate with other teams, or finding themselves lacking specialized knowledge in authentication and identity — and then learning ‘the hard way’ by releasing vulnerable identity systems.

An organization we’ve worked with in the ed-fintech market was building an onboarding process with a UX-sensitive user base and began creating their login process via APIs. They later decided that exploring additional (frictionless) authentication methods with more bot resilience was easier to achieve with a specialized, no/low-code solution.

Business-to-consumer (B2C) organizations like financial services put a high premium on custom, frictionless user journeys that suggest a code-heavy, SDK approach…however, like enterprise-focused organizations, they may be challenged in cross-functional collaboration and in their delivery speed for their in-house product release schedules that are more suited to low-code.  

We know of a financial services organization that now actively recommends to ‘buy rather than build’ and solve their challenges with no code. Why? After their highly skilled architect and dev team had worked through a challenging build project that failed to align cross-functionally on the tech, goals, and platforms upfront, they realized that transparency would have saved them a lot of time, cost, and pain.

My Take

At the end of the day, it comes down to which development approach will effectively solve the problem you have – both technical and business – for your company, your team, and ultimately your end-user or customer. With this perspective, many dev teams are now adopting a mixed approach between no/low code and SDKs to meet their needs for time, budget, skills, technology, control, standardization, and especially, outcomes.

But most importantly, determining the right tool and approach to meet the moment comes to you, the developer or engineering manager on the project. You are “the buyer” and the one best qualified and able to make the right call. You do you!