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

I would look at what you could buy off the shelf before building it yourself. I know some of the guys at Rygen.com and they're building some great logistics software. I don't work there or have any financial interest in it myself.

A friend is in a similar situation, they work for a small, state government (US) agency and pay for the only solution on the market. My friend often complains about the software and lack of support. The kicker is they’re only paying $25k a year to use it.

I think this is the lens OP should be using. A small team of “in house” developers is going to start at close to $1 million a year (a senior and a couple of mids; adjust for European salaries of course) with someone already on staff managing and defining the product. Does OP have anyone who can lead the effort?

What is being expressed here is not a new problem. The challenge with solving it is that there isn't an easy set of steps that works every time. Someone's experience with the challenges of getting time with SMEs is highly dependent on the culture of the org, incentives, structure of the engagement, personality of the SME, actual workload, SMEs situation/feelings/stress, etc.

You can solve or mitigate these problems, but it takes experience and expertise that most coming from more pure software development backgrounds may not have. From experience, someone coming in with some consulting experience will tackle the situation differently.

Writing stuff down isn't always the best approach. Having a written record may be a good end goal. It may be better to have the small implementation soak up that experience through co-location with the experts. That way they are close by for interviews (probably too formal) but more likely sit and observe as the experts work. OP can then focus on building relationships between the experts and dev team. On this foundation you can add in more formality.

As part of the relationship management, OP will have to help the experts free time by working with their management. Without details of the company, we can't give real examples, but it might include supporting their requests for contractor support or giving their leadership political help.

When you can't come to some sort of co-location situation, you have seriously undermined your ability to execute the project. You will not have a true picture of the situation. Getting PMs or user experience people to engage with the experts will be lower value and require more clarifications. Developers can be low threat to the experts versus other types of people you can bring in.

I suspect the quagmire might come as much from dealing with government institutions as it does from programming. Does the provider already have relationships that facilitate that?

If you can work around that, then the EDIFACT thing means that it is very inaccurate to say you have a "straightforward CRUD app". I am a freelancer and if I saw those two statements together it would be a red flag, like you were trying to minimize the complexity to try to pay poor rates or didn't understand what CRUD was or just wasn't thinking clearly.

EDIFACT in a modern context where we have human readable formats like JSON, looks like a nightmare. I suggest that you see if there are any libraries you could build off of such as pydifact.

You should also start trying to collect a comprehensive documentation of everything that software is doing for you. In detail. No programming team can be successful without that information and aside from the EDIFACT stuff and bureaucracy that will probably be the biggest bottleneck is discovering that.

I didn't get that from the tone. I inferred this person was trying to convey the perceived importance of some critical things and gave good examples with clear knowledge of the problem domain in a limited space. IOW, I thought it was very well articulated and helpful, FWIW.