>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.
Ask HN: Should we bring software dev in-house?
101–110 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#102> 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…
Re: Ask HN: Should we bring software dev in-house?
#103Re: Ask HN: Should we bring software dev in-house?
#104At 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?
#105If 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?
#106Re: Ask HN: Should we bring software dev in-house?
#107To 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?
#108Money! 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?
#109First 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?
#1101. 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.