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.