Navigating No-Code, Low-Code, and Traditional Coding | Interview with Steven Schkolne, Founder of MightyMeld

[Ryan Purvis] Hello, and welcome to the Digital Workspace Works podcast. I'm Ryan Purvis, your host, supported by our producer, Heather Bicknell. In this series, you'll hear stories and opinions from experts in the field, stories from the front lines, the problems they face and how they solve them, the areas they're focused on from technology, people, and processes to the approaches they took that will help you to get to the scripts for the Digital Workspace inner workings.

Ryan Purvis: Stephen, welcome to the digital workspace works podcast. You want to introduce yourself, please?

Steven Schkolne: Yeah, I'm Stephen Skolny. I'm a digital creator, engineer, designer, entrepreneur, and I'm happy to be here chatting to you today,

Ryan Purvis: Fantastic.

Ryan Purvis: Do you want to tell us what the Digital Workspace means to you, please?

Steven Schkolne: Yeah, I mean, I really think of the Digital Workspace, it gets bigger and bigger with every passing year. You know, in the early days when I was younger, it was very, computer usage was very narrow and very focused. But these days with all these emerging technologies [00:01:00] and not only That can affect and impact the world, but I could also sense and understand the world.

Steven Schkolne: It seems like it's getting bigger and bigger with every, every passing day. Myself, I'm, most passionate about the web and web design. And in terms of my focus in the digital workspace, I've been very focused these past couple of years on how people build sophisticated web products and that whole workflow that's where I spent most of my, career design development and building products on the web.

Steven Schkolne: And so sort of zoom in, you know, from the whole world, I would say, you know, zooming in a bit in terms of my specific focus and the things that I'm most passionate about within the digital workspace would be the web and, you know, experiences that are delivered on the web and just seeing how. These just keep getting better and better every year.

Ryan Purvis: And I'm

Ryan Purvis: reading your profile and you've heard there's some interesting stuff. I mean, some VR stuff, which I'm interested to go to hear what your thoughts are. And then maybe tell us a bit about what Mighty Meld is. Yeah.

Steven Schkolne: Yeah. Mighty Meld, basically what we're doing with Mighty Meld, it's inspired by game engines.

Steven Schkolne: And as you see, I've worked with a lot, [00:02:00] of different. Build a lot of different kinds of products, right? From VR gaming, mobile apps, web apps. And what I think is the coolest way to create experiences is the way game engines do it. And I think game engines, they need a certain level of viscerality to the experience and.

Steven Schkolne: They have these setups where you have your whole game laid out visually and you can play the game. And while you're playing the game, you can kind of pause at any time and move things around and then keep playing. It's very essential for like level design. Imagine being in a first person shooter and you're like, Oh, I can't quite see that enemy.

Steven Schkolne: And let's move the tree out of the way. And so I'm focused on this project called mighty meld, which is trying to bring that same experience to, to web design and web engineering. And if you've ever built a website you know that when you're coding it which is the route for like the most sophisticated experiences, there's a real divide between like CSS and all your JavaScript and the app itself.

Steven Schkolne: And there's this like back and forth experience that developers have, like go into the code and they're like, Oh, get hot reloads. And they go to the browser and they go back and forth and they're not really stitched [00:03:00] together. And so what we're building is a visual way to make web apps. It's a lot like.

Steven Schkolne: The way game engines work, where you actually visually see your app. You can pause time, move things around visually it's all tied to the code. So you get that absolute control and just a faster way for people to build those kinds of, you know, typically more sophisticated web apps, but basically any, kind of situation where people turn to code because they need that extra control over what they're doing or they're doing something that just hasn't been done before.

Steven Schkolne: And so no one's really made a no code platform for it.

Ryan Purvis: That's very

Ryan Purvis: interesting. So I'm involved with a business called FinEx One, which would be a no code, low code platform for fintech apps and we're pretty much making APIs beautiful with our UI. While you're talking, I'm wondering about how we could use mighty meld, and I don't know.

Ryan Purvis: I mean, obviously we're using some javascript at the box in the front end, but I don't know if it's reacts aligned or if it's what's the other one? That kind of the framework is called now

Steven Schkolne: view view is other popular one or angular maybe.

Ryan Purvis: It's probably, it's probably Angular. I think it's probably an Angular based one.

Ryan Purvis: But would yours, your [00:04:00] product work with Angular? Because it's

Steven Schkolne: JavaScript, or? No, we're focusing on React right now. You know, we could support other platforms, right, but just in terms of we're an early stage startup. We're focusing on React. Yeah, sure. But yeah, our vision is to support all the frameworks.

Steven Schkolne: And I think the way to work for a product like yours is just, you know, as you're building out, it's a web based. Builder, I assume, like a SAS product. Yeah. Yeah. So it's like, while you're building it out, it would just make it faster for your team to build new iterations on your product and to get that, that user experience really, really nice.

Steven Schkolne: You know, most of the actual nuts and bolts of UI is actually controlled by engineers these days. And I don't know what kind of engineers you have, but often you'll have this kind of design oriented engineer. Who understands a little bit about what's going on and mighty mode really unlocks that kind of visual thinking for those kinds of engineers.

Steven Schkolne: So yeah, I think it would just, it's basically helps you build faster. It's really pretty simple. Just a dev tool just to, you know, helps you develop faster. Just kind of supplements[00:05:00] your experience. And yeah, I don't know how, how much you've gone into it, but a lot of developers use like in their browser, they kind of inspect what's going on.

Steven Schkolne: And you like see things, right. That actually shows you stuff that's already been processed and compiled and running in the Dom. It's very far away from your code. And one way to think about MightyMiles is it's kind of just like Chrome DevTools, except everything is phrased in terms of your actual code.

Steven Schkolne: So you can understand what's happening in a way that's much closer to your source code. And when you change things that actually updates your code with the same code you would have written yourself. And so that experience that a lot of people are familiar with, which is like poking at their site and they kind of see things in these Chrome DevTools.

Steven Schkolne: It's made a lot more sensible because instead of the Dom, everything's in terms of your code. And as you change things things update. And we also have like drag and drop building and a lot of those things that are familiar from no code tools that operate on your code, which is a bit of a tongue twister to get into.

Steven Schkolne: It's like, there's no code is a code. I really just think of it as WYSIWYG. It's easier to think of it as WYSIWYG, which is a bit of an old school term, but. You know, you can take your existing [00:06:00] components in your product, drag them around, move them around visually and basically have a lot of that power and ease that we all know is great from no code and finding a way to make those same kinds of interfaces apply to, you know, coded products where it's kind of sky's the limit in terms of the complexity of what you can build.

Ryan Purvis: How did you decide to get into this? Was it just a frustration for you? Cool problem to solve or where does it sort

Steven Schkolne: of rank? I would say I, you know, sometimes you don't really have a choice in these things.

Steven Schkolne: I would say it was, you know, sometimes you get bit by an idea. And I think I've always, that's kind of always how I've worked in my career. I've been. Often I get very passionate about an idea. It doesn't happen that often, maybe once a decade or so. And, you know, I just couldn't, couldn't stop thinking about it.

Steven Schkolne: It is a problem that I've yeah, about almost a decade. I've been thinking, you know, had conversations with this friend about a decade ago and the very experience we're building something for unity. We're just like, you know, we're just [00:07:00] flying through. It, and then we were, we switched over to make a website for some reason.

Steven Schkolne: And we're just like, man, the web is broken. You know, like it has been a sort of a bee in my bonnet while now. It's like, why is the web so broken? You know, for Mac, they have like Xcode to your iPhone apps and all these tools exist. It's like, why is the web behind everything else? So it's been a bit of a bee in my bonnet.

Steven Schkolne: Yeah, I just had this this moment a couple of years ago where I just, I S I was working a lot as a designer and seeing how Figma worked. And I was also working as a, full stack engineer. And I just saw that the two were kind of the same and that they could be made the same and the same kinds of flows in Figma could be done on.

Steven Schkolne: Living source code and yeah, from there, I just, was like, Oh, this is impossible is, you know, I can't do this doesn't make any sense. It's too difficult, but I just kept plugging away at it and couldn't quite put it down. It's almost like I needed the world to tell me that it couldn't be done and the world never did.

Steven Schkolne: So I'm working on now.

Ryan Purvis: No, look, I mean, I think, I think that's the [00:08:00] entrepreneurial thing, right? You want to solve problems. And, I mean, there's a very famous quote from Nelson Mandela. it's impossible until someone does it. And, and you know, I subscribe to that completely. And sometimes you will, I mean, you know, you have those days where you just want to give it up.

Ryan Purvis: And you make a little bit of momentum, like, like fishing, you know, have no bites the whole day, and then you get this one fight that keeps you, you don't get the fish, but it keeps you in the fight, you know, it makes the whole trip worthwhile. Yeah, I think that's what, what happens with this sort of stuff.

Ryan Purvis: You start building the product that solves the problem and you don't make any progress. And all of a sudden you have this one little moment and you're like, Oh, okay, we're on the right track or someone else says, Oh, geez, I really need that because you think no one needs this thing anymore. They reinforce it.

Ryan Purvis: Like, okay, so I'm not completely, completely lost.

Steven Schkolne: Exactly. You have that conversation with that person who's just, you know, dying, to get it. And, as already what I love the most is running into people who are like, I've been thinking about this too. You know, it's like they've been dreaming the same dream and that's always really invigorating.

Ryan Purvis: Yeah. I just love the concept of a, of a mental. Visualization of your code, because I think [00:09:00] that's the hardest thing about building software is that you, you know, especially when you work in very abstracted things, you know, trying to keep track of all of it. And then I like your analogy of the game system, because I think that's, that's what, what really resonated people is, is some sort of story they can tie in with, , with action.

Ryan Purvis: Because that's, really, you know. What's interesting for me. And I mean, would you, I mean, obviously, there's in this day and age, a lot of AI back towards this? This is pretty much a an old school sort of approach of building without AI.

Steven Schkolne: Yeah, no. So we we do leverage AI to you know, make, things faster, essentially.

Steven Schkolne: But a lot of our core technology is more traditional. Because we actually have a very like precise model of your code and what's happening. A lot of the AI manipulations have some ambiguity to what you may or may not do. Use natural language and it really excels at that fuzziness. And so there's spots in our app where you can, and actually we do have a vision around AI.

Steven Schkolne: Which is really this experience of using your product. And as you're using it, giving prompts to the machine and saying, change this, change that, change that, [00:10:00] and having the product evolve in front of your eyes. And we have some of that happening right now in terms of styling, where you can look at an element and say, change the way it looks and give it prompts and updates it, but we don't.

Steven Schkolne: Depart too much from those Lego bricks, which are the pieces of source code under the hood. Right. And so our vision is not so much like, Oh, you're not going to understand. Right now, if you use AI repeatedly, things get to be a bit of a mess and people need to make very sophisticated things. our vision is more one of a human in the loop.

Steven Schkolne: And so we have AI prompts. We use AI to do iterations essentially. So say go from this to this, to this, to this, and to rate it on your app. But we also have a lot of traditional technology. We have sort of a reverse compiler in a sense that takes your code moves to some intermediary abstractions, and it turns out that those abstractions.

Steven Schkolne: Support our AI tremendously. So we can tell the AI, for example, what imports are being used or what things are supported. And so we can actually feed the prompts with more context. So it's really a hybridization of traditional [00:11:00] technology and AI that allows us as we've gone deeper into the AI, we've, noticed there's some limitations where it doesn't understand certain things, or you'd have to send a problem to like your whole code base or something of that nature.

Steven Schkolne: And so we're finding ways to blend the traditional. With a I and the traditional is actually the really difficult part. The impossible part of our problem was making everything work backwards. And the AI is more something that is, really. Easy for us because we built this foundation using traditional methods, we can kind of stand on the shoulders of the giants at open AI and those kinds of teams and use their code generators.

Steven Schkolne: But we're allowed to feed the system a lot more precisely because of all the traditional stuff we've done.

Ryan Purvis: when you were speaking, I don't know how close this is. I mean, my sort of development background is NET and you know, I don't write code in ANGO anymore. But I was thinking about reflection as a concept when when you were speaking where you would, basically generate, not necessarily generate your code, but you'd write your code against, you'd write your code to go read.

Ryan Purvis: what's available in the object model of that components you're using, and [00:12:00] then by having that you'd be able to, you know, almost smartly use those methods to go and do your activity without having to go right all the boring, you know, extrapolations of everything. And I wonder how close it was to that or I completely misunderstood the.

Steven Schkolne: Yeah, no, I think that makes sense. Like we have this object model and let me rephrase it and see if we're converging, but we have this object model and we can feed that to the LLM. And so we can feed information. To the LLM to make it more effective and more efficient. And yeah, we also expose that object model to the user and allow the engineer in this case to see and manipulate things.

Steven Schkolne: And yeah, our goal is to kind of automate a lot of the boring things and the simple things and the trivial things just to take humans to that, that higher level of creativity and power and really strip away a lot of the mundanity. Of it. And leave more space for problem solving and more space for intuition.

Steven Schkolne: Just by Take and I, that's kind of how I see the role of AI in, in engineering, at least now using tools like co pilot in terms of traditional coding, it really [00:13:00] helps like my favorite use case for it is just debug logs, you know, just like print out great debug statements. Like it just saves me from having to think about writing those debug statements.

Steven Schkolne: Right. And so it doesn't actually have to, solve the whole problem to be. Really a huge productivity enhancer

Ryan Purvis: yeah, 100 percent right. I mean, than writing that sort of stuff out, which is not useful. I mean, it's useful when it's broken, but it's not useful when it's not broken.

Ryan Purvis: And I mean, the amount of time, I mean, you know, as I say, most of my stuff was. net, Microsoft stuff, you know, the amount of time you see the same error given to you, like third party components thrown an exception. But you're like, but which third party component has thrown the exception? Yeah, tell me a little bit more.

Ryan Purvis: Give me some, you know, and then you have to go dig through a whole stack trace. And if you could just, you know, and, you know, I mean, obviously you're not going to solve all these problems, but just having some intelligence that, can give you that generated boilerplate that lines up with the component you've just built.

Ryan Purvis: And when the error happens, it's a correctly formatted message that, you know, it's nice for the user, but you can also have the technical person go. Oh yeah, OK, I know what that is. We can, you know, kind of know. I don't kind of know where to look for that thing [00:14:00] versus the generic error that people right after I was to get bored.

Ryan Purvis: What about multi language and that sort of stuff? Is that something you'd be able to help developer cater for or not?

Steven Schkolne: Things like internationalization. Yes, you mean? Yeah. Yeah. I think, I mean, we're at least with MightyMode, we're more focused on the visual and so sometimes you have like, I guess, certain requirements about say, right to left or left to right in terms of language modes.

Steven Schkolne: And, you know, we have a kind of multi browser set up so you could see both of those operating at the same time and sort of fine tune. You know, do changes to a component once, see it update both languages to help understand just make sure the layout and the user experience is good for both languages, or maybe you have a language like German which tends to have long words.

Steven Schkolne: And so, yeah, this sort of gets into some of the multi browser things. We do where we could show you multiple views of your page, and then you could actually make an update to one part of code and see it updated different responsive breakpoints or for different languages so that we support.

Steven Schkolne: Well, in terms of the framework for setting up internationalization, right? Like there's a lot of scaffolding that [00:15:00] goes into that. You know, we have JSON files or, language maps or something like that. we don't help much with that at all. We're more like set that up your way. And that's a lot of our philosophy for some of the stuff deeper in the guts is, Do it your way and our tool will work around however you do it. And so we're very focused on the front end and the visual part of your app. And that's kind of our philosophy is we're going to make it a lot faster for you to do the UI and the visual parts. Kind of where design thinking could come in to play a little bit.

Steven Schkolne: But you know, as for the guts, the guts are yours to build. Anyway, you want that's really something that's been missing in a lot of the no code tools. And you know, no code, as you know, is growing every year and like getting, you know, you know, but code is growing as well. Like kind of everything is growing in every, every direction.

Steven Schkolne: It's kind of like the expansion of the universe. Right. And so, yeah, but it's really difficult to have a, you know, Once you start to introduce real code or like give it, you know, no code platforms don't typically give access to all the underpinnings of things. And so [00:16:00] our philosophy is we don't want to get in the way of those underpinnings.

Steven Schkolne: We want to let you engineer and architect it the way you want to for the reasons that, you know, millions of developers you know, architect things these days. So.

Ryan Purvis: what it's funny is as much as no code is growing and without a doubt, I mean, you think about, I mean, I know if you're a Treky fan or not, or, I mean, 'cause it was always, been like my funny comparison, if you compare Star Wars to Star Trek.

Ryan Purvis: Yeah. Star Wars has almost no intelligent AI like systems. Like they have the, they have the bots and the droids. But you don't, you don't see anything that, like the spacecraft is still dumb devices in a sense the droid can fly, but not, but the droid is not integrated into the aircraft.

Ryan Purvis: Right. And then if you look at obviously Star Trek, which has the computer in, you know, that you talk to that does certain things Is a far more integrated experience and it's as much as, and I mean, I remember some, some episodes like where, where data is working with the computer to go write an algorithm to go solve this problem, to do whatever.

Ryan Purvis: Yeah. That's kind of the low code, no code sort of experience where you want to talk to the computer to go build the app that you need to go and [00:17:00] do, et cetera. But the point I'm trying to get to is that as much as we're going down the route of no code. There's still the need to provide some level of code interaction that you, so the low code pieces is still relevant.

Ryan Purvis: It's still important because no matter how much you low code it or no code it, you still have to provide that little bit extra that you can customize. And you mentioned the object model. I think that's, that's, you know, we, we have a thing inside of Phoenix one that's similar where you can reference the data fabric to get the fields out that you need and that'll become more, more intelligent.

Ryan Purvis: And then what over time will happen. Not least in theory is whatever we build is customized things using low code. Becomes components in the future because now we've seen someone use it a hundred times and we're just gonna convert it into a widget or a whatever. And I'm assuming you did something similar with what you're doing.

Ryan Purvis: You're seeing repeating patterns that you can further improve and automate.

Steven Schkolne: Yeah. I think it's maybe interesting, maybe we could dive into a little bit about, you know, no code, low code and code. I find it difficult to express why people choose code and the kinds of projects. That people choose to code as opposed to no [00:18:00] code, low code.

Steven Schkolne: And given that, you know, we both have a lot of experience in this space, maybe we could dive into that a bit. Yeah, because I think, I mean, the way I see low code, or maybe just like sort of establish a way of thinking about it. You have no code where there's some visual interface. You never have access to the code.

Steven Schkolne: And then there's low code, which usually is sort of like modules that plug in. Right. And so it's like the platform establishes a certain like framework. And then, you can code on top of that framework, you know, you can put a little thing in there that can access the database underneath or whatever the data store is underneath.

Steven Schkolne: And then you have coded, which is kind of, you know sort of free for all. Right. But when I sort of see the difference with code, I think my, my experience as an engineer with and this is not just about like. No code tools. Also with things like templated solutions is like that last little bit of control can be very difficult to get

Ryan Purvis: I probably had a fourth one in there, which is probably in the middle between your last one and the second one. so I think in your, in your low code environment, you're still going to have that piece where you [00:19:00] may need to go build a plug in. It goes into a low code, no code that's not built by the vendor by the platform.

Ryan Purvis: So someone who's got the development skill can go right there. So you look at something like Salesforce or Dynamics. You know, those are probably the first ones that did this really well. Where you could go build your component and deploy it into the marketplace and have it deployed into the app. But it's still written by a developer like a, you know, WordPress.

Ryan Purvis: WordPress is probably even a better example. You know, the amount of add ins and plug ins that exist there. And then you still have the bespoke custom dev. Application. That's completely, you know, specialist skill set if you like.

Steven Schkolne: yeah, yeah. WordPress certainly plugins can get pretty deep.

Steven Schkolne: Yeah, I guess plugin model is, I guess there are different flavors of plugin too, right? Yeah. Sure. Yeah. And I think even in code, we might be able to split code into two buckets because can code within frameworks and there's also things like templated solutions. For example, If you're writing a react app, you could bring in a carousel, like a image carousel component, right? That's someone else coded and that's different than coding it from scratch yourself in terms of the level of control. You get the level of [00:20:00] finesse. And so even in coding, there's sort of an ability to bring in other modules.

Steven Schkolne: Yeah, I guess there's just a lot of different ways to slice this, this one up.

Ryan Purvis: Well, and I think what's great about what you're doing and what we're seeing market wise is that the barrier to entry for a person with an idea is getting lower and lower for them to enter. And if you just look at something like Zapier or make or power apps, whatever the commercial calls their thing now and integrate services together, you know, a lot of things that you would never have done before.

Ryan Purvis: You can just do. Provide you've got time to go and wire the things up. Now, obviously there's nuances to those things. So they don't all work kind of how you'd want them to or whatever it is, but it still gets you there. And then I think with what you're doing, what we're doing in the sense of very niche things, you know, someone's coming in to build a front end application.

Ryan Purvis: To solve a problem, anyway, to do that faster is a good thing. But also not having this reliance on a big dev team to go and build it because you're getting efficiencies and effectiveness because you're using ways to get there faster. And also in a better [00:21:00] quality way, because I think that's the other thing people always forget about.

Ryan Purvis: Everyone loves to build the app and no one wants to do the maintenance of the app. Because that's really the painful part. That's actually what gets more expensive. Because it was really badly built in the first place that maintenance costs can spiral to the point and I'm going to one of my products where we made some bad decisions up front.

Ryan Purvis: Well, I made some bad decisions up front and we were re architecting some of the stuff and we're now realizing how badly built some of the stuff was, to the point that. You know, I was actually jokingly saying, why don't you just generate the whole thing for me and then we'll just see what it looks like.

Ryan Purvis: That might be quick and that might just be less stressful. But you know, it's one of those, still want someone with a bit of a creativeness to build it.

Steven Schkolne: yeah, I've been thinking a lot about sort of what differentiates, where, you know, everyone's I think these days thinking about where AI fits in.

Steven Schkolne: And I think one way of kind of looking at it is, first of all, like there's a big difference between things that have been done before and things that haven't been done before. And when it comes to things that haven't been done before, I think the more things have been done, the more effective no code platforms.

Steven Schkolne: Get to [00:22:00] be like, look at Squarespace, right? Or Wix. You want to do a simple marketing site. You want to do a simple blog and there are actually a number of landing page products. We were using one, I'm blanking on the name right now. So maybe it'll come to me, but those kinds of things, and you know, if want to do a marketing page, most people can get that done with no code, right?

Steven Schkolne: Because it's such a well trodden, if you want to do e commerce, you want to do a store or something like that. There are a lot of out the box solutions for that. But then if you want to build something like say linkedin. com. You know, it's like you won't really find a no code platform or framework that will generate a site, a product of that, that complexity.

Steven Schkolne: And so I think that's kind of sort of where I see, there's two ways that I see the spectrum from where no code. It's more like the closer you get to a linkedin. com or the closer you get to, I don't know, tick tock or something like that. Right. When tick doc came out, it's like the other way it's scroll and the feed and like the way it's all organized.[00:23:00]

Steven Schkolne: No one really anticipated that. And so you kind of need to get into the weeds on that. And that's sort of one axis. The other axis is, is a little harder for me to locate like our landing page. We actually started using. You know when we were sort of pre launch, we had a landing page builder that we used and it was really fast to iterate and get messaging out there and, and just get something up.

Steven Schkolne: And we transitioned over the summer as we were getting a little more serious and heading towards launch, we just started building our own site and we use MightyML to do it, to help us along the way. And it was nice for us to, you know, be able to dog food our product, but. It wasn't just that reason that we did it.

Steven Schkolne: We wanted a certain level of control over the design, a certain level of finesse. And it was just difficult to get that like, just to get that elevation of our design in terms of the visual in a preexisting platform. And that's a really small thing. Our landing page is very small, simple, tried and true.

Steven Schkolne: It'd been done a million times kind of thing. I think maybe Webflow would have been the closest tool for us if we wanted to. Use something no code, but even then there were there were things we [00:24:00] wanted to do that would have maybe necessitated putting certain shadows, like integrating forms and other things.

Steven Schkolne: That we just. Thought it was going to be faster to hand code it. And that's like a more difficult access in terms of, well, yeah, a lot of people have done this before, but I want to hand code my e commerce app. Like why would you hand code an e commerce app when it's been done a million times? But there's still cases where people end up wanting to do that.

Steven Schkolne: So that's, yeah, I wish I had good names for these or good a good language map. That's kind of what I want to open it up to you to just see how you understand it and how we can really talk about. Where these different things fit in.

Ryan Purvis: I think that the challenge if you go back to, you know, early software development days, and I mean, you know, there's that joke that goes around.

Ryan Purvis: You can have a quick, you can have a quality or you can have it cheap. Yeah, we can have two of those three things, right?

Steven Schkolne: Good, fast, cheap. Yeah, good, fast and cheap pick two, I think. Yeah, yeah.

Ryan Purvis: the original days, I mean, everything was a waterfall project. And you would sit and design it for six months before you even started writing the code.

Ryan Purvis: And then the business would be a year ahead or

Steven Schkolne: changed. [00:25:00] You'd mail out the floppy disks. Yeah,

Ryan Purvis: exactly. Exactly. And You know, now you're in this, you know, there was a sort of overcorrection to agile where everything had to be, you know, the perceived thing is every two weeks you're changing priorities.

Ryan Purvis: Well, actually, no, every two weeks you were just doing a feedback loop on what you said you're going to build. It's still kind of following the same waterfall module, but you're just trying to stay closer to the business and that, and there's obviously different permutations of that. And I think what I'm seeing with the low code and specifically what we're doing.

Ryan Purvis: Is the ability to follow more that cycle of constant feedback, constant improvement. But you still have to have underlying platform that's got all the integrations, you know, it's connected everything up, you know, from from a financial point of view, we take care of the regulations and governance, all that kind of stuff.

Ryan Purvis: But the Apple that doesn't have to go and worry about all that stuff. Every time they build the app, all is go and drag and drop and get all that stuff in. And then from a you know, the economies of scale thing, you don't need to have 10 people go build the app 10 times doing the same thing. What they just have to go and do is go and customize their app from a UI point of view, [00:26:00] knowing that the background stuff is done.

Ryan Purvis: And I think that's You know, from our point of value proposition, and I think what's similar for you is, least from my understanding of what your product does, is you've got that learning as well, and you're providing that acceleration for the builder because you've got X number of samples that have shown you this is a good way to go, And then speed it up.

Ryan Purvis: I don't know that makes sense to you.

Steven Schkolne: Yeah, yeah, I think there are. I mean, certainly people are working agile when they're working with code, and I'm sure there's some fintech apps that wouldn't make sense for your platform and what your platform is doing. I haven't looked much into it. It's just basically said, look, there's this whole class of apps.

Steven Schkolne: That all these people would be doing this repetitive work for, and we're going to automate that. And so they don't have to do that repetitive work, financial stuff, like connecting accounts, security like all that, right? And but if someone was, I don't know wanting to. Maybe there's some use cases that may not fit in there, right?

Steven Schkolne: Like, I'm not sure if you support crypto at all, but maybe someone has some, some crypto answers.

Ryan Purvis: so yeah, I mean, what we end up doing is, we will, we obviously have partners that deliver certain capabilities to us and we make, we take their [00:27:00] API as we make them pretty and solve the problem.

Ryan Purvis: So what will happen for a customer is they will come and say, okay, I want to do crypto

Steven Schkolne: and make a module for that. Yeah,

Ryan Purvis: who's your provider? Like, let's go talk to them and then we'll go and see what that, you know, we'll go check out the provider. We'll make sure that they fit with the compliance and, and depending on what the jurisdiction is, the what other services you have in mind.

Ryan Purvis: So if you're going to work with a UK bank, now there's some regulation around crypto in the UK that's coming into play. So there's some stuff to factor in. So all those things will happen as part of a due diligence, due care. Process. What will happen in the end is that when you go and build your app, you're not going to go worry about it.

Ryan Purvis: Every single time you drag on a payment widget to go into a transfer to go buy some crypto, you'll know that when you drag on the payment widget, all the pages you need, all the widgets will generate and create the experience for you. And then all you have to do is make sure the colors are right.

Ryan Purvis: Make sure that you, you know, you can't delete the fields that are mandatory, but you can move them around. Like you can get, so you get the usability thing that you want. So it's your experience. You know that you're compliant and you're regulated because all your providers that you sign up to will make sure [00:28:00] that you are because they'll audit you.

Ryan Purvis: we try to, you know, so there's a sort of double whammy here in the sense of we do make it quicker for you. We do make it cheaper for you because we kind of a lot of the stuff you have to go and learn and redo. And we do give you full functionality because we've done all that work for you.

Ryan Purvis: And then what happens is because economies of scale on the platform. Is you end up with other other clients. You want different things that you could just benefit from because you're on the platform. So much like you would with with WordPress or so. So that's you know how

Steven Schkolne: we're doing it. but you don't use a no code tool to make your platform. No, I

Ryan Purvis: mean, we do have generative components that we, you know, generally we bring in, but It is a dev shop. Yeah, I mean,

Steven Schkolne: yeah, I think there's certain situations where maybe we could think of it in terms of the, there's like that foundational layer.

Steven Schkolne: Maybe there's a bottom and a middle and a top. And so for your product, you provide the bottom layer and then people, use that to quickly and efficiently do the middle and the top. Right. But when it comes time to actually building your product in your shop, you're in control of the bottom layer, but you're bringing in things in the middle of the top, like you're [00:29:00] bringing in components, you're bringing in, you bring in frameworks and yeah, it's maybe that's one way of thinking about it.

Steven Schkolne: No, that's

Ryan Purvis: exactly it. So, so that's, so the platform, you know, the Phoenix one platform in this case is a platform, and then when a customer comes in. And it is a thing to discuss, you know, conceptually all the time with people, this is, you know, internally and with customers is we're not a dev shop to go build you the widget that only works for you.

Ryan Purvis: We're like, we have to conceptually look at what you want so the UK we have a company's house, which is where every single company is registered and, and directors I listed. So when you drag on a company we just let's say company name, you can also drag on the director's widgets or the people's widgets that come in.

Ryan Purvis: Now, each of those things will have logic built in to go and check the minute you have a first name and a surname to go for a company to go check that that person is a valid director of the company straight away. You don't have to go. Okay, they can turn that off on. That's pretty much the thing that capability is available to you.

Ryan Purvis: We didn't go build that favorite for anyone. So that you built everybody. Now, when [00:30:00] it comes to things like you want to go and build your own flow, your own workflow, whatever it is, you have that capability to, but you're playing at this top level. So instead of going into Figma and designing your whole app in Figma, you could design everything in our UI.

Ryan Purvis: Because it's built like Figma and then you basically press play and you know, you've got an app now obviously going to deploy it to the app stores and all that stuff. But you know, the reality is you're building an app as quickly as possible as you could without having to write much code on the code that you do write is ways to this is the sort of low code piece where you're accessing the data model because you want to do a customized greeting based on the time of day.

Ryan Purvis: Which we didn't built, we hadn't built a widget for because we thought, well, if we built this functionality to basically access the data model that's far more functional and rich for a designer than building a meeting widget that will have to be changed. Yeah. Over time. So, so yeah. So your, your analogy of three layers is perfectly correct.

Ryan Purvis: Yeah, that's

Steven Schkolne: exactly good way to put it. Yeah, it's like, could you actually have automation at all three of those layers? I think that's, that's sort [00:31:00] of the thing that's elusive, right? Is a system where you can be, you're not worrying about the infrastructure at the same time that infrastructure can handle anything, right?

Steven Schkolne: Just have automation, like the kind of platform where you could. All of your backend stuff could just be automated and all the UI could be automated. And I think, yeah, it's almost like you have to choose you want to be working on the bottom, you know, have control of the foundation and then leveraging all these things to make it easier.

Steven Schkolne: Even on the foundation, there are a lot of things you can. Anyway, I think I'm getting closer to understanding it. I appreciate this conversation. Yeah, no, no, it's

Ryan Purvis: great. Yeah. And I think, I mean, that's where I think we will, we will go at some point is that the platform, which is extensible already, but you will have partners that will want to build their own.

Ryan Purvis: Widgets, one of the term or, you know, the ability for us to bring in an API is no longer a case of, you know, a development cycle. It's a discovery of the API methods, sucking it in, generating widgets of those methods. And, you know, there you go. You're off to the races.

Steven Schkolne: Yeah, that's an area that's seen a lot of growth lately is various degrees of automation [00:32:00] over connecting APIs together to speak to one another.

Ryan Purvis: Yeah, and I can't believe I'm in the micro sas ecosystem There are just so many businesses that just offer one little service Yeah you know five dollars a month and you can have you know whether history and whether current weather predicted weather and history of weather.

Ryan Purvis: That's that's a service. That's a

Steven Schkolne: business Yeah, it's, it's striking how many, you know, businesses they just, they offer an API and that's the whole, the whole business is an API. So,

Ryan Purvis: I don't know if there's anything else you want to, want to share with anybody?

Steven Schkolne: No, you know, of course, encourage people to check out MightyMeld if you're a front end developer or building custom apps.

Steven Schkolne: yeah, I mean, that's, Nothing else comes to mind. So, yeah, well, fantastic.

Ryan Purvis: It's been great chatting with you. I really enjoyed our discussion. Do you want people to contact you direct on LinkedIn or is a website? What would you prefer?

Steven Schkolne: Yeah, you can just find me on LinkedIn.

Steven Schkolne: And message me there. Yeah, I have a, my last name is it's pronounced Skolny, but the spelling is I'm pretty easy to find online. So just feel free to drop me a note.

Ryan Purvis: Was been great chatting to you and I look forward to chatting to you in the future.

Steven Schkolne: All right. Cheers. Have a great one. [00:33:00] Bye

Ryan Purvis: bye.

Thank you for listening to today's episode. Heather Beckner is our producer editor. Thank you, Heather. For your hard work on this episode, please subscribe to the series and rate us on iTunes at the Google Play Store.

Follow us on Twitter at the Dww Podcast. The show notes and transcripts will be available on the website, www.digital workspace works. Please also visit our website, www.digital workspace works. And lastly, if you found this episode useful, please share with your friends or colleagues.