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

- small team hired (via a well regarded agency) - small team creates and releases initial, limited POC - company retains the freelance lead to staff up an in-house team - in-house team takes over and starts moving to a more complex phase 2 product - initial project ends up being maintained by an offshore team while in-house team goes gangbusters on everything else the company needs.

We had a freelance team for each major product (web, iOS native and Android native). In house teams existed for backend and devops but freelancers create all of the customer facing products for at least phase 1.

It was useful to have an architect level person involved at the start but once development was moving everyone had enough experience to make the need for a higher level tech person a non-issue (the freelancers ranged from senior dev level to architect level). It helped to have someone in-house overseeing things (timelines, scope, etc.), of course, but someone at the CTO level would have probably not moved the needle much in that first year of work.

The "move fast, break stuff" phase benefited from a small crew of experienced devs without too much bureaucracy while later phases needed more structure.

I'm probably thinking about this at a different level, but when I start something new I like to find the core pieces and the most difficult pieces and see if I can tackle those first. Everything else builds on top of that. I'm assuming you mean to start at a higher level piece that will need to use all of the lower level pieces. That's good too because it may help identify what those difficult core pieces even are that I'd like to go after first.

Quality isn't always easy to find - avoid agencies, hire the kind of freelancer who dares to work on complex / hard projects (there aren't that many of them) and ideally.

The pitfalls are mainly hiring:

a) Inexperienced people who happen to work for themselves. b) Agencies, they have an incentive to sell bodies: two mid-level bodies are 1.5-1.8x the cost of 1 senior and they do less work. Especially if they sell you a team of them.

Pick a small vertical slice or process and have them implement that. Run in parallel (the costs in these projects is when operations are negatively affected). Treat it as a learning process. Iterate. Then grow based on what you learn.

If you bring a software team in-house you run a lot of risks:

- Second system syndrome: the software we use today is full of bugs and annoying limitations we have to work around. Let's learn what we can from that system and develop our own bugs and annoying limitations.

- Cost centre dysfunction: Developing software is expensive and if this software isn't contributing to the bottom line it's soaking up money that could be used to generate more profits. You can inadvertently create a lot of dysfunction by adding a new team that appears to burn money as far as the rest of the organization is concerned.

The toil around using a sub-optimal tool might be cheaper than building a new, sub-optimal tool. The likelihood that you'll develop a better tool is low if you don't have any experience developing software and it's not your business' core competency.

You might get around the drudge work of automating some of the toil work by hiring freelancers/consultants. Someone who can come in, figure out the process and the pain points, and write some scripts to ease some of the manual work-flows getting in the way. They don't need to be on full-time working on a product that won't make any money for the company. They can just zap away some toil and save a bit of money for you instead.

Update: spelling.

I'll disagree with Dave on one thing: I personally prefer not having a single lead developer. I've come to appreciate the advantage of having multiple, aligned leaders in a team. Teams like that are absolutely awesome to work on and you can specifically hire for it.

You will absolutely need buy-in from your company, you'll need to give them access to the people doing the job and likely have one of your senior employees do the job. Based on my experience the best internal people are the same people who you'll be putting through a management development program - the type where they get to know the entire business. They'll have the right attitude (can-do, hard workers, personable) and ideally are good with people / nice to work with.

Have the team as a whole report to you. It's a small team (3-4 devs + 1 internal full time).

Also make sure that the team are in control of their own destiny. You'll need backend/frontend/ops/dev-ops skills covered in that team, you don't want them crying for the sake of having a server made available for them. Give them an AWS / Azure account and let them work there.