Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

271–280 of 607 posts

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

#271

Post by Aeolun »

darkmarmot wrote: post #221

I used to do this kind of work as a contractor (for logistics and manufacturing), and I've it seen go both perfectly well and tragically wrong. The most common points of failure I've seen are underestimating the amount of business/domain knowledge needed and picking the wrong team. Sometimes it's worth bringing someone in to build a temporary prototype to test the waters (I once wrote a wireless hand scanner pick sys…

> You could probably find someone pretty good willing to build it in Elixir without much trouble.

While I agree with that assessment, you’ll also spend the rest of your days cursing yourself if they were to leave.

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

#272

Post by alexdowad »

alentred wrote: post #136

There is a lot to consider given your situation and you have lots of input here already. So, I would only add my 2 cents in the case you finally decide to bring the dev in-house: 1. Start the team from hiring *senior* talent. Prefer *pragmatic*, experienced, and reasonably "passionate" (about technology) people. 2. As soon as the software team starts to grow, hire at least one experienced product design / business an…

> Start the team from hiring senior talent...

This is very important! Once you hire the first couple members of a development team, subsequent hires will almost certainly be at the same level of technical skill or weaker.

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

#273

Post by bjornsing »

yyyfb wrote: post #242
superice wrote: post #145

I'd recommend against it, but then again, I'm building software products in this exact space with my launching customer being a 200-300M annual revenue logistics company. I don't think they could do it in-house. You don't give a lot of info on the exact niche you are in, but the username tells me that you're doing containers in European context, most likely shortsea or domestic, not deepsea. Me telling you the ISO643…

> Your biggest pain point is most likely that you know your business very well, but you probably do not know enough about the business context of your partners. I'm not in the market, but FYI, the tone of your post wouldn't make me want to buy your stuff. You sound too eager to lecture your customers instead of being eager to learn from them.

> You sound too eager to lecture your customers instead of being eager to learn from them.

One does not necessarily exclude the other, in my experience. Personally I love being told when I’m wrong, and I think the OP was actually fishing for this kind of feedback.

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

#274

Post by darkmarmot »

Aeolun wrote: post #271
darkmarmot wrote: post #221

I used to do this kind of work as a contractor (for logistics and manufacturing), and I've it seen go both perfectly well and tragically wrong. The most common points of failure I've seen are underestimating the amount of business/domain knowledge needed and picking the wrong team. Sometimes it's worth bringing someone in to build a temporary prototype to test the waters (I once wrote a wireless hand scanner pick sys…

> You could probably find someone pretty good willing to build it in Elixir without much trouble. While I agree with that assessment, you’ll also spend the rest of your days cursing yourself if they were to leave.

It's not hard to learn and my current Fortune 100 has had zero trouble hiring for it.

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

#275

Post by Fire-Dragon-DoL »

By the way, as a developer, I find logistics interesting, I wouldn't be concerned about the industry. Your problem seems intriguing, I'd work on it.

I don't have experience in this situation, but your assessment sounds very solid,I agree with you.

The main pitfall I keep thinking about is making sure to hire somebody very focused on getting the stuff done specifically for your business. If they go down a path of developing software, it can generate enormous waste. To clarify, they might need to be ready to create scripts to extract data from the existing software and integrate the workflows (kind of doing what you are doing with no code), rather than writing from scratch, because the alternative might have astronomical costs. I would focus on senior devs, pass on juniors for the first hire. Not sure how many people would be necessary.

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

#276

Post by EVa5I7bHFq9mnYK »

cvladan wrote: post #191
j45 wrote: post #130

Earlier quoted context omitted.

As a developer who became this kind of a CTO a decade, maybe two before it became fashionable, I would have agreed with this in the past until I learned why otherwise with companies this size. All the devs in this comments can do what I share below. 1000%. It’s a different way to make an impact and help make healthier spaces for technical teams to do what they want. I’ll share one example. Clever architecture and lev…

OMG. GPT? Claude?

Nope, those usually get basic grammar right.

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

#277

Post by bjornsing »

Aeolun wrote: post #270

From the inside, I’d recommend that if you bring software dev in house, you bring it entirely in-house. There’s nothing worse (as an in-house developer) than having to work with contractors that have zero skin in the game beyond their paycheck.

What’s the difference between an employee that only cares about their paycheck and a contractor that only cares about their invoice? In my experience you can get burnt by both, and at the end of the day the character of the person matters a lot more than the kind of legal docs they work under.

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

#278

Post by Silhouette »

intelVISA wrote: post #249
davedx wrote: 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…

I'm gonna go against this heavily tbh: If you don't have a 'trusted wrangler' freelancers won't build anything worthwhile as they're not interested in the long term unless forced. There must be somebody you know, or friend of friend, to get a warm intro to an experienced developer you can pay to oversee said team on an interim basis. No consultants, agencies etc. they'll fleece a non-tech like you, save your money an…

If you don't have a 'trusted wrangler' freelancers won't build anything worthwhile as they're not interested in the long term unless forced.

Freelancers' careers live or die based on where future work is coming from. Happy clients are good for repeat business. Happy clients refer other potential clients. Happy clients are good for portfolios or case studies. Smart freelancers are all about keeping their clients happy in the long term. It's just good business.

Of course there are people in the freelance world who are hopeless and will never build anything useful just like there are people in the employment world with the same problem. But it's much more career-endangering to be incompetent as a developer and/or as a communicator in the freelance world because freelance gigs can often be terminated relatively easily if the client isn't happy with the work.

Maybe this is different in the parts of the US where compensation for tech employees can be way higher than anywhere else but in most of the world freelancers tend to be relatively good at what they do and part of the attraction of going the freelance route is that it doesn't have the glass ceiling on compensation that being an employee often does so if you're good enough to justify higher fees then you can actually charge what you're worth.

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

#279

Post by simonz05 »

We recently went through a similar situation at a logistics company in Europe. We decided to bring software development in-house after facing similar frustrations with a third-party provider. It was a challenging process, especially in attracting talent, but ultimately, it allowed us to build a solution tailored to our needs.

I’ve been with the company for the past 4 years, working as a lead software engineer. If you’re interested, my contact details are in my profile, and I’m happy to setup a call

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

#280

Post by 4b11b4 »

You must bring it in house. I am few weeks away from doing what you ask for an org. New stack from ground up taking all the old learnings and pieced together existing software,no/low code pile of yarn to simply build the correct db architecture and CRUD to match. Existing software worked and props to founder who scrapped it together, but it increasingly does not match the real world abstractions of the business.

Hire from within -- promote someone who is technical enough but more importantly excited and already knows the ops/logistics and has the entire mental model in their head. This eliminates a lot of headache for leadership to explain everything repeatedly and over many hours. Support this person with a senior developer with a track record. Luckily for this company I am both of those people. Keep the team lean, support them and let them work for multiple focused months to start, requiring certain milestones but allowing for refactoring as they see fit. There will be and should be some refactoring at the beginning. You want it to happen at the beginning, not later on. Maybe two people is enough or add one more person to support misc tasks and QA labors.

Within 3-6 months (depending on the team) you'll have a software foundation that actually matches your organizational structure. (note: lot of assumptions here)

edit: grammar,typos

Post reply on HN