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

Sometimes it's worth bringing someone in to build a temporary prototype to test the waters (I once wrote a wireless hand scanner pick system for a startup warehouse in a weekend -- they planned to throw my code away but just needed something functional right then.)

I would only pursue it if:

- your business is truly niche/unique and there's a significant cost due to process friction

- the total amount of work needed to have a functional product could be completed by one or two good developers in a matter of weeks/months.

If you do pursue it, I would try to take advantage of the Python Paradox (https://paulgraham.com/pypar.html) and hire someone, counterintuitively, working in a niche technology. You could probably find someone pretty good willing to build it in Elixir without much trouble.

I recommend caution with this kind of approach. Even if you're bringing in a team of freelancers instead of hiring employees trust is still an essential foundation for the relationship. Clients who play silly games tend to get fired abruptly because it creates a toxic working relationship that isn't good for anyone involved.

You should be able to have an open and ongoing conversation with your team of freelancers about the long-term intentions for the system they are building for you and they should transparently and proactively work towards your goals without being nannied. If that's not happening then you don't need some kind of surprise audit - you need to find different freelancers who are on the same wavelength as you.

It's rare for anyone to be around to look after the code they write for you forever. Ironically you might have more chance of a good long-term relationship with some of your freelancers - having a few good clients who come back to you from time to time is an excellent strategy as a freelancer.

So you always need the system and processes to be designed with future maintainability by other people in mind. Good developers will do that whether they're employed or freelance. Bad developers will mess it up either way too. Choose the people you work with wisely and try to make sure when you do bring in new people they have a good way to get up to speed so they can naturally take over as others leave. There's not much else you can really do.

I don't know why you think they won't stick around long-term. I've seen many freelancers maintain relationships with clients for a decade or more - not necessarily full-time as if they were employees of course but with a genuine connection and coming back to do more work with the same client from time to time. If you want to retain access to the knowledge and insights of your early developers but also want to bring things more in-house - often because you don't need an all-star team to do every little thing once the system is in production and hiring a more mixed team is sensible financially - then this kind of occasional recurring contact can work well for everyone.