You could try posting here the specific industry/niche and the software that’s not working for you, and chances are they’ll have three new competitors before Monday morning!
Ask HN: Should we bring software dev in-house?
231–240 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#232id be happy to hop on a call and listen and explain what you should do, free of charge. you can take my plan to someone else to implement (im too expensive)
Re: Ask HN: Should we bring software dev in-house?
#233Whilst I don’t have a ton of experience in logistics, I have helped executives in other industries map out transition strategies. For the software in question, a few considerations come to mind: - how critical is the software to your company’s competitive advantage? - how big is the vendor team supporting the software? - how much revenue/customers does the vendor currently support? - how much of the software is entir…
This comment lists most of the questions I would ask. Couldn't agree more. Only advice I would add for the OP:
Check if your contract with the vendor includes any business continuity clauses. What happens to their solution, their code, and your data if they go out of business or get acquired (by someone else)?
One relatively common option is to have them put their code in escrow, and get access to it if certain events happen. You can probably negotiate this into your contract if you have enough leverage.
If their software is critical to your business, and you feel they are stagnant and underfunded, there may be some risk here you can address today - check with your lawyers.
(also, just noticed the username I'm replying to... hi Teren!)
Re: Ask HN: Should we bring software dev in-house?
#234It all hinges on hiring the right people for the job - you may want to find someone very senior who perhaps doesn't want to build it themselves, but can help you evaluate tech talent - help you hire the first few key senior people to get started.
And I'd say, if whoever you hire can get the database schema nailed down more or less correctly in the first iteration or two - you'll be good. It all hinges on finding someone who's done this sorta thing before, won't over complicate it, and can wring out the first level of mistakes before implementing an entire software system around it. Knowing the business in and out would definitely help here.
Re: Ask HN: Should we bring software dev in-house?
#235Earlier quoted context omitted.
> I've found that the best programmers (and the ones you'd want) are more interested in the technical aspects of the problem and business and customer impact, rather than the sexiness of the business domain. Just want to heartily agree with this point here. Certainly many of us do get excited about particular business domains from time to time, but in my own experience, I get more excited about technical challenges,…
For me red flag is that for OP as a developer I will end up being a cost. Even with all the good words he wrote how company can improve by doing own dev - reality is that company makes money in logistics and as a software dev I would be second class citizen and cost center. That is why I much rather work in company that makes money on software, because here I am money making.
> company makes money in logistics and as a software dev I would be second class citizen and cost center
If software can make the company provide better logistics more efficiently, it's not a cost center, it's an enabler. It pays for itself in reduced costs and increased revenue.
Re: Ask HN: Should we bring software dev in-house?
#236I think you are asking the wrong question. Before you decide what to bring in house, you need to have an IT strategy That sets out what components of your desired solution should be built, and what should be bought. You need to have a view about which technologies you will use, and why. What is your end state IT architecture? Have you prioritised your objectives and requirements?
I understand your current systems are holding you back and there may be no appetite to get a bunch of expensive consultants in to answer all these questions. But just hiring a bunch of devs without a plan for what you want them to do is a recipe for disaster.
Re: Ask HN: Should we bring software dev in-house?
#237Do you have technical people local to manage your near/off shore resources?
Re: Ask HN: Should we bring software dev in-house?
#238I’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…
However the problem domain that this fellow has 'Logistics' Can be a big scape, but more importantly the nature of the logistics is important whereas "shipping logistics for a parcel" is a hell of a lot different than logistics with specialized compliance, handling, security, discretion, coordination-of-other-entities, does.
It would be interesting to know what niche is ~$300-400 million ARR thats being handled by 3rd party contracted infra?
---
However, having worked as a high-paid consultant on high ticket/visibility/risk projects -- HN is giving some great advice. (hire and empower a great lead - allow a new approach. Ivolve your staff and have what you need built.
Continue to work with the external that you have, and as a requirement (where appropriate - have them respond to your lead on any questions your lead comes up with)
Re: Ask HN: Should we bring software dev in-house?
#239First off, as an occasional customer of logistics providers who sees so much crappy software held with duct tape and a wish, I completely agree that it is smart to bring it in house.
You need a solid team of at least two - a product person and a builder, preferably who have worked together before. Notice I didn't say CTO because some CTOs are admins rather than builders. Notice I also said product because you don't just need to build, you need to know what to build - and that might be part of the problem, if you're the one spec'ing the features and prioritizing bugs, you need someone to do this full time for you.
I'd look for one of the two to start with and make it clear that you will expect them to build the team up as their very first responsibility. Most great engineers have product people who they can recommend and most great product people have software engineers they can recommend.
I have come across people who operate very well with a specific offshore software dev team. If they can come in and bring their offshore connection, all the better (can be 1/2 as expensive as US). But in the formative stages, if you can afford it, I highly recommend an in-person team rather than off shoring, because it's a crapshoot that can be very expensive too if it doesn't work.
Re: Ask HN: Should we bring software dev in-house?
#240Honestly, this sounds like a project I would enjoy working on: designing and building a brand new system, learning about a new kind of business, encoding some complex business rules into code, being able to work closely with the people who would be using my software (ie other folks at the company).
However, I would be worried that software development at a non-software company would be a second-class citizen. Lots of pressure, and unhealthy culture, upper management that didn't understand the nature of software development... How would I know that I would have the space and the support to do good work in a good environment?
I actually had a good time doing this at Target of all places, where I got to work on building a new supply chain optimization system from scratch. It was a lot of fun and had a lot of impact, but largely because our team was insulated from the "normal" way of working at Target for several years. But, eventually, the Target way of doing things caught up to us and most of the best people on the team left within a couple of years. (Side note: we were transitioning from a third-party system that ran on a literal mainframe, but I was never involved too directly with the legacy system.)
So, my advice? You can definitely hire legitimately strong programmers even in a non-tech company, but you need to solve two problems: how can you show-not-tell that the software team won't just be a cost center without the space and scope to do good work, and, once you can do that, how do you get the word out to strong programmers? I've seen companies do this well but always in pretty context-specific ways; there's no universal solution. Just saying something "we're like a startup inside a bigger company" won't do because a) everybody says that and b) it's too fuzzy. And how to get the word out, well, I really don't know much about that.
Side note: happy to talk more about this if you're interested.