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

If you choose to stick with your existing provider, you can negotiate a service contract where the provider hires and manages engineers that work exclusively on your account. We did this in the past with pretty good success. We were planning to exit in 1-2 years and didn't want to invest in an entirely new platform or build it ourselves when we knew the acquiring company would end up rolling up our service into their existing platform/infrastructure.

One thing to consider with in-house dev is there's no one to yell at except the man in the mirror. Think about this, you need an application as part of your workflow, you're not in the business of selling the software development. What you risk happening is employing a dev team who's job becomes writing code 9-5. Your developers don't have much of an incentive to deliver a v1, they get paid no matter what.

A small, experienced, eat-what-they-kill consultancy may be better. If they don't deliver they don't eat. A firm like that is motivated to get things done on budget and on time. You'll get the application you need to move on with your business rather than having an internal software development firm 100% funded in perpetuity by your real business.

I think it’s certainly doable and sustainable.

Pitfalls you’re not considering:

Maintaining it. It will have an ongoing cost of keep things running, secure, up to date. This will get bigger and bigger as the project becomes more integral.

The right mindset. You don’t want devs who approach this as is they’re building the next Amazon or Google. You don’t want it over engineered and have devs trying to be too clever/ padding out their own CVs. This might also make it pretty boring.

Unless you have some dev who is very interested or experienced in logistics you’ll need a some people from the business investing time helping explain what the feature is and acceptance testing it.

Having had the fun of taking over a project from a bunch of clever contractors I would caution: It may be too clever. There is value in simplicity and a stake in long term ownership. Some article here recently associated technical debt as lost institutional knowledge so handing the most key decisions to contractors has also drawbacks. One needs an integrated approach for design, build, maintenance and operation.

Firstly, it's important to note that on Hacker News, responders are probably going to be biased towards writing software that solves your problems.

Secondly, it sounds to me as if you are jumping ahead, and favoring one particular solution, rather than looking at this as business problem. If I were tackling it, I'd be making a list of all the possible solutions: - Stay as you are - Stay as you are but make a deal to buy the source code/or perhaps the company that makes the product if that's feasible/or the division - Buy-in an entirely different commercial platform - Build your own as a clone of what you already use, and extend out - Build your own as an entirely new system - something that exactly right for you - Glue systems together to get something that works for you - Probably there are more.

Then I'd list the advantages and disadvantages, the risks, and guesstimates on costs and monetary benefits. This does not need to be a long process - a month and a spreadsheet.

At the end of this process, I'd be thinking about next steps to facilitate the likely candidates. E.g. initial talks to vendors or approaches through an agent about buying the company.

If build-your-own is still on the list, then I'd look at having someone spend a few months documenting and thinking about your existing software, specifically with the aim of mapping out the likely pain-points - e.g. does the system use an interesting scheduling algorithm and if so, what is special, and where does it fail?

This stuff will eventually form the basis of spec for the backbone of a new system. But it's first job is to build some organizational expertise in the software, rather than the use of the software. You want some maps of the territory.

If at the end of this, you have a sense of the pitfalls, then I would think about mapping out what is really needed - interviewing all the levels of your org that have an interest - from the end-users/operators, through to the board. You want to find the stuff that's not documented. You probably don't want to get to a spec, but you do want to have a document that accurately reflects your needs (and also the love-to-haves, and the opportunities to extend)- and it can be used to judge whether a buy-in or a build-your-own can successfully meet your needs.

If you even get this far, this is the point at which you should be deciding between build-your-own and buy-in.

And if it's build-your-own, then this is where you take all the stuff you've learned to spec it.

And if this is the solution, I'd be thinking about what technology will serve you best at least cost, now and ongoing. E.g. should you be building a web app, and if so, what tech could function as the core, so that you don't have to spend money on re-inventing layouts.

Strategies - these are not secret: - Make your business a place that people want to work - that means getting rid of bullies and trouble-makers, and encouraging a supportive environment - Make sure there are challenges, and they are achievable - Offer excellent packages - this can be a mix - work-from-home, healthcare, pay, etc - it's the whole package that matters - Understand that if you don't offer people a pathway to improvement, then you will lose them - Ensure that the actual physical work environment is conducive to concentration - Ensure that the software team are a proper part of the fabric of your company, and not an afterthought.

Transitioning software too, is not rocket-science. You need a solid plan for the transition. You need to train people constantly. You need changes to be small, incremental wherever possible, and clearly communicated ahead of time; you want the people who use the software to feel in control - that this is to help them, rather than to hinder them. And if there are organizational changes as a result, then you need to be sure that you are not shafting staff; you want people on your side, not against you.