Live data from Hacker News

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

news.ycombinator.com

101–110 of 607 posts

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

#101
Invest in high quality software kernels and professionals that can comfortable build with them; divest from low-quality "wrappers" around said kernels, which is most SaaS.

>90% of SaaS are some (expensive, low-quality) wrapper around (free, high-quality) Node/Rails/Django/Spring + a FOSS RDBMS, with more features than you want and less than you need.

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

#102
post #6

> We're using a third-party product that functions, but barely. > Our business operates in a specific niche and there are no other providers who cater specifically to our industry. If you decide to do in-house, I’d recommend thinking about competing against existing as a new revenue stream, and spinning it off as a separate business unit as much as possible. I imagine this is implied in your question but it wasn’t sp…

Remember that writing bespoke internal software and general-purpose commercial software are very different things with very different budgets, and you will need support staff. Do your research and talk with someone who understands commercial software before planning any kind of spin off. These are two very different goals, even if one would hypothetically fulfil the other.

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

#104
If you go down this route, try to hire someone from your provider that knows the current product well from the inside. If there is someone left, of course.

At a previous company, when the provider of our software started stagnating, we brought the development inhouse by hiring his best engineer and a few good freelancers, then slowly phased them out in favor of employees. But an important difference was we owned the code because it was a bespoke solution from the start.

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

#105
My advice would be: Specs specs specs.

If you're going in house, or buying in a consultant, you need to be sure about functionality and why you want it. That way you can draw up small, medium and long term goals for what you _need_ and how it affects the business.

The risk with inhouse (or contractors) is that the devs get bogged down in what tool rather than how to solve the business problem.

make sure you have a good idea about the processes the software is supposed to handle, and what data you need for that.

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

#106
Like others mentioned get a freelancer or an external team for starters. Engage them for 2 weeks. I run a dev agency. I recently made a chrome extension for a customer for the first time and it just took us 2 days instead of 2 weeks because we leveraged claude sonnet. So building a software today is incredibly easy, you can build almost anything at an incredible faster rate. So if you set 2 weeks engagement and you can see how much is done, you will know how to work with the person and team and also will be confident in your plan to move away from the software you're using. You could then have this team or freelancer document how this is setup etc and you can slowly start hiring in house. For eg, it costs like 800 USD for two weeks in our case since we are based out of India, so when you outsource to India, Vietnam etc you have low risk, you can quickly experiment instead of contemplating.

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

#107
Maybe the limitations of the software arise from the fact that it's being sold at a price that's relatively too low? It sounds like it's very niche software with only a handful of users like you at most. With a small number of paying users, even if each one is paying thousands per month, the tool's team might be too underfunded for it to do much more than maintenance.

To do it in-house, you'll probably hire 2-3 engineers. You'll aim to have smart people who can self-manage, design, and who can intuit the business requirements. Your part-time duty will become to be the product's "CEO" of that whole thing.

So you'll end up paying at least €16000/mo (3x€6000) in salaries alone. Data access, storage and infrastructure will probably cost a bit too. How much are you spending now?

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

#108
> Besides, can we even attract experienced developers to a non-glamorous industry like logistics

Money! Work life balance. Good benefits.

I currently have zero interest in the business idea of the place I work. But they pay well, aren't on my ass if I wake up late or need to visit a doctor appointment, and provide zero cost benefits. I have no interest in making even more money or trying to climb. Take care of your people and the business line doesn't matter. Just make sure you get what you're paying for.

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

#109
The best developers I've worked with, in my career, were all from contracting firms. (Distillery, Ralabs, EPAM.)

First thing: If you outright fire your contracting firm, you'll loose all of their knowledge. This could harm your company more than you realize, depending on how much your business relies on their knowledge of the code and your processes.

What I would do is have some employees who work for you, who are experts and "in charge." They should be experienced in hiring and screening, and should be able to give you an honest assessment of your code base's maintainability.

At that point you can decide, with your expert employees, how much to outsource with your current firm, how much to outsource with a new firm, how much to insource, and most importantly, what you are doing wrong in your relationship with your developers.

The thing is, software development can fail for many reasons, and a lot of them have more to do with you than your vendor. You might have unrealistic expectations, you might need to work more closely with your contractors, or your contractors might be "warm bodies punching a clock." It's hard to know unless you have people you can trust hands-on.

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

#110
I've faced a similar situation as an exec in a different field. Some questions consider:

1. Are you trying to replace the system-of-record? I don't think it changes the technical merits of going in-house, but it does raise the stakes. It becomes more important to engage other stakeholders, and to prepare the business processes/workflow for changes. Secondly, there will be a transitional period where you will need to use both systems, so you will need to have a way to reconcile and merge conflicting records from both systems into a single source-of-truth. Again, these are not deal-breakers, but just things to think through.

2. How many integrations do you have with external parties? You mentioned EDIFACT and government institutions. Integrations are often the dominant source of project delays and complexity.

3. Management structure - you can hire someone to run the program, but like it or not, you are the corporate sponsor. It's success or failure will fall on your head. Whether you hire a "CTO" depends on your technical management ability, but I'd stay pretty close and pretty involved.

4. Attracting talent - as always, it's a question of money and time. You need a healthy budget for a healthy amount of time. A good, experienced senior dev consultant will generally have a lot of contacts, and can pull in others if you provide a solid environment, budget, and roadmap. I wouldn't be worried about not being in a "glamorous" industry - the people you want won't care about that. Some kind of equity or performance-based bonus can really motivate people to deliver value to the business.

5. Roadmap - take a vertical of the business that is more stand-alone and start there. You want to show an end-to-end in-house solution that solves a real problem. It will help you diagnose exactly what kind of challenges, culturally, organizationally, technically, (and even legal/compliance) that you have to deal with. It will be a confidence booster to the rest of the organization that this can work and will be successful. Adjust expectations and timelines as needed.

Would be happy to discuss more, just DM me.

Post reply on HN