We wanted to build a solution that brings comfort, security and enough transparency to both parties to help simplify the handover equation. Hello
and welcome to the Business of Architecture. I'm your host, Ryan Willard, and today on the Business of Architecture podcast, I'm thrilled to be joined by Harry Sophias. Harry is the dynamic founder of the Sydney based startup bugle labs, his own entrepreneurial journey is nothing short of inspiring. Before bugle labs, he served as the vice president of Global Services at Smart Sparrow, an E Learning startup renowned for pioneering adaptive learning technology. Under his leadership, smart Sparrow made waves in the ed tech space before being acquired by Pearson in 2020 Harry's connection to innovation runs deep. His journey with smart Sparrow began while he was completing dual degrees in mechanical engineering and finance at the University of New South Wales in Sydney. His ability to blend technical expertise with a keen business acumen has shaped his approach to creating impactful solutions in the tech industry. So join us as we delve into Harry's fascinating career, explore the lessons learned from scaling startups and discover how his new venture, bugle Labs is poised to make its mark. And before we dive in, I'd like to say a very special Happy birthday to you, Harry, because today, the day that this episode publishes, is his birthday. So sit back, relax as we enjoy Harry sous. This episode is sponsored by Smart practice, business of architecture's flagship program to help you structure your firm for freedom, fulfillment and financial profit. If you want access for our free training on how to do this, please visit smart practice method.com or if you want to speak directly to one of our advisors about how he might be able to help you, please follow the link in the information we are looking for architect developer stories for the Business of Architecture podcast, so are you an architect, developer, with valuable insights to share? We're always on the lookout for passionate voices in the industry to join us on the Business of Architecture podcast. If you're ready to share your journey, lessons, strategies with our global audience, we'd love to hear from you reach out to us to explore being a guest on our show and help inspire other architect developers on their path. We'd be interested in hearing your story, whether you're at the very beginning of your development story, or whether you have $100 million portfolio of projects already in the bag completed. We'd like to hear from you if you're working with the developers, or that you've developed a number of small houses, or you're working at a larger scale. Harry, Welcome to the Business of Architecture. How are you very well? Thank you, Ryan. How are you? I'm very good. Good to be speaking with you again. Now. Very excited to have you on the show. You're not an architect, you're a software tech engineer. If you like entrepreneur, you have become the founder of bugle Labs, which is a software startup which is founded in Sydney, Australia, and your mission is to end the broke client architect relationship through your platform called bugle viewer. And I thought this was quite interesting. I mean, we met on LinkedIn, didn't we? That's correct, we did, we did. And then you gave me a demonstration of parts of the software last time we spoke. And I was very impressed with with what it did. And I was also very interested in your own entrepreneurial journey and how you came to, number one, identify the problem that you've seen here, and also your own kind of experience in e learning and developing e learning platforms. So perhaps we could start there with like, how did you come to found Bucha viewer? And then we could talk about a little bit about a bit about what
it is. So Ryan the story, began listening to the stories and the tales that my brother would bring home from his workplace, and he would share them at the dinner table with us. He was an architect working in a small architecture firm out here in the suburbs of Sydney. Now this firm did your typical small firm projects, I think new home designs, additions and alterations, like a new garage, so small apartment buildings, as well as the odd gig for a property developer. Now, as you'd expect, these types of projects, they don't always run smoothly, and so he was often the person who would need to intervene when things were starting to look a little pear shaped, or there was some spot fires that had to be put out. He would take up the role as firefighter when, say, his boss wasn't there to do that. So he'd come home, he'd tell us. Us about these stories, what's gone wrong, and how he was able to restore peace to the galaxy. I would sit back, and I always kind of be amused at some of the things that I was hurt, that I heard. But what I noticed was that these stories, they continued for a very long time, and although the projects and the clients would come and go. It was always the same type of challenges and problems that persisted each time I would leave the dinner table and reflect on the story that I had just heard, and I would always come back to the same conclusion that 90% of these challenges that I was hearing about were deeply rooted in two main themes, and the first was to do with money and the ability of the firm to be able to collect the money that it was owed. And the second was to do with this gradual accumulation of small communication gaps that would develop over the life of a project, and in a very stealthy way, they would accumulate and result in what I call a miscommunication bomb, which would always just go off at the worst possible time. So think the day before a submission, or the day before a court case, or the day before some pivotal milestone within that project. The most frustrating thing for me as a listener was that I thought these scenarios could have been avoided had, you know, the people involved in the project just taken some time to listen to each other for a bit longer, the outcome could have been very, very different and a lot smoother. And so while that was all unfolding, I myself was working at an E Learning startup called Smart Sparrow here in Sydney, and smart Sparrow was an educational tech company that had developed its own platform that allowed for content creators and learning designers to be able to assemble and then deploy their own learning materials to their students anywhere in the globe. What made smart sparrows technology special was that it used an adaptive e learning technology, which pretty much allowed for a learning experience to morph or adapt around how a student was answering those questions. And so much of the work that we produced was for students at universities or for learners in, say, a corporate setting, who needed to run through some training exercises and things like that. When I started working at Smart Sparrow. I initially began as a learning designer, but similar to how an architect doubles up as a project manager, I began to be drawn to the project management side of things in the company, and I remember that, you know, some of the issues that I was hearing about happening in the architecture space and that design space there I was also observing within our own projects, one common issue that we used to, I suppose, encounter, was the people in our company who would go out and do the deals with, say, university and set up the project. They weren't the same people who will be in working on the project date every day during the life of the project. And so I would start off a project with my counterpart, say, at a university, and within two or three weeks, we started to see that there was a misunderstanding between what we were working towards and perhaps what the higher ups had agreed upon. And so we would then get together in a room try and iron out any differences of opinion or thought that we had, and that would help keep the project moving forward. What we had made use of quite a lot was some software tools that were, I suppose, there to help reduce project turbulence. So these were things like project timeline tools, record keeping tools and systems in place to capture feedback while we were working on projects and shipping storyboards is what we used to call them. And we also had a process in place whereby we used to have customer success managers that would stay on top of the relationship that we had with our customers, and they would just reach out casually and say, you know, how are things progressing with this project? Would you give it a rating of a green light, a yellow light and a red light? If it was a green light, well, then there wasn't really too much to worry about. But if there was a red light, well then there was probably need to have a conversation about what was going on. I couldn't find a tool or an approach that kind of complemented the approach that I would take to resolve some of the issues that I was hearing about in architecture and particularly those in the smaller firm. And by that stage, smart Sparrow was acquired by Pearson pub. Pushing. And my job eventually came to an end once we wound down the company. And so I used that time off to start building on my interpretation of a solution to try and help remediate the issues that I was hearing about, that architects were encountering. And then once we got to a point where the Id had sort of morphed into more of a product. That's when I decided to commercialize the activities that we were doing. We established the company called Bucha labs, and I was also joined by my good friend and our co founder, rithic, who has been very integral to helping us stand up the systems that we have today. Great
and so at that, at the moment, then what kind of, what does the, what does the software platform do?
So, the approach that we describe it, I describe it as a client relationship tool. So all of the functionality or the tools that I think are required to be able to manage a successful client relationship are there. So that includes things like being able to set up a client, architect agreement, collect approvals, work that's been done, have on platform conversations, so as a way for you to collect feedback and have discussions about what's being shared. We also have some workflows that allow for the secure handling of documentation, because we're trying to balance, I suppose, an architect being open enough to be able to share documentation with their customers, but at the same time not leaving themselves exposed, whereby, you know, might take a very long time for them to get paid for the work that they've done, or in some instances, like I've heard in the past, people just not getting paid at all for completed work. So I suppose, as a whole, we're really looking at a risk mitigation strategy, a tool that reduces the risk at different aspects throughout the architectural workflow,
got it, got it and and so your your previous experience in an E learning organization, what's been some of the kind of key insights there that you've taken and that have been brought through into into this platform itself?
I think in order to put the best type of learning experience together for someone, you have to empathize with the person who will be using it. So if, for a student, how does a student feel when they're learning the content that's being presented to them? And I think one way, sometimes it was difficult for us to do this, because we couldn't really speak directly to the students who we were designing the content for. But if there was someone, like a subject matter expert who was, you know, quite well connected with the student body, and understood where the shortcomings were of the students, then we could factor that in when we were designing out the learning experience. So, for example, our platform was in a very to explain it in a very simple way, imagine having a very, very, very powerful instance of PowerPoint, whereby you had a series of screens, but then for each screen, depending on how a student interacted with the question, you could set up what we call trap states. So that meant that, let's just say there was a question, what's three plus three and someone answered nine, you could safely assume that the person answered nine because they multiplied three and three rather than adding three and three. So we could set up a piece of feedback that said, Did you perhaps multiply these two numbers rather than adding these two numbers? And so we applied this same type of feedback tool to some very complex concepts. So I spent quite a lot of time developing some mechanical engineering modules, so things from like fluid mechanics, numerical methods, engineering mechanics as well. So the platform was very powerful, and I think over the time the company exist, we would have serviced millions and millions of students across here, in Australia, across America and through the UK as well. So But to your question, I think in our case, we've done our best. I've taken the same approach here with the platform. We've tried to speak to quite a few people and empathize with the issues that they deal with, both on the client side and on the architect side as well, and even some other consultants that often get involved, like your engineers, your surveyors, your 3d designers, you might do a render for a building as well.
So are we talking about a kind of live database and of like organizing drawing information, where all of the design partners or the collaborating consultants, kind of kind of log on view and see what's been happening, and then, and then the client is also able to kind of understand what the time frame timeline is. Of. The project
similar. So we've got what we refer to as Project briefcases, so as documentation is produced for a project that then will reside within the project briefcase. Now, sometimes a document can take on different statuses. So it could be in a state where it hasn't been paid for, it could be in a state where the payments pending, or it could be just paid. And as that documentation is disseminated to the people working on the project or collaborating on the project, the status is flagged. And depending on what the status is that influences what you can do with the documentation. So if you've produced a piece of work for me and you only really want me to be able to review it and approve it, then that will reside in our secure document viewer, which prohibits things like downloading or saving of the document until I've either paid for it, or if you have released that document
to me. Gotcha. Gotcha. Okay. Now, in terms of allowing better kind of client architect, client communication, what do you think? What sorts of things have you seen have been issues for clients with architects in terms of the like, the kind of structuring of agreements, the the relationship communication, etc.
So if we start with the client, architect, agreement side of things, I believe that a successful in a professional and a well functioning client relationship is founded in a good client architect agreement. In some areas of the world, like here in New South Wales, this contractual element of the client architect relationship is is regulated by law. So really we need to have one in place. If you're an architect, you need to have one in place when you're working with with your clientele. So getting a good one in place can be a challenge and it can be a time consuming task. And I've looked into why people avoid putting an agreement in place in the beginning. And I think from the architects perspective, there are concerns that if the agreement that they're putting forward is too long or too detailed and it's filled with very legally style language, this could be a deterrent for the client to want to go and do business with the architect. And so the reaction there from the architect is to water down the contract, or, in some instances, just to forego the contract altogether, because they don't want to miss out on winning the work. With regards to on the client side. And this is where I think it's a little bit interesting. I think the reasons why a client might be hesitant or drag their feet when it comes to signing an agreement probably has something to do with them wanting to keep their options open. They do want to work with an architect, but they aren't prepared to go all in by signing the document. And what I think they're trying to do, and I have seen this firsthand, I think they want to ensure that they've got an avenue to bail from the project if things start to look like they're going pear shaped, or they're not happy with the direction the project is taking. Now, where I think this strategy falls apart, and I've kind of had advice on this from a solicitor that I was talking to about what we're doing. Let's just say that you were preparing an agreement for me, and I haven't signed that agreement. I was trying to get away from having to sign it, but you started working on my project in good faith, and then I started making financial contributions to the project. So I was paying you money for the work that you were doing. From what I've understood, if I start paying you, that, in itself, signifies that I've accepted the terms that you've put forward in the initial contract. So I'm sure that's a difficult conversation to probably have with your client if you're getting to a point where that's having to be discussed, because it's probably already something else going on that they're not happy about. Yeah, so because I know it can get messy, and I have seen this one unfold firsthand, what we're doing is we're developing a tool that will streamline the formation of a client architect agreement in a way that makes it a more expeditious project and more dynamic exercise, particularly for those smaller types of projects where this step can be entirely overlooked. The way it works, just very briefly, we have a series of generic templates in our platform. The alternative is an architect can bring their own template in, so if they're working from an associations template, they can build that into our platform and. And then, depending on which aspects of the template, whether it's the generic template or the another template of their own, they can select which clauses or which dot points they wish to use to form their potential agreement for their potential client and the project that they're working on. Then the next step is, once they've selected those dot points from the template that they wish to include in their final contract, they can then add some additional information pertaining to the specifics of the project. So as an example, if I was to task you with sourcing the additional consultants that we need to make use of to complete the project, you might say, I will need a surveyor, I will need an engineer, and I'll need a certifier, and then, that way, when I am presented with the contract, I will know exactly who else you'll need to engage in order to successfully complete the project, gotcha.
Gotcha. Okay, now, in terms of how you've been developing this piece of of software. Perhaps you could walk us through what you're, you know, how, how you've been designing it and and building it and and testing it, and what has that from your own, you know, kind of launching this business. Perhaps you could tell us a little bit of the story about actually setting up a software company by itself, because this is no small feat to be doing this.
So look, it's definitely taken us quite a bit of time. Um, I remember I built a prototype very early on, and the reason I built the prototype was in order to sort of convince myself that I knew what I was building. I remember thinking, had I outsourced this task to somebody else to do, which I think is quite common. People may want to build a piece of software, and they'll be like, oh, I'll just send it offshore and get someone else to build it. But I know with all of the gaps that I had in my understanding, I probably spent more time trying to plug the gaps in my understanding of what I wanted to build than what I did building the very first version. Now, I kept on running into issues, and I thought to myself, I don't know how other people can do this, because there was that many things that I missed on the first version, like even things like permissioning. So who will be allowed to edit a document or update a document once it's been contributed into a project briefcase, right? I had to think about that, and it wasn't something that I would have thought about at the very beginning of the software construction. So we built a good prototype, and it was that prototype that I then used to show to Rithvik, and said, This is what I'm thinking about doing. And then it helped him understand what was going on, and we spent quite a bit of time just iterating around that, making sure that we understood the different workflows that we wanted to include in that first version. In terms of testing, I was fortunate to have a few people around me that were happy to sit down and just run through the bugs and things like that that were there in the very, very early versions, and that was even before we went live. So as I mentioned before, my brother, he's an architect, so he tested out a few of the workflows. I also tested it out from the perspective of the client. I wanted to see what their feedback would, see what their feedback would be. And I even tried to get people who weren't necessarily the most tech savvy people to see if they could navigate the platform as well. So we've put a very high emphasis on making sure that the platform is very simple, the user interface is very easy to navigate. And part of the reason for that was, I think a lot of the time there may be a client who's hesitant to interact, um, say, with an architect he's using a digital tool. Might be because of the tech barriers that are in place. You know, they might not be very proficient with computers. Or, you know, they're worried that if they press the wrong button, the whole thing will blow up. So I wanted to make very sure that everything that they see on the screen is very simple. We've minimized the number of clicks that you need to press in order to do things, just to keep it as smooth and streamlined as possible. We've tried to do that with our approvals functionality. So we've got this one click sign off, kind of tool whereby someone can very easily log in, look at what they're looking to approve, and just press the the Approve button if they're happy with what they see. In terms of the roadmap, what we did there was, from the beginning, we identified a lot of the risks that can creep into the architectural workflow, everything from, say, between the formation of the client architect agreement and that handover of documentation in exchange for some form of monetary funds that happens at the end of the project. And then we looked at those risks, and then I suppose, triage them based on which posed the biggest threat to a project. And then the ones that had the biggest threat to the project were the ones that we tried to tackle first, particularly in that first stage of development that we did. And then in terms of our future roadmap, we've taken a similar approach there as well, but we have the added benefit now whereby we're speaking to a lot more people every single day, and that allows me to collect a lot of feedback, to understand where the pain points are that people might experience. And I'm also getting a lot better understanding of the different challenges within different geographies across the world as well. So of course, I'm speaking to a lot more people now. You hear a lot more about what goes on in a specific geography, and it's very different depending on where the person is located in the world, which I find very interesting.
Yeah. Now in terms of what you've of how this has been received by architects so far, what kind of feedback have you been getting? How is it? How well has it been adopted? And how do you beta test some of this stuff?
So the feedback is interesting, and I'm going to share with you some of the feedback that I get to do with our secure document handover workflow, right? I'll just give you a quick rundown on how it works, so that anyone who hasn't seen the software is aware of or why we're saying what we're saying. We I'm I want to make sure that, and I understand that there's a big importance for an architect to work transparently with their clientele, right, so that they can get to the best design outcomes in the smoothest and the most efficient way possible. Now, historically, I think this has involved an architect acting in good faith and handing over to their client a version of work that carries some form of monetary value. And they've done that in the good faith that the client will reciprocate and compensate the architect in some form of timely manner when the time comes right now, unfortunately, and I know that you've spoken at length about this before, in the past, there are just too many instances where an architect, or any other type of design consultant, too, for that matter, gets caught out, where the funds that their road take Months and months to come in right in some of the most extreme circumstances, they just don't get paid at all. And then this has the flow on effect whereby, you know, there's the struggles to remunerate its employees, bills aren't paid, and it becomes a cash flow nightmare. So knowing that the customer really wants to see the drawings that an architect's prepared, but knowing that an excess amount of Transparency can put the company at some form of financial risk, where we wanted to build a solution that brings comfort, security and enough transparency to both parties to help Simplify the handover equation. So what we've done, we have developed a call it, a two tier solution, which I'll run you through. It. Now, suppose you're an architect, and you produced a piece of work for me. It's an elevation plan, and you're ready to share that to me. What you would do is you would upload that document to our platform, and then the contents of that document, they would be rendered in our secure viewer, which, as I said before, prohibits things like downloading and saving. If you want to add an additional layer of security, you can do that by adding a watermark, but it's not like your normal draft style watermark that we've seen since, like, you know, Windows 98 and Microsoft there where you would just get the gray draft that sits across the document. What we do is each page that's uploaded is analyzed, and then we scan the, say, the length of a document and the the side of the document and try and determine how many watermarks can we fit along the long edge, and how many can we fit along the short edge? So if the answer is four and three for say, an A four document, you'd expect to see about 12 watermarks patterned across the page. Now we don't just use a normal watermark either. The watermark that we have has got three components on it, so the first part of the watermark makes reference to any payment that might be owing on that document. So suppose that elevation drawing that you prepared for me had a value of two or 3000 pounds. Well, then that payment stipulation would be printed onto the watermark. Suppose that then you wanted to add some form of a custom commentary, so something that says this is only for review purposes and software construction, you could include that as well on the watermark and on the other half of the watermark down the bottom, we normally put our company logo just as an additional form of protection. We have had some users who've asked us to put. Their own design company logo there, and that's something that we've been able to do for them as well. Now we get mixed responses on some of this functionality, and I think it comes down to a couple of things, as I said before, depending on where someone is in the world that influences their response. I think depending on the type of projects that people take on as well influences their appetite to want to use perhaps some of the more stringent security measures that we've got. The other day, I had a conversation with someone who said to me, they said, Harry, looking at platform was good and all, but why would I need to use so much security to share a document with one of my clientele, if we've been working together for such a very long time, and they've always been good payers, but never had any issue. It just seems like it could be a little bit overkill. And the truth is, Ryan, I agree with that person, you probably don't need to have that much security in place when you're working with someone who you trust and you've got a very good working relationship with however, there are still scenarios where I believe this functionality can be very, very beneficial. If it's okay, I might just share a quick story about this, because I think the story will beyond just showing why the platform has a purpose. It's also a good learning experience for any say, younger architect or any design consultant who might be looking to get involved in projects that are larger than just one architect and one client, whereby the relationship may be a little bit more transactional. So a little while back now, I was made aware of a set of circumstances involving an architect who was leading a project for a client who was a property developer. Now this developer, he was a very wealthy guy, and he operated mostly as an individual. And what His strategy was, he would purchase or acquire a piece of land, he would then try and get the land height limit uplifted. And then once he was successful with getting the land height limit uplifted, he'd then get an architect and their team to design a new building for that block of land, and then he would sell the project with a development application approved to someone like a construction company. Now this fellow, as I said, wealthy guy, very clever, but he had a reputation of being a very slow payer, and he was somewhat a selective payer, and in some instances, if he got with that one of his projects was about to be or had been rejected at the planning level, there was a very good chance that any consultant that hadn't been paid as yet probably wasn't going to get paid. Now, in this scenario, the council required an artist's impression of what the proposed development was going to look like, and so the lead architect engaged a 3d designer to produce these required renders. The time came for the architect and the client to review this first version of the renders, and so the designer, in good faith, sent over the images with the very basic draft watermark positioned across the image. A LITTLE WHILE past, and the 3d designer hadn't heard back from the team the architect, and so he got on the phone and said, What's happening with the work that I've done? Do we need any changes, or do I just export the final version? Now, when he spoke to the architect, he was met with this very vague and somewhat dismissive response. And this aroused some suspicion in the mind of the 3d designer, because he knew that when he took on the project, there was a quick turnaround required, and that, you know, it had to be done yesterday. So here in New South Wales, we have a system in place whereby whenever an application or a large development application is submitted for review, it goes on public exhibition, right? So anyone from the public can log on and have a look and see what is going on in the planning world around here in Sydney. And because this 3d designer was a little bit suspicious as to what was going on. He knew that the project should have been submitted by now, so he got onto this portal and looked up the project that he had contributed work to. And so he starts digging through. He finds the project, and halfway through the file, he finds his work that he had submitted, right? But the draft watermark had been removed, right? We now he found out later, that interesting, yeah, so he found out later, due to some time constraints, that the architect in the office they had a. Gotten their act together with giving the feedback back to the designer and the architect, actually asked one of the juniors in the office, who was very savvy with Photoshop, to lift that draft watermark and touch up any blemishes on the render. Right now, when I heard this story, I was just very disappointed to hear that this stuff happens like they're a group of professionals, and, I mean, they're basically acting like thieves. It's not the right thing to do.
And the renderer, still to this day, has not been paid for the work that he did. And so I think it's stories like these that, in my opinion, justify the need for the technology that we have, that we have developed. And I would go as far as saying that had that piece of work being shared using, say, bugle viewer, it would have been a lot more difficult, at the very least, to have removed the watermark that was on that drawing, and to go on and submit an unpaid version of this work. And so I think where this functionality will prove itself is when the person who wants to protect their work, or what they want to protect their IP it'll it'll come in handy when they're working for someone who they'd never, perhaps met before, and where the relationship is a lot more transactional. And this can often happen when the person who commissions the work isn't necessarily the person who's paying for the work. Yeah,
no. I mean, I can see this being very useful in maintaining leverage points for an architect when they're getting when they're getting paid. And often I'll see clients, they'll come and you know, if we, you know, a lot of times when we deal with architects, we will have a cleanup operation for for new for practices that we first start working with. And sometimes we'll see large amounts of outstanding AR that have, that have happened from the result of either a poor collections process on the architect side, which is usually that, or the client has withhold payments, and the architect has got no leverage, because they've already given they've already issued the drawings, they've already given stuff out, and now they're, you know what they're going to do, the client is off and running, and the client then may feel justified, for whatever reason, not to pay because they don't like it, or it wasn't done in the timely or some some expectation hasn't been met, and it's been poorly communicated on both parts, and the relationship has begun to deteriorate. That's correct, yeah, but something like this actually, you know, you've got a lock box basically, with the drawings. And they're not going to be retrievable and usable. You can see that they're done. It's kind of like, you know they're doing, doing the handover under the under the bridge. You can open up the suitcase and show the money, but you're not correct.
And that's the whole it's, it's not so much about providing full transparency, whereby you can do whatever you want. It's about providing adequate transparency, because we also think that if you know what you're about to pay for, then you've got no reason and you're happy with it, then there's no reason not to pay for what you're about to receive, at least with the in with regards to not being happy with the work that's there. If you can't pay for it, well, then that probably means that there could be a cash flow issue, or it's a reason that sits outside of the jurisdiction of the architect, I suppose,
very interesting. So yeah, as going back to kind of the testing of the software, and also just how you're financing kind of this whole endeavor. What does that process? But you can walk us through the process of, you know, being a startup software company. We have a lot of startup software companies that come on the show, and I always find it fascinating, you know, the process that they've got to go through in order to raise their own capital, to put in the optimal support. They put their own money into the into the endeavor, and then they've got to, they've got to demonstrate a proof of concept and demonstrate that there's a market viability, and then either seek funds or investment from outside sources to take it to the next level, where, where are you in the process? And how is it? How has it been working thus far?
So to date with we're bootstrapped, so we're self funded, and I think one of the main reasons we've been able to do this is because both rific and myself, we're both quite capable when it comes to building the product. So where we've saved probably in the order of at least $100,000 I would say, is we haven't had to pay a developer to do any work for us. I can write some code. Rhythmics even better than me at writing code. And so we have spent a lot of time building what we've been building, but we haven't necessarily had to spend. A lot of money to get to where we have gotten to, I think, to date, you know, we've spent a bit of money on things like, you know, setting up companies, you know, on some advertising. We've just started to, you know, really try and work on that aspect, on how we're going to distribute this software. Now, you know, across the globe. So that's where we've been able to save money on the development side of things. We now have some money to use on the marketing and those more admin side of things of the business. We're still, I suppose, in that startup phase. It's only rific and myself this point in time, and it's a deliberate decision to keep the business as small as possible for as long as we can, until we work up, until we work out exactly how we want to start scaling up. I think things will all change when we work out the best way forward to scale up. And I don't think we've worked out the exact way yet that we're going to start scaling up. We're working that out now. And what I like about still being quite small is that it gives me the chance to go out, speak to people, and spend a lot of time doing those type of activities, rather than having to run back to the desk see what other people in the team are doing, or have to respond to someone who's, you know, invested money in us and explain to them why we may not have spent the money that they've given us just yet, I'd want to make sure that if we ever went down the path of getting any form of funding, that I knew the best possible way to spend that money, I wouldn't want to use that someone else's money to experiment on the best way forward, at least I'm at this point in time. Anyway, there's always going to be some risk in everything that you do, but I think we can reduce the risk associated with spending someone else's money to get the best outcome for them as an investor and for us as a company as well, when that time comes.
So what does the next 12 months look like for you guys in terms of how you want to be able to evolve the platform and and kind of get it into as many hands?
Yep, so I think we'll be very heavily focused on on distribution. I think what we have now at a functionality level is very, very good. It's very usable. It all works. It's it can offer a lot of value. We are working on a couple of things. So as you know, we've got that contract building tool, which I think will be able to help a lot of people. I am trying to speak to as many different architectural associations, not just here in Australia, but across the world, to try and get, I suppose, permission to use their templates that they provide their members, and to make them available to members who are using our platform who want access to those templates. So that would be quite a valuable thing, I think, to offer someone so for example, if I'm guessing you're part of the Riba, they would have their templates that they supply their their architects, if you could very easily, quickly take a snap of that template and then select the pitch that you would like to use and construct an agreement out of that. That would be a very helpful thing to do, rather than you having to physically build in that template into our platform. Templates get updated depending on the changes in laws. So that could be something that we could handle, rather than you having to stay on top of that all the time in terms of things like the viewer, I'd like to be able to just add a little bit more functionality to how people we can capture feedback, or how an architect can capture feedback from their clients, just to, again, further streamline that the feedback loop and things like that. Great,
very cool, very good. And so listeners to the podcast who are intrigued or seduced by the what you're what you're talking about, and the possibilities that the platforms could be providing for their firms. What would you suggest they do? Is it to get in contact with you and bugle viewer, or is there a kind of they can jump on and start testing out the platform for themselves? What? What does that look like? So
look, there's always the option to sign up and start using the platform yourself. What I always love to do, I love to meet the people who are, you know, wanting to use the platform so that I can give them a very thorough demo. I generally give anyone that I speak to an extended kind of call it a free trial, so that I'm sure that they're sure that there's value there for them to be had to be had. So I'd encourage anyone who wants to give it a go to reach out either to my direct email or to the the email that's on the website, and we can organize a time to go through the platform. I'll take you through it and. Um, and you can have an extended um test of the software is or to make sure it's something that can provide value to you, whether you're a freelancer, so operator, or, you know, someone from a
firm, brilliant, excellent, I think that's a great place to conclude. There. Have I missed anything? Carrie, is there anything
else? I think we've covered a fair bit of ground today. Ryan, yeah. Today. Ryan,
excellent, that's been that's been really fascinating. And very appreciate your time coming in here and telling us about your your story and bugle viewer and its capabilities. And big supporter of these kinds of technological innovations for architects that just streamline our process and allow us to do more with smaller teams and better clients. So Harry, thank you so much for coming on board. I
appreciate you having me, Ryan, thank you, and that's
a wrap. Hey,
Enoch Sears here, and I have a request, since you are a listener here of the Business of Architecture podcast, Ryan and I, we love putting this podcast together. We love sharing information as much as we can glean from all the other industries that we're a part of. To bring it back, to empower you as an architect and a designer, one thing that helps us in our mission is the growth of this podcast simply because it helps other architects stand for more of their value. Spreads the business information that we're sharing to empower architects together, so architects, designers, engineers, can really step into their greatness, whatever that looks like for each individual. And so here my my simple ask is for you to join us and be part of our community by doing the following, heading over to iTunes and leaving a review of the podcast, and as an expression of our sincere thanks, we would like to give you a free CEU course that can get you one professional development unit. But more importantly, we'll give you a very solid and firm foundation on your journey to becoming a profitable and thriving architect. So here's the process for that. After you leave us review, send an email to support at Business of architecture.com let us know the username that you use to leave the review, and we will send you that free training. On the training, you'll discover what 99% of architecture firm owners wished they would have known 20 years ago. Hello,
listeners, we hope you're enjoying our show. We love bringing you these insightful conversations, but we couldn't do it about the support of our amazing sponsors. If you're a business owner or know someone who would be an excellent fit for our audience, we'd love to hear from you. Partnering with us means your brand or reach over 40,000 engaged listeners each month. Interested in becoming a sponsor, please send us an email at support. At businessof architecture.com, the views expressed on this show by my guest do not represent those of the host and I make no representation. Promise, guarantee, pledge, warranty, contract, bond or commitment, except to help you be unstoppable. You.
