We often see articles boasting custom software development will be the 'silver bullet' your business needs to get ahead of the competition. In this week's episode of Lancom TV we sit down with our General Manger, Waruna Kirimetiyawa, to discuss a rather controversial spin - when NOT to develop a custom software application.
If you're considering bringing your app idea to life, make sure you watch this video first:
Want to discuss your custom application idea with an expert? Register for a complementary consultation here.
Transcript:
Hi, guys. Welcome back to Lancom TV. Hi, Waruna.
Hi, Priscila.
I believe Waruna is our long-time guest. About three or four times now.
Lost count.
This time I'm bringing him back to talk about software. So today's topic is lightly controversial, we're going to talk about when not to write a software. We've spoken a lot about the whole idea of businesses writing software, how software is helping create leverage in this world potentially. So, today I wanna talk to you about the opposite, really, Waruna, when should people actually not go ahead and write something from scratch?
Yeah, of course. I mean, we deal with this question a lot with our client base.
Yeah.
Especially people who want to create software, it's quite a costly affair if you don't know exactly what you're trying to achieve. So there's a few key things that you need to kind of work out in this. Number one being is this a problem that's already been solved by somebody else?
By someone. Yeah.
That's already built a piece of software, and as a result are you just looking for a feature enhancement or you're actually trying to solve something from scratch which nobody else has done before? So there's a little process that we go through with that, we use what's called a LeanCanvas, which will actually go through and identify is there an existing alternative to what you're trying to do?
Right. Yeah.
What are the pain points that you're trying to solve?
Yes.
As well as what sort of problem or the magnitude of the problem is that you're trying to solve?
That you're actually trying to solve, yeah, yeah.
Because the worst thing that you can do when you're trying to create an application is to write an application for someone's tenth problem as oppose to their first, second, and third.
First and third problem. Yeah, okay so it's looking for, "This is my problem. Is it worth solving through a completely brand new solution?" And understanding the implications of that. Is there anything else that we usually would say if this is not needs met just don't even go there?
Yeah, I mean, we've talked about the working backwards process qui
Yes, quite a few times.
Everything sounds really good in your head, and you think everything is a great solution, and sometimes even around the boardroom table or around your colleagues there's an echo chamber and everybody says, "Yes, that's a great idea. We should go on and create it."
Let's do this.
But the working backward process really puts some rigor into that what you're about to embark on and allows you to go through and write that press release, write the FAQs, write the user stories.
User stories.
And then really communicate what you're trying to achieve out of that application, and if it's going to actually solve a problem that is worth solving.
And I guess if that only makes sense in your head and you can't really put down on paper, then usually that's where you have an issue. Another thing is it's usually way easier and cheaper into write on paper than it is once you've handed that over to developers to try and actually build the tool.
I guess the other thing from my perspective as well is, "Can you keep up with updates," right? The thing about technology and software is that it keeps evolving.
Absolutely, yeah.
And I'm sure down the track you'll have some new ideas, some new things you want to bring into life for that product, and if you haven't really talked through the life journey of that product or software, and potentially can't really keep improving on it, then probably that's a sign you shouldn't build it from day one, should it?
Yeah, exactly. I mean, as soon as you build a piece of software it becomes an asset in your company.
It does. Yes.
And just like anything else it needs work at it. If you're looking to integrate with other application, or off the shelf applications they all evolve, security evolves, the complexity of the data evolves, and as a result you need to spend more time and money in making your application which you've just created from scratch evolve with those other systems to keep up with them.
Yeah, yeah.
So there's a level of investment that's required year on year, or even quarter by quarter, it's not something that you build once and forget.
And just forget.
Yeah, absolutely.
I guess as a final point as well, it's a given but it's always worth talking about it. If your investment is greater than the return you're likely to get with this application, then probably don't even go there.
Yeah, exactly right.
It's doing your numbers and understanding what are you likely to be getting as a result of investing in that application, and going, "Is this worth it? Should I even start?"
Sure. You don't wanna spend $2 to make one.
No. No.
And as a result, I think what you really need to work out is, you know, "Is the application really going to create more efficiency within your business?"
That's right. Yeah.
That's actually you can put that down to a dollar value. Is it gonna create a new market or a new set of products for you that is gonna give you more revenue? Or if it's solving a problem which you can resell to other who have the same...
To other companies, exactly.
...and the same vertical that you can create a whole new business out of. These are all things that you can actually work out using that LeanCanvas, like I said.
Yes, yes.
There's a free application for that from LeanStack. So you can go online, you can download a Canvas.
Try it yourself, yeah.
Then you can fill in the quadrants and work it out.
Awesome, that was really good Waruna. Thank you so much for popping by again.
No problems.
Appreciate it. And we'll see you guys next time. Bye for now.
All right. See you later.
See you later.