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

I dunno how technically difficult this is, but consider either hiring an expert on this stuff, or hiring your core software engineering team, and hiring a consultant/freelancer type who is an expert in this stuff to get it done / up and running.

> 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.

Part of outsourcing, is you're not just buying the technical solution, but the support and potentially the liability if something goes wrong. So it's important to consider what secondary benefits are baked into using a third-party, and deciding if you have the ability and appetite to support those as well as developing the tool.

I sort of imagine that replicating the tool / business process is the easy part, it's stuff like setting up and wrangling EDIFACT that will be the hard things.

No matter what you decide, it sounds like in the short term there's no getting away from them. As such, I would attempt to open a dialog focussed on mutual success. If this is a niche, chances are you are as important to them as they are to you. Show genuine interest in the problems they are facing, rather than expressing frustration. Are they struggling in general? Perhaps there are ways to help them get back up to speed. What about you as a customer (e.g., too distinct a workflow) makes things extra complicated? Look for specific points of friction, and how to address those.

A viable option, at least to get started, could be to use them as a building block. For example, handling that data exchange you mentioned. Establish a simplified format that is still detailed enough for them to do what they need. Then have your own logic, however complex, construct the input to their system. Add something in the opposite direction as well. Over time, you'll have more and more components that are easier to replace, because of their limited scope. Finding another vendor or building more custom solutions won't be all or nothing anymore, which is exactly where you want to be.

Doing this in-house? I feel the challenges are already plentiful without that. Instead, lean more to the side of having a couple subject matter experts interact with a small(ish) software house. It wouldn't be the first time that eventually one of theirs jumps ship, tagging on a colleague or someone else from their network. Basically the team would build itself, organically.

On a final note, I just wanted to say this sort of stuff fascinates me. Likely you wouldn't have time for anything like that, but I'd love to see in detail what your business is doing, and how said software is holding you back.

In the early 90s we worked as contractors to a company developing (DOS) software for them. They sold and supported it. They got acquired and after another year the new owners decided we were too expensive and took the development in-house (as was their right under the contract.) We moved on to some other things.

Bearing in mind this was simply a continuation of the existing product, not a rewrite. They encountered the following problems;

A) there were no existing senior people on staff with software development skills. So they hired a couple programmers but with no clear vision of architecture and no clear understanding of the implications of short-term decisions.

B) it was already a "big" system, so it took time for new developers to get up to speed. Their developers would get a job offer somewhere else (paying more) so they had to get replacements. (Remember bringing the development in-house was supposed to be a cost-saving exercise, so they didn't overpay.)

C) over the 6 years they stewarded this the product was essentially stagnant, with no major changes or additions made.

3 years after they took it in-house we spoke to them about a Windows product. We would build it (and pay for development) they would sell it (we'd get paid-per-sale). This took 3 years to build, and once that shipped the in-house work was abandoned.

My lessons from this saga were;

Developing in-house is expensive. And forever. Staff posts you add to do this will always be there. Development of big features will end, but maintaince is forever.

Whatever you have budgeted for this, it'll cost 10 times that. And probably 2 to 3 times your (current gustimate) budget for years after that. If you plan to recoup thus investment selling to others (we did) add another 0 on the budget. Going from in-house to "product" is not cheap.

You will need a senior systems architect who stays over the long run to make long-term decisions and to give the project "coherence". Some early decisions can be very important down the road.

Hiring is hard. You want people good enough to do the job, but who are also looking for job stability. Be prepared to look again every few years (unless you get lucky.)

My advice; figure out your budget. Have a sit-down, at very senior level with your supplier. Discuss your long-term relationship. Discuss how much you are willing to spend. Discuss how you might make the deal attractive to both parties. Make yourself important to them.

By FAR this will be the cheapest approach, and the least distracting for you.

If you can't come to a deal, figure out what it will take to transition the existing source code to you. Probably a big pile of money. It'll still be cheaper than writing from scratch.

Ultimately recognise that software development is expensive, and the management of it is hard and distracting. (And in many ways counter-productive). Your best hope is to rekindle your relationship with the provider, which recognizes that you need, and want, to pay a lot more. If there are reasons they can't actually do what you need anymore then figure out the best way forward from that.

Once you do that you will probably have a reasonable understanding of your potential: budget, opportunity cost, RoI, risk, etc. for undertaking some kind of organizational change.

The actual software development side of this seems secondary until the above is done.