Let me break down how to think about it. The key question to ask - is the software revenue generating?
1) IF the software is revenue generating, then you can spend 10-40% of your annual revenue on your software team, because you're anticipating that the spend will grow your revenue and you can factor that growth budget into the software team's budget.
2) IF the software does not help the company make money, expect to spend 5% of the revenue on IT (and maybe 30% of that budget is software dev). 10% if it's extremely important to the business. Sometimes as low as 2.5% or lower. This number dependent on the operating margin / COGS in your industry.
Should be somewhat easy to look up these percentage spends in various departments for public companies in your space to have a comparison.
Note: You have a 3rd party product and team because it is cheaper than in-house. So unless you have extreme inefficiencies with your current vendor, an on-site team will be more expensive.
Once you get your IT budget as a % of revenue, then look at it in the 5 year picture. Is it $5m/y? Does it grow based on the projected company's growth? Map out the yearly budget, because it will be capped.
3) From a yearly topline budget, map out what you can afford as a combination of build, buy, and build + buy. Do not think of it as one unit, categorize the spend into several key layers that are important to you. Day to day product. Support. Key issues. Future roadmap. Estimate the amount of spend you commit to each.
The key question is if will you have to build your own product from scratch? Or can you build on top of your vendor? You can bring in a consultant who can do that analysis for you, don't skimp here, get someone super qualified/overqualified with plenty of real world experience in your industry. You want him to have gone through pretty much every possible problem you may go through, so he can flag them down preemptively. You'll pay him a set amount of hours to give you insights on how your next 5 years of spending (25-125m$ of money) are going to play out.
4) Deep evaluate your vendor's issue. Is it complexity or complacency? Don't guess and don't be biased.
Software vendors are able to spend more money on engineers than you because of simple economics. Their entire revenue is spent on 3 functions, sales, engineers, and support. Your entire revenue is likely spent mostly on COGS and sales.
The key question you need to ask is can you allocate your IT budget more efficiently compared to your software vendor's IT budget? They may have a 10x bigger budget than you. But they also have to support many other company use cases that may not apply to you.
Here, you really don't want to get it wrong. If it is complexity that is the vendor's issue, then you don't want to take on their complexity with less budget - that's just making things much harder on yourself. But if it is complacency, there may be a lot of room for a new, modern software. But real red flag is that logistics is a notoriously complex industry.
Look for alternatives to reducing complexity, or to creating robustness, without rebuilding core functionality however you can. This may be impossible, but you never know. With a large enough budget, you can hire some really smart people who can figure out something clever.
5) Create a budget to figure out what the plan would be.
A budget where you identify the key questions, and send freelancer senior engineers to figure out those issues and solve them - is a really good place to start. Think of this budget like insurance, or like a multiplier of your success chance, which starts off at probably 10%, and goes up the more you dig, plan, and know.
The core business issue is never about building an in-house team or not, its about finding the key bottlenecks and finding intelligent and creative people to craft human-capital solutions around those key bottlenecks.
Good luck.