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

> We're using a third-party product that functions, but barely. The provider is understaffed and unresponsive and the platform is stagnant. It's a fight getting basic bugs fixed let alone new features implemented. We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

Most successful and agile 3PL and LSP (non VC backed) do not build all their tech, but rather glue tech together. They leverage pre-built TMS, WMS, YMS and build out in-house middleware layer for analytics and control points. Key is to guarantee portability of data and analytics with a unified view of the business.

> On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.

The Devil is definitely in the details. We regularly ignore what C/VP/Dir-level's description of tech and business process. Talking with the direct team member or their manager reveal so much more of the real painpoints than what higher up learns. The risk here is not business adopting tech but rather tech team understanding business. Have a senior leader here who are technical with strong business domain expertise is critical. They need to form a culture of domain understanding throughout the tech org.

> Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning from third-party to in-house software (success stories and cautionary tales).

It is very hard. Mostly due to comp, EPD treated as a cost center (and engineers do not want to be devs), lack of recognition of the industry.

There is one thing going for logistics, it touches physical world and is extremely complex (not hard). It attracts certain types of people prefer complex problems. Aside from senior tech leaders and a few senior engineers, you will be aiming for the diamond in the rough profile here.

There are rare cases such as Ryder acquiring Baton and use the latter as their core Engineering while keeping some old IT groups hanging around. Ryder is large enough to pay tens of engineers 300k+ salaries.

> Potential pitfalls we might not be considering. Alternative solutions we should explore.

Instead of building a tech team to build everything, you have an artifact, who is a domain expert on your own business, define a business middleware and analytics ingress for the company. Start by normalizing against the middleware and analytics ingress with consultants before building your own tech team.

Logistics has been the most fascinating industry I have worked in and I see my whole career in this industry. Excited to chat more tech strategy in logistics, email shu at loop dot com.

You'll need to attract folks who care deeply about the space (yes, they exist, for some people logistics is fun), are seasoned software devs (the pool shrinks) and set them loose on the problem with as few restraints as possible.

Your best bet here is an approach that gives them a stake as well. Either as an external experiment with performance gates, or by founding a subsidiary that they co-own, or ... well, any number of solutions.

Yes, you won't be able to outcompete FAANG on salary, but you can outcompete them on autonomy. And a lot of experienced devs care about the latter part more. (Having made and saved a good chunk of big tech money)

Biggest issue will be vetting the people you find. If you don't have inhouse experience, either take an approach like davedx suggested, or reach out to somebody who has (hekker)

If your business is growing and this is an important part of the business, then you'll eventually regret not building in-house. Of course, you may regret poor execution on the in-house solution, but the response to that is to start small and incrementally grow scope instead of trying to switch over a big mission-critical system. All big functional systems start as small functional systems and grow incrementally. It's easy to imagine the system you'd like to end up with, it's hard to imagine a series of small changes to get there from where you are. But if you want it to be successful, you have to take the longer path that is in production the whole way through.

Consider having the new development focus on features you don't have in the current vendor solution instead of replacing features you already have. These will be more impactful and give the new team some positive inertia.

Yes. This is a complete non-issue. Plenty of developers work for companies that aren't "glamorous / sexy tech companies." In fact, I'd almost be willing to bet that - in aggregate - more developers work for companies like yours than work for those glamorous tech companies. Consider - every auto manufacturer, auto parts chain, soda-pop manufacturer, supplier of sheet metal, supplier of PVC pipe, sewer construction company, insurance company, retail chain, yadda, yadda, yadda, has IT staff. OK, excluding maybe some really small firms who also outsource to a service provider of some sort. But I think you get the point - using and developing tech isn't something that is only done by "tech companies".

Offer good pay, good work life balance and private offices for developers (if working in the office) and/or a healthy approach to remote work, and finding developers shouldn't be a problem.