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

Can those employees generate their salary in value? How long can they do so?

It makes little sense to in-source dev if you have 6 months of work that revolves around bugfixes. Less still if what you're building isn't saleable, which in your case it sounds like it isn't.

The other side of this coin is, you suck at dev management. Your whole company does. All companies start at that point. Any project you pickup at this point is going to feature creep to the moon and cost 2-3x as much as it should because it's not going to be well defined, and it's not really going to accomplish what you'd like to accomplish.

The best advice I can bring you is, take on a SMALL project first, very small, like a single-purpose app, pick one thing at your company that really sucks to have humans do and isn't complex, build an app to do that. Probably use outsourced contract dev/devs to do it, have them bid on it. Make sure your product requirements are bullet pointed out and crystal clear. Your mother should be able to understand them. Do not set an open ended timeline, because you're going to get high bids as it's a clear sign you're a newbie and are going to be expensive to work with. Project check-ins/meetings should be defined and scheduled, create stages and meetings for those stages, and review them upon completion, again, all defined in the project pitch.

Basically, you want a developer to be able to take what you've written, and complete the project with no surprises.

Do that a few times, make the project a little bigger each time. You will learn alot, and once you have a few things under your belt, you can start to consider hiring your own dev team.

You absolutely can attract talented developers; this company preferred to hire very experienced people, and that translated into minimal management. (Which also created a high level of ownership by the devs, because they can proactively fix what needs to be fixed and directly add/fix what people/users are complaining about.) They also used a functional language, which tended to limit the pool of available people to people who were capable of quickly coming up to speed.

Even after you have something working, you'll probably end up having to do a fair amount of development just to "stay in place", since the needs of the business are (presumably) constantly changing. Sometimes this can take longer than you'd like. But the advantage is that you get exactly what you want. If you're struggling with your current software, it seems reasonable to write your own. You might want to start with writing just the most frustrating part, and then the next frustrating part, etc., rather than trying to implement the whole thing. Especially at the beginning it makes the project smaller, lower risk and you get more successes along the way. And if it doesn't go well, you'll find that out earlier.

Let me build this thing for you. Exactly, to your specification, by sitting and working with you and your team, and solving exactly your problems.

Once the solution is done, you can either buy the software org from me or chose to license it from me.

Happy to talk details.

Our client has tried what you're discussing several times. They are a bit bigger (10x) than your org, but never built up the software muscle in house despite hiring and firing entire teams to attempt to build stuff in house. We've handled one corner of their offerings for nearly 2 decades while all their other teams have cycled in and out of internal and external suppliers.

You need a new vendor, if you can't afford it, you may not be able to afford a proper in-house team. I've worked with great vendors that would not give you this experience, and vendors that would you give you far less than you're getting now.

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

Yes of course you can. But reach out to engineers in your network that work for non-FAANG companies and understand why.