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

If your current third-party product is barely functional and unsupported, it's clear that you need to consider a replacement as part of your mid-term strategy. It seems that there is a high risk of your vendor ceasing operations or their solution not being able to support your growth. The sooner you start the transition, the less painful it will be.

When deciding whether to build a replacement yourself, consider whether this solution could become a competitive advantage in the market. This is unlikely to be the case for a logistics company unless you plan to sell the software you build. From a business perspective, it's usually better to invest in your core strengths and outsource everything else as much as possible. Otherwise, securing the budget to hire the right talent in the right amounts will always be more challenging.

Assuming software is not your core strength, it may be wiser to search for one or several solutions that you can combine to support your strategy for decades while providing a certain level of flexibility. This might also mean building some parts of your system with low-code or even custom code, but I would try to keep that to a minimum.

If you still decide to build something custom, my recommendation would be to avoid replacing everything at once. Instead, replace your existing solution gradually. Start by rebuilding the most problematic functions first, and then add other features as you go. You might find along the way that some parts of the older solution's functionality are no longer needed.

As the founder of a low-code SaaS product (https://uibakery.io) and a service provider company (https://www.akveo.com), I can definitely relate to your challenges, which are quite similar to those of my clients. If you need any help with your transition, feel free to reach out at vlad a-t uibakery.io, and I can look at your use case in more detail or connect you with others who might help.

My take is that software is a new form of literacy - it’s that important.

So here is a slightly different question: “currently all our reading and writing of English is outsourced - should we bring reading and writing in house?”

This was a serious question hundreds of years ago btw.

Edit: As for the rest of your points:

Find a good, middle aged, experienced developer who you trust. Don’t worry too much about how you tell if they write good code - you can’t. Focus on have they spent years writing code - a Middle Aged dev who is still an IC is a good indicator. Someone you trust - this is something you know from living amoung humans.

Once you have someone you trust, build around them. Pay them well. Pay the people they hire well. Demand incredibly good comprehensive stub-based “test rigs”

Use a blog and OSS as a means to attract talent - become attractive by being pro-software - believe in literacy

Yes! This also happened in the team I mentioned. Sometimes during design/architecture meetings we'd run into the "too many chiefs" problem. That's why I think it's also important to make clear who the lead is from day one.

I've worked as a freelancer for a while, and have often worked with mixes of freelancers, permanent employees and everything in between.

I think there's a big difference between bringing on a boutique consulting shop and hiring freelancers who sit together in your office. The sense of ownership and professional responsibility is way higher in the latter case. In fact I'd even go as far to say that many freelancers have MORE professional pride than permanent employees, many of whom just want to draw a paycheck and live their life.

YMMV of course!

Did you find freelancers are motivated to really learn the business like an employee (hopefully) would? In my experience of having freelancers/contracters on the team they learn things in a very shallow way, just enough to get things working. They also aren't often motivated to make things easy to maintain because they know they won't be the ones maintaining it.