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.
Ask HN: Should we bring software dev in-house?
351–360 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#352I 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…
Re: Ask HN: Should we bring software dev in-house?
#353For the opposite perspective, https://danluu.com/nothing-works/ .
Re: Ask HN: Should we bring software dev in-house?
#354What 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?
#355Re: Ask HN: Should we bring software dev in-house?
#356It 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?
#357I’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
Re: Ask HN: Should we bring software dev in-house?
#358Re: Ask HN: Should we bring software dev in-house?
#359The 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?
#360I 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.