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

Senior programmer here. Yeah. You’re in a spot where you need a senior programmer and a couple of juniors but can’t guarantee steady work for them long term.

Also, in house software needs to retain knowledge, otherwise the knowledge disappears when the senior resigns.

I’ve 20+ years experience with business like yours. Contact me.

https://x.com/eduardoarandah

Yup. My consultancy is this- collective of very senior folks who have worked together for years, with experience in most business domains, most tech stacks, and most compliance regimes. This is what we do- accelerate the transition from either internal legacy or external dependency onto new solidly architected appropriate/ergonomic stack for internal team to maintain/extend. You can't hire the experience to get you started in the right way. We leave once you are transitioned because you don't need to pay premium to operate. Feel free also to reach out, email in profile.

I can see there's a lot of good advice in the comments. I just wanted to contibute my 2 cents to the matter. I've done a lot of conversions, interconnection of disparate systems, migrations, monkeypatching and straight abominations in my day. In your position I would hire senior freelancers to patch the system in interations. First, fixing the most anoying issues you have in order to streamline the whole process. This will allow the programmers to really understand the domain and based on that knowledge iterate and consolidate pieces of the architecture until you have what you're looking for. I don't really believe in complete rewrites or starting from scratch based on my experience. Most of the users/companies I've dealt with (small and big) don't really have documented processes and domain knowledge. Well, that's not fair. It's rare those are documented and up-to-date. That's better :-) I agree with some of the comments, the technical challenge is what attracts people (at least that's my case). If you're looking for people to tackle something like this, please send me an email :-) Cheers.

This is excellent advice but I would back up a few steps and do a few things before bringing in a freelancer team.

Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible. Then document the requirements for this part thoroughly. This allows you to:

- Have something smaller for your new team to cut their teeth on.

- Ensure you have collected all the diffuse domain knowledge for this part in one place in the form of structured requirements.

- Forces you to think in terms of what you need and what is acceptable delivery,

If need be you can bring in a Senior/Staff level engineer to help you through this discovery and definition phase.

In my experience the most common difference between success and failure for a project often comes down to clear requirements and expectations. Your employees are the domain experts. You need to collect that expertise and document it in a way that this team can reasonably consume. This is difficult and time consuming so start now.

They will still have questions and get things wrong but this gives you a roadmap. They are going to be learning your industry while you are learning how to build software.

Best of luck

EDIT: formatting

Pulling something like this off is pretty serious business, there are a million things that can and often do go wrong, which is why so few software projects are successful.

And you're in a pretty shitty position, to be honest. Because you don't even have the skills required to hire the right people. Much less handle the project yourself and delegate tasks.

My advice would be to find someone you trust with plenty of software experience, explain the situation and LISTEN to what they have to say, especially when it's not what you want to hear.

Or you're likely going to waste a lot of time and effort making the situation even worse, happens every day.