Live data from Hacker News

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

news.ycombinator.com

401–410 of 607 posts

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

#401

Yes. I worked on the warehousing developer team for a mid sized UK retailer (£75 million) and they had a home grown ERP system and it was a competitive advantage. It wasn’t perfect, the business makes trade offs, they see expensive coddled devs who are basically a cost center BUT they get total control over what gets built and can align very well with business strategy. Support is the biggest pit fall. All software h…

> It doesn’t need to be a big React app, Ruby would be fine, This just made me feel incredibly old. I remember when Ruby was the new, unstable technology.

Don’t worry, I’m old too - that’s why I recommended it. That or Django or even NestJS running in SSR mode.

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

#402
I guess now is as good a time as any to hire qualified software engineers, because a lot of them are looking for jobs. This is pushing down wages, and making this kind of in-house development more feasible.

The thing is that if you hire the right people, you can probably build something that is better (for your specific use case) than whatever third-party tool you're using now, with a relatively small team and in a relatively small timeframe (by which I mean probably at least a year or two until you have something that you can start to use). You might even end up being able to sell your product to other companies in a similar position, if you want to do that.

But if you hire the wrong people, or you don't have the necessary institutional support, or something else goes wrong, you can throw away millions and end up with nothing.

As for retaining tech talent, give them ownership, acceptable wages, and freedom. And don't hire a scrum master.

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

#403
I would start by defining an MVP. What do you really need to support operations, and what can wait until later? If it can be done by hand for a while, don't put it in the MVP. If you can manage with Excel for a few months, don't put it in the MVP. That should give you insight into how big of a project you are looking at. The bigger the project, the greater the chance it's not going to go well.

EDIFACT is a bit of a mess, but not that scary. IME the details of logistics are more complex.

If you are in Europe there are a lot of people in software development in non-glamorous industries. I see more risk in judging tech talent. How do you know if you're talking to the right people?

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

#404
post #62

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…

Im a product designer who loves these types of roles the most. Im biased obviously but having a designer work with the dev team speeds up results as you will have someone focused on identifying prioritizing and solving important problems for the team.

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

#405
I work in logistics and let me tell you what I think would attract high quality developers.

#1 good benefits. More than 2 weeks pto. A paid sick leave policy. Company paid health care. Paternity leave. Company match on 401k.

#2 Leadership that cares about good engineering over deadlines. Logistics is very fast paced. There is often a lot of pressure to deploy things yesterday. Development takes time, trial, and error. You need to be able to have patience for engineering.

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

#406
post #91
post #62

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…

Genuine question: how do you suggest for that code to be maintained long-term if the original team was just freelancers?

There is a whole class of hybrid incubator/vc firms in the US ("VC Studios") that have used this model and achieved success. Sometimes the model is inverted, in that the VC studio will build the MVP with their small, in-house engineering team before staffing the "real" company and eventually handing the codebase off to founding engineering team.

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

#407
post #233

Whilst I don’t have a ton of experience in logistics, I have helped executives in other industries map out transition strategies. For the software in question, a few considerations come to mind: - how critical is the software to your company’s competitive advantage? - how big is the vendor team supporting the software? - how much revenue/customers does the vendor currently support? - how much of the software is entir…

This comment lists most of the questions I would ask. Couldn't agree more. Only advice I would add for the OP: Check if your contract with the vendor includes any business continuity clauses. What happens to their solution, their code, and your data if they go out of business or get acquired (by someone else)? One relatively common option is to have them put their code in escrow, and get access to it if certain event…

Hey Alex!

Indeed - good point to ensure business continuity. There should also be a transition period to ensure OP, you’re getting support (like 6 months of service) in addition to code that allows you to address the issue if the vendor does disappear.

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

#408
Yes. Don’t just bring it in-house, bring it “in-brain,” learn to code yourself and lead by example! Make sure you can write tests (gherkins at a minimum and ideally E2E tests with some browser automation or whatever you need to simulate a user) for your team’s code to know it does exactly what you want and make sure you can run the tests on the dev branch yourself. Then you can trust AND verify!

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

#409
As some others suggested I would also recommend to try to make an experiment. Identify one part of your software suite you think you can build, operate and do the maintenance for. Aim to do it as fast as possible. Test if you can resolve the issues, you have with your vendor, if you do it yourself. If that fails, it propbably isnt a good idea to go full scale on it. Again: aim to get some real world experience with your own build software AS FAST (and cheap) as possible. Dont go for a perfect solution.

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

#410
> I feel like we could do much better with a product catered specifically to us.

This is likely true, but still might have an overall RoI under 1.

I think you have to be in control of the fundamentals of what makes your company different ("don't outsource your core competency"). If you can't immediately see how software is part of that and you have a viable path forward otherwise, I'd tend to advise you not to bring software in-house.

Very few software projects are as easy as they seem, are delivered on a timeline that looks like the original schedule, and experienced devs are not inexpensive. (Yes, you can absolutely attract experienced devs to any industry; just give them interesting problems, competitive pay, and leadership that isn't utterly terrible.)

I have our logistics group (mostly outbound parcel, so a different part of the industry) reporting into me. We found a niche that we felt gave us a competitive advantage from having that team in-house [and I think that's been proven to be correct], but it was far beyond "the existing software is terrible" to drive that decision. OP: Email is in my profile.

Post reply on HN