Live data from Hacker News

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

news.ycombinator.com

311–320 of 607 posts

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

#311

I have no experience in hiring programmers at all, but here's a couple tips based on my experience working at a company, and also family member's experience who is involved in hiring So never ever hire a freelancer until after you've talked to a bunch of their previous clients. Not sure if this is possible though, but if you can, its probably really good I've seen what a non-software engineer hiring freelancer progra…

I think I may be the kind of person we're talking about here. I wouldn't ever let a new prospect client talk to previous clients. They'd all immediately compare rates and try to low ball me. Conversely, I'd never take on a client "cold". Too many a-holes, crazy people and fraudsters out there. I only work for people I have a long history with, or on occasion the next transitive hop out on the network from those people. I would suggest that the counterparty do the same: reach out into their network and find someone where they can get a strong recommendation based on years of collaboration. If you can't achieve that, don't proceed with the project.

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

#312
post #206

Earlier quoted context omitted.

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.

>The myth of revenue centres was made up by sales & marketing.

Funny that sales and marketing sells and markets itself.

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

#313
It's really hard to give advice without knowing the complexity of the software, desired SLOs, how much you currently spend on your currentvendot, and how many $$ your current solution is costing in lost productivity/growth.

You haven't named the third party product. I presume because it reveals too much, but perhaps you could name it along with its competition so that we can get an understanding of complexity?

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

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

My caution is at the end of working with free lancers you have no technical retention.

My company worked with freelancers/consultants for years, it just delayed the inevitable. You need to start building your in house team.

Find the ONE. See if he can build anything on their own. If they can/thinking is good, then scaling with freelancers seems good because you retain knowledge and long-term vision/oversight.

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

#315
post #243

Earlier quoted context omitted.

I think there's a big risk there of hiring a "CTO" who hasn't coded in 10 years and it's just a paper pusher. Ask to see the GitHub.

This will filter out 90% of candidates, but yes. Problem though is you need another turtle layer to evaluate the git commits. They might have been just changing CSS.

Maybe chatgpt can assess!

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

#316

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.

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

#317
Long thread so I'm not sure if someone has already made this observation, but -- reading your description of the single entrenched supplier to your industry that comprises your company and a set of competitors, made me wonder about "going bigger". This is the idea: yes start a team to develop a greenfield modern solution to meet your needs, but do that with the goal to eventually spin it out as a separate company that is also a vendor to as many of your competitors as you can sign up. The benefits to this approach are that more resources can be brought to bear, meaning better developers can be hired, and the cost can be shared between the participants. This has been done in the past for example by the airlines with Orbitz, and media companies with Hulu.

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

#318

Earlier quoted context omitted.

Having had the fun of taking over a project from a bunch of clever contractors I would caution: It may be too clever. There is value in simplicity and a stake in long term ownership. Some article here recently associated technical debt as lost institutional knowledge so handing the most key decisions to contractors has also drawbacks. One needs an integrated approach for design, build, maintenance and operation.

Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality. Those foundational architectural decisions have a way of becoming set in stone, long after the freelancers have left, dooming the project to scalability and latency problems which seem to linger forever.

I've seen equally many projects never achieve lift-off because they were stuck in analysis paralysis trying to architect MVP for scalability, extensibility etc.

And even if that succeeded you often end up with fear of change because the complicated architecture can't be touched.

It's really important to have the right balance here, but KISS and YAGNI are often easier to scale when you need it, than the reverse. If you don't have the mentality that the MVP must never be rewritten.

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

#319

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

Post reply on HN