Live data from Hacker News

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

news.ycombinator.com

351–360 of 607 posts

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

#351
It's complicated. Building software is very expensive and high risky. You can try with a small project in-house and get your learnings from.

Yes you can find people that want to work in a non-glamurous company easily. These places are excellent if you want to see your work doing direct impact in improving peoples lives.

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

#352

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 m…

"Pivotal Labs". That's the first issue with the basic economics.

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

#353
> [I'm] getting more and more frustrated with our software situation and am considering taking software development in-house. I've been lurking here for years, so looking at the HN community to talk me out of it.

For the opposite perspective, https://danluu.com/nothing-works/ .

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

#354
I'm in the process of similar transition in global manufacturing company, where my role is to build internal engineering team to essentially increase ownership and remove reliance on external vendors. So far I would say it worked, but with a few caveats. One key thing to note is that usually you don't have to build e2e team to replace your current vendor, as replacing key roles might be good enough to drive visible positive change.

What I would suggest is to divide the work scope into smaller chunks, eg. isolate applications / systems. This will allow you to distribute the work to other vendors or your own in house IT team. The change usually requires a lot of work in different areas, such as clearly defining people functions, R&Rs or work organization. Then you insource key roles, and see if the effects are what you're expecting. Having some local CTO type of person to drive the change would definitively help.

Overall I would expect the process to take several quarters, highly depending on your system complexity and vendor lock-in (they will not be happy about the change!).

I've seen in the other comments reco to find freelancers instead of FTE, and it could work depending on local market specifics. In some countries you have to watch out for employment laws and potential issues. I'm based in Poland so can provide more info if you want to chat (myr11242@gmail.com). Good luck regardless :)

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

#356
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 has bugs, all software requires maintenance, never let speed of delivery happen at the cost of sensible levels of quality or you will suffer greatly with support requests which your devs will spend their time fixing.

Since it’s in house hire people who value stability over sexy new tech. You don’t want bleeding edge JS frameworks, you want tried, tested and boring. It doesn’t need to be a big React app, Ruby would be fine, a nice boring relational database would be great. Functional, reliable and stable is the order of the day.

Start with a small project as a test run and build up from there.

Oh and read The Phoenix Project, it’s an excellent fiction book about modern software delivery and the impact it can have on a business just like this. Aside from having some good lessons it’s also just a good read.

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

#357

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…

Second this. Cross functional knowledge is the secret sauce of in-house designed software. Nothing off the shelf does that. Integration is where cross departmental solutions live and that’s an underrated nightmare

Third this. If the software team (at least the lead) does not know the business requirements, you are not doing in-house development. Otherwise, it is just equivalent to off shore development, that happens to sit in the same building as yourself.

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

#358
My team worked remotely from the EU for a similarly sized ($100-$200M) US-based company in the print-on-demand space for over 8 years as an external provider, building much of the core infrastructure and services. We are looking for new projects; contact information is in my profile.

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

#359
I'm a CTO and scaled multiple companies from zero to multiples of TBs of data (also to millions in revenue). I also worked on companies such as yourself that have an existing solution and want to revamp their entire technology base.

The short answer is yes, you should hire an in-house team so you can execute faster and also reduce the red tape of the provider not being more proactive.

How to do this is more nuanced:

1. I would start by documenting and/or asking for documentation on how the whole system works. This is key. I would start with a high level diagram. Even if you're not technical, this would allow you to evaluate the existing stack and see what could be worked on in parallel to the existing tech if any. I feel like you are technical enough to understand this since you understand CRUD and other terminologies. You can even set a time for the provider to explain the services to you if needed. I say parallel because I'm assuming you can't just quit using the system entirely, it will need to function until you do the switchover.

2. Once you have a good understanding of the system, this will allow you to be more specific on your needs. I almost never recommend a re-write but based on the statement that you are using a third-party product, this might be the case here. If it is indeed a re-write, I would approach it so that it's 1-1 parity with the existing system first, and if not, maybe with some ample planning and product grooming make the features even better. Furthermore, this will allow you to make a basic PRD for the requirements of what you are building. Doesn't have to be really specific but it will make it clear to yourself and others on what the task would be.

3. Hiring. At this point, I would start hiring a CTO/VP/senior engineer. Describe the problem from 2., maybe deep dive even if needed and start to get technical leadership going. I'm assuming cash is not a problem so if you start at $175k/year salary (maybe some stock/benefits) you can find many technical leaders that would go for this. Once you make that first hire, if they have a good network and or social clout it should be easy for them to hire people and/or consultants to do the job.

4. Iterate. Once you have that amazing team and if they have a good process in place they should keep iterating on the product and continue doing this on a steady pace.

5. Once the product is ready or any point that is it deployable make the switchover. At this point, you should have full in-house control of the product and have competent tech team in hand to do whatever is needed.

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

#360

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 m…

I have a fully staffed team it’s not 5m a year. For a company twice his size. These are very generous consultant pitch #s not reality. We doubled running 1-$200k/guy … 2x full stack devs (me) 2x data guys 1x MSP for IT. That team was awesome and did serious buzz saw damage because we shipped solutions that made the company better every day. Didn’t have to be huge. Just help someone do something better.

What does on-call look like for you?
Post reply on HN