Hi everyone. I’m Johno this is big tech on point. And this week, we’re gonna talk about how to maintain some sort of visibility over what your development is gonna cost you. You’ve got this idea and we need to take that idea from this kind of seedling in your mind, into a working piece of software and how are we gonna do it? And more importantly, streaming the you’re not a developer. How are we gonna do it in such a way that it doesn’t absolutely cripple your bank account? Because I’ve dealt with lots of people who have this idea. They wanna build something. That’s fine. We talk about the build cost . Now things are gonna be a little bit different. If you are going to a software house or an agency, if you are getting some funding or you are gonna hire some people it’s different, but you’re still gonna need to understand what the process is because that process is gonna affect how much it costs you to build. And ultimately that’s gonna completely affect everything you’ve worked out to do with how much this bit of software’s gonna make you , or what value it’s gonna add. And is it still worth it?
So we’re starting off with the idea, okay? I dunno what the idea might be, but you’ve got an idea of a thing, an app or whatever that you need to do. You wanna build the first step from that is gonna be obviously sourcing your technical partners. The people that are gonna help you make this thing happen, make it like a reality. What they’re gonna want to do from your idea is create a specification. Okay? So that specification’s gonna give the, it is the nuts and bolts. You know, you’ve sort of decided why I want a shop. That’s what I want. Um , and we we’ll talk physical buildings just cause it’s a little bit more tangible. It’s a little bit easier to, to get your head around . We talk about buildings. So they’re gonna want a specification or a brief. Usually they’ll come in with a brief and we try to turn that into a specification. So they’ve come in. They said, right, I want a building . And from this building, I want to sell products. Okay, wicked, what sort of products are you trying to sell? Cause these are questions that need to be answered to understand the full scale of everything that we need to do. So if you are selling, I don’t know , miniature bottle of wine , you are going to need considerably less space than if you are selling Teslas. So we need to get some details like that out. The way now web project costs tend to spiral from my experience is where you have said, I want something, the developers or the development team or whoever it is has said, yep , that’s fine. We can do it within these strengths . Here you go. There’s the specification. And along with the specification, which really kind of starts to lock you in here is the price wicked. So you’ve said right in this building, I need a, the capability to bring a vehicle to the back door and be able to move some stock in fine. The developers will probably outline this somewhere, but they’ll make an assumption that , oh , that’s gonna be like a normal size van. Okay? That’s this normal size van we’re gonna put in a garage door. That’s gonna open up. You reverse the van inside. There’s gonna be, you know, a loading bay or an unloading bay where you can deal with your goods in and good out. Do you need one bay or two bays ? Do you want goods in and goods out? Do you need multiple goods in and one goods out? What , what do you need? And they’ll try and get there. And then what changes here is the specification is I need a vehicle to be able to come into the premises to load and unload. And we’ve got , okay , we’ll assume it’s a van . And then you say, oh no, it’s not. It’s a , it’s an articulated lawyers . How you go is whatever.
Well that changes things because the whole floor layout would need to change. You’d need bigger doors. Everything would need to change about how that works. Although neither a party was actually wrong. It’s a misunderstanding. It’s the kind of thing that you want to try and iron out in your spec. And usually when you get to spec is when you start getting to numbers, you start getting to what it’s gonna cost this, but there’s some other cost involved as you really need to think about. And I’m gonna do a talk later on about agile and how it helps with these kind of problems you need to differentiate. What is my MVP? What is a minimum viable product that the absolute least that this needs to do before it becomes what I want it to be. Okay. So in this example of shop, maybe your cos can walk in the door, three boxes, depending on how many couriers you’re gonna get and how much they’re gonna bring in. Maybe we just need a second door. We don’t necessarily need a whole one loading unloading by depending on how much business you’re doing. If you’re selling Rolexes , then you are gonna need your exchange. The , the amount of goods in goods out, you’re gonna have the size packages, the size of the deliveries , all gonna be different. And how many things you need to dispatch is gonna be different. So that’s something to think about , uh , how much do you need? How far do we need to go into this? And what does it really need to do as a bare minimum?
I need to be able to show the products. I need to be able to take the money and I need the customers to be able to come in and leave. Okay, fine. How many set ask people are you gonna have? Cause you’re probably gonna need some toilet facilities. So that, that example, the toilet facilities might not be a thing that immediately came to your head in the spec, but it is something we’ve still gotta cater for. You know, fire alarms might not be your Burg alarm. These might not be things that you initially thought of in the spec, but they have still gotta be considered even if not implemented straight away .
When you get into the build, you’ve got the spec , you’ve got the brief , you’re gonna end up in a cycle . It doesn’t really matter if you’re doing waterfall development or agile development or any other methodology, but I will cover agile in a talk at a later point. You’re then gonna kind of go into this build test. If it fails a test, fix it. We’ll build some more. We’ll build the fixes. We’ll test it again. We’ll show it to you. You will look at it and go, yeah , I don’t like this bit. This bit, this bit let’s change. Those we’ll iterate it. We’ll build we’ll test. We’ll fix we’ll test. It’ll pass. We’ll iterate it.
Now that’s the bit that’s where it spirals. Okay. Those changes those iterations. As much as you can keep the variable of what needs to be built down, the easier it’s gonna be for you to maintain costs because at some point , uh, if you are just paying for time, so you’ve got like an in-house development team. Well , the cost are gonna spiral cause you’re still paying for those people. They’re annual leave and so on. If you are working with a software house or an agency or someone else building it for you, they will have some kind of limitation on how many iterations you can have, how many change requests you can have in the spec. And there’s gonna be some things that are gonna change the cost completely. They’re gonna be some things, you know, taking the example of, well, I need someone to have goods in , right ? We’ve given you a door. You can walk through that door. Wicked. We’ve given you a store .
Oh no, I needed a warehouse. Okay. Well, we didn’t understand that you were store 10 million different Rolexes. We thought it was just gonna be a , a few hundred, a few thousands. Would’ve been fine, but millions changes again . So we need to kind of keep a handle on that and we need to make sure that in our specification we’ve covered all of the bases between the, the team that’s working on this. We need to cover all of those bases and make sure that’s right, because otherwise that build cycle is where the money spirals. It’s where the agency says, wait, we need to charge you more to do this because this is considerably more work than we understood it to be. And that’s not really anyone’s fault because they’re still paying for people. So at some point, that spiral has to stop. The easiest way is use the agile methodologies to get to your minimum viable product as soon as possible. Because anything beyond that is a luxury. Even if it doesn’t feel like one either should be in the minimum viable product or it’s a , it’s a necessity , uh , sorry, it’s a luxury afterwards.
Anything that’s a necessity is in your minimum viable product, but there’s a little bit more to this after we go on. And some of it you would’ve thought of, and some of it you might not have. So after we’ve built, we’ve gone wicked. I’ve got my product. This is ready to go live. And we , we are happy where everyone’s tested it. All the stakeholders are happy. Let’s push the button, let’s go live. So we go live. Then we’re gonna have maintenance and upgrades. And when I talk about maintenance, I mean a new version of LaVale again, which is something I’ll cover later on. But the base software that your platforms built on, maybe that’s got a new version. We need to update it because maybe software versions are updated in the same way that windows, you know, at one point windows 2000 was the thing we all used and we all used windows XP . And at some point they deprecate, they kind of decay away. So they have to be upgraded, but the same is true of software . It has to be updated to work with the latest versions of crime, to work with the latest versions of Linux, if you’re running on Linux server .
So those things happen anyway, for as long as your software is live, there’s a base level of maintenance that has to be covered, but you might also have, there might be some bug fixes that nobody found until it went live, because users will always test things better than air new testing team in the world possibly could. And I’m gonna , test’s another big topic that I’m gonna cover cover later on. So you’re gonna have maintenance and upgrades. You’re also gonna have structural costs to start with. This might be a small server, maybe it’s, you know, $80 a month with digital ocean or something. It’s not gonna be , uh , huge that cost . But if your thing suddenly takes off and becomes super successful, and this is a good problem to have, but if you suddenly get successful and you gain load, now we talk about load. We’re talking about how many users are concurrently on the system, how much stuff have you got a store? You know, maybe your users uploaded way more photos than you were expecting that will somewhere incur costs .
So every software platform, particularly if it’s online becomes a victim of its own success. So you need to understand if this takes off, there’s going to be costs to it. And they might be costs that you’re not particularly worried about for whatever reason, but it it’s worth knowing that you also might then start to hit load issues. Oh, wait a minute. Actually, because of the amount of traffic we’re getting, we need to upgrade the infrastructure. Now you can lay the foundations for a really good infrastructure there early doors, but it’ll be more expensive. Now you might op you might be so confident that you are going to hit that scale, that you need to do that, that you put that infrastructure in place. But really the point of all of this was to understand, and I’m running over time , but I , I don’t wanna cut this short.
The point of this is you’ve got the specification phase. That’s gonna cost you something. The bit where you are gonna spiral is the build phase. And that is really gonna be limited by having a good specification at the begin . If you use agile, which I’m gonna cover later, that’s gonna also really help you keep a grip on what do we need to do to go live at this point. But even once you’ve released, it’s not done and dusted, you’re still gonna have maintenance to do. Maybe a couple of times a year. You’re still gonna have some features that you need to patch or fit or bugs that you need to fix. And you might want to be improving the software own adding stuff in. So you need to know your route to get all of that done as well. And then if it does become successful, it becomes really busy. Congratulations. That’s awesome.
But you’re gonna have new challenges, new problems there. You’re gonna need to make sure your systems will work properly under that amount of load. You know , all of a sudden you’ve got 5 million people using it, your L $80 , digital lotion server, probably isn’t gonna do it anymore. So you need to upgrade that maybe you need to start splitting things out and have more servers doing stuff. And how does that work? That needs to be planned properly. And then there’s other costs that aren’t as nice to think about, but are worth touching on things like security, what is gonna happen? How do you, or you can’t really make sure, but how can you do everything reasonable to ensure that you don’t get hacked? Cuz that’s always a problem. Whether you get hacked or cracked and I’ll probably cover that in a different one, but how do you protect against that? What about backups? What’s the frequency of backups? What is actually getting backed up ? How quickly can a backup be restored? Do we think it’s likely enough that you need to be able to do it the click of a button or is it being a manual job and it takes half an hour or something is that acceptable?
So these are all things, but these are all things that can cost money later on that we need to think about, hopefully anyone that’s building something that is semi-decent has already thought about security and backups and how we gonna scale it if it gets busy, but it’s worth thinking about. So in short, the best way to keep your project costs down is to make sure your specification is nailed and everyone knows what needs to be delivered at the end or uh , some sort of increments. And ideally if they say, oh , it’s a 12 month build, don’t go the whole 12 months and only start thinking about it 10, 11 months in, because that is definitely where things go wrong. The further along you are, if a change comes in, the likelihood is it’s gonna be more expensive because everything else has been built relying on that previous part. So they’re the things that maybe you haven’t thought about when coming up with this app idea, it clear around maintenance and upgrades and how are you gonna get these updates out? Are there gonna be additional costs for these updates? How quickly can they be developed depending on what they are, what’s your minimum viable product, what’s your ultimate goal. And you need to find some sort of way in the middle there that doesn’t box you off from your ultimate goal, but isn’t cost prohibitive early doors before you’ve sort of proven this concept before, you know, it’s gonna be successful. I think that covers everything as always hashtag beat up . This is big tech on point I’m Johno you can find me on socials @johnothecoder. And if you have any questions or if there’s any topics you particularly want me to cover, feel free to send them in. And I will do my best to cover them in a future episode. All right , take care . I’ll see you soon.