Ask HN: Should we bring software dev in-house?

I'm a CIO/CTO in a similarly-sized (revenue, although we have roughly 900 employees) company in the distribution space. We do almost all development internally, but I have been developing for decades so I know what good looks like. I've had good luck attracting a jolly band of developers and devops.

I despise outsourcing development to third parties unless I absolutely have to. The quality of work is just better with the internal devs, and we retain the knowledge of our entire stack.

Our software is the life blood of our business, so that's a big win for us and it sets us apart from our competitors. I'm able to outpace them from an innovation perspective.

All that said, unless you're very technical or you have a strong IT executive on your team, this approach won't work.

I read: "I'm an executive at a mid-sized logistics company (~200 employees, $200-300M annual revenue)"

I think about: https://www.bloomberg.com/graphics/2015-paul-ford-what-is-co...

I'd recommend against it, but then again, I'm building software products in this exact space with my launching customer being a 200-300M annual revenue logistics company. I don't think they could do it in-house. You don't give a lot of info on the exact niche you are in, but the username tells me that you're doing containers in European context, most likely shortsea or domestic, not deepsea. Me telling you the ISO6436 type code for your username is either LEG1 or LEGB depending on max stacking height should tell you I know my stuff :)

Your biggest pain point is most likely that you know your business very well, but you probably do not know enough about the business context of your partners. If you are running a small-ish container terminal for example, you really should know how the depot department of the major carriers are managing their empty stock so you can decide your stacking strategies in the yard. You should probably also have an understanding of benefits vs drawbacks of tower cranes vs gantry cranes found at bigger quays. That then influences what your TOS should be capable of. Same thing goes for intermodal transport planning, you really should know not only how detention/demurrage works, but also what tricks you can pull to optimize for it, and how shipping lines monitor this internally. If you are building stuff in-house, you're inevitably going to be limited in your understanding of the wider market. Short term that's a huge improvement (more tailored software, better flexibility), long term that might cause huge issues.

I can certainly understand the frustration with third-party products. Your description of 'they are understaffed and the platform is stagnant' could realistically apply to pretty much any software provider in this space. There is a huge opportunity for somebody to swoop in and build something, the bar for this sector is mostly something that doesn't straight up suck. And I'm going to be honest: we're trying to be that somebody.

If you'd like to talk, my contact details are in my profile. I'm happy to show you what we're building, and tell you what that is like behind the scenes. If you go ahead with your plan to in-house it, let's stay in contact, perhaps we can learn from eachother.

Definitely could attract talent, not only is stable job but it is green fields with flexibility to choose your own technologies and build something ground up.

Most engineers don't love joining a giant co. and using tech we are not fond of.

Lots of good comments in this thread, but I think this is a critical one. It seems you've (OP) almost already decided, but you're unsure about details such as how to retain software developers. Before you go into such details you need to be sure you want to make this move. This must be a strategic move, meaning a long term move where you're sure you're gaining a strategic competitive advantage through this being a core competence (in the academic/theoretical strategic sense). There are very few quick fixes in IT. Most projects are grossly underestimated - in particularly if you lack the competence in-house today (easily 10-100x).

At it's core, it should be a decision that is not only about control over the software, it's about bringing the knowledge about the processes and technical complexities of doing your business in-house. You might think you know all about it, but most likely you don't (otherwise most IT projects wouldn't fail). The big cost in IT is specifying exactly how things should work (that's basically what coding is all about). If you're not a developer (and even most developers underestimate/don't fully understand this) it's highly likely you underestimate this part of it (otherwise it would be easy for you to code it yourself - again, how to code is not a big deal, it's specifying exactly how it should work).

Software development is a lot about managing and documenting processes, aka knowledge, about your business.

Otherwise I agree with lots of other comments. Make sure you and the rest of the business is sure and have enough budget/resources allocated for a long time forward. Bring in a CTO/leader with the experience/skills of doing something like this. Make sure that person has the mandate to do what's needed (hiring, culture, etc). Could be a good idea to do it step by step to test out (again, a good mindset is to see this as an investment in learning about how to do your business, using IT/automation). A hybrid approach could work (take over existing code, use another platform/ERP/system as a base) - all depends on the specifics of your business, how custom your business and processes really are, how core to your business they are, etc.

Good luck!