Consider using a low code platform to test your thesis first. Use a platform like Budibase or something, that's open source, you can self-host and use your own database for security reasons.
Ask HN: Should we bring software dev in-house?
421–430 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#422I used to run the "Enterprise Apps" org in a low budget F500. My team of about 125-135 (globally distributed in US, MX, BR, IN) managed dozens (hundreds?) of internally developed apps and a number of externally licensed SaaS & on-prem systems.
The reality is this: if you are not a software product company and you decide to create internal tools yourself, your life will become one of perpetual technical debt, and deciding whether to prioritize new development vs refactoring vs platform modernization. When you license products, you just throw money at the problem, but when you DIY it, you end up also needing to implement things like Change Control Boards, a real PMO, more security & privacy controls/competency, and internal tech support functions. This can work and be cost effective, but you really need to go in with your eyes open and account for all this "mess" you'll be creating as you create this new team.
It can absolutely work and save money, but it requires 1) xfn executive buy-in and clear agreement around change management and feature development prioritization, and 2) a budget for things that go beyond just the software development.
Fwiw, if this is an "IT" function and you're not a product company, you'll be able to save money by employing "enterprise software developers" (e.g. IT staff) rather than SWEs (tech product company folks). You'll also benefit from their experience navigating the complexity that comes with all the crap I listed up above, much of which is fairly foreign to small tech companies.
Re: Ask HN: Should we bring software dev in-house?
#423Earlier quoted context omitted.
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.
What does on-call look like for you?
Most business do not require on call for their internal tools
Re: Ask HN: Should we bring software dev in-house?
#424[deleted]
Re: Ask HN: Should we bring software dev in-house?
#425[flagged]
Re: Ask HN: Should we bring software dev in-house?
#426 Besides, can we even attract experienced developers to a non-glamorous industry like logistics?
Re: Ask HN: Should we bring software dev in-house?
#427Earlier quoted context omitted.
> 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.
Well I do agree everyone is a cost. But it still doesn’t make company dynamics not true. Logistics company will have bunch of logistics specialists as management and they will see it as revenue center and will see „their own kind of people” as more important.
The management sets the company dynamics to whatever they want.
That idea of costs and profit centers is bullshit that only bad manager believe in. It may or may not be the case with the one company of the OP, we don't nearly enough information to judge.
(But the fact that the OP is reaching into IT with the goal of improving their people's productivity is a very weak indication that they are better than that.)
Re: Ask HN: Should we bring software dev in-house?
#428I 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.
> Do people just pull random numbers out of their ass with no actual experience?
That’s a weird question to ask someone who stated their relevant experience in the first sentence of their comment. I just looked him up on LinkedIn and it checks out, you can do the same.
If you have substantive objections to what he wrote, perhaps it’s better to state them explicitly? You seem to say that the figure he suggested is based on developers being based in a very expensive location, and therefore not generalizable.
What numbers have you come up with that contradict his?
Re: Ask HN: Should we bring software dev in-house?
#429I’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…
I'm not sure they necessarily need to know it cold at the start, but they do need to have access to someone who knows the business cold, and they need to care a lot and be willing to dive into the business details.
> but they do need to have access to someone who knows the business cold
Yes. Very close access, to the point where that someone will spend almost as much time working on the software as the software developer.
Re: Ask HN: Should we bring software dev in-house?
#430Earlier quoted context omitted.
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.
Ive never seen it work in practice. Every time I see it end up with Appv1, Appv2, Appv3 all running at the same time because the new systems cant move quick enough to add new features so they get added to the older versions. But the newer systems offer unique things the older didnt. So they all coexist and never die.
There's something wrong with your experience, because the entire point of making a new system is that it will eventually move faster than the old one.
Maybe your strangling software is still too ambitious.