Just because you can build it doesn't mean you should

Building software is cheap now. Cheap enough that the thing which used to stop people building bad software, the cost and the sheer difficulty of it, doesn't stop much any more. You can describe an app to a chatbot and have something running by the evening, and plenty of people are doing exactly that and then deciding they're in the software business. So before you join them, or pay someone who already has: being able to build a thing tells you nothing about whether building it is a good idea. Most of what gets built this way works, which matters less than people think, because getting something to run has been the easy part for years. The questions that actually decide whether you should build are whether anyone wants it, whether it brings in more than it costs to keep running, and whether you could have rented the same thing for a fraction of what it costs to own one. A booking system, a way to take card payments, a CRM (the system that keeps track of your customers and your deals), there are dozens of mature options for nearly anything an ordinary business needs, built and looked after by people whose entire job is keeping them working. Building your own from scratch, for something those options already cover, is rarely worth what it costs you. A lot of bad builds start from wanting. When it's your own idea, the one you've been carrying round for weeks, building it feels obviously right, and all that feeling really measures is how much you like the idea. It says nothing about whether your customers do, and quite often nobody's asked them. I write this off the back of watching feature after feature get built because a founder was certain, and then sit there used by nobody once it turned out the certainty was just enthusiasm. The worst version is building the whole thing on the assumption that having it will create the demand for it. It won't. Either the demand is already there and you're serving it, or it isn't and you're guessing with your own money. A finished product sitting there with nobody using it is usually telling you something fairly simple, which is that the audience was never there. That's a horrible thing to learn after you've paid for the build, which is the entire reason it's worth trying to learn it before. Developers are no better, we just hide it in code. The usual move is building something custom when a library would have done the job. (A library being a ready-made piece of code someone else has written, tested, and keeps patched and secure, so you don't have to.) I like building custom things, and there are real reasons to: you carry less code you'll never use, there's a smaller attack surface (fewer points where someone could break in), you control the lot of it. But none of that is the same as "I wanted to build it", and a good deal of custom work is really just that with a technical justification bolted on. The client's the one who pays for it, both in the bigger bill up front and in the years of maintenance after the developer who loved building it has wandered off to something else. None of this means build nothing. It means building should be the thing you arrive at after asking some dull questions, instead of the thing you assume at the start. Will it actually help. Is building it the cheapest way to find out, or would a rough version, or even just asking a few customers, tell you the same thing for far less. And if you're hiring someone to do the building, the most useful thing to look for is one who'll argue against the work when the work isn't worth doing, knowing full well it costs them the job. Most won't, because it's easier and more profitable to say yes. The few who will are the ones worth your money. If you're weighing something up right now, a build you're not sure you actually need, or one that's already underway and not going the way it should, you're welcome to run it past me before you commit any more money to it. It's a free conversation and there's no pitch at the end of it, just an honest read on whether the thing's worth building, and if it is, what it really needs. I'd rather tell you to spend less, or nothing, than talk you into a job neither of us should be doing. And when building is the right call, that's the work I do, and I do it so the result is yours to keep, with nothing tying you to me once it's done. But that's a conversation for once we know there's something worth building. Tell me roughly what you've got in mind, whether it's new or already going, and the sort of timescale you're working to, and I'll give you a straight answer.