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

Median compensation for senior engineers in Europe is nowhere near 150k. Even in Switzerland.

My experience is in the car industry with factory-to-dealer and some of the supplier-to-factory. The core systems were built by SAP, they were very expensive but they were reliable thanks to some smart architectural choices. Those were supported by various bespoke solutions to solve very specific requirements over the company.

In general, at your size, and assuming that you're doing something with retail-like margins (1-2%) then you're almost always going to be better off buying and running some COTS solution. The time look away from that is if there is nothing suitable on the market and if there is a strategic move on the table. Software systems can give you a big competitive advantage. It could even be a way to build a sister business - I can give you a number of examples where companies have "scratched their itch" and then spun off their software as a product company.

So what do you do? You know your business. Can you afford to waste ~1M EUR a year (3-4 really good freelancers in Europe + cloud/license costs) for a couple of years next to what you're already doing?

Personally, I find it really fun. It's a nice mix of development, design, and organizational understanding.

What I want to do is divide up the project. Usually, these legacy systems don't have clear division points; it's all a big bundle of interdependence. But in my experience, there's usually some less impactful secondary functionality that can be spun off.

That will allow you a few things:

Figure out what you quantify as success for such a project. Its limited scope makes it easier to identify the endpoint. Allow learnings about the legacy system, and perhaps identify what elements you can extract from it—not necessarily code, but in previous work, I've been able to wrap or scrape data in certain areas to provide a sort of external output. Figure out how to work with devs, manage your own time, and educate your organization about what you're trying to do. The third and last point is critical. The failure modes for development are obvious, but the political and design impacts are less so:

1. Lack of experience

2. Poor scope

3. Overly complicated solution

etc.

But the real failure mode is political. You need a developer with some political acumen as well. There's going to be a lot—and I mean a lot—of interviewing people about how exactly subsystem X fits into their workflow. You need the political skill to navigate that, in terms of getting buy-in and quality information.

Downstream of the political dimension, in my experience, is the possible design solution. The actual interviews with people and the regular, constant contact with staff about their job are critical to building something that replaces the existing system but doesn't replicate its design failures.

One mistake you want to avoid is building something too similar to the old solution and missing out on critical information about how the job is actually done.

Also, I'm not currently looking for work—enjoying my current role—but if you want to hit me up, feel free. I can at least impart some experience on what to do.

I had a similar experience working with a large agricultural company, where we developed a track-and-trace system to manage their entire workflow. This system provided them with insights into all aspects of their processes. They gained full insight into their margins, mass-balance and quality control, from field to fork.

Our agreement included the agreement that we would own the system, with the option to eventually resell the system in the market, ensuring we could establish a company to support the system after development was completed. As you don't want to loose the knowledge after the system is finished and don't want to have a complete team of developers on your payroll.

We only developed the components that were crucial to the business process, relying on existing software packages, such as the accounting system, and ensured seamless integration between them.

One approach that worked really well for us was working on-site and providing support to the people using the system. This was invaluable in resolving issues that users were experiencing, and it also kept us focused on delivering quality—otherwise, we would be the ones responsible for providing support.

Please note that if you begin development, don’t expect the first version to be the final one. This was a major pitfall for us. The first version was good but not future-proof. Only after developing the second version, essentially a complete redesign and redeveloped from scratch, did we achieve the best solution for the business.

Ensure you maintain an open dialogue with the development team and allow for quick iterations. For us, a significant challenge was aligning expectations. Budgets were tight, and expectations were high, which created a high-pressure environment, that worked great for us and helped us focus. However sometimes this led to a lack of appreciation for our work, as expectations where not met. Keep in mind that developers think differently from business owners. We addressed this by having a technically proficient, data-savvy production manager in the company who understood most of our challenges and helped realign expectations.

Unfortunately for us, the company we built this system with didn’t respect our contract, preventing us from distributing the system and killing future opportunities. This resulted in legal action, which didn’t end well for us, as the company was much larger. We were naive in thinking we could make it work, assuming it would be in the best interest of both parties, but they didn't share the same intention.