A bit of a naive question but can you acquire your provider's company, or poach their programmers ?
Ask HN: Should we bring software dev in-house?
331–340 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#332It sounds like you're running with your breaks on, because of the software issue. So, finding someone who can make the software work right can at least remove that obstacle from your business.
For this, I would hire an experienced developer who can look at the current solutions you are using, the third-party product + your low-code solutions. If you find a good developer, they can at least design a product that integrates the functionalities from your 2 existing solutions. Even better if they understand User Experience.
Another good sign is if they want to build it in a "boring" technology. Java would be a good choice, because it's robust and also because it's easy to hire for it in Europe.
Frankly, for starters, you need Design + Frontend + Backend + Infra. You either get one person for each, or a person that does the first two and another for the last two.
Also, I recommend doing a fixed-rate project with milestones. You can use a generous budget (50k - 100k), depending on the complexity of the software. This way it's in the best interest of the people you hire to deliver on time. You release payments when features are delivered and meet standards.
If you want to talk more, my contact is in my profile.
One more thing, which I think is very important. If you build the software right, it can become a force multiplier and enable your company.
Re: Ask HN: Should we bring software dev in-house?
#333My biggest suggestion is to look into ways that the transition can be done in stages, rather than trying to replace everything in one big swoop. This is likely doable, especially since you are already having to rely on outside tools. Then to start building, hire a small team (employees or freelancers) and have them create a single piece of functionality that can be swapped out from the current workflow. This type of…
Strangler Fig pattern works really well: https://martinfowler.com/bliki/StranglerFigApplication.html
You split out segments of the old application and rewrite it, slowly moving traffic over - eventually slowly strangling the old application and replacing it with new parts.
Re: Ask HN: Should we bring software dev in-house?
#334This is a variation on the "build vs. buy" question that has been active in IT for decades. And answered for decades, too. Building something yourself makes sense only when that something drives the unique value prop from your business. But if your needs are something that is more generic, buy it. So it all comes down to what you said about operating in a specific niche. If that niche is your value prop, and the reas…
Yes, and also when you hire software developers you want someone who understands that they are running internal tools which is COMPLETELY different from building consumer apps. Simplicity is key. Keep the team small and lean. Also the build vs buy decision has to be made with every feature. If its not your competitive advantage just buy it. Dont make a new database, just use postgres etc. There are a different set of…
This is a huge thing.
Way too many internal teams build their tooling "too well", to a point where it could be a separate startup product in itself with a tiny amount of extra work.
Like game companies writing their own engine and ending up as a game engine company eventually =)
Re: Ask HN: Should we bring software dev in-house?
#335Earlier quoted context omitted.
> 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. That’s taking the second step before the first. If this is going to work at all, first try to build a solution that works for you . Once you have that, then there may be a chance that others will find it useful as well, but it is a whole…
+1. Last startup I worked at basically tore itself apart because certain leaders fantasized about spinning of "AWS for X" before we had even met our own needs.
Same here, C-staff tried to start a cloud service company "but X".
There was no market for it, it was too expensive, too unwieldy and too nonstandard.
AWS could do 90% of what the custom cloud product could and the last 10% was regulatory stuff, not technical.
Re: Ask HN: Should we bring software dev in-house?
#336Working on logistics software has been my day job for 14 years. You can attract experienced developers by giving them autonomy, GOOD pay, and a healthy work environment. I wouldn't trade a "cool project" for any of that. It does sound like the best solution would be to bring most of the development in house, but integrate with third-party APIs where it makes sense (ie, the data transfer piece you referenced)
There's something about creating software that lasts for decades and is actually used by actual people every day.
Re: Ask HN: Should we bring software dev in-house?
#337Both the strategies have their own pros and cons. For most companies having an in-house team works best, but then you would need to hire someone to manage them.
Getting work done through outsourced agency is always tough. You may try to change the vendor the the challenges would always remain.
What works best is to hire a single senior developer to begin with, who can work closely with your third party team. He can initially get hands on small bugs or features. Slowly you can start building inhouse. Finding a senior person as CTO should be done only after a major chunk of things have moved in house.
Re: Ask HN: Should we bring software dev in-house?
#338Earlier quoted context omitted.
This is excellent advice but I would back up a few steps and do a few things before bringing in a freelancer team. Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible. Then document the requirements for this part thoroughly. This allows you to: - Have something smaller for your new team to cut their teeth on. - Ensure you have collected all the diffuse domain know…
> This is difficult and time consuming so start now. A specific difficulty you are likely to face: Your expert employees are busy doing their jobs. Writing requirements means taking attention away from that work - a difficult proposition, especially if they have managers who will ask why their KPIs are slipping.
These experts may also be hesitant to change.
It could be due to many different reasons. One the personal spectrum, they can overvalue themselves or have fear of loosing their jobs.
On the technical spectrum, they can be stuck in old tracks without computer knowledge and not thinking outside of the box. For example, in their eyes the objective is to move PDF file from directory A to directory B. In the ideal automated world, why is there a PDF in the first place? Basically "if you asked what they wanted they would have said faster horses...".
Re: Ask HN: Should we bring software dev in-house?
#339I 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…
> Building and running your own software team is probably around $5M/year
Do people just pull random numbers out of their ass with no actual experience? 99% of developers do not live in Silicon Valley on 1m salaries.
Re: Ask HN: Should we bring software dev in-house?
#340I would start with a business case - what are the benefits, is it going to generate revenue or reduce costs, when do the benefits start to be realised.
Then look at the cost in starting to develop what you need, and how you’re going to get started.
Are there existing COTS systems (e.g. SAP, Dynamics, Salesforce) that are extensible but can do 60% of the base functionality out of the box? Can you start by integrating two systems or using your low code platform to prove the concept? A couple of engineers/freelancers/external shop for a few months is a lot cheaper than hiring a whole development team… others in the thread have given you a reasonable estimate of that.
Think about what’s the MVP needed to start showing ROI. Maybe do a smaller business case for that.
Look at the payback period internally and ask what hurdle rate is needed to invest from your CFO.