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

Right now you're making 1 million dollars a year per employee or a 10x or 20x revenue to average employee cost.

The reason your software providers probably suck is that I'm not hearing how permanent or consultant employees can provide the kind of ROI that it will cost to build even basic software.

Let's say you're based in Detroit, MI - somewhere dirt cheap - 3 engineers for 1 year is 350K in salary, another ~300k in benefits and then you'll take 2 to 3 people normally earning money off their real work to be the domain experts.

Let's say 1 million in developers and 2 people providing 10x the value of their 100k salaries as well, and that's 3 million dollars of cost + lost revenue from productive employees.

If your company has a 15% profit margin on revenue and 250M in revenue - you're making 37.5 mil in profit, and you'll be giving up roughly ~10% of the company profits on this venture.

So the question is, do you think you have greater than 70% chance of getting a 3x return on their cost? Maybe 9 million dollars more worth of revenue?

If not, the project will fail just from the ROI expectations of the bean counters.

You could try to outsource stuff to somewhere with cheaper programmers but that just means the 2 million in lost revenue from productive employees becomes 20 million in lost revenue as the outsourced engineers need 10x the handholding because they aren't onsite, watching the people that do the work and interacting with them with a tight feedback loop.

First and foremost -- document your business case and expectations of other Sr Execs as to sales-growth and OPEX comparison for the current state, and then the desired state.

Your current vendor will likely cry foul if you disconnect from them too quickly and without sufficient empathy. Consider the possibility of the current vendor stepping up to fill the gaps if you could negotiate terms with them that give you better ROI than having your own in-house team. And, would you trust them with the extra outlay?

Requirements, Requirements, Requirements -- cannot be stressed enough. Getting those right (even if they are a moving target) saves 10x development over jumping straight in with designers, and 100x savings over just hiring coders with no domain expertise. Most of your existing domain expertise is in your non-technical staff. They need to participate in a reverse-engineering of what your current system is actually doing for you, and help identify gaps in the current tech that would help their productivity or reduce other toil.

As the first hire, I would hire (contract) a top-notch software architect to lead a "requirements documentation" phase of 2-3 months before hiring anyone else to the team.

Does your current team have access to an underlying database schema? Can you quickly and clearly state how many "screens" your team uses in their current workflows? Can you quickly and clearly state how many unique fields there are on those screen? Same questions for EDI/ETL as for workflow screens. The answers to those questions can quickly reveal the size and scope of your existing system.

There are enough buyers who can tell the difference. Good freelancers just gravitate towards good clients and vice versa.