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

I'm an executive at a mid-sized logistics company (~200 employees, $200-300M annual revenue) getting more and more frustrated with our software situation and am considering taking software development in-house. I've been lurking here for years, so looking at the HN community to talk me out of it.

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.

As we are growing we're running in to the limits of what this product can offer. We're being hampered in our speed of execution and missing crucial insights. I feel like we could do much better with a product catered specifically to us.

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.

Besides, can we even attract experienced developers to a non-glamorous industry like logistics?

We'd particularly appreciate input on:

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). Potential pitfalls we might not be considering. Alternative solutions we should explore.

Has anyone here navigated a similar transition? What worked? What didn't? Any advice would be appreciated.

I have worked in a senior role in asset management (think bridges not derivatives!) for 10+ years, and this sounds like a familiar problem. A few thoughts:

1. You don't necessarily need to bring your development in-house. But you are looking to move away from your current provider. You might want to think about using contractors to build a new platform - possibly hire a software house to do it for you, rather than hire individual contractors. There are lots of small software houses who would love the opportunity to build a long term relationship with a client of your size

2. You need to be clear about your budget. How much are you paying your current provider? What would the development cost? What are the opportunity costs of the missing insights you are suffering from. What is the RoI on a new platform?

3. The absolutely critical thing you need to think about from day 1 is the migration onto the new platform. How are you going to get data off the old platform onto your new platform? How are you going to introduce the new platform. Can it be a phased introduction or is it a "big bang".

4. You need to have some good people in your organisation to manage the migration. People you trust to tell it like it really is, not to tell you what you want to hear.

5. I would recommend that you start by identifying the absolute minimum functionality you need to keep your business running smoothly. That is your initial platform (the MVP). The data you need for that MVP is the data you need to migrate initially. Don't try to do anything more than this in your initial migration - keep everything as simple as possible.

6. Do put procedures / checks etc in to ensure you maintain data quality across the migration. And if you can clean up the data as you migrate, so much the better. Do test all your data migration and platform migration before doing it for real!

7. After the migration, you then keep building the functionality, and bringing more data in. But concentrate on stability and keeping your business running. Your migration should be invisible to your customers. If you are having to making excuses to customers about why you suddenly can't do things, or meet your normal standards, then you are doing it wrong!

Hope this helps :-)

Right, and notably you want the CTO whether or not the answer is:

   * build a team in house
   * bring in some contractors
   * make the most of the existing vendor through API integrations
   * switch to a different vendor
   * some combination of the above

because somebody with the right skills, attitude and integrity has to be in charge of it.

Yes the right person should be able to handle any or all of it.

If you don't do it right it won't necessarily be more suitable than it already is, and when that's the stakes there's got to be a responsible individual who can put in full-time effort however much it takes, with the resources appropriately allocated to back it up. The same CTO needs to be capable of single-handedly being the only "tech" employee, served by their own carefully orchestrated select contractors, or at the other extreme capable of building an in-house team to make things better from the ground up if more beneficial.

One person will have to make sure it comes out better than it is no matter what, or it's less likely to come true.

Regardless, it can be like servicing airplane engines in flight, so that's another outstanding skill to keep an eye out for.

Thank you. This is very helpful. Getting the data of the old platform should not be a huge issue. Because we’re filling some gaps with a low-code solution, the infrastructure to get data out is already there.

Feasibly, we could replace functionality bit by bit.