Ask HN: Should we bring software dev in-house?
We're using a third-party product that functions, but barely. The provider is understaffed and unresponsive and the platform is stagnant. It's a fight getting basic bugs fixed let alone new features implemented. We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.
As we are growing we're running in to the limits of what this product can offer. We're being hampered in our speed of execution and missing crucial insights. I feel like we could do much better with a product catered specifically to us.
On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.
Besides, can we even attract experienced developers to a non-glamorous industry like logistics?
We'd particularly appreciate input on:
Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning from third-party to in-house software (success stories and cautionary tales). Potential pitfalls we might not be considering. Alternative solutions we should explore.
Has anyone here navigated a similar transition? What worked? What didn't? Any advice would be appreciated.
606 comments
[ 1.00 ms ] story [ 371 ms ] threadYou first need to hire somebody rather senior to be a "CTO" or "Engineering Manager" who is first of all supposed to help you consider "potential pitfalls" and "alternative solutions." Next I can picture that person putting together a 3-5 person team which could take a big bite out of your problem in the course of a year.
Personally I have done many projects in e-commerce and I find logistics to be meaningful because I like knowing my system controls activity in the physical world. Today is a good time to be hiring software devs because the job market for software devs is softer than it's been in a while.
The right person fulfilling that kind of role can make all the difference.
When there were no comments I wrote a little message which instinctively favors focused CTO effort myself:
At the one extreme you write all new code.
At the other you have a turnkey system using code that is already written, perhaps a system brought together by combining various task-specific apps.
Or anything in between.
You still may never be able to hammer everything to perfection.
Either way as much code as possible should be built against a completely non-moving target, with a core that ideally meets a stable unchanging foundational requirement, the objective here is to have a digital enhancement/replacement of a highly-performant optimized manual workflow, whatever can go forward with no further updates or maintenance. Quite simply this makes for the best long-term investment if the code just plain lasts longer after it's paid for.
The moving-target stuff or component (which might include government regulations) might be better off "leased" since it might never be a very good investment anyway, especially not long-term.
Either way a CTO or equivalent should be the ultimate expert on how this gets done in your specific company, having more than just domain expertise, but specific-company expertise on top of that. The deeper and longer-term familiarity the better, must be an absolute master of the detailed workflow before any type of irreversible commitment should be made. The level of trust needs to be up to the highest integrity of executives, there can not be a doubt that decisions are in the best interest of the company.
You may already be a true master of the workflow and with enough mastery be more suitable for directing a team that could craft the most ideal solution, as long as you actually know how to program computers. You wouldn't really need to be up-to-date on any specific languages that are popular now.
Someone needs to fill or acknowledge a CTO role, pick up the ball single-handedly and don't make another move without making sure where the correct goalpost is. A little lonely indecision when you first pick up the ball is worth it if a CTO can then lead a team most directly to the desired end zone. Building a team from the ground up if necessary. It may not be completely necessary, but when that's not off the table, it's a whole new ball game anyway. More options, but probably gives rise to additional levels of uncertainty that need to be resolved.
If you don't do it right it won't necessarily be more suitable than it already is, and when that's the stakes there's got to be a responsible individual who can put in full-time effort however much it takes, with the resources appropriately allocated to back it up. The same CTO needs to be capable of single-handedly being the only "tech" employee, served by their own carefully orchestrated select contractors, or at the other extreme capable of building an in-house team to make things better from the ground up if more beneficial.
One person will have to make sure it comes out better than it is no matter what, or it's less likely to come true.
Regardless, it can be like servicing airplane engines in flight, so that's another outstanding skill to keep an eye out for.
It has one customer (initially).
If it doesn’t pan out you can drop that shitty vendor.
1. You don't necessarily need to bring your development in-house. But you are looking to move away from your current provider. You might want to think about using contractors to build a new platform - possibly hire a software house to do it for you, rather than hire individual contractors. There are lots of small software houses who would love the opportunity to build a long term relationship with a client of your size
2. You need to be clear about your budget. How much are you paying your current provider? What would the development cost? What are the opportunity costs of the missing insights you are suffering from. What is the RoI on a new platform?
3. The absolutely critical thing you need to think about from day 1 is the migration onto the new platform. How are you going to get data off the old platform onto your new platform? How are you going to introduce the new platform. Can it be a phased introduction or is it a "big bang".
4. You need to have some good people in your organisation to manage the migration. People you trust to tell it like it really is, not to tell you what you want to hear.
5. I would recommend that you start by identifying the absolute minimum functionality you need to keep your business running smoothly. That is your initial platform (the MVP). The data you need for that MVP is the data you need to migrate initially. Don't try to do anything more than this in your initial migration - keep everything as simple as possible.
6. Do put procedures / checks etc in to ensure you maintain data quality across the migration. And if you can clean up the data as you migrate, so much the better. Do test all your data migration and platform migration before doing it for real!
7. After the migration, you then keep building the functionality, and bringing more data in. But concentrate on stability and keeping your business running. Your migration should be invisible to your customers. If you are having to making excuses to customers about why you suddenly can't do things, or meet your normal standards, then you are doing it wrong!
Hope this helps :-)
Feasibly, we could replace functionality bit by bit.
> 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 specifically mentioned.
> Besides, can we even attract experienced developers to a non-glamorous industry like logistics?
Yes. Are you kidding? Non-glamorous reads as safe in uncertain times. It’s a positive point that will be a marketing multiplier for attracting talent, if coupled with other indications that your business has clear goals and good ideas.
Sorry I missed this thread, I think it was meant for me.
I currently work for a small logistics company as a senior engineer. I am pretty happy and not looking for work (like many of the comments here), but I am happy to converse or schedule a call sometime if you're interested to discuss. 0x03e14@protonmail.ch.
Other commenters had I think the correct answer - you just need ONE REALLY GOOD IT co-founder or vice president to help coordinate that, who can both leverage outsourced solutions but also build things on their own, and most importantly who truly understands and cares about the logistics and cost savings.
I see a lot of dysfunctional and large tech teams building out over-complicated solutions with zero industry awareness, instead of lean solutions.
Did you see this article [1] here from a couple months ago about Temu's semi-managed delivery model? I was pleasantly surprised to see logistics on YC. We don't talk about it enough but it's the backbone of global economy.
Best of luck! Let us know what you decide to do and shoot me an email if you want to connect.
[1] https://news.ycombinator.com/item?id=40497472 - Temu's semi-managed model could change everything
Would be interested to know the industry and any specific requirements that are very unique!
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 lot of additional work to turn an in-house solution into a proper product, and your in-house needs are unlikely to translate 1:1 to other companies, and vice versa.
Another option is to consider building in the open. If the technology is not a differentiator in your industry, then maybe you build it open source under GPL. That way you can build a consortium of similar firms to build a genuine alternative to the status quo while preventing lockout.
You don’t have to decide about proprietary vs open source release now… but you should consider taking steps to preserve those options down the line.
An internal user that can wander over to Bob and say hey, this thing isn’t working quite right, I’ll grab a coffee with you and we can talk through it, is very different from a paying corporate who will not tolerate service falling below a certain standard. I joined a company where they were trying to transition an internal piece of condition monitoring software to be a SaaS app and it went really badly wrong, the sales people seemed to assume it was ready for this but it just wasn’t and needed a huge amount of hardening and security work, not to mention features to make it easier to use.
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.
Most engineers don't love joining a giant co. and using tech we are not fond of.
A startup mindset is importantly for the first hires, but selling software is an aspiration not a requirement.
That aspiration can be distracting from simpler business problem solving solutions too, so be clear “new codebase” when we are ready to sell…
Shortcuts for us, no shortcuts on the software resell company.
I dunno how technically difficult this is, but consider either hiring an expert on this stuff, or hiring your core software engineering team, and hiring a consultant/freelancer type who is an expert in this stuff to get it done / up and running.
> Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning from third-party to in-house software (success stories and cautionary tales). Potential pitfalls we might not be considering. Alternative solutions we should explore.
Part of outsourcing, is you're not just buying the technical solution, but the support and potentially the liability if something goes wrong. So it's important to consider what secondary benefits are baked into using a third-party, and deciding if you have the ability and appetite to support those as well as developing the tool.
I sort of imagine that replicating the tool / business process is the easy part, it's stuff like setting up and wrangling EDIFACT that will be the hard things.
NRE means that the IP remain their, and they will be able to amortize the costs across multiple clients.
Assuming that this vendor is unresponsive because they're not incentivized enough (e.g. fixed pricing or SW licensing fees), not because they're incompetent.
Also, most software projects fail[2], especially inhouse ones. I would expect vendors to have a much higher "not fail" rate (but not necessarily "success").
--
[1] Non-Recurring Engineering
[2] stagnation is also considered failure
No matter what you decide, it sounds like in the short term there's no getting away from them. As such, I would attempt to open a dialog focussed on mutual success. If this is a niche, chances are you are as important to them as they are to you. Show genuine interest in the problems they are facing, rather than expressing frustration. Are they struggling in general? Perhaps there are ways to help them get back up to speed. What about you as a customer (e.g., too distinct a workflow) makes things extra complicated? Look for specific points of friction, and how to address those.
A viable option, at least to get started, could be to use them as a building block. For example, handling that data exchange you mentioned. Establish a simplified format that is still detailed enough for them to do what they need. Then have your own logic, however complex, construct the input to their system. Add something in the opposite direction as well. Over time, you'll have more and more components that are easier to replace, because of their limited scope. Finding another vendor or building more custom solutions won't be all or nothing anymore, which is exactly where you want to be.
Doing this in-house? I feel the challenges are already plentiful without that. Instead, lean more to the side of having a couple subject matter experts interact with a small(ish) software house. It wouldn't be the first time that eventually one of theirs jumps ship, tagging on a colleague or someone else from their network. Basically the team would build itself, organically.
On a final note, I just wanted to say this sort of stuff fascinates me. Likely you wouldn't have time for anything like that, but I'd love to see in detail what your business is doing, and how said software is holding you back.
https://frappeframework.com/
In the early 90s we worked as contractors to a company developing (DOS) software for them. They sold and supported it. They got acquired and after another year the new owners decided we were too expensive and took the development in-house (as was their right under the contract.) We moved on to some other things.
Bearing in mind this was simply a continuation of the existing product, not a rewrite. They encountered the following problems;
A) there were no existing senior people on staff with software development skills. So they hired a couple programmers but with no clear vision of architecture and no clear understanding of the implications of short-term decisions.
B) it was already a "big" system, so it took time for new developers to get up to speed. Their developers would get a job offer somewhere else (paying more) so they had to get replacements. (Remember bringing the development in-house was supposed to be a cost-saving exercise, so they didn't overpay.)
C) over the 6 years they stewarded this the product was essentially stagnant, with no major changes or additions made.
3 years after they took it in-house we spoke to them about a Windows product. We would build it (and pay for development) they would sell it (we'd get paid-per-sale). This took 3 years to build, and once that shipped the in-house work was abandoned.
My lessons from this saga were;
Developing in-house is expensive. And forever. Staff posts you add to do this will always be there. Development of big features will end, but maintaince is forever.
Whatever you have budgeted for this, it'll cost 10 times that. And probably 2 to 3 times your (current gustimate) budget for years after that. If you plan to recoup thus investment selling to others (we did) add another 0 on the budget. Going from in-house to "product" is not cheap.
You will need a senior systems architect who stays over the long run to make long-term decisions and to give the project "coherence". Some early decisions can be very important down the road.
Hiring is hard. You want people good enough to do the job, but who are also looking for job stability. Be prepared to look again every few years (unless you get lucky.)
My advice; figure out your budget. Have a sit-down, at very senior level with your supplier. Discuss your long-term relationship. Discuss how much you are willing to spend. Discuss how you might make the deal attractive to both parties. Make yourself important to them.
By FAR this will be the cheapest approach, and the least distracting for you.
If you can't come to a deal, figure out what it will take to transition the existing source code to you. Probably a big pile of money. It'll still be cheaper than writing from scratch.
Ultimately recognise that software development is expensive, and the management of it is hard and distracting. (And in many ways counter-productive). Your best hope is to rekindle your relationship with the provider, which recognizes that you need, and want, to pay a lot more. If there are reasons they can't actually do what you need anymore then figure out the best way forward from that.
If that product (area) could be named or sufficiently-described, the audience size & substance here on HN might lead to 10 new hungry sleek alternatives popping up within a quarter, which won't be satiated=stagnant for years to come and keep it maintained and improved to customer feedback (if they find takers and a keeping-the-lights-on adoption curve). It's a hacker but also startup forum. Why not, while gathering all this good advice on your question, also share what this is all about in terms of _what_ in your niche / b2b market corner is currently badly and under-served?
Plenty currently-underoccupied top talent here noodling on their techie pet projects while hoping to hit on some obscure / vertical / niche-specialized but promising real-world making&shaking (ie. sth to found build launch & expand) opportunity. =)
Once you do that you will probably have a reasonable understanding of your potential: budget, opportunity cost, RoI, risk, etc. for undertaking some kind of organizational change.
The actual software development side of this seems secondary until the above is done.
Pay a decent amount + meaningful perks (yes insurance, no tennis table), be decent people, give them agency and let them see they're making an impact, allow them to use whatever hardware and software they think it's best to do their job, don't force them out of remote work if remote work is what they want, be decent people, be decent people, keep bureaucracy and excessive process out of their way, and last: be decent people.
Pay them well, treat them well, and let them do their jobs. If a company could only do 2 of those 3 for me, my expectations for those 2 would be through the roof:
- Pay sucks? I need to feel like the most wanted person in the world and have free rein.
- Management sucks? I better be getting rich from this, and I’m working on what I want to work on.
- I’m going to be micromanaged? Hey, let’s talk about contractor pay, and the CEO needs to name a kid after me.
If a company does all 3 things reasonably well, I’m your guy. 2 of 3, they’ll need to make up for the missing bit. Only have 1 of the 3? No way.
(Miss me with any “you sound like a prima donna” nonsense. I don’t have crazy high expectations of those things. I do have a reasonable baseline though. I don’t work for free, I don’t work for jerks, and I don’t work where I can’t have freedom to do my best job for the person paying me.)
If your specific problem is well contained enough, it could be a good fit for in house. You mention that you’re filling the gaps with a low code platform. You could perhaps experiment with moving that piece in house as a trial run. You also say that your existing platform is stagnant, perhaps you could acquire them or the specific IP you utilize. You might learn some valuable insights about what you’d need to do in house even if you don’t end up seriously engaging in an acquisition or if it ends up falling through.
I wouldn’t be concerned about attracting talent, plenty of engineers in logistics already and it’s a hirer’s market right now.
Anyway, the devil’s in the details as you mentioned, my contact info is in my profile if you’d like to chat, happy to give what perspective I can.
Treat your product team like wizards, not a cost center. Make sure the product director is a tech hire with business chops, not a sole tech hire (will let the team resume build) or a sole business hire (wont understand the peaks and troughs of velocity).
Ensure that the customer is clearly defined internally, that the KPIs are oriented towards the bottom line, and keep things well-oiled but lean.
Your best solution would be to spin off an internal company with eventual plans to commercialize what you build. You want someone with startup/entrepreneurial experience.
Anyone who promises you a product within 3 months or tells you it will take more than 12 months for an MVP is snowing you.
Happy to chat more, my email is in my profile.
So it all comes down to what you said about operating in a specific niche. If that niche is your value prop, and the reason software is difficult for you, then yes, in-house it and build what you need.
As far as retaining talent, money talks. Put a number on the value that solid software would bring to your business, and if that number can support compensating a software team at market rates or higher, you have the potential to retain a team. However, it also needs to be a good team -- solid leadership, with a culture that matches what is expected by software devs: respect, autonomy, flexibility, and trust.
If all of that sounds reasonable, go forth and build. If not, accept the struggle of having to buy.
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 developers that can navigate through this than the ones who will reinvent the wheel if they can.
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 =)
This used to be standard.
PS1 and PS2 was coded in Assembly basically. No OS. All games had "drivers" in them. There was only renderware as a ready-made engine. Every Final Fantasy game was a new engine, FFX and FFXII are 2 very different engines. Bespoke only for that game. And beautiful. Same with RE4. Same with God of War 1 and 2. Unbelievable. Same with xbox and gamecube. Even in the 365 era, the Halo games were its own engine.
Look back at the dark Unreal 3 period 2006-2010. Most UE3 games looked like shit. A brown bloomy mess.
Code is an important tool, and also a liability. Hire devs that understand that.
Email is in my profile, feel free to reach out. Full disclaimer, we're a small consulting/contracting agency but I'm still happy just to talk shop.
It depends. In the end EDIFACT is just a protocol. If you go the Java route Smooks, for example, has pretty decent support to read/write EDIFACT messages.
If you do not want to do the heavy lifting yourself, both AWS and Azure provide SaaS services to do the heavy lifting for you (AWS: B2B Data Interchange, Azure: Azure Logic Apps)
> Besides, can we even attract experienced developers to a non-glamorous industry like logistics?
If you can provide a good salary and conditions: absolutely. And I should know, because my previous stint WAS in logistics :)
> Strategies for attracting and retaining tech talent in a non-tech industry
Provide a great work environment, good salary and conditions
> Experiences transitioning from third-party to in-house software (success stories and cautionary tales)
Start as easy as possible and don't hire anyone who wants to build a microservices based platform from scratch w/ almost zero domain knowledge at your org. Because that road will lead to nowhere. (Ask my previous colleagues who decided "we" should. I was against. They are still working on it, 3 yrs later, and nothing has been deployed yet because it still does not work properly.)
> Potential pitfalls we might not be considering.
Do not go the microservices road unless you really, really, really have to (and with good arguments!)
Need any more tips? Happy to help.
You can also do shim servers to translate between protocols - a long time ago, I had to interface with a Rails app (by another team, so I couldn't modify it) with an Emerson (the industrial giant) SOAP API, and what turned out to be effective was a Sinatra shim server that only converted JSON to SOAP. Now I could plug the two together without worry.
So - I'm guessing you could have a Java Smooks applet that translates from a JSON API to the EDIFACT protocol, and then you can write your main app in anything you want.
PS - Seconding the "don't go microservices", even though I'm advocating for one here - IMO, you only want microservices if they can be fully defined, independent products; a JSON/EDIFACT translation service would probably qualify.
The great thing about the modular monolith is that it gives you a fantastic foundation to grow: You can still invest in multiple teams each handling a certain part of your problem domain (due to the modularity); and because it is modular you could easily break it apart, and evolve it, into a microservices architecture if and when there comes a time you need to do so (due to extensive problems getting code shipped, or difficulties concerning NFRs defined for the architecture, for example scaling issues in production).
...unless you still do the same thing I'm advocating for when considering microservices: defining, and treating, each chunk as a discrete product.
If you can do that, great! MM or MS will both work, and you can probably decide between them based on the other factors you're dealing with.
If you can't, I would expect you to end up with a regular old monolith, so you might as well lean into it.
a) there is something on the other end that expects the data to be exactly in a specific format, which may not be documented correctly or in a language your devs can read,
b) the consequences of not getting it 100% right are expensive,
c) there are a lot of these "somethings", each potentially requiring their own format/special quirks for which the provider may have already built workarounds.
Is that the case? If so, trying to build anything yourself will be a nightmare, and my first approach would be to find something that handles this part and beat my data into it, even if it means using some fully-featured software package just for this feature.
Wikipedia provides a pretty good explanation: https://en.wikipedia.org/wiki/EDIFACT
The beauty of EDIFACT by the way, is that with enough time and effort it can get parsed and validated using any text processing tool at your disposal because everything is _rigorously_ specified by the UN.
For example I once had to do it with a set of specs, standard Linux text processing tools and a sprinkle of shell scripting for a school assignment.
Has it? If so, that's a pretty remarkable feat, and I'd love to be wrong about this one. And are the open source libraries good enough at it?
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 entirely custom developed vs modules built on top of other platforms?
- where does the software reside (on-prem/in-house acct vs mix vs vendor)?
Without knowing too much detail about the situation, if it’s an application that is easily testable and verifiable (I.e. perform an action results in observable actions), then it’s much easier to rewrite than an application with background functions and procedures so some level of due diligence or discussion with the vendor maybe useful.
Other alternative solutions that may make sense if software is critical:
- joint venture with vendor
- code acquisition + in-house team
- code/team acquisition
- short feasibility project to determine migration strategy
I’ve worked fairly extensively in transition/acquisition projects so happy to share more if there’s anything specific you’re interested in knowing.
At it's core, it should be a decision that is not only about control over the software, it's about bringing the knowledge about the processes and technical complexities of doing your business in-house. You might think you know all about it, but most likely you don't (otherwise most IT projects wouldn't fail). The big cost in IT is specifying exactly how things should work (that's basically what coding is all about). If you're not a developer (and even most developers underestimate/don't fully understand this) it's highly likely you underestimate this part of it (otherwise it would be easy for you to code it yourself - again, how to code is not a big deal, it's specifying exactly how it should work).
Software development is a lot about managing and documenting processes, aka knowledge, about your business.
Otherwise I agree with lots of other comments. Make sure you and the rest of the business is sure and have enough budget/resources allocated for a long time forward. Bring in a CTO/leader with the experience/skills of doing something like this. Make sure that person has the mandate to do what's needed (hiring, culture, etc). Could be a good idea to do it step by step to test out (again, a good mindset is to see this as an investment in learning about how to do your business, using IT/automation). A hybrid approach could work (take over existing code, use another platform/ERP/system as a base) - all depends on the specifics of your business, how custom your business and processes really are, how core to your business they are, etc.
Good luck!
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!)
Indeed - good point to ensure business continuity. There should also be a transition period to ensure OP, you’re getting support (like 6 months of service) in addition to code that allows you to address the issue if the vendor does disappear.
I worry that without a culture to sustain and nurture a software team over time, whatever you build this year will become nightmarish tech debt a few years later. Dev turnover might be high due to limited advancement potential / lack of resume building opportunities / not enough sexy problems to work on. Institutional memory between generations of devs might be hard to maintain and your totally custom software might get harder and harder to work on and use as the years to by. It doesn't seem like a great way to run an essential part of your business.
Can you switch to a more responsive vendor but then find an agency to do the day to day dev work and add custom code as needed?
I've spent much of my career working in tech roles for non tech companies, and I've seen a lot of bespoke custom garbage that's really hard to work on. It ends up being more forensic than engineering work, with a lot more reverse engineering and landmine avoidance than new feature development or UI improvements. I try to steer these types of businesses into commercial off the shelf software whenever possible, but maybe building custom webhooks and such into them.
It's a lot easier to have a solid base built and maintained by a good vendor, with some small snippets of modular code (webhooks, plugins, extensions, etc.) added on top. No one feature is tied into everything else, so less experienced devs can fix or replace it modularly without having to reverse engineer your entire custom stack.
All engineers are utilizing GPT to write their resumes/cover letters.
The written word and keyword references are no longer a signal of ability.
Give them a couple of questions to answer on video.
Record the time when the questions were displayed vs when their video cover letter/resume was submitted to ensure they're organically answering the questions.
Otherwise, be prepared to sift through literally 1,000+ applicants.
Hiring has slowed in the U.S. I wonder if in part it's because everyone now can submit a very qualified resume and it's become increasingly difficult to differentiate good vs bad candidates? Especially given the increase in applicants.
What kind of logistics does your company do? (Transport, Warehousing or both?)
Will depend a lot on your functional requirements, but I would say that unless you are doing something particularly unique, there are probably off-the-shelf products that do what you are looking for, and will probably be cheaper and more stable than a 3+ person dev team in house.
I don't know what your requirements are, but if you are in any way a somewhat normal logistics provider, what you are looking to do will quite closely match an existing software package out there on the market (or more likely, multiple packages). Just because you have package which is a poor functional match at the moment doesn't mean there isn't one that better meets your requirements!
In my experience home-grown systems give you exactly what you want in the short-term, and then come with massive limitations as you try to grow/scale them (i.e. if you are on the 3PL side of things, if you get a new client and have a good WMS you can probably on-board them purely with config without having to write code, despite them having some new/unexpected requirements), and the 'new' home grown system today becomes a legacy nightmare in the future.
Plus home-grown logistics software often misses some critical component that makes warehouses function well (e.g. I have come across many that don't have hard allocation, and then find that they have pickface shortage issues that are hard to resolve!). Unless you are closely copying how other software works in this space, you will probably fall into pitfalls that are already solved.
Assuming it is a WMS and you are a 3PL (my best guess from your description!), personally I think the best thing to do is get a good 'off-the-shelf' WMS and then dedicate your engineering efforts into the more customer facing side of things (e.g. customer portals) where you can actually show differentiation with your competitors. No point reinventing something that everyone else already has!
If you are a 3PL on the transport side, there are also great options that cover 'business as usual' and you can again push some development effort towards the customer side.
For logistics businesses, having software which is industry-standard and has a large support base is a bigger sell to a prospective customer than having your own 'great' homebrew software, but that's just my two cents.
Slightly boring answer.
Often a very similar story to yours, what I find that works consistently:
- Start small, don't plan to replace the whole platform in one go, but instead figure out what elements can be separated and replaced individually. Even if this means having to integrate with the existing platform it will be the better approach
- Have a migration plan, even if you are replacing individual pieces of functionality each piece will involve retraining users and have its own quirks, so have a plan not just for the data and tech migration but for the user side of it
- Focus your development efforts in the core of the business, leverage open source and SaaS for the rest – with a rebuild it's very easy to end up going way above budget and time if you focus on the wrong thing, this should also reduce scope creep
- When it comes to onboarding developers the most important thing you can do is document everything as well as you can – that way if developers leave half way through the project you reduce the impact, and new developers will be able to ramp up quickly and overall be less frustrated