Live data from Hacker News

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

news.ycombinator.com

281–290 of 607 posts

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

#281

I’m part of a 20-person company that was in a similar situation. We have since built our software in-house, replacing the software we previously struggled with, and it’s worked out even better than I originally hoped because it felt so audacious at the time. One thing I think is key is making sure that whoever is leading this project (the lead developer, not just the person they’re reporting to) needs to know the bus…

I'm not sure they necessarily need to know it cold at the start, but they do need to have access to someone who knows the business cold, and they need to care a lot and be willing to dive into the business details.

Understanding the domain is mission critical for projects. As the lead/architect/PO/... You need to balance what stakeholder say and what the really need. You can not get that, if you do not know the domain.

This is all DDD play book.

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

#282
If you're comfortable spending $2M+ and 2 years building, then maintaining and renewing that software continuously for the life of the business then go for it!

In reality all big business become software companies eventually, but the really big ones tend to lean towards customizing a vendor product (e.g. SAP) to replace their collection of built-from-scratch tools. I'm not in the logistics business but if that's not SAP then I'm not sure what is.

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

#283
post #280

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…

I agree, take an internal which is able to abstract and understand logistics and your niche and combine the person with a lead engineer/team you hire. Send the internal on some PO, scrum and requirement engineering trainings. The lead engineer can then also fix the quality and process issues your internal has.

Like that you can start relatively quickly compared to hiring someone and make them understand your business

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

#284
I used to run the Singapore and Seattle offices for Pivotal Labs and helped a couple of companies build in-house teams to do exactly this.

My first question is to check the basic economics:

$2-300M in annual revenue, ~15% margins, you’re probably looking at earnings/profits around $30-45M. Building and running your own software team is probably around $5M/year, which feels like it could be a substantial hit to your margins. Is there a clear story for how this software will allow you grow to $300-500M in revenue or more? I like to have a credible story for 5-10x ROI on software development because the costs end up being so variable and uncertain.

Then the trick is figuring out how to hire, train, and establish a productive environment for the team. My customers approach was to hire a vendor [Pivotal Labs] to ship a first release and help hire in-house staff to replace vendor roles until the team was fully in-house. The customer got rapid feedback that the team and concept worked; we shipped working software. The new hire landed into a productive context, and could see that the company had an effective approach to software development (because it was already shipping working software).

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

#285
post #206
post #175

Earlier quoted context omitted.

> I've found that the best programmers (and the ones you'd want) are more interested in the technical aspects of the problem and business and customer impact, rather than the sexiness of the business domain. Just want to heartily agree with this point here. Certainly many of us do get excited about particular business domains from time to time, but in my own experience, I get more excited about technical challenges,…

For me red flag is that for OP as a developer I will end up being a cost. Even with all the good words he wrote how company can improve by doing own dev - reality is that company makes money in logistics and as a software dev I would be second class citizen and cost center. That is why I much rather work in company that makes money on software, because here I am money making.

> as a software dev I would be second class citizen and cost center

Everyone’s a cost. The myth of revenue centres was made up by sales & marketing.

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

#288
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…

This is excellent advice but I would back up a few steps and do a few things before bringing in a freelancer team. Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible. Then document the requirements for this part thoroughly. This allows you to: - Have something smaller for your new team to cut their teeth on. - Ensure you have collected all the diffuse domain know…

>> project often comes down to clear requirements and expectations

Here you are just copying an existing system. Reverse engineering requirements from domain experts unnecessarily turns this into a green field project.

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

#289
> I'm an executive at a mid-sized logistics company (~200 employees, $200-300M annual revenue) getting more and more frustrated with our software situation and am considering taking software development in-house.

Would be good to know what kind of margin you have on that revenue. Software development is expensive and if this project will eat a substantial part of your profits it may be hard to see it through. One of the major pitfalls you want to avoid of course is spending a ton of money, but not enough to get a meaningful (in-house) product out of it.

> We're using a third-party product that functions, but barely. The provider is understaffed and unresponsive and the platform is stagnant. It's a fight getting basic bugs fixed let alone new features implemented. We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

I’d start with trying to find out why this provider is understaffed, unresponsive and stagnant. Is it just a bad business they are in? If so then you run the risk of investing substantial capital in replicating their bad business in-house, except at least initially with only one customer (you). But it could also be that this is a cash cow product for them and their focus is elsewhere.

Another question that may be clarifying: How much are you currently paying for this software, and would you be willing to pay x times more if it was well adapted to your needs? (Because you probably will be paying a lot more.)

An even bigger question worth pondering: Could you do your business differently if you had your own software? Really successful companies today typically don’t build software that fits their business, they build businesses that “fits software” (in the sense that they can be highly automated and optimized through software).

Feel free to shoot me an email at bjornsmedman@gmail.com if you want to talk.

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

#290
Regardless of whether you hire in-house developers or hire a software studio that does contract work - I believe the key to success is giving the developer unfettered access to an experienced subject-matter expert who really understands what is needed.

No offense meant - but by my personal experience, executives like yourself are a bad choice for this - some experienced longtime employee that's deeply involved in day-to-day operations in the trenches, would be preferable, I think. Ideally somebody who went through process changes before - like was already working there before your current software had been introduced.

Don't get a developer who wants to start programming right away - you want somebody who asks for time to first really learn and understand the processes the software needs to cover - and who actually questions all the underlying approaches your current software takes - but does not just rule those out out of hand.

Then get that senior employee to mentor them and teach them the job - not the existing software. I would even advise have the developer DO the work for a while - under the supervision of that senior employee.

Post reply on HN