IME what works best getting new projects kick started is hiring a very small team of senior freelancers, making one of them lead, and letting them loose. I worked on such a team once and it was really excellent. The advantage of this strategy is if the experiment doesn't work out, terminating freelancers is much easier than permanent (I noted you're based in Europe). Contrary to what other people said, I wouldn't try…
Ask HN: Should we bring software dev in-house?
91–100 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#92My current industry is pumping chemicals, it's non-glamorous but it's a need that must be fed, versus "fancy tech" or whatever. We keep a team of guys employed and happy. Just pay them decently well, don't try to micromanage them, give them good requirements and honest feedback, give them the tools they need.
Re: Ask HN: Should we bring software dev in-house?
#93IME what works best getting new projects kick started is hiring a very small team of senior freelancers, making one of them lead, and letting them loose. I worked on such a team once and it was really excellent. The advantage of this strategy is if the experiment doesn't work out, terminating freelancers is much easier than permanent (I noted you're based in Europe). Contrary to what other people said, I wouldn't try…
Genuine question: how do you suggest for that code to be maintained long-term if the original team was just freelancers?
Re: Ask HN: Should we bring software dev in-house?
#94Re: Ask HN: Should we bring software dev in-house?
#951. Have you considered managing your providers performance? What could you do in this area?
2. Have you considered going to market for other providers to start new or to take the solution over? Is that even feasible?
3. Have you considered the long term capability build you need in your company if you decide to bring this in?
Re: Ask HN: Should we bring software dev in-house?
#96I think if you do this and take the development seriously, it will be a ridiculous good return on investment. The success to Tencent according Mohnish Pabrai was that they had ROI on their developers over 10 years. They just put everything they could in development and if it was too much they would spend the rest on lower ROI categories. Overall 50% ROI. (IIRC).
It’s also essentially vertical integration if you do this. If you think it can make your beer taste nicer, as Jeff Bezos put it, then it’s probably worth it. Note that Amazon’s in-house team spawned a new industry. Also, Tesla is currently much ahead on competitors due to their software. I think many car manufacturers underestimate how much Tesla is ahead. The apparently even have their own ERP system called Tesla OS.
For attracting and retaining, I think you can definitely do it. There are engineers who like to see physically how their product is being used. Short feedback cycles can be very rewarding. Also, to retain I would look at Napoleon. What is the best for morale? Winning. Give ambitious projects and make them succeed.
Re: Ask HN: Should we bring software dev in-house?
#97Re: Ask HN: Should we bring software dev in-house?
#98Unless this software is your core business, I would look at a third alternative: contracting the work out to experienced developers to replace the platform. If it works well, you can bring development in house slowly after the platform is more mature. Worst case, you’ll have a more responsive external party managing the platform for you.
Worst case is that you don't know how to run a software team and you end up spinning your wheels for ages and then have to onboard a Dev team and convince them they want to clean up someone elses tech debt. Thus making everything cost 10x what management initially thought. This is probably the last thing I would suggest.
Re: Ask HN: Should we bring software dev in-house?
#991. why do you believe you can build it better? (even with the most amazing team)
2a. its easy to over-estimate the gains of a rewrite, and dramatically under-estimate the negatives. how bad could things get, for the business, if you migrated to a worse solution? (lost revenue, lost customers, etc)
2b. after you answer #2a, do the gains (of a rewrite) now really seem so big?
3. if you outsource this rewrite to a 3rd party (freelance, contractor, etc) - how is that any different than today? you're already "outsourcing" this to an existing vendor. How would you maintain code from non-employees?
4. can the business even support the cost (and it's a positive cost/benefit analysis) on hiring full-time employees to rewrite and maintain this code base - forever.
5a. what do your competitors do? (buy the same vendor software or they built their own)
5b. if they use the same 3rd party vendor, is the market big enough for you to turn this into a new revenue generating business (sell this in-house app you'd build)?
Re: Ask HN: Should we bring software dev in-house?
#100We were a bespoke software dev shop, and the freight company was our customer.
During my time there we were transitioning to their third “major” version of the software over about 30 years. It was a new system designed to handle the US market, where the customer was a relatively new entrant who had been running off the shelf software for some time.
Due to the way they run their business, with strong P+L requirements down to each individual location/site they had a presence, and even individual trucks operating as separate business units, a lot of what got built was effectively accounting. If this sounds like you, or you use a lot of third party carriers, keep this in mind: tracking freight movements alone isn’t that hard, but you need really strong accounting fundamentals in the system from the get-go to be able to really understand costs in this business. Some off the shelf software doesn’t do this particularly well.
Based on this - my strongest advice would be to choose boring tech (Java or .NET) and recruit specifically for some core developers who have a solid grounding in accounting fundamentals, or do some serious training on this before embarking on the design. You will inevitably end up posting journal entries to your accounting software, so treat cost tracking as a double entry accounting system rather than trying to construct a journal as an output.
The customer is pretty vocal in their annual reports (publicly available as they’re listed) about their successes in IT as well as their business model. They look at having control of their platform “in house” (product ownership in house, outsourced development of their own platform) as a core part of their success.
If you would like to chat, I’m not hard to find - look me up on GitHub, then search my name + New Zealand on Linked In. (My customer is also pretty obvious from there).