Automate all the things

A weekly no-code automation delivered to your inbox (with thoughts on no-code every now and then)
Feb 02, 2022 • Issue #74 by Aron Korenblit

"The moment you've written code, it's become legacy" an interview with Nick Gamble, VP Solutions @ Unqork

I've written a lot recently on my belief that the future of no-code is low-code. That belief is what led Connor and I to launch code meets no-code.

Below, I'm excited to bring you an interview with Nick Gamble VP Solutions at Unqork who believes the opposite. That instead of business users crossing the aisle towards developers, Unqork thinks that it is in fact developers that should adopt no-code tools to deliver more value to their businesses.

You can get the full audio and video of this interview here. If you're the reading type, below is the transcript (lightly edited for readability).

Aron Korenblit: Welcome Nick, officially to Automate All the Things. We're excited to have you here. 

Nick Gamble: Thanks again. Thanks for having me. 

Aron Korenblit: Most folks reading this newsletter will be unfamiliar with Unqork. Start us with what is Unqork and what is the tweet length summary on Unqork and the industries you serve?

Nick Gamble: Sure. So Unqork is a no-code platform, but it is an enterprise grade, no-code platform for software engineers. We're targeted for technical folks who have to take on very technical tasks in very technical and very regulated industries. We started in financial services and insurance – that was where our leadership had a ton of expertise, and that allowed us to grow very rapidly in those industries. But quickly we realized that we're not an industry solution. We are an industry-agnostic development platform. 

So from financial services to insurance. We went to healthcare. We went to public sector. If you ask me, there's really no limit to the use cases that we can build, even on a total outside of the box thing. I built a board game in Unqork. So it just goes to show that while we have success in certain industries, particularly because of the regulated nature of them, it is a very general purpose no-code platform.

Aron Korenblit: For folks who are unfamiliar with the platform, what are some things that are built in it, but also talk a little bit about the primitives that you have in place. What can I do with Unqork and how does it feel using it? 

Nick Gamble: Sure. So Unqork has the concept of the module, that's our primary element that makes up applications that are built in Unqork. Those modules contain UI elements. They contain some business logic and all that. And effectively what we've seen is there's more or less two to three types of modules that our creators are building. 

You have your schemas or your data models, and I think if you look at a lot of similar platforms, it starts around the data, right? You really need to have a good understanding of what you're capturing. relationships between the data, maybe where that data is going to go and things like that. So there's the element of Unqork of defining your data. 

But then, what are you going to do with that data? So you have the UI elements. So, about a little bit less than half of all of those modules in Unqork -- those building blocks -- are UI screens. So your typical form elements. So we have just about every form element you can imagine under the sun available to drag onto your canvas, and build that UI that you need to allow your users to submit information.

And that's going to also include reflexive logic. So if I check this, then I want to make this thing appear. If I answer one thing one way, I want to do the other. 

The one that actually excites me most as the engineer is the API layer. Everything that you do visually can also be executed as an API, as well as you can build things that are dedicated APIs.

Now, those could either be APIs that are going to sit on top of the data that you collect from that first type of module. It might be APIs that sit in front of third-party applications that you're calling or other applications within your infrastructure that you're calling, or it could just be some piece of reusable logic that you want to expose out to anybody else who's building within your Unqork environment or even externally to other folks. So taking those building blocks of your data your UIs and your APIs, and then stitching that together with our workflow product, to create those, whether it's visual workflows and the steps you need to collect information and pass it on to different stakeholders along a given workload process or even completely automated processes that may run on time sequence, to do some calculations, batch processing, you name it. 

Aron Korenblit: So it sounds like Unqork is a no-code tool or a low-code tool in the same sense as Webflow, Airtable, and others and that it has the same building blocks: UI, data and logic, but what I hear from you that is different is actually who you're targeting, which I think is unique and where I'd like us to spend a moment where you say it's a platform for developers. So maybe talk a little bit about "What is a no-code tool for developers?" 

Nick Gamble:It's not exclusively developers – what Unqork is able to do is really foster the collaboration between your technical users, your developers, and your non-technical users. We're in these highly-regulated, highly-complex enterprise organizations. I personally think we're kidding ourselves if all of a sudden someone can create a tool that allows anyone off the street to build an FX trading system, which some of our bank clients have done, or a patient onboarding portal like Maimonides Medical Center, the largest employer in Brooklyn, a big hospital, did. 

To think that someone can come in and just know how to do it -- maybe they can get it done -- but what's really important about software is not just getting it done, but getting it done well. Right? You want something that's scalable. You want something that's maintainable. Something that's almost more important than ever is secure. You want something that's secure and that's where the technical users can really come in and kind of lay that architecture out -- lay the foundation out -- and take on maybe some of the more complex aspects of the build that you're doing, but still giving the business users an option to come closer to that development process, contribute throughout the SDLC, really understand what it is maybe the more technical person is doing when they're actually following through on the requirement that they're given.

So we really feel that it is the engineers that you're going to accelerate. We call it a 10X engineer. There's certainly a seat at the table for everybody and that collaborative process is what's going to result in the best software you can build. 

Aron Korenblit: Personally I love that idea of building on the same platform, whether we're a developer or a non-developer. So I'm curious, in your experience, has it been more of a question of developers speaking business language or business users understanding development principles, such that they can contribute, whether it's Unqork or others? So where do you see folks migrating towards more as someone who speaks to both of those audiences?

Nick Gamble: I think it's advantageous for both sides to come into the middle and come together. That's actually a change I've seen in technology in general. If you go back to the eighties -- maybe nineties of technology -- it was a lot of pure developers who were just focused on whatever their task lists that they had to code was and not interfacing with the broader market and the rest of the organization. And now, it's the tech moguls that are the cultural icons and all that. So I think it goes both ways, but to answer your question, I would say I'm seeing a lot more of the business come closer to the technology. 

So it’s a question of how you can form the right team to deliver on it, and what can you do in Unqork to support that? 

Unqork is really big into reusability. So there might be a very complex calculation that needs to happen, or a complex workflow, or a flow on top of the data. You can still have the more technical person create that, expose it to all the lesser technical people who are involved who understand the UI, who understand the end user that's going to be touching this application and take those reusable blocks and use them without having to know really how they work. Now, of course they can dig in if they're super interested. It’s always fun to see that person whose eyes start to light up when they're like, "This is how websites work and this is how these things happen." So they can always dig in, but they also just understand, "Hey, somebody did something technical. Let me use it where I need." 

Aron Korenblit: As someone who teaches no-code principles or sometimes code principles, I love that idea of seeing folks being like, "Oh, I now understand this thing that I've been using all the time." So that definitely resonates. 

I guess a question I have for you is how do you convince someone who is a developer to entertain the idea of not writing code in the sense that it’s the most flexible, it's clearly the most scalable. "Why not write code?" seems like even a difficult premise. So how do you convince someone who's like, "why would I use this when I have more power and more flexibility using the things I already know?"

Nick Gamble: We really believe that engineers need no-code. Yes, with code you do have infinite flexibility. But there are so many things that developers are coding that don't need to be coded.

I think you would agree on the same side on Airtable, you've solved a tremendous use case where someone's going to have to go build a very interactive spreadsheet effectively, with connections every single time. And you said, "No engineer, don't do that.You don't need to go build what we've provided you. You can take your energy and your brains and you can go focus on the stuff that maybe we don't cover, that our platform doesn't cover just yet.” So I don't think it's even convincing them that they need to stop writing code for everything. It's just, "Hey, when you look at the things that you do time and time again, there are so many things that can be done without code." 

I think you even saw that evolution before no-code and low-code really started to change the trajectory of software development. You saw that even within code. First, there was very low level assembly language where you had to do everything. You had to jump around the circuit board, then you had to start to manage your memory when you got to C and languages like that, which was very hard. And then languages came along that did garbage collection for you and now engineers no longer have to manage their memory. And then, frameworks came out. Ruby on Rails, Django, Spring -- like all of these MVC frameworks came out to avoid you having to connect to every single database. 

So there's always been that abstraction and trying to take away some of the things that are going to be critical across or part of every application. With Unqork and no-code in general, the world of what those things are has grown -- not to say it's taken over everything just yet -- but certainly, I think we all would love to get there. So I think it's more about just targeting engineers to things that they're probably gonna drive a lot more joy out of doing and provide a lot more value to their organization out of doing. 

You also mentioned that code is going to be more scalable. I may challenge that assumption. I think code may give you more options to deal with the ultimate scalability problems that you're going to have, but when you take on any kind of SaaS or past platform, now all of a sudden you're pushing a lot of that scalability concerns out of your world. Within Unqork, you don't worry about running your application. We'll worry about running it, scaling it when it needs to. Maybe in a sense that could mean no-code is even more scalable because of course we do have engineers working under the covers behind the scenes doing that to our platform as well.

Aron Korenblit: I think the question around scalability is often one of not "Can this scale to an X number of users?" It's more of "Will I hit a wall?" And I think there's actually really interesting the case of Unqork where -- from my understanding -- code is not a part of the platform. There is no escape valve of "We will write custom code."

So, how do you balance that need for primitives? Obviously you're not going to build every single primitive that is possible while also potentially hitting a wall of like, "I can't do this thing that I have to do," which a lot of other no-code platforms allow you to use code in to unlock those use cases. So how do you guys think about that? 

Nick Gamble: Sure. So I would say a couple of things there. So first off -- again -- I've been at Unqork for three years and have not hit that wall, which I think says a lot. But, I also haven't seen every requirement under the sun that every customer is going to give and things like that.

So, let's take an example of connecting to a database, right? Like a direct connection to a database. That is something that we have just flat out said, "You're not going to be able to do from Unqork." We don't want you to connect directly to a MySQL database or even some more legacy one that's even harder to connect to its driver that's really hard to find. But, you need to do it, right? So I would say that's a great example where an engineer can then focus on something that is still exciting to them – and that'd be organization – and build an API that stands in front of that database and then Unqork, through its integration layer and its visual API builder, can connect directly to that. Now, maybe over time, we'll be a little more open to that concept of doing it from Unqork, but that's a good example where you can write code outside of the world of Unqork, and then connect Unqork to it. Whether you're connecting Unqork to the code you wrote or connecting Unqork to a third party, like an Airtable.

We're not going to let you write code in Unqork because we want to ensure that what you're building on Unqork truly is codeless and really is just a flexible representation of your logic. But, there might be an instance where it's advantageous for the infrastructure, the architecture, or the needs that you have to write some side code.

I would say the other part of that too, is we don't sit here and think that we have completed the journey of building the greatest no-code product in the world. We're obviously extremely proud of what we have done and we think it is a tremendous platform. We talked to our customers on a daily basis. We talked to our internal users on a daily basis. When they come with feedback that might be along those lines, "Like, I don't feel that I can do, X requirement given the capabilities that you have," we'll certainly look to take that need from Client A, abstract it away from what they're asking, get to the root of what's needed, and find a way to then take that and expose it as a new feature in Unqork.

Aron Korenblit: I think we can get into a debate around, which primitives do you build and what that enables and how you prioritize those. I think one thing I'm hearing from you is, you would always rather build those primitives rather than have that code kind of functionality, right? But it doesn't stop folks from writing code outside. And I think that's definitely a unique approach.

Nick Gamble: Right. We believe that if you're writing code inside of Unqork, the moment you've written code it's become legacy. Because within a week, a new version of ECMAScript is going to come out. Within a week, a better database is going to come out. The moment you've committed it to Git or whatever, it's now legacy that you need to maintain and deal with it. Whereas, by keeping as much of that as this language agnostic standard, we are opening up the Unqork JSON representation as an open standard and that it's just there, a no-code representation because we don't compile code. We don't generate code. Everything is interpreted on the fly. So as long as you have that codeless representation of your logic, you don't have to worry about changing it when the JavaScript library changes, when the cookie policies of browsers change, and all that. That's not to say we might not have to do that, but -- hey -- wouldn't you rather we do that for you? And you're just responsible for your business logic. We'll handle the rapidly changing world of code under the covers. 

Aron Korenblit: We appreciate that. As all no-coders, we appreciate all the platforms doing the true heavy lifting for us.

So to end, you've painted a picture of this idea of developers working with business folks to enable mainly internal use cases -- maybe just to end here, if we were to project ourselves 10 years from now, and maybe you work at Unqork, maybe you don't, what do you hope is possible with no-code 10 years from now? What can I do as a no-coder in 10 years? 

Nick Gamble: Yeah. I think we would both hope that it's just about everything, right? And, I mentioned that open standard, and I've used the term codeless a few times versus no-code -- because that's kind of the lens at which we're looking at things now. Rather than focusing on just the designing principle of it, focusing on whether it's an Airtable-like application, a Webflow, Zapier -- all the tools -- rather than trying to say that one -- and I even think you said this in one of your blogs -- there will never be a one-size-fits-all platform for everybody. Right? That's what we are really embracing right now by saying that -- look -- we're going to focus on this open codeless standard. Just as serverless changed the way people can run their code, we're looking to change the way that you can effectively run your no-code. And the input into that open standard can be anything, right? You could use Airtable and then generate that out against our standard. Go ahead and use Salesforce Service. You name it. We've provided that intermediate standard and you can come in with whatever IDE you want, whatever other platform you want that translates to ours and then gets run.

By defining that standard, we're hoping that it's going to lead to everybody's success in no-code, so that folks who are focused on different use cases can succeed in those use cases and we can help facilitate that and just facilitate the continued growth.

Where I see no-code going in 10 years truly is almost everything except maybe the writing of the no-code platform. And actually -- when I say that -- I'd be remiss not to bring up that a large portion of Unqork is now built with Unqork.

Aron Korenblit: Right. 

Nick Gamble: So we actually have a number of capabilities of our product that are built using our product. So that is affording us the ability to take all the benefits that we've talked about so far today and apply that towards the growth of our platform and then allowing our engineers to do that through the parts of the platform that run the platform, rather than some of the capabilities that folks are asking for or really need as they're using it.

Aron Korenblit: Well, let's hope for a future where we do have that promised land. I'm sure there are some big hurdles. That question of will people actually adopt that standard, First and foremost, and second, I'm sure there are things that we build now that will require that code kind of element, right? I don't think we'll be able to innovate always on existing primitives, right? And we need new ones all the time. So... 

Nick Gamble: Yeah. I would say, well, quantum no-code soon. 

Aron Korenblit: Right. Exactly. Well, I hope that future for us and for you guys does materialize and really appreciate you Nick coming on Automate All the Things and talking to us.

Until next week, keep building!


Automate All the Things
Read the latest post in your inbox every Wednesday.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Related streams

See all streams
No items found.