Hey guys. Today on the show we have a good friend of mine started out as a software developer worked his way up to CT 0 and now runs his own Tech startup and is CEO of intent. Architect we talked about everything that comes with that the hardships. He faced and his journey so far ladies and gentlemen, Gareth bars Beyond coding, a dive into the world of successful people in IIT from your sponsors Z, Bia, creating digital leaders. Here's your host, Patrick akhil. Amen.
Patrick thanks for calling on. Thank you. Yeah, this is gonna be awesome. It's gonna be fun for me. Coming out of high school. I actually wrote in my yearbook, I'm going to be an entrepreneur, I always knew that some point in my career, I want to start a business. It's still holds true. Was that the same for you? You know, the funny thing is that I think the first business idea I had was probably when I was, I don't know, like six
years old. Yeah. And I think that my idea was that I wanted to invent a motorbike really that Ran on bovril. Okay, I don't if, you know what bottle is, but in South Africa, bottle is like, it's kind of like Marmite. Yeah. You know, what mom might is, Right. Nope. Okay. So it's like a veggie extracts kind of weird stuff. It's a spread for bread. Yeah. The day and it's not marmalade. It's like more like a salty. Spread. You put the butter and you kind of.
So, anyway, I, I told my dad when I grow up, I want to invent a motorbike that runs a bottle because I've always my favorite spread. Yeah. So that's basically where it all started. My first business idea. Obviously, I realize how ridiculous that is. It retrospect, hopefully pretty soon. Well, yeah, maybe maybe one damn you after this Allah, I'll give it a go. Exactly, that's the next one. That's the next business.
Yeah, cool man. So you started out as a software developer also had a role as a CTO. Yes. Um how you started your own business. How did that go? Well okay. So you know, the truth is that over the years I actually started a few businesses. Okay. Most of them are just in the graveyard. Most of them are Just like really bad ideas in retrospect. Yeah. And I see when I went through University as well. I did computer, literally engineering.
And I really enjoyed the into the, you know, the climate basically, like all the learning and stuff, but I don't really see myself, like, climbing the corporate ladder in the software World. It just sounded very Bland to go from Junior developer to intermediate developer, to senior to architect. And, you know, that's the Holy Grail. Yeah. And so, when I actually left University, I thought to myself, well, you know, that's what I want to avoid that.
At. And so, the first job I got was ultimately, as a, you know, I just took a kind of it. Have an internship in a sense with a company that was doing some kind of software, but they were like, look, let's just see where you end up. Yep. And quite naturally, so, they had like a, some kind of a configuration system. It's almost it's similar to low code in a weird way, like very, very old, very dirty stuff to be honest, but it was database configuration.
And I find myself just gravitating towards writing. A lot of the Equal and, you know, that kind of stuff and it's almost like the program. In me just started coming back out again. Yeah. And then before I knew it, I was like okay cool. After the after about a year there. I thought to myself juice you know I could thrash these guys because the software so terrible. Yeah and that was my first business was called since nearly
software. Okay? And I said I'm going to basically do what these guys are doing but I'm registered bidder. Yeah, okay, which is a the 23 24 year old guy that seemed like a good idea. And after about eight months of just blowing all my savings are like just building a lot of stuff and doing a lot of Research. I realized that, oh, you actually your sales function to a business.
Exactly. So, I went out and I actually tried to sell it and I got actually quite close like, scary close to actually selling what I was doing. I'm so glad that didn't go through, cause I probably would have been in a lot of trouble because it was no way that I could have delivered who's trying to sell and so, yeah, that business ultimately, like went down and then I just decided at that point. I was like, very clear to me that actually software was my love.
Yeah, and that I just loved building stuff, but I had this deep desire, which I think a lot of Developers. Do at some point in the life. I had this deep desire to to essentially know what the right way to do it is. Yeah. And so I went and I hunted around South Africa and I said well you know, where's the most prestigious consultancy /? You know, software house. Yeah. But I could possibly join and I ended up joining a company which had really, really, really solid
guys. And I was very lucky because all the projects that I had there, I was there for about five years. I ended up in management by the end. And, you know, all the guys I got to work with over the years. Years, which is really, really super talented incredible guys, very strong Architects. And I got introduced to a lot of the concepts and actually did a lot of training there that we've kind of built upon in the business that we feel today. Nice? Yeah, yeah.
How so obviously you joined that consultancy firm but I still missing kind of the bridge. In starting your own company. You join that 45 years. Climbed up the ranks also. Yeah, so yeah. So basically, when I ended up coming at the end of my career there, I was in management. Yeah. And so, therefore I wasn't being as technical as I used to be. Yeah. And I didn't realize it at the time, but I was actually really unhappy. Okay. But I'd come over very super, super challenging project.
Previously that like, would you be doing a lot of management around many, many projects and stuff like that? To enter, I do admit the co-founders to intent architect at the time as well, but I was really unhappy and management. And so that's when the opportunity as a CTO came about. Yeah. And in fact, we already decided that we wanted to start this company at that point. Okay? And so we're you could say that
we were side hustling. Yeah. Towards the end of that part and I was, when I joined the company as a CTO, we already actually had something going. And essentially the story was that, that company had to the Anywhere on the CTO. They had to do a lot of new
software development. Yeah and because of that there was this opportunity where we could take this tuning that we built, which we ultimately built based on, you know, because of the problems in the software industry that we had been experiencing over the years that we were working as Architects at
the consultancy. Yeah. And we took this and said, well look, you know, we can use this and I checked with the other guys who in as part of Mexico and I said, would you guys be interested in giving this ago and they said sure it sounds great. Yeah. And it absolutely Clearly dominated. You know, we ended up rebuilding five years with a software and like six months, I sewed was incredible. What we are able to achieve and, you know, everyone was just flying at the quality of the
system was so much better. And you know, the consistency and the architectural structures everything like that, there we were building art was just, you know, it was incredible. And I could, and I could sleep very well at night. Even though I had, you know, quite ass, like, a bit of a junior team. I could sleep very well at night because I knew exactly what the software look like.
Yeah. And so when we, you know this, Progressed. I was there for about just over two and a half years, I think it was and before I told the guys like, look, I'm going to be moving on to building this company and they were very, very supportive of that actually gave them an entire year to figure out what they wanted to do. So as I guys, in one year's time, I'm going to be going full time. It's this business.
Exactly. And and they, I mean, they've been basically a paying client from day one. They have still with us there. Yeah it was your first client, was our first client ultimately at the nice but you built it then, let's say, as a side hustle, obviously you had a job. Yeah, get this more on the side. Probably with the co-founders. How many co-founders so were three co-founders all Engineers. So I mean, if we kind of, you know, wind the story basically
back to the beginning. So we were all basically civil engineers working as architects in this consultancy there and we were managing you know quite a variety of different projects at the other day. And so what we were seeing was that you know, I mean in terms of size you're dealing with, you know, I'm talking and ran tombs here. So you'll have to do some division. Yeah, that's it was like, you know, 30 million rent, you know, Ten Men Dev teams, two and a half.
Years with q&a's and Bas and project managers. And everybody on these teams we're dealing with some really large stuff all the way down to you know, four Man team, you know, five months delivery you know, smaller stuff.
Yeah. And so what we ultimately realize what's in the software industry there is essentially a set of Trends. Yeah, that everybody is experiencing and, you know, we've had an opportunity now in the privilege, in a sense to have spoken to so many developers and so many Architects that it's so clear to us how Universal these Enzo. Yeah and so when we analyze that and we looked at the situation, the first thing we realized was that actually software development from the perspective
of developers and the architect is actually a very repetitive process. Yeah. Okay. And it's not that let's just forgiving sake. Say that and developers typically don't repeat themselves but let's just for argument's sake. Say that they never write the same line of code twice yet. It's still very repetitive because all of the tasks that they're doing even though to new use case is very similar to the previous use case because it follows the architecture, follows the pets into the team
has agreed. Upon. So in this we saw a huge amount of waste. Yeah like a we estimated probably between 70 and 80% of developers time is all of this like repetitiveness that's surrounding the use case at the Toronto Chief. So there was the one side of things that we realized. The second thing that we realize was you know when a tea when a project starts you end up with a certain velocity. I mean this is to quote the agile guys.
Sure, you know, the velocity of the team starts to come out and usually it's very very quick in the beginning. So you know about the four month mark That's when you really see the team is started to chug. Yeah. And Are you know, outputting use cases pretty quickly and things like that but you can come back and you can visit that team you know a year and a half later. Yeah. And they can be massively different results depending on the project depending on the team.
I mean we have you know, spoken to people who are telling us that you know back, you know, when they started their project, just two years ago, you know, they were going things that used to take them a day to do then and are taking them for 56 days to do. It has point. So there's deterioration in velocity is something that we notice in the projects as well. Yeah.
Yeah, and it's almost like you can do a lot of teams with through discipline, through architecture, through certain structures in the code bases and things like that. They are able to Stave off this deterioration by almost taking a velocity hit in the short term. Yeah. And you know, there's a lot of documentation that Martin Fowler has backed this up. So when we analyze it we thought
to ourselves. Well, what is causing this deterioration of the software and, you know, the first thing that Kmart was and was so very clear was technical bit. Yeah. Okay. Now everyone knows what technical debt. Very well documented, but what we noticed more than anything in software is that technical data something that just seems to be growing. Exactly. So it's continuously growing in the system.
And so the agile guys are telling you, we'll look, you know, for every single Sprint. We highly recommend that you bring the technical data in. Yeah. Okay. And we recommend that to, I mean, that's a, you know, that's the only way to actually to avoid I from the coming out of control, but exactly the thing is that in a lot of ways, when you look at it really, as developers, what we're doing is trying to stop the bleeding from getting out of control but it Is still growing in the system
sets. The first thing is has this technical data. Steer it's growing and storing to compound in the system. The second thing we notice is that there's lots of inconsistency and start to develop in a code base. It's like the entropy, it's a form of technical debt. Yeah. And the thing about inconsistency, in the way, people who think, in the within the way guys are doing things, you don't like in how each case, it use cases implemented.
This always just little inconsistencies that are coming through and it's not really anyone's fault. Sure, the first thing is that like, everybody on the team doesn't understand architecture. Exactly. Exact. It's impossible for them to the different human beings, but, you know, let's just say that on average. It's there's an overlap of a
certain word. There's always going to be someone who doesn't want everybody on the team, who just has some little bit of a different view of how things are
done. Yeah. So that's the first sign of it. The second is that this different skill levels, I mean, that's just, you know, there's different experience levels, you know, to the developers and then, of course, you know, besides the fact that maybe they've got different styles even you know, the team can also realize that there's better ways to do things, you know. But then it's very expensive to go back and fix it.
Also, you just like what Well, and so does if you extrapolate this problem with kind of compounds as well in the system. So you always have the gold versus new. Exactly, exactly. So you got those technical debt compounding, you've got this inconsistency compounding. Yeah. And the other thing that we realized was that there's an architectural rigidity, okay. Suppose a certain threshold making certain architectural changes in the software is very, very hard.
Yeah. And, you know, probably one of the biggest examples of the so like a team when they build a piece of software. Yeah. If they know what they're doing, they It's a non-functional requirements and they'll say, well, you know, I think that this architecture is going to work for us. Exactly, but those non functional requirements, can shift the security requirements, can shift hosting requirements, can shift certain even like, you know, performance requirements
and things like that. Availability requirements can shift. And so what ends up happening, if you think about it, is that then the architecture doesn't necessarily support those non-functional requirements. Yeah, and a great example of this is actually the move to Cloud. Yep. Okay. Because Cloud, if you think about how many systems will architected For on-prem hosting. Now I have to be re-written. So this architecture rigidity is so huge. I mean, this is a big example.
Yeah. You know, that when Clark came along, it's literally still causing. I mean, the number of companies we talked to the Discerning well right now. We re modernizing, we want to be cloud cloud enabled. Exactly. And so they're basically means we're rewriting our types of software. Yeah. You know for the cloud. So that was the next thing is this architect rigidities. A huge Force as well. And the sad thing is this really bothered us?
Is that this applies to Technologies to so you build today A on a set of Technologies which may be obsolete. Exactly. And so, you know in a few years time it's just not the latest one and developers always want to work on the latest technology. Number one, they want to Leverage What the technology offers. Exactly. Okay, even though from a business perspective, you like look at that wouldn't make the business, a much better business at the first day, but developers want to do that.
So it starts to component to Alma's a human resourcing issue because you can't keep good developers if you're not giving them what they want the day. So this is another problem.
And so if you look at The big picture of basically you could look think of it. Like the painting that we've basically painted at this meal is that this is what we think of as the tendency towards Legacy. So you know, the academics will tell you all the second, you write a line of code its Legacy but developers don't see it. Like that developers think to themselves. This is not a legacy system.
It's still fresh. Okay. But then they've got this funny thing and it is no, you can't say, well, it's two years old, if it's Legacy words, 10 years, all different Legacy. So really it's a feeling that developers have in, it's usually because the technical debt is getting out of control. Is very inconsistent, very hard to maintain making changes is difficult. There's certain may be non-functional requirements that have shifted and we call makers architectural changes.
So, we're having to, like, Hackett adding to the technical did get around this problem. We're also stuck on all Technologies and so this is kind of and this is actually the fate of almost all software which is very said and it's almost like something that the whole industry just ignores and in fact I think some people thrive in it they're like well this is
good news. We're going to be doing a rewrite every few years Cedar. So and you know developers does love having that blank slate because of course were never going to To make the same mistakes we made last time which is probably true. Just going to make a whole new set of mistakes, so that's typically how it goes. And the final thing that we picked up is that the there's no blueprint, is no blueprint to the systems that we building.
Yeah. And it's, you know, a lot of ways and I, you know, we were talking about this the other day, you know, in a lot of ways, it's like a new Joiner comes to a project and it's they have to basically walk into some walking into Skyscraper, no and the dev team system while, you know, the blueprint around, you know, The only way from to really know what the design of this app is is he's got to go break into the walls. Exactly check.
Okay, so the plumbing went through, there goes the ceiling electrical cables down there and then of course you go to the second floor and it's inconsistent different. They did it differently. Here. Third floor different and so it's really hard. You might get an outdated blueprint. Exactly. And any company that gives you a piece of document, well, you know, sometimes firstly, it's very expensive for developers to make documentation.
Yeah. You know, they can spend almost longer building the document than is coding it sometimes, so that document can be really expensive. Civ. And then the second thing is that, if it doesn't reflect the underlying code, it's worthless. Exactly. Okay. Because now you're looking at a blueprint, that's not true. So that's, you know, and of course, update documents is also incredibly expensive more expensive than updating code.
So I mean, this was essentially where intent architect started. This is essentially where the problem space that we found ourselves in. And we said to ourselves, well, you know, we need to solve this and we looked around. We saw the low code guys were there you know they may indexes that are systems that are piensa sales forces that you know there aren't but Is that software isn't a cookie cutter? Mold, you know, it's not like you can't not all software
follows the cookie cutter. Yeah. And they are offering a cookie cutter solution, so if you're doing what they support, you are the happiest guy, exert a second, you want to step out of that or you want to control the underlying architecture. You've got a funny non-functional requirement. That you have to handle. You can't do it. Yeah, so we saw that. And we saw all the different ways that guys are trying to
handle these things. And, you know, where all the different patterns and DDD and microservices, and where there's all fit in, but nothing was really ultimately solving the Mental issue. So when we boiled it down, we actually realize that at the center of it all is an is an issue that is also Catalyst to everything. And ironically it's code. Yeah. Okay. That's the ironic thing. And developers, always look at us when we tell them this and they're like, what do you mean it's cold?
It's like, no, no code is beautiful. We love coach. Okay, don't get us wrong. We love coat. It's just how much code. Yeah, we have to deal with. Okay, and we call this the weight of code at the end of the day. So because it's like, it's got a weight to it. Yeah. And you could think of it like sand in a way And where's developers basically have a shovel. So you just end up with these mountains and mountains of sand all over the place and all you've got is a shovel to hands in a keyboard.
That's really your tool. And so this weight of code is actually causing a lot of these issues. So think back to the technical debt. Why does technical debt exists? Yeah, well it's because you know, there's too many lines of code that we have to change in order to get rid of that, you know. Correct. The design get was a hack and give her the technical debt at some point during your complexity increases such a point that it just gets a whole operation exactly change it. Exactly exactly.
I mean, it's a certain consistency too many lines of code. Yeah. Change that in order to get the system to consistency that, you know, to upgrade this technology. We've got too many lines of code against this API, the next version of the API breaking changes, we would have to change, you know, 10,000 lines of code. It's going to take us the team's going to take them three months or six months or whatever the time is now and the business. Like, I'm sorry. We can't afford it.
Exactly. You know, even though the developers want to do that, the business would love to do that. Yeah, but no one can afford six. Yeah, okay, so that's really where. If you look at it, it's the fundamental. If yours are opinion as a company, we have analyzed. We think that there's essentially two problems in software to fundamental problems in software. Yeah. And the first is weight of code, okay? Which is almost like your inadvertent complexity, okay?
And actual complexity, okay? So complexity of the system is like what are non-functional requirements. One of the functional requirements, that kind of stuff. Yeah, so between those two and you could map every single thing in the software industry are trying to handle one of those two things. You know, what is microservices trying to do? Microservices, simply trust trying to handle weight of code. That's it that's all is trying to do because it's definitely
complexity. Exert, taking your complex problem and turning it to disturb its complex. Exactly. So I mean and you know, I'm a huge fan of microservices, okay? At the end of the day because it does force a certain way of thinking which is actually quite
powerful. But at the end of the day, it's you know, D D. D is all into complexity handling and it does do some little weight of coat because obviously the sit any kind of separation of concerns in a kind of Are coupling is good for weight of code. Yeah, you know, because then you change less to get certain changes in and that's the key circling back then to yes, yeah, yeah. So coming back to intend
architect. This is essentially what we decided we were going to do is we were like we're going to tackle this problem space. Yeah. And so when we you know, myself and the co-founders we said well let's you know let's build a company that's going to solve this the way that we did that was we said to ourselves. Well you know let's imagine a world of software. We're div. Yeah, from the perspective of a developer, as an ideal world. Like, how would it look in an
Ideal World? And we came up with a few set of ideals or principles, okay? And the first one was what we called code weightlessness, okay? So the inverse of code weight of code exactly. And code weightlessness. You know, in the most, Layman's definition is basically the ability for developers to be able to change 10,000 lines of code as easily as just changing tin. Yeah. Okay. So that's code weightlessness.
The second ideal that we see Was really that you should have what we think of as a Agile. Auto, not an agile architecture, free architecture agile architectural. Get to that second butter free architecture because whenever you come up with an architecture as a team, you come up with some kind of a you know a structure that you believe is going to meet the non-functional requirements of their project.
Yeah and at that point onwards it is actually a lot of work that goes into every single use case to put that architecture in place. Sure and this is what we estimate to be around, you know. So if you see on the backend you're probably looking at Durant, you know 70 to 80% off the work. Okay, maybe more. Depending on the project. Sure. It can be a hell of a lot of work. Depending on how much complexity you trying to handle the clay do. So that's basically the big
thing is that I kill you. If you got accomplished project, you tin would tend to have a complex architecture. Yeah. Okay. And so, you know, having this free architecture was an ideal for us because once you know what it is, surely, you shouldn't have to pay for every single time. Now, of course, paying for a new use cases is expensive, but actually shifting and architecture as use cases need to change here. Is five times, more expensive Foundation. Yeah, it's just changing code,
is so much harder. I'll so yeah. So that was the second ideal. The third ideal? We set out once this idea of having this agile architecture. So sure, you've got your free architecture now, but an agile architectures, the idea that should something changed later, we realize a better way to do things. They're not a function, requirements shift. We need to bring in a cross-cutting concerns, something like that. Should we have that?
We should be able to make that change in the system, regardless of how old that system is. So that system could be five years old. It could be thousands of use cases could be a massive system and you know, successful systems do tend to give large. Yeah. Because you do tend to enhance them and add Lots, not to Features. Exactly. And you know, while you're adding features in a linear sense, they're all interconnected so your
complexity skyrocketing. Yeah. So ultimately, that was the next one is to say, well, you must be able to change things for free, and then we said, well, take that one step further, you know, you should be able to extrapolate and say, well, then that should be applied to Technologies to. Yeah, we should be able to stay on the cusp of the latest Technologies. That's an ideal as a software developer. I want to be able to stay up to date.
Yep. And that's essentially what we decided from our deals perspective to build a company on the one loss. When I just wanted to mention is that we also said that a system should be self-documenting. Okay. And what that means is that you should have a blueprint for the system. Yeah. But the key is that that blueprint must be true. Exactly. The underlying code is always reflect the truth, the truth, if
it doesn't, it's worthless. So at least a contract level because I mean, if you think about a blueprint, that's what But it's a contract for what you want your system to be about. You know, the fact that you just say like you know wall from here to here red brick, there's Plumbing configuration that electron configuration, you know, and in the guys go and build it. So ultimately, you want to know that if I've got this line here that that is the truth almost
like in the code base. So that's essentially the ideals that we sent out. And then, you know, we built a lot of the system, we built a lot of this originally for ourselves. That's the truth is that we said well there's must be a tool for us. We built a fair amount of it, you know, up to a point where it's like a That used to run, but a lot of the principles were in place and anoxic, oh, we had this. And this is where I did the CTO role.
We ultimately brought this in and this is where we were able to leverage this part. So, because of the code weightlessness and because of the free architecture will just saved huge amount of time exact. Hey, we were able to fly and also we have the quality because everything was perfectly
consistent. We also had These Blueprints because now we could see the systems and that made it very easy for us to reason about what the changes should be for the next feature because I mean, The biggest problem. Sometimes you sit in a room with two old fellow developers are not everyone's on the same page. Exactly. And then you set the arguing about something you like, I'll show you in the code base. Often spent, you do, you know that that argument happens all the time?
So I mean, yeah. Just to tide back, you know, kind of like a long-winded way of how we got to this company. Yes. Yeah, but ultimately, we, you know, when when we saw the success that we had, you know, at this at this company was the CTO. You know, I said this thing's got legs. Yeah. And, you know, we did a little bit of a push out too. You know, just people that we knew and we said, hey guys, we've got this thing. I mean, it was still, you know, version 0.8 or something at the
time, you know? And we actually ended up catching the tension of this this individual who was on a project at one of the bank's. Yeah. And he chatted to the guys at the bank and they were a little bit of trouble and they said, well, you know, there's tool could actually help us in the space. Yeah. And so they brought it in and they were able to get what they wanted at the end of the day. So they've been a client of ours, you know. So those those fines or to the One, exactly.
So, the funny thing is that I remember when I decided to leave the company and go full time into this business. I had this idea that we were just going to hit the ground running. Yeah. Okay. And I think of anything I've learned building. This business is that you've got to keep a fridge jam-packed with, you know, ready and stocked with Humble Pie. Exactly. Because you're going to have to get that apple pie Arts. You can have to cut yourself a, slice it up and you're gonna
have to eat it all the time. There's never going to be a day where it's just going to like all like things can start falling into place. Moment. You get excited about it. Just wait, you're gonna have to get that humble pop fridge. You're going to eat it. Yep, so that was, you know, when we decided to go to market straight afterwards I went and I set up lots of meetings and I basically went through my network and we got no one.
Yeah. Not a single client out of that and I mean that was such a blow think that's a punch in the gut, such a punch in the gut. And I think it's really because, you know, being so new to business you don't realize how hard it. It's like there's not you don't walk out into the business. World and just start selling the exact, you know, especially if you've got something that's unique, you know, like I was like, well, we haven't heard of you guys. That's the first problem.
And there's a technical complexity there as well because people need to understand it before they can actually put it to practice. Yeah, big topics. Exactly. I mean, we had no idea how to explain this this product probably up until the end of last year. Yeah, you know, we were just explaining it in every way we could think of and it just
wasn't hitting home. Yeah. And so it took us a long time to actually figure out you know if we have a conversation with a company How to actually explain what this tool does and how it can help your company at the other day. Yeah, that's something you need to hold and probably and you need to make it razor-sharp. Yeah, yeah. Now like I said, man, it's just been. It's I think one of the biggest challenges has been trying to figure out how to commercialize,
something that you don't. I mean, if you say like who are the competitors to intense architecture? Like, that's a bit of a hard one. Okay. Because no one's really in the same space. Is US sure? I think that the low code guys, you could say, oh no, are you guys a local? We're not a local platform. Yeah, we're 100% code platform. Before we get into that. Yeah. You know, I know but we haven't really laid out on what it actually does. Yeah. You've laid out the problems.
Yes. Yeah. Okay yes, we're getting two competitors. Yeah, sure. Okay, so I mean, just to give an idea of what intent architect is. Yeah. The day. So it's, it's a software tool for developers and for Architects. But I think that there's a few things that are worth just knowing about the first is it's not a local platform, okay? So so it's also not That introduces runtime dependencies or it's not a framework the
other day. So, in a lot of ways, it's not something you build on top of. So you don't build on top of intense architect, you build with intent architect? Yeah. Okay. You know, so an example would be, if we go back to our developer analogy of developers having shovels. Yeah, it's like you go from a shovel to having a tlb and, you know, one of those tractors that can pick stuff up and exactly. It's got like drills and electrical and, you know, stuff
like that. So, you've got automated tools, okay? That just do the work for you. So that's really the thing. King, and a lot of ways that, you know, we explain it to developers is that the at the footprint. Okay. If you want to think about it, like the footprint often tent? Architect is the same as an IDE. Yeah. Okay. So if you think about what an IDE is it something that's installed on the local machine.
It manages the code base. So the files that make up the code base and it can do, you know, some pretty Advanced Management. So for example, you could rename a method in your loving sister and then it'll rain, if that method is called in 20 files, it would go to update all those 20 files for you. Okay so that's amazing. I mean that you otherwise I have to go run through each and every single file. Yeah, so intense.
Architect at the same kind of footprint in the sense that its installed on the local machine and it manages the underlying code base alongside the IDE but it's not a replacement for an IDE, okay? So that's key so that the guys want to hold on so you're saying it's an idea it's like no it's not easy. It's not a replacement for us. Yeah, it's impossible. It's something exactly.
It's basically the developer is going to be continuing coding using the IDE which is where you'll spin still the majority of his time. But intent architect is where he is designing. Okay, okay, so he designed And his blueprint ill intent architect and the two of those tools together in a way and we use quite fancy mechanisms at the end of the day. It will, I mean, one of the things we do is we call ourselves a next-generation code
automation platform. Sure. And and the reason for that is because yes, we are managing code and we are doing automated code generation which is something that has been around for eons. Yeah but we're doing it in a completely unique way so that the developer and automation tool can actually coexist. Yeah. Okay. And that's I think that's really probably what makes it practical at the other day and it's Being one of the major reasons why
we've had so much success. Yeah, up until this point. Cool. So let's put it in a you can use case, I want to design something that stores a user in a data base. Do I first go to intend, architect model, my business domains and then go into my ID or how would I put it to practice?
Yeah so I mean if you think about it traditionally what guys would do is the first thing they would do is let's say and you use case came along, okay the team or at least like the more senior guys in the team probably would go into a white border. Room and they would start whiteboarding. So there's a cool, we've got these entities or lay them out to the Whiteboard, they'll draw relationships between them, they'll say, well, this gets this is what gets persisted.
This is what we're going to have. These are the services we probably need to set up. Maybe this is the front end, maybe we're in a micro service architecture. So these are the events that will publish and they kind of lay all of that art.
Yeah. And then they will go and they'll take screenshots of that with their phones and they'll hand it over maybe to the PA or if it's very technical, they'll keep it for themselves and they'll just talk about it and everyone's on the same page and they'll go and like write it. Yeah. So, The difference between that and, you know, a team that uses intense architect is, they'll also whiteboard sessions, but then they'll take that white board design in there and they'll capture an intent
architect. So, we've got, we've got powerful modeling capabilities. Yeah, so you can model out exactly what you wrote on the Whiteboard, okay? These are my domain entities as their relationship. These are the services, the venting, all of that kind of stuff can be modeled. Yeah. And so, by modeling up that contract, we then can use intent. Architect to actually automate that architecture that holds it all together. And so, that's the second part of intent.
Architect is what we call pattern reuse. So you can have patterns that have been installed into that kind of work space and we call them modules and ultimately those can output the code for you exactly the way that you want it. So something that the developers are controlling, it's not something that we prescribe we're not a prescriptive tool at the end of the day. Yeah. Exact as a makes it kind of via your comments in its framework agnostic and it's also code agnostic. Yeah.
How does it do that? Just kind of high over. Okay, so okay, so it basically, you know how intent on architect He works. Yes, is you've got these three mechanisms which you could think of as having you know, they're essentially you could say three pieces of same puzzle, okay. And the first is, what we call this pattern reuse, which is the modules that I just mentioned. Exactly.
So, if you look at any architecture, you know, you could say, well, you know, in a typical very kind of another architecture or maybe you're following like a, let's say, a Robert Martin, your Uncle Bob's clean architecture, you know, you'll say cool, well, we've got some kind of controller pattern, which is handling, the the calls from the API. I calls at the end of the day, so it's handling that then we've got a dispatch to the business logic, which is using a mediator
pattern probably. So it's commanded queries for the cqrs and then you've got your entities, you've got maybe repository patterns, you've probably got some kind of an orm in the mix of using a relational database and you know maybe this Factory patterns and specification patterns and all
kinds of stuff. Now, all of these patterns, ultimately, you could idea behind pets and reuse is that you could take any one of them and you could turn them into a module, which essentially automate that pattern going forward. You can get it for free. So that's the first mechanism, okay? But to make that possible, we've got two other mechanisms. The one is what we call code management. Yeah. Okay. And this is really an advanced form of cogeneration.
I think that's quite interesting, but it's little bit more Technical. And then the last kind of piece of the puzzle is the modeling systems, the ability to describe a blueprint of the system, okay? And I mean, to do a little, you know, understand, you know, kind of understanding the automation side of things in terms of the code management. Yeah, is that That you've got these. I mean we're not language agnostic completely. Okay. I mean intense. Architect can automate any file sir?
You are language agnostic for the most part but code management is actually something that we have particular support for a set of languages which was Squirt. We are expanding on. Yeah so at the moment we're very very much in this eShop Java typescript space with a vision to go into the go and Python and so on so forth. And it's really just about kind of, you know, choosing the languages which are getting the most popularity amongst the
divs. Sure. And so essentially what it is, at the end of the day, is, if you think about. So it's probably easiest way to describe it is just to talk about code, generation code Automation in the industry. Yeah, and then to compare that with what code management is sure. So, if you look at the industry at the moment, you've essentially got, you've got two types of code automation. The first is scaffolding sure. Okay.
Now, everyone's super familiar with scaffolding, it's like any kind of, you know, command line interface where you're just punching in some, you know, create me a new this edit just drop some code in your code base, or you've got a CLI, you know of Snipping Tool something like that where you can just snip it stuff inside of your your IDE. So any kind of, you know, once-off generation of code, you know, to speed you up. Yeah, is essentially scaffolding
sure. And that's exactly what it does. Is it speeds the developer developer up from A to B in a short period of time, it's not dangerous because assuming they get what they want, let's just go ahead and assume that assuming they get what they want. They are able to change it. Exactly that it doesn't have any Long-term benefits. Okay, okay. So that's the problem. That was not a problem with it, but it's just that it doesn't solve any long-term issue.
So if we go back to our things about technical debt. Yeah, you know, ultimately that code is still the liability of the developers. Sure. So, you know, and that's the truth, it's a code, is a liability, the more you have, the more you have to maintain. Okay. Okay, so it's not an asset. The blood product is an asset to my code is the liability. Sure, so. So that's so scaffolding. Great shorts, make saturated. No long-term benefits doesn't really fix our long-term problem.
We described earlier on the flip side. Side of that. You've got this thing. We call really continuous Automation. And essentially, this is something that is usually done by the dev team and it's very attractive in some senses, but it's basically got a downside, which is so huge that it oftentimes invalidates the approach. Yeah. So essentially the mechanism is that the developers have written some kind of a little you know, system or an engine, which is piping metadata.
So like an easy example would be you know database schemas or stack of files or you know some kind of specific Except that they've created, maybe Json objects and stuff like that. Yep. And they're piping this metadata into a template engine which is are putting code into the code
base, you know? Now if it's done really really badly which is most of the time it's like this single file that looks absolutely computed and you don't want to open anything an IDE, you ignore like here, be dragons. Yeah, that's basically the problem with us and that's a, that can be a nightmare in of itself. But if it's done really, really well, then it'll be individual files and they'll look exactly like a developer wrote them. Yeah. Okay.
So there's you know, from that. Perspective, there's no issue but and there's essentially there's two sides to it than I that I was mentioning earlier. And the first issue is well, at least we'll let me rather go through what tracks developers to it. So what is attractive about this approach is number one using automation. Yeah. Okay, which is something that every developer loves so using automation, which means you're saving yourself a lot of time. You don't have to write that
code, okay? You just say, well, create a new database object in the database. This is my relationships. He's my foreign keys, but blah blah, and boom. All of a Gets every or entities, maybe you're over in mappings and maybe repository as well. Okay, which is very common to see a lot of this kind of stuff and what's really powerful about it? So, beyond the fact that you're getting this cook, those coaches are about that.
I love talking with my exactly. The, the beyond the fact that you've got this like Automation, and you've got this acceleration. Yeah, the other thing that's very attractive is let's say, for example, you're automating some kind of Technology. Okay? And let's just use the example of Of an object relational mapper sure. No worry. So let's say, for example you've built it against version 5 of whatever or emu using, okay and version 6 comes out with significant breaking changes to the apis.
Yeah. Now you want to stay up to date. So, what do you do? You go to your template and you shift what your template outputs to now, adjust to the new API, okay? You hit it again and it just overwrites. Maybe you could have a thousand entities in your database and you change 10 lines of code and you just Updated 10,000. Yeah. Okay. And they're in, if you become tied back to what we talked about earlier. Yeah, Varian is the most basic form of code weightlessness.
Exactly, better D to change 10 at update, 10,000. Yeah, 20,000 on and also self documenting. Well, it's not self dot, it's a little bit, like, if you want certain that, if you exactly, if you consider your database to be your document, okay relationships, then that is self documents. Yeah. So as long as you've got that document, that is to some degree self documents exactly. But we're taking the the Swagger file example. Well, swag LEL your Swagger.
It's, I mean, it's regular is a document as well. It's either the truth at the end of the day, what you want is something that is true to that line code base and by having that document and having a continuously update, it means that you can look at the Swagger document or you can look at the database or you could look at whatever you're looking at from, you know, maybe you doing it in xmi. So you're exporting it from some other modeling system or
something like that. And you can know that because of this templating system that what you're looking at, is the truth. Yeah. Yeah, that is soft document. Yeah. So, I mean death, I agree. I maybe it's not like, I wasn't a green 100%. I told you do that. Exactly. So that's the upside. Sure. K and the upsides very attractive. That's what pools. That's what draws guys in. Yeah, the downside is massive, and this is where cogeneration in the industry has a very, very bad name.
Okay? And it is, the downside is dead. It's very, very bad. And this is basically illustrates probably easiest, just to illustrate with an example. So let's say you had to make a change in a method. Yeah. Okay. In one of the files that was being managed by this template. Yeah. Okay, so you go in there and you make some change as a developer. And let's just say it is 100% legit. Like, you're not trying to be funny. You think this is a legit change?
You need, is, you need us? Yeah, which invariably is going to happen. Yeah, because software is not a cookie cutter. That is always something that you want to tweak or optimize somewhere. Yeah. And what happens, the templating engine get kicked off again because of course, it's continuous. Exactly. Top again and it just acts out your changes on.
And if you can't get around this, and I know in like, for example, the.net space, they they tried bringing a partial classes shirt in the Java space, a lot of guys use inheritance. And I mean, they did basically you just convolute your code more and more and more. So It ultimately just a hack at the end the day, but you can't really to code more and more try, get around these problems that the automation engine is causing it is always a breaking point where you are not able to
get around anymore, okay? And it's at that point that the chair will fly across. Ross the office exactly. It's at that point that someone is strangling The Architects and telling him what he thinks. Yeah. Okay. And so this is this is the Dark Side of fat that in basically invalidated or at least for the most part. It keeps it in very specific spaces of the soil so that's why you still see guys, having some little success with for example database 20 remapping.
So you'll see guys having like Swagger automating their proxies. Exactly they know where to apply it where it becomes an asset and not a crutch exactly a Europe. Buying it in a space where it can't be dangerous. You're not really going to want to tweak things that you hope you're not going to want to tweak things.
That's, you know, there's other ways you can maybe intercepting, so make your changes through interceptors, but you still are sometimes having to convolute the software a little bit to get around your automation system. Yeah, so tying it all back to what code management is. Yeah, is code management is system which we envision. Where basically, we looked at the landscape and we set ourselves, you know, we really like this code weightlessness than exactly can see the power
here. But there's downside is so massive. That you know, no one's going to accept that. Yeah. Okay. You also can't, you know, especially the closer you get to business Logic, the more that automation systems start to break down, okay? And so, when we looked at it, we said to ourselves. Well, how do we get the best of all worlds and just kind of eliminate the downside? Yeah. And essentially, the idea was we said, well, okay. Let's develop a system which could do that and that's what
code management. Ultimately is. It's a taut. It's a, it's a term we've coined, okay to try and differentiate it to the guys considerate, different too. Cogeneration. And I think this is maybe jumping a little bit technical, so it will just kind of brush over it quickly.
Sure. But essentially how it works is we use a combination of abstract, syntax, tree, potting and algorithms to actually understand the code in the code base and the code that's coming out of the automation system at the same as code, understand those the same with the developer does, okay? So we see, for example, if you're looking at like an old language, like C shop, we will see the classes, the methods, the constructors, the 30 is the field, we see all of that stuff. OK.
And we see that in the code that exists to and then with algorithms, we can make Intelligent Decisions as to how these two worlds must be joined together. Yeah, so the idea and the principle is that by using it automation system, it never puts you in a worse position in. If you wrote it all Yourself by hand open and you can see it is obviously if that's your first principle and also of that principle is that whatever is automated should look like I wrote. Exactly.
So there's a ton of to you know, complimentary principles. Yes. Code must look like a developer eroded. That's number one. And the second thing is that I'm using an automation system, it should never run my day. She never fight this thing. Should never become that. Crutch It should never. Well, it's not, it's not a crutch. It's just like, it's just massive liability that can come into the system in the day. But so just to give you an idea kind of going back to our use case.
So let's say, for example, the developer wanted to make that change at the bifida. Yes, the gentleman change, okay. And they went to their made a change. Their automation engine runs again, take the change out. Yep, with intent. Architect. We could say, for example, in C sharp, you could put a attribute over that method to say in take notes or Java. It's an annotation in typescript.
It's a decorator. Yeah, you know, so whatever language we find a way to add metadata to the file and you wanted in line there because then you can see exactly what's going on. You don't want it hidden somewhere and you don't know where exactly and that level of granularity can be applied anywhere but it's essentially an override. If for example a put this you know attribute yes a ignore this method from that moment onwards that method but only that method.
Is now under the developers control? Yeah. The rest of the file is still under the automations control, which means that I still got code. Weightlessness over that entire design. Okay. Which means I can still change it holistically from one place. Exactly. And like I said, you can apply this override at any level, you can apply it to, you know, the class or individual methods, or anything like that.
Yeah, another example is where you say and this is where the granularity gets very fine as you could say. Well actually, I want intense architecture manage the signature of this method. Yeah. But not the body. D. Okay. And what that allows is it allows let's say you automating a whole world of infrastructure around a certain contract that your blueprint is describing. So let's say for example you're describing your business contract or Leisure service contract.
Yeah, for this is what I will expose out as my dto. This is kind of the operation. Yeah. You could say, well, I'm going to automate all the infrastructure but then at some point, we got to get into business logic coding. Now, business logic is not, it's not great to design that in models. Exactly. Because it becomes it becomes Like a big bowl of spaghetti at the end of the day. Like, it looks like a circuit board. Yeah. Two for loops. And it's like what is going on here?
They're trying to wrap your head around that, but if you saw the encode is just so obvious. What's going on? Yeah, so code is still the best way to handle that kind of complexity to still govern the thing. So that's why you don't need answers. Yeah, exactly. That's why we don't see the below code guys, really winning on this one. You know, use code is still gonna win when it comes to
structuring business logic. You've got all the patterns, you've got, you know, the whole Gulf pets and said to you can use Decorators and strategies, and composite patterns and all kinds of things to handle your complex business. It seems. And ultimately, that's, you know, with the was saying, like, look, I want you to manage the signature. Yeah, you can end up tying all of the infrastructure to the business logic and you've drawn A Line in the Sand and said, cool.
At this point, I'll take over, I'll take over. Yeah, and so you can have the automation run all the way to the point of the business logic and then the business logic, you know, the developers running that kind of stuff. Yep. And then it can hand back over to infrastructure, okay? And by doing That you can end up automating, you know, it said 80% of a back-end 85% of a back end and you can see how much I mean for a lot of people that use that on new projects. We just see them flying.
Exactly flying. Yeah. How do you manage those overrides that? I'm guessing you have something in place that tells you. All right? This is where you've put your overrides. So when you rerun your generation, this is what will happen. You just put it in line in the, in the code. Exactly. Yeah. So if it's in line in the code, it means that there's no confusion now and also you don't want to be jumping around so you don't To have that hidden in the background, you're like, okay,
is this thing over it or not? It's exactly like that. Yeah, it's not a runtime dependencies. Like an empty metadata. It could be a comment. Yeah, you know, it could be anything we you just need something to indicate. Hey, you must stop here. And I'm a developer is going to take over this or this is the rules. And of course you can you can instruct the system in a lot of different ways. Yeah. So I mean, if it's just a title back, you know, it's this code management which makes it
practical. Yeah, at the end of the day. So having that is essentially what I would say is, He has made us what we think of as a next-generation code automation platform. Yeah, yeah, awesome. So then let's Circle back to you decided. All right, I'm going to do this full-time. Yeah, I'm going to hit sales and I'm going to hit the ground running and then no sales what happened then. So we've the first thing we thought is that the products not
good enough. Yeah. Okay. And I'll be honest with you, we were just so naive in the early days of starting this business. I look back in it in retrospect. And the truth is that we we We had a build and they'll come out of attitude, okay? If we build, just the most beautiful piece of software, that just has all the functions you could possibly want. Yeah, people will just want to buy it. Okay, now that's led to an incredibly mature product, Okay?
So we've got a really mature product, you know, we've got a third version and all that stuff, but from a commercial perspective, yeah man we just got slammed and a lot of it came down to what I realize is. A lot of it comes down to how do you communicate? Yeah. How do you how do you communicate these ideas? Is especially in a space where you're a first mover exert.
All the reading I've done in first-movers is that actually, you know, they'll say you've got an advantage but the evidence is actually massively that you've got a huge disadvantage okay? By being a first mover. Yeah. So we're a little bit cognizant of the gonna pave, the way you've got to pay the way you end up, educating a markers, you end up creating this market, and then someone else comes along as his will hold on, you know, this is something that we could
possibly do as well, okay? So our, our approach that is just basically to say, well, this be cognizant of That. And let's make sure that we don't that the product itself is, is the best that we can for them. Exactly. You know, someone anyone overtaking you if they've got better ideas, we're like we must have the best ideas sir. And I think that that's, you know, that's really the culture that we essentially built in the
company. How did you get your product to such a maturity level, but you need that customer feedback. I'm assuming while the, the lucky side of it was that we always. So we dog food it. Yeah, so we use it to build itself. Exactly. So that's, that's number one. Which has been a massive accelerator for us. Yes. Of course, that makes our development a lot faster and so on so forth. Yeah. And and also, of course, we had our clients. So we had the client coming with
real. These is some of the guys started scaring us with how they were starting to use the tool. Okay? You know, as an example way, how was? So as an example, they started using a domain designer. Yeah. You know, for entity relationship, diagrams, they started using that and a combination of like what we kind of borrowed this idea from the amount guys called stereotypes. And essentially they start building at workflows.
Yeah. So they suddenly think the domain systems for workflows and we got a fright. We were like this is, it's a bit of a bastardization of what the tool is meant for. Yeah. And so that sent us down a path where we said, well she's you know we actually need the ability to configure and customize the design and capabilities and that has been one of the features which gets so many divs. Incredibly excited. Is this idea that hold on?
We can you know, you're not telling us how to design a system we can come up with it ourselves. Yeah. You know, we can like literally makeup Concepts and then model them out and then use their to automate, all kinds of things that we haven't even thought of yet. So you know, we've since seen
some really interesting stuff. So workflows is a common one you know guys will end up creating their own workflow designers with their own you know structures and maybe even the 11 insurance companies in South Africa. That uses our software has they use like if they have a cassoulet associations and say okay 45 minutes between these two steps and dinner so they bought all these unique things and quite structured. And if Perfectly into their
world. Yeah, and we seen guys do things like infrastructure as code you know like describing their pipelines, describing their deployment strategies and stuff as models including testing stuff. So the more vanilla stuff is, of course, entity relationships Services Eventing systems. Yeah. And, you know, recently we've been doing more and more front-end related stuff here. Structuring our front end, but from a contract perspective and that's the key. Is that your blueprint is a contract?
Yeah, you don't want to be, we don't see ourselves jumping into the drag-and-drop, you know, edit After anytime soon. Ultimately, that's, that's an HTML that with the Dave's exerted. That's something else. Exactly. You know, you want the devs knees, still have all the power. Remember the philosophy is like we don't, you never want to be in a worse position than if you didn't, then if you wrote it all yourself. Yeah. So that's the kind of philosophy at exactly if I were to use that tool.
Can I reuse with with other people wrote? Is it kind of? Yeah, open. And I can use the modules they created. Yeah, so I mean not necessarily the ones that I've clients have credit so they keep those It's a form of intellectual property for an organization. So if they've gone and built a set of modules, yeah, that would be, there's a good, you know, we can't tell them guys, you need to give this to the world.
Exactly. But all of our modules that we built as examples, so guys can get a feel for what the tools all about. Those are all open source exert so it's available and guys can download it. And you know we just been implemented architectures that we see as quite popular. So an example is in the darkness space, we recently implemented Uncle Bob's clean architecture.
Yeah. And so, you know, that comes in with, with all the, all the different, Jimmy Bogaerts, libraries and the patterns and stuff. And you know what's nice is that because we get to see so many different ways of doing things. In a sense, we can kind of see the pros and cons. And then we just choose the one that we think is the best. Of course, there's pros and cons to every approach. So, we just pick those.
And then, you know, we've got some, some guys who say, well, we love these patterns, they're perfect, we're going to use them, but a lot of clients, they just love getting behind the wheel and they want to manage their own modules. And so, that's something I would say that the majority of the stuff they were doing at the moment and we love that because Ultimately, this tool was built for him. Awesome. Awesome. So you've got your product which is I'm guessing you're happy
with the maturity level. Now, yeah, I'm guessing you're going to focus on Commercial level more than, or what's your plan here while the thing is that? Yeah, I look for myself. Yes, yeah. Okay. For the rest of the team, its product product product. Yeah, the reason is that, you know, ultimately, by the time, I think that anybody wakes up to that, this is actually potentially the best way to be
building software. Yeah, by the time, we hope that that, you know, the community, Wakes up to that, that will be so far along that if anyone wants to jump into the game, they'll be playing, you know? Years of ketchup? Yeah. So that's the thinking around, like the product. Also, we see so many ways to improve the experience, you know? So you know you want faster feedback and we get this feedback from clients all the time that I go.
Be so great if this would be so great if that, and we're always sitting there analyzing that and saying well you know what is the best way for us to bring that into the product and get that article exerts it back to them so that they can get? They can use it and I think that's quite cool as well. Write the That are using our products at the moment feel very much involved because a lot of the features that they're asking for, you know, a month or two later, it gets released and
like, there you go guys. You know, this is what you've been asking for in that I got, you know, it's been great but I also got these 10 other features so that that's how it goes. Yeah, it's not goes exactly. Yeah, yeah. So at some point we left off, you had two customers and obviously we're trying to focus on sales how far along are you know? So while we're much much further along at the moment. So we've basically, I mean, Over the years, we picked up another corporate.
It's funny how the corporate seem to actually, you know, if you've got the right Connections in a corporate, it'll open up to you. But if you go to a corporate from the outside, yeah, hold its shoot you down. It's quite difficult. It is. It's also, you know, they'll make you jump through a thousand hoops and stuff like that. And they get they get to bully you as well as this that's hard. Yeah, yeah, exactly. Then they're just like, you know, will only pay you this?
This is the budget. We've gotten. Okay. Well, I'm just so glad to have you on the books, you know, just you just kind of put up with it. But I think we're getting to a point now where You know, we've ramped up white massively in the last while I mean you know, our client base is, is getting close on 10. This is hoping to we've got a set of new clients at the end of the day it's set on, you know, basically, almost doubling that's just in the next few months.
Yeah. So it's really started taking off at this point. We finally figured out how to explain it. Yeah, we figured out how to, what the, fastest way it is. For a team to start getting the benefits, okay? And we just know how to do everything. So it's at this point, Not that we were really, just looking to scale it up a little bit.
Go a little bit faster. Yeah, and my thinking is really true from a strategic perspective to say, well, let's run this engine at, you know, the 500 RPM, 5000 RPM o'clock, you know, you don't want to go into the red. You don't want to be in 6 or 7,000 RPM. Yeah, you know, going so fast. You know, we reckon that if we pushed it, we could probably do, you know, eight new clients
month? Yeah, but the time is 35, would just be insane it. It'd be, you know, we would have no time to really look at internalizing and retrospective. And so on. So, What's exactly? So, that's really the, the the kind of strategy at this point. But I think we're very, were very lucky to be where we are. We've got some really prestigious clients on the books. Yeah, we've got a pipeline,
which is looking awesome. So, you know, with a lot of, a lot of interest coming in. So at this point, it's just looking like, we're going to sail. But like I said, earlier, I keep a fridge packed full of apple pie first. I should, you know, it's weird. Little, you know, we're at a point now, where we can say we've got product Market fit, but, you know, there's always going to be some curveball, exactly.
Yeah, I'm guessing you wrote a lot of the code yourself and a lot of the platform yourself and you're still very much involved. Yeah, I know, I wrote I wrote a fair amount of it. I definitely could not have done it without the team. Yeah. Yeah. The guys are I think that what was really great about the team is that I'm working with probably the smartest software Engineers that I have ever met okay? And, you know, I've got a list of guys that are We could be
good enough. Yeah but it's not a long list. Exactly. So I think that we've been very lucky in that sense. And these guys have come up with incredible, incredible ideas over the years and implemented, some amazing stuff. So, you know, I think that's the key, right? Is you got to be an ideation Hub, you know, to be like continuously coming up with ideas and thinking about things. Yeah.
So, you know, it's I don't want to make it sound like I did, you know, it sure it was all me. It was, it was the team. That's almost more than more, than myself at the exactly. How is it hiring first higher than that? Trusting them with let's say your thing. I mean, it's your products, your baby. Well, I think that someone into the fold. Yeah, it's slow. Yeah. You know, there's a lot of kind of outside edges where one can start dabbling with a tool and getting a feel for how it works.
Yeah. Before one gets into the core. Exactly. And the core at the moment there's really just myself and one of the other Engineers who do play around in the core the most okay? And that's because it's you know it is complicated. Yeah you know it is it is under the hood. It's a Funny how like over the years in so many ways we've simplified, but at the end of the day, the simplification and the generalization that we've brought in, has made the power
incredible. Yeah. Because, of course, now it's so Dynamic and so flexible, but that does mean that you need to kind of think about second order, third order, fourth order consequences to a lot of the technical decisions were making and stuff like that. So you had to answer your question on the, you know, on hiring and bringing guys in slowly. That's like I caught you, you can't just let it go too
quickly. When I brought, It in the guy's been helping was with the commercial side of things. That was also quite tricky in the beginning. But you know, it's what I've really seen is one of the most powerful powerful factors in the business is even though we're so small, we focus a lot on culture. Yeah. You know, and you wouldn't think
of that as a start-up exactly. But I read it, Jim Collins book, The Briand entrepreneurship 2.0, and he basically convinced me, you know, it's, this is the heart of the company, exactly. And so, we started focusing on the culture and The strangest thing started, just automatically happening. Yeah, before I knew it the guys were more energetic.
Yeah. Because I mean like you know we are building a lot of the stuff you know especially in the early days we were building a lot of the stuff in our spare time so you know this is extra hours, you're tired, this is your weekends, you know, that's really where a lot of the dev work had to go down and ultimately, you know, the, the culture that we sort of building out at the end of the day, was starting to re-energize these guys after these like yours of
just building and building. And so we started seeing the guys You know, spending time on the weekends and spending time, you know, just coming off two hours and stuff like that, which is obviously, it's on their own accord. It's because they love it. Yeah, it's because they're bought in it's because they see the vision. They we are all working towards the same dream. Yeah. And that's where I see the power of a culture and like it's one of those things where you almost
realize. It's not something that you set out. It's something that you work on all the time and find ways to live. Yeah, as a company continuously loving it. And you see, everyone's God starts to drop and everyone. To relax a lot more and more themselves and there's all these other benefits and then they feel more part of a family. And then they share things like, you know, vulnerabilities and things like that. And they asked for advice and all this kind of stuff starts to come out of it.
And we're doing all of this remotely, which is crazy if you do about as well. So it's, I mean, it's been a mess. It's been a crazy crazy Journey up to this point but, you know, we're at a point now where we the Futures just looking so, massively Brides. Yeah, but like I said, all times that Humble Pie is waiting for me in the fridge. Exactly. It if we focus on what you said building on culture, how do you do that at some point? You reflecting you say, okay,
this is what we need. Probably or you try things out and you some point. No, it's alright we need to work on culture. Yeah. I think that's the first thing is obviously stopped with a why? Yeah, like why do we need culture? Exactly. Okay. So that was the first thing is that I needed to in a sense I need to convince my team that culture is a necessary thing because I was going to bring in. You know, I wanted to bring this culture thing in. We I didn't know.
To do it. You know, there was some kind of guidelines out there from the book, but I didn't know how to bring the culture in. So, the first thing we essentially, I can only say, how we did it. So far is, you know, we sat down and we said, well water, our personal values. Yeah. Like, what do we value personally? And then we didn't exercise when we cross correlated those values. And so, well, okay, all of us feel very strongly about this this and this.
Yeah. And then we started coming out with what we called, the company code. Okay. And it is little, you know? Okay, it's funny to some degree or another Clever to some degree because it's code. Sure. Yeah, yeah, yeah. So we were like, oh yeah, that's okay. We'll call it the company code.
Yeah. And you know, we kept elaborating on that and we went through about three or four versions before, we felt that it was, you know, good enough for us to say we could put a stamp on this and then I start getting idea. Well, you know, this is something that we still want to do is, you know, say guys should sign this thing of the day and you get all these crazy ideas like we should sign it in blood if this isn't but I thought,
okay, that's good. Let's just sign it, even if it's digital signature or something like that. Like, as long as guys are sitting there going like I, you know, my name here by, you know, saying that I will follow 16, uphold the company culture, etc etc and then they sign it and of course that you know, that's just one piece. Sure. So, Jim Collins will basically say well these three pieces to a vision for a company.
So, you know, your coat, your company, your culture is essentially the main thing, okay? And the other guy who I love is is Tom Balu, okay? He's incredible and he's, you know, he's He talks about like the immutable kind of you know that every company needs certain things, and he talks about things like idea meritocracies, you know, and it doesn't matter who comes to the idea, the best idea must win. Yeah, you know, and I've got things where I feel very strongly, that a team has always
stare at problems in the face. You know, you never sweep stuff under the rug. You never have feel good stuff. We always deal with reality. Yeah, which is something that I got from Winston. Churchill, you know, if you read about his stuff, he's like, he's like, If You're Going Through Hell keep going, he's so stoic. He is sober. Atleast, okay? It's also I think he's got some really, really great sayings and you know the first piece is this
these values? The second thing you need is you need a purpose now the why it's like your North Star at the other day and you need to be heading towards this North Star at all times. Yeah. And the thing is, it's a purpose for a company is something that should in theory be able to withstand, you know, the next 100 years. Exactly. It's like, it's why the company is on Earth and three companies, purpose, if you lay it out in one line, oh, I don't know.
It's written down somewhere and I don't wanna risk butchering, it's no worries. So then the next thing. But it's so funny. When we're going through this one of our Founders, Joel, he he always jokes. He's like the purpose of this company is to unshipped show that the software industry like Joe, we can't have that as the as the purpose of a company. But you know it's I think it puts it in perspective. It's like it's a complete, you know, I don't use my friendship but yeah.
So anyway, so that's the second piece in the final pieces, you're what they call the Your mission. Yeah, you know, your big hairy audacious goal. Exactly. You know, and so for us at this point, we essentially see that as being the, an essential tool in the software industry. Yeah, you know, we see every developer when they get there, you know, high-end machine. Yeah, they have a copy of whatever the operating system is they have a copy of their favorite IDE.
Yep. And they have a copy of intent. Architect, beautiful. And that is what we want to be in the software industry. You want to be such a core piece of Of the of the industry. Yeah. Day that it's just like this is how you develop. Yeah this is how you build software these days and these are the principles that you use is you don't you don't manage, you know, a code Base by hand. Yeah, you know, you don't go right every last line of code and then shift it all around
with a shovel. It's like we got power tools how we operate this is how the software industry Works awesome. And so that's yeah. That's basically the vision. That's awesome, man. Thanks for coming on. It was a lot of fun. Talking to you two. Yeah, let's do this again sometime. Patrick. Thanks very much fun. Yeah, no problem. Creating digital leaders.