Should we bring software dev in-house?

IME what works best getting new projects kick started is hiring a very small team of senior freelancers, making one of them lead, and letting them loose. I worked on such a team once and it was really excellent. The advantage of this strategy is if the experiment doesn't work out, terminating freelancers is much easier than permanent (I noted you're based in Europe).

Contrary to what other people said, I wouldn't try find a CTO straightaway. It's a hard role to hire for, especially at the start. I think you're better off unleashing a small, excellent team of builders then hire management later to help build out the team if the initial effort succeeds.

Happy to chat more about my experiences with this strategy, davedx@gmail.com (I'm in Europe too)

My biggest suggestion is to look into ways that the transition can be done in stages, rather than trying to replace everything in one big swoop. This is likely doable, especially since you are already having to rely on outside tools.

Then to start building, hire a small team (employees or freelancers) and have them create a single piece of functionality that can be swapped out from the current workflow. This type of approach will limit the upfront costs and give you a much better idea of how feasible the replacement will be as a whole. It will almost certainly go smoother as well. Every rewrite/replacement of a large software project runs into a lot of unexpected challenges and complexity that will have to be ironed out, and this limits the disruption at any one time.

There are a lot of factors in whether or not to go this route, but it's certainly plausible that it's a good decision. I worked for a smaller company that did something similar and gradually built out their own internal workflow software tailored to the business. Overall it worked out quite well and they ended up with much better software at a lower price than they would have paid for outside tools. I'm sure there are plenty of examples of the opposite result as well. You're right to be cautious but I think it's an idea worth exploring further.

I’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 business cold. They should spend serious time learning the roles of the people who will be using the software so they can design it well to solve the problems those roles face. I lead the development for us, and I attribute most of the software’s success to simply having spent so much time in so many roles in the company. It’s that cross-section of knowledge that makes all the difference.

I 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 margins. Is there a clear story for how this software will allow you grow to $300-500M in revenue or more? I like to have a credible story for 5-10x ROI on software development because the costs end up being so variable and uncertain.

Then the trick is figuring out how to hire, train, and establish a productive environment for the team. My customers approach was to hire a vendor [Pivotal Labs] to ship a first release and help hire in-house staff to replace vendor roles until the team was fully in-house. The customer got rapid feedback that the team and concept worked; we shipped working software. The new hire landed into a productive context, and could see that the company had an effective approach to software development (because it was already shipping working software).

I'd recommend against it, but then again, I'm building software products in this exact space with my launching customer being a 200-300M annual revenue logistics company. I don't think they could do it in-house. You don't give a lot of info on the exact niche you are in, but the username tells me that you're doing containers in European context, most likely shortsea or domestic, not deepsea. Me telling you the ISO6436 type code for your username is either LEG1 or LEGB depending on max stacking height should tell you I know my stuff :)

Your biggest pain point is most likely that you know your business very well, but you probably do not know enough about the business context of your partners. If you are running a small-ish container terminal for example, you really should know how the depot department of the major carriers are managing their empty stock so you can decide your stacking strategies in the yard. You should probably also have an understanding of benefits vs drawbacks of tower cranes vs gantry cranes found at bigger quays. That then influences what your TOS should be capable of. Same thing goes for intermodal transport planning, you really should know not only how detention/demurrage works, but also what tricks you can pull to optimize for it, and how shipping lines monitor this internally. If you are building stuff in-house, you're inevitably going to be limited in your understanding of the wider market. Short term that's a huge improvement (more tailored software, better flexibility), long term that might cause huge issues.

I can certainly understand the frustration with third-party products. Your description of 'they are understaffed and the platform is stagnant' could realistically apply to pretty much any software provider in this space. There is a huge opportunity for somebody to swoop in and build something, the bar for this sector is mostly something that doesn't straight up suck. And I'm going to be honest: we're trying to be that somebody.

If you'd like to talk, my contact details are in my profile. I'm happy to show you what we're building, and tell you what that is like behind the scenes. If you go ahead with your plan to in-house it, let's stay in contact, perhaps we can learn from eachother.

Consider that the software you're using, buggy and kludgy as it is, isn't the reason your business is making (or failing to make) profits.

If you bring a software team in-house you run a lot of risks:

- Second system syndrome: the software we use today is full of bugs and annoying limitations we have to work around. Let's learn what we can from that system and develop our own bugs and annoying limitations.

- Cost centre dysfunction: Developing software is expensive and if this software isn't contributing to the bottom line it's soaking up money that could be used to generate more profits. You can inadvertently create a lot of dysfunction by adding a new team that appears to burn money as far as the rest of the organization is concerned.

The toil around using a sub-optimal tool might be cheaper than building a new, sub-optimal tool. The likelihood that you'll develop a better tool is low if you don't have any experience developing software and it's not your business' core competency.

You might get around the drudge work of automating some of the toil work by hiring freelancers/consultants. Someone who can come in, figure out the process and the pain points, and write some scripts to ease some of the manual work-flows getting in the way. They don't need to be on full-time working on a product that won't make any money for the company. They can just zap away some toil and save a bit of money for you instead.

Update: spelling.

This is a variation on the "build vs. buy" question that has been active in IT for decades. And answered for decades, too. Building something yourself makes sense only when that something drives the unique value prop from your business. But if your needs are something that is more generic, buy it.

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.

https://martinfowler.com/bliki/StranglerFigApplication.html could be a good approach.

You 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.

One idea is to start it as a skunkworks project, with a very experienced and skilled person starting solo.

With the express understanding that, if this is successful, you'd expect them to ultimately lead it (head of engineering, R&D, CTO, or whatever fits).

Greenfield development is appealing, and the big growth potential adds incentive to do that greenfield in a way that's aligned with the goals of the company.

Don't make it super-lucrative initially, to help weed out the serial job-hoppers and the transactional hours-billers who aren't as invested in the long-term success.

On your end, you only need buy-in that, if this succeeds, then company will want to follow through.

With that understanding, it's only a single hire to justify.

If, when you review every 3 months, it's not looking like it will work out, start over with a new champion. Your only lead time is to find one candidate who you're willing to give a shot at it.

It's their responsibility to make the skunkworks so successful that the company is confident in taking the next steps of greater investment.

A complementary possibility to keep in mind is that, if you really execute well on this system, maybe you could spin it off into a subsidiary that provides IT solutions to other companies in your field. (Especially since your own purchasing experience sounds like there's market opportunity.)

> We're using a third-party product that functions, but barely.

> 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.

> Strategies for attracting and retaining tech talent in a non-tech industry

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.

I used to do this kind of work as a contractor (for logistics and manufacturing), and I've it seen go both perfectly well and tragically wrong. The most common points of failure I've seen are underestimating the amount of business/domain knowledge needed and picking the wrong team.

Sometimes it's worth bringing someone in to build a temporary prototype to test the waters (I once wrote a wireless hand scanner pick system for a startup warehouse in a weekend -- they planned to throw my code away but just needed something functional right then.)

I would only pursue it if:

- your business is truly niche/unique and there's a significant cost due to process friction

- the total amount of work needed to have a functional product could be completed by one or two good developers in a matter of weeks/months.

If you do pursue it, I would try to take advantage of the Python Paradox (https://paulgraham.com/pypar.html) and hire someone, counterintuitively, working in a niche technology. You could probably find someone pretty good willing to build it in Elixir without much trouble.

Maybe just hire a data engineer or two to start. They could potentially deal with the pain points and make life easier for your team. A lot of data engineering these days involves glueing various services together and managing the data flows between them. So an experienced data engineer should be able to do what you need.

Overtime, you could move away from the software in question as various functions are replaced with other services or internal code. Or if you realize that replicating the software in question would be too prohibitive, at least you have some folks that are adept at dealing with that type of stuff.

It is worth mentioning that when managing software projects, the complexity and frustrations tend to sneak up on you. The first prototypes tend to come together fast, and are nice and clean and crisp. But overtime, the feature set grows, the complexity grows, and the cost and time it takes to iterate grows. If you only need a very small slice of the features of the software in question, and you are paying an arm and a leg for said software, then it might make sense to roll your own. But it is easy to underestimate the complexity of what you need accomplished and rolling your own could end up being a very costly mistake.

> "This feels like a quagmire in which development can quickly stall."

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.

Working on logistics software has been my day job for 14 years. You can attract experienced developers by giving them autonomy, GOOD pay, and a healthy work environment. I wouldn't trade a "cool project" for any of that.

It does sound like the best solution would be to bring most of the development in house, but integrate with third-party APIs where it makes sense (ie, the data transfer piece you referenced)

Whilst 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 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.

I worked on freight and logistics software for 10+ years for a New Zealand based company that has significant operations in USA, Australia, Europe and Asia. (domestic freight/road, air, sea, 3PL)

We were a bespoke software dev shop, and the freight company was our customer.

During my time there we were transitioning to their third “major” version of the software over about 30 years. It was a new system designed to handle the US market, where the customer was a relatively new entrant who had been running off the shelf software for some time.

Due to the way they run their business, with strong P+L requirements down to each individual location/site they had a presence, and even individual trucks operating as separate business units, a lot of what got built was effectively accounting. If this sounds like you, or you use a lot of third party carriers, keep this in mind: tracking freight movements alone isn’t that hard, but you need really strong accounting fundamentals in the system from the get-go to be able to really understand costs in this business. Some off the shelf software doesn’t do this particularly well.

Based on this - my strongest advice would be to choose boring tech (Java or .NET) and recruit specifically for some core developers who have a solid grounding in accounting fundamentals, or do some serious training on this before embarking on the design. You will inevitably end up posting journal entries to your accounting software, so treat cost tracking as a double entry accounting system rather than trying to construct a journal as an output.

The customer is pretty vocal in their annual reports (publicly available as they’re listed) about their successes in IT as well as their business model. They look at having control of their platform “in house” (product ownership in house, outsourced development of their own platform) as a core part of their success.

If you would like to chat, I’m not hard to find - look me up on GitHub, then search my name + New Zealand on Linked In. (My customer is also pretty obvious from there).

I have a part-time gig maintaining in-house software for a medium sized manufacturing company, which I have done since 2019.

1) your timing is auspicious, there are many devs looking for a new gig

2) you can retain them if they are able to do meaningful work, without a lot of bureaucracy, and you pay enough that it's a comfortable living (don't need to match FAANG salaries entirely)

3) the advantage is that they will know your business well enough to make software for your purpose. Therefore, the answer to whether or not they are interested in a "non-glamorous industry like logistics", is to straight up ask them in the interview what they think about that. Some will find it interesting to dig into the details and learn how another industry works, some will not.

4) but if you cannot afford to have at least two devs, consider the issues of what happens if your single dev gets another job or goes on vacation

My comment is made from the background of someone who has led the effort of bringing software development in-house, building a 20-odd FTE dev team, and is still leading it 3 years in.

I'd not bring everything in-house at once unless you really have to. Your fear that the devil is in the details is very much justified (I have stories, boy, do I have stories ...). However, in your position I would definitively start building a dedicated tech team. That allows you to start developing real solutions to solve pain points in a way that feels less like "filling the gaps" and more like "the first steps towards a better future". It also may make you a better, more informed customer which may perhaps help with your current vendor as well. It also gives you something to fall back on if the proviable shit really hits the fan with your current vendor.

Do not underestimate the importance of product management. Product management drives your development team. If you now use a basically off-the-shelf product, this is likely taken care of for you. Or not, given you describe the vendor as stagnant. In either case, you need to have that covered well.

One-is-zero: do not rely on single individuals, build a team. At the leadership level you'd want at least a product lead, business analyst, cto and a senior software architect. Make sure they work together as a team and that there is healthy cross-over in expertise/experience so that people can cover for eachother. In-house, not contracted.

I'd advice against fully outsourcing to an agency. You can contract a development team, and depending on where you are located that may be the most realistic option, especially in the beginning. But make sure you are at the steering wheel and have the people and experience in-house to use that wheel well (see previous point).

Invest in boring things like documentation and testing right from the beginning. It will pay for itself many times over. If you let it slide, you'll never catch up and you'll pay for /that/ many times over.

Other than that there's probably a lot I've learned from my adventure so far, but I find it typically difficult to assess what the lessons learned are unless someone pokes me with the right questions. Feel free to reach out at my HN username @ mailbox.org.

A good question is what else does your organization do in-house. You're a logistics company. That probably means you have some trucks around. Who maintains those? And how well?

If the organization can manage its own maintenance operations without crises, it can probably manage software maintenance. The tradeoffs between maintenance expenditures, downtime, and failures on the road will be understood and accounted for properly. If almost all the trucks are out working and the maintenance staff is doing oil changes and replacing worn fan belts, you're good. If you have six trucks out back with parts missing and one being towed in by a wrecker, while the guys in the shop are trying to fix a truck by cannibalizing one of the dead ones, developing software you have to maintain probably won't end well.

While I have no experience building software teams, I did navigate a few situations where a relationship between a business and a software vendor went sour. How long two parties can talk past each other is impressive sometimes. Once everyone is on the same page, seemingly insurmountable problems go away faster than you think.

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.

Hey! We also went through the some process, and in the logistics space. We ended up developing a solution in house. Because we fully understood the problem we were able to build the best product for us at the time, but it did took considerable investment from the company (and while the product was great, still questionable if it was the right investment to make). On my side specifically: I ended finding that what we built could be generalized for similar verticals, and now we have a SaaS product based on what we had built internally.

I have worked in a senior role in asset management (think bridges not derivatives!) for 10+ years, and this sounds like a familiar problem. A few thoughts:

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 :-)

> Strategies for attracting and retaining tech talent in a non-tech industry

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.

Can you simply buy the provider? This may be simpler than it sounds.

Once you own it, it’s your asset and you can then attempt to fix management to focus on producing a better product.

I’ve been involved in a few attempts to do exactly what you’re talking about with varying degrees of success. Feel free to reach out to the email in my bio.

I've faced a similar situation as an exec in a different field. Some questions consider:

1. Are you trying to replace the system-of-record? I don't think it changes the technical merits of going in-house, but it does raise the stakes. It becomes more important to engage other stakeholders, and to prepare the business processes/workflow for changes. Secondly, there will be a transitional period where you will need to use both systems, so you will need to have a way to reconcile and merge conflicting records from both systems into a single source-of-truth. Again, these are not deal-breakers, but just things to think through.

2. How many integrations do you have with external parties? You mentioned EDIFACT and government institutions. Integrations are often the dominant source of project delays and complexity.

3. Management structure - you can hire someone to run the program, but like it or not, you are the corporate sponsor. It's success or failure will fall on your head. Whether you hire a "CTO" depends on your technical management ability, but I'd stay pretty close and pretty involved.

4. Attracting talent - as always, it's a question of money and time. You need a healthy budget for a healthy amount of time. A good, experienced senior dev consultant will generally have a lot of contacts, and can pull in others if you provide a solid environment, budget, and roadmap. I wouldn't be worried about not being in a "glamorous" industry - the people you want won't care about that. Some kind of equity or performance-based bonus can really motivate people to deliver value to the business.

5. Roadmap - take a vertical of the business that is more stand-alone and start there. You want to show an end-to-end in-house solution that solves a real problem. It will help you diagnose exactly what kind of challenges, culturally, organizationally, technically, (and even legal/compliance) that you have to deal with. It will be a confidence booster to the rest of the organization that this can work and will be successful. Adjust expectations and timelines as needed.

Would be happy to discuss more, just DM me.

One thing I did not see discussed here which in my experience as an outside consultant for significant bespoke software developments was important:

Yes, you can attract and retain a good core development team through extrinsic benefits like nice salaries, bonusses, company cars etc. even if your business is not considered intrinsically attractive. However, how will the rest of your employees, both workers but also management cope with people in essentially purely production roles potentially be significantly more compensated than your middle management?

I have seen more than one client that in theory could have benefitted from an inhouse team, but where that was the dealbreaking issue.

If you're going to do this I recommend you at least take these things at heart:

Why do developers slow down

> https://youtu.be/7EmboKQH8lM?t=1476

80% of developers are unhappy. The problem is not AI, nor is coding

> https://shiftmag.dev/unhappy-developers-stack-overflow-surve...

What you're looking at is starting greenfield development. This always starts in the same way: 'we need to deliver functionality quickly because management wants results'. This always leads to the same issue, where code quality is ignored for sake of delivering functionality, which then leads to development slowing down and both management and devs becoming unhappy.

If you want to build something for the long term, I'd recommend starting slow. Get some experienced freelance devs where you do thorough reference checks. Get them to set up a stable core and help in hiring some medior level devs to train.

The medior level devs can grow to become the coaches of junior devs and then you can start scaling down the freelance devs.

Whatever you do, don't plan to release something within the first year. Don't ask the team to estimate a delivery date within the first six months. After six months you should have a baseline that development can be continued with and then you probably have a team that can start estimating work and has a grasp of what they need to do to deliver something useful.

Also, get a good product person, someone who can talk to business, draw out the different parts of the application and explain them to the developers.

All of these things are hard, so you really need to commit, or else you're setting up to fail.

Can you buy the service provider? Can you buy a copy of their service and run it in-house?

If they’re struggling as you say; you may find that the premium to acquire all/part of their operation is relatively low.

It’s nearly always better to iterate an existing solution to better than to build one from scratch.

Happy to talk it over if you’d find it helpful: ossareh _at_ gmail

I'm working on digital transformation for a traditional company. Challenges are from both culture (80%) and technology (20%, EDIFACT/COBOL is ok, not the worst part for us). Traditional companies can retain talent -- they definitely can compete with big tech if they want to. Especially in current tech talent market, you still have a good window to hire enough talents. A few key questions that you need to answer: - Can you get support from the top (board/CEO) to modernize HR to create competitive comp structure? - Can you identify real engineering leaders that can commit to the job? -- You can't just hire non-hands-on random middle managers. Good engineers don't want to work for politicians. - Do you have political stability to invest in the transformation long-term (3yr+ or more if you are more massive)?

I agree with a lot of the "how to" suggestions here. One addition is that you need to have a small number of key non-development employees really guide the development with strong opinions on functionality. This will likely mean your strongest folks in the departments that the software will serve. I would avoid building this by committee. 1-2 of your best folks who will be the ultimate end users should have massive decision-making power in what gets developed, in what order, and for what purpose.

Also, don't underestimate maintenance in your cost assumptions. Even after you've developed the product, you will need several people full-time just to maintain, update, and bug fix, let alone add new features that got sidelined during the initial development in order to meet the MVP.

I've worked at an online retailer which uses custom code for both warehouse operations as well as corporate operations, similar size as you. The dev team grew over time, but was on the order of 10 people.

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.

I work on an internal team like you would be building, I think for a company of your size and probably needs it is very much a needed thing to control the software in-house. Not having people that are dedicated and know your stuff leads to the situation you're in. Just do it. We've outsourced a couple small projects, then re-written them within our team because the quality and lack of specification is just...bad.

My current industry is pumping chemicals, it's non-glamorous but it's a need that must be fed, versus "fancy tech" or whatever. We keep a team of guys employed and happy. Just pay them decently well, don't try to micromanage them, give them good requirements and honest feedback, give them the tools they need.

Right in the middle of a retiring of a big external platform and moving it over, slice by slice into separate company owned products and APIs (and a few off the shelf things mixed in too!)

I think there’s plenty of sensible advice about getting a technical person with experience and expertise to help make the right decision. Between doing it yourself, building a platform with various tools stitched together to finding ways of getting what you need from existing suppliers and other tooling.

Something I would also suggest is to be really clear right now on how you currently work, how your existing platform works and the problems it’s causing or at least the opportunities you feel you’re missing out on.

To do this suggest getting a “discovery” team together and doing some service design and analysis to map out your user flows, business and tech. The as-is. and laying against that all the pain points and missed opportunities.

Then using the same team to help you craft how it should work. The to-be vision.

Then using that to-be vision and the insight and expertise you’ve developed to help you decide how best to get to that to-be vision. As cheaply and sustainably as possible.

Part of the organisation I’m helping out. There’s a vast difference between the parts where that discovery work was done (and done with clear purpose) and the bits that haven’t been done. And the endless delay and struggle they’ve had.

Yes. I worked on the warehousing developer team for a mid sized UK retailer (£75 million) and they had a home grown ERP system and it was a competitive advantage.

It wasn’t perfect, the business makes trade offs, they see expensive coddled devs who are basically a cost center BUT they get total control over what gets built and can align very well with business strategy.

Support is the biggest pit fall. All software has bugs, all software requires maintenance, never let speed of delivery happen at the cost of sensible levels of quality or you will suffer greatly with support requests which your devs will spend their time fixing.

Since it’s in house hire people who value stability over sexy new tech. You don’t want bleeding edge JS frameworks, you want tried, tested and boring. It doesn’t need to be a big React app, Ruby would be fine, a nice boring relational database would be great. Functional, reliable and stable is the order of the day.

Start with a small project as a test run and build up from there.

Oh and read The Phoenix Project, it’s an excellent fiction book about modern software delivery and the impact it can have on a business just like this. Aside from having some good lessons it’s also just a good read.

It 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.

No. You will almost certainly fuck it up because you're not a software company and very likely don't have a culture conducive to efficiently creating software or identifying and retaining software-related talent. Your costs will balloon and your output will pretty quickly slow to at least as much of a crawl as the vendors you're using, once attrition and tech-debt catch up with you.

If anything, you should contract with a software company that builds custom software solutions for niche businesses. But be very careful when identifying the company to go with, as a lot of them are essentially scams.

I’m just an engineer so I’ll leave the “shoulding” to others.

Can you attract experienced developers? Yes.

Do all of your developers need to be highly experienced? No.

EDIFACT is an old standard with lots of code floating around to parse it. I don’t know the ins/outs of its usage but an in-house team should be able to tackle this kind of data exchange without too much difficulty. You will likely want to ask candidates about experience with this data format explicitly. You can also ask about related data formats or information exchange in general but you’ll probably want at least one developer with solid experience with the format.

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

Yes. This is a complete non-issue. Plenty of developers work for companies that aren't "glamorous / sexy tech companies." In fact, I'd almost be willing to bet that - in aggregate - more developers work for companies like yours than work for those glamorous tech companies. Consider - every auto manufacturer, auto parts chain, soda-pop manufacturer, supplier of sheet metal, supplier of PVC pipe, sewer construction company, insurance company, retail chain, yadda, yadda, yadda, has IT staff. OK, excluding maybe some really small firms who also outsource to a service provider of some sort. But I think you get the point - using and developing tech isn't something that is only done by "tech companies".

Offer good pay, good work life balance and private offices for developers (if working in the office) and/or a healthy approach to remote work, and finding developers shouldn't be a problem.

No advice per se, but questions you'll want to consider as you read others posts:

1. why do you believe you can build it better? (even with the most amazing team)

2a. its easy to over-estimate the gains of a rewrite, and dramatically under-estimate the negatives. how bad could things get, for the business, if you migrated to a worse solution? (lost revenue, lost customers, etc)

2b. after you answer #2a, do the gains (of a rewrite) now really seem so big?

3. if you outsource this rewrite to a 3rd party (freelance, contractor, etc) - how is that any different than today? you're already "outsourcing" this to an existing vendor. How would you maintain code from non-employees?

4. can the business even support the cost (and it's a positive cost/benefit analysis) on hiring full-time employees to rewrite and maintain this code base - forever.

5a. what do your competitors do? (buy the same vendor software or they built their own)

5b. if they use the same 3rd party vendor, is the market big enough for you to turn this into a new revenue generating business (sell this in-house app you'd build)?

I guess now is as good a time as any to hire qualified software engineers, because a lot of them are looking for jobs. This is pushing down wages, and making this kind of in-house development more feasible.

The thing is that if you hire the right people, you can probably build something that is better (for your specific use case) than whatever third-party tool you're using now, with a relatively small team and in a relatively small timeframe (by which I mean probably at least a year or two until you have something that you can start to use). You might even end up being able to sell your product to other companies in a similar position, if you want to do that.

But if you hire the wrong people, or you don't have the necessary institutional support, or something else goes wrong, you can throw away millions and end up with nothing.

As for retaining tech talent, give them ownership, acceptable wages, and freedom. And don't hire a scrum master.

Here is a success story from a unicorn startup. They started a traditional business; there was no IT at that time. The business was good, and they had already made a lot of money.

They want to create a digital product for the business. They first hire a local person and freelancers. Then they work together to build the product. The local person acts like a CTO and product lead. Freelancers are developers. Then they want to speed up the project, they hire an offshore/outsourcing company - a quality one from a developing country. They worked very hard, with fast responses.

After a while, the product is really working; they start in-house devs. The original local person became CTO. They hire product people(product managers, product owners) locally(cause they know about business requirements...). And they grow massive devs in developing country without visiting that OR just only 1 or 2 on some year.

Unless this software is your core business, I would look at a third alternative: contracting the work out to experienced developers to replace the platform.

If it works well, you can bring development in house slowly after the platform is more mature. Worst case, you’ll have a more responsive external party managing the platform for you.

As a software developer myself and judging by the description, this sounds like a perfect job offer so many mature software developers.

You are pretty much ticking all the boxes:

- real life application that has a big impact on an existing real industry, not another web3 crypto project or AI startup of potential intergalactical importance(AirBnb for hamsters). - existing business with predictable income flow means that the project is not going to be scraped within 3 months, which is again going to attract experienced devs who are willing to plan their life, vacations and work-life balance. - software is going to be built after a third-party product which makes it easier to build the actual thing because there is an existing reference product. - software is going to be build from ground up, chosing the proper technologies, not the newest flashiest JS framework or PHP version from mid 2000s - internal products tend to have softer deadlines and, therefore, technical debt does not accumulate so quickly, which is again something experienced devs enjoy. - in order to help with the project, several existing employees of the company will gladly transition into something new(its basically a raise for them)

You will be surprised how easy and cheap(in Europe) it is to hire experienced developers to build something like that. I would strongly suggest hiring the actual team instead of using some outsourcing company, because they will build unnecessary complicated processes all based around billing more hours.

OP, my 2-cents having done this in a different industry within a company ~1/10th of yours: - as other comments mentioned, going slow and sticking to a solid vision of what “success” would look like in these efforts is important - most implementation challenges will be cultural, not technical - with the previous point, (and this may go against every other comment here) I have found it’s easier to teach someone software development basics than it is to teach the intricacies of your business/industry

with that said it has been my experience that a key first member in this is to find a passionate person within your org, whom you consider an expert or very knowledgeable in your business, and convince them to transition their full-time role to build these types of solutions. Find this person, convert them, and give them complete creative autonomy to pursue these efforts head-on. This person will implicitly possess an intrinsic understanding the problems with the highest value:effort ratio for the company, and when necessary, be able to fill the (many) necessary assumptions it takes to make functional apps that provide real value. You would be surprised at the simplicity and crudeness of what a smashingly successful app can have (and most importantly, what others will actually use) - so long as it addresses the right problem.

I’ve led the software development at a design agency to build project and client collaboration tools in a web app over the last seven years. The company founders never set out to intentionally run a design agency with custom built software in house and from the outside looking in, building “project management” from scratch would sound like a terrible idea. Yet we’ve been profitable in every year and grown +30% more than half those years and were acquired last year with decent equity payouts. The acquiring company (300m+ rev / year) is now expanding the engineering team to build SW for their adjacent market.

Myself, my boss (former CEO) and current CEO strongly believe in the power and potential of in house engineering, in particular for spaces that “sound on paper” like solved problems. The efficiency and productivity gains from building exactly what you need is hard to quantify but has been proven in our business as indispensable and, we believe, a significant competitive advantage.

Of course, as others have mentioned, you need the right person to make this happen in your business. I would look for someone with proven startup and product development experience that you could ultimately see managing a small team. None of this is cheap but the ROI long term is likely justified given the issues you’ve outlined.

Full disclosure: I'm a Technical PMM at Retool, which makes me a little biased, but I'm also a developer who’s seen these sorts of projects from both sides.

I generally agree with most of the commenters here, that you need a team of just a couple experienced people to start building your in-house platform. But when you're constrained with that small of a team, building something full-code can make it tough to find the momentum you need to get any one solution over the finish line.

If you already have a solid software development process or a team already in place, maybe going with full-code could work. On the other hand, we have a customer that replaced a custom-built React dashboard that was powering their whole business with an app entirely built in Retool, and let them work with the team they already had in place. Empowering the entire team is one the reasons Retool exists. They’ve been prototyping new features incredibly fast, even the non-technical folks on their team can contribute, and they haven’t had to worry about managing freelancers or attracting and hiring a team.

You've got a lot of choices ahead of you and a lot of good advice here in the comments. Feel free to reach out to keanan@retool.com if I can help sort through any of it!

First 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.

Hey, CTO of a healthcare company here, been doing the CTO thing for over a decade, and in tech leadership for nearly three.

My advice is to work to find a partner that has both deep technical experience (they should write code most days) and practical business experience. That's hard to do, but unless you can, I think you're better off not bringing dev in-house.

Whatever that person's title is, make sure they have some skin in the game. They should be able to understand business goals and recommend technical strategies to meet them.

I suggest finding someone who is at a point in their life and career where they are not using the opportunity to build their resume, but are instead focused on the success of your business.

It takes an experienced leader to resist the pressure from hype marketing and developers to use the new shiny, and instead focus on software that will have a shelf life of 5-10 years.

There are seemingly irrelevant technical choices that you won't understand (like the choice of a UI framework) that can end up costing you millions in "framework churn" (I've directly experienced this several times). This is where it takes a leader that is aligned with business goals rather than interesting or popular tech-of-the-moment to make the tough and unpopular calls.

Technology is the beating heart of your company. Evaluate your technical partner with the same rigour you would use for your cardiologist. You're placing an enormous amount of trust, and I'm not being hyperbolic when I say the wrong decision can cause your company to flatline.

First, get a senior person to lead the effort. They need to have experience hiring and managing developer teams. Ideally, it is NOT going to be someone with a lot of wizz-bang shiny tech on their CV. You need someone who wants to understand your business, and will focus on business value, and swallow the elephant one piece at a time.

> Strategies for attracting and retaining tech talent in a non-tech industry

This varies, but if you manager to hire and retain 200 employees, I'm guessing that you'll do alright.

> Experiences transitioning from third-party to in-house software (success stories and cautionary tales).

If you have a decent manager and someone who can make sound technical decisions, you'll do well.

> Potential pitfalls we might not be considering.

You seem to have good awareness of the danger areas. Devil is in the details. Figuring out how to slice the problem and building things piece by piece will be important.

> Alternative solutions we should explore.

In general, outsourcing companies are hit or miss, but if you find a good one, you will get many of the benefits without the downside of managing software dev in house.

Having a more seasoned person supporting the lead engineer will help you avoid costly pitfalls. I'm being self-serving, but a fractional CTO working a few hours per week might bring the kinds of safety check that will make such an endeavor more successful.

Does it have to be one or the other? Can you contract the work to an agency, in effect leasing developers without having to bring them in house?

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.

> I feel like we could do much better with a product catered specifically to us.

This is likely true, but still might have an overall RoI under 1.

I think you have to be in control of the fundamentals of what makes your company different ("don't outsource your core competency"). If you can't immediately see how software is part of that and you have a viable path forward otherwise, I'd tend to advise you not to bring software in-house.

Very few software projects are as easy as they seem, are delivered on a timeline that looks like the original schedule, and experienced devs are not inexpensive. (Yes, you can absolutely attract experienced devs to any industry; just give them interesting problems, competitive pay, and leadership that isn't utterly terrible.)

I have our logistics group (mostly outbound parcel, so a different part of the industry) reporting into me. We found a niche that we felt gave us a competitive advantage from having that team in-house [and I think that's been proven to be correct], but it was far beyond "the existing software is terrible" to drive that decision. OP: Email is in my profile.

The best developers I've worked with, in my career, were all from contracting firms. (Distillery, Ralabs, EPAM.)

First thing: If you outright fire your contracting firm, you'll loose all of their knowledge. This could harm your company more than you realize, depending on how much your business relies on their knowledge of the code and your processes.

What I would do is have some employees who work for you, who are experts and "in charge." They should be experienced in hiring and screening, and should be able to give you an honest assessment of your code base's maintainability.

At that point you can decide, with your expert employees, how much to outsource with your current firm, how much to outsource with a new firm, how much to insource, and most importantly, what you are doing wrong in your relationship with your developers.

The thing is, software development can fail for many reasons, and a lot of them have more to do with you than your vendor. You might have unrealistic expectations, you might need to work more closely with your contractors, or your contractors might be "warm bodies punching a clock." It's hard to know unless you have people you can trust hands-on.

I have not navigated a similar transition, but I have studied CS and read tons of business books.

I think if you do this and take the development seriously, it will be a ridiculous good return on investment. The success to Tencent according Mohnish Pabrai was that they had ROI on their developers over 10 years. They just put everything they could in development and if it was too much they would spend the rest on lower ROI categories. Overall 50% ROI. (IIRC).

It’s also essentially vertical integration if you do this. If you think it can make your beer taste nicer, as Jeff Bezos put it, then it’s probably worth it. Note that Amazon’s in-house team spawned a new industry. Also, Tesla is currently much ahead on competitors due to their software. I think many car manufacturers underestimate how much Tesla is ahead. The apparently even have their own ERP system called Tesla OS.

For attracting and retaining, I think you can definitely do it. There are engineers who like to see physically how their product is being used. Short feedback cycles can be very rewarding. Also, to retain I would look at Napoleon. What is the best for morale? Winning. Give ambitious projects and make them succeed.

So this kind of "platform independence" approach is something I have been hired to figure out a few times before as a tech consultant

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

I'm leading an in-house team that's developing a custom software for a niche financial institution. The original product was outsourced to a software factory, forward 2 years and they decided this project wasn't worth their time and left. I took the responsibility of moving the project forward, then with only another dev.

What worked great to me as dev?

. the direct connection with the CEO as he became a high level PO. With this arrange we were always sure that our work was giving value to the business.

. I learned a LOT about the business and loved it

. I was in charge of growing the team when the amount of work justified it. I got several wonderful devs onboard.

What worked great for the business?

. they decided and prioritized the direction of the (customized) product.

. they understood the strategic constraints and possibilities of their software

what was tough for all?

. at least the first full year, was spent killing bugs and making the project work properly. Operations needed too much support in that initial period. Stressfull times.

Starting with a pair of Senior Devs is a good choice IMHO. If you trust them, even better.

Those points I mention above that I found great, are your selling points to hire some good Developers.

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

I wouldn't worry about this. For some devs the industry might matter, but for many code is code, independently if it's for finance, healthcare or logistics. Just make sure salaries are in line with the market.

Internalizing devs will likely produce cost savings long term unless off the shelf tools are good enough for you, but it's an investment that needs long term commitment. Initially you'll still have to pay for your existing product plus the devs, so it'll feel like you just added a cost. Make sure you are committed enough to pass that phase. Your first hires should be able to work independently, talking directly with employees about requirements, without requiring extensive documentation or dedicated PMs before starting. Too much structure initially would be detrimental, you'll probably want to keep the team small anyway.

> 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.

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. =)

There are other options.

I've worked for Engineering Services companies and they excel at this kind of work. We'd interview you to understand your needs, quote a price to provide what you want and a schedule to get it done, along with maintenance as needed.

Yes, I'm vastly oversimplifying to get the point across, but this might be a better model than trying to hire a single dev or create your own internal development team. I could only recommend doing that if you expected that your internal needs would grow continuously and that you could both feed your team enough work to keep them busy (and not wandering off into other jobs) and manage them well. Both of which can be far more difficult than it appears on the surface.

You're not looking for an Accenture or IBM Global Services, but a small company, probably in your local city that provides custom development services. If you're in the US, I'll give Saturn Systems a plug: worked with their team before on a development project and I think this would be right up their alley.

> We do a lot of data exchange via EDIFACT

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.

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

Yes!!! Nothing a developer loves more is getting into a new market where their work will drive the business and will be seen as valuable instead of a necessity (cost center vs profit center)

What's your core competency? Does it include this software? If yes, then yes you should make this a core competency.

You need to partner with an engineer with a good amount of experience that has worked both in startups and established companies. You need to discuss all the intricacies and then they can tell you what timelines you will be looking at, potential cost, and potential benefit. Do NOT HIRE a CONSULTING company. I worked at one of these and it's a good way to spend $millions without getting much in return.

There are probably providers out there - they probably aren't very good and that's why you're not familiar with them.

> Strategies for attracting and retaining tech talent in a non-tech industry

As someone who is a tech lead at a non-tech company that does software in house for a niche product in a niche market...

You can either treat the software as a product in it of itself (as opposed to bolting it on to other projects for your core business) or you should expect to include some hazard pay to compensate for the mental and spiritual trauma caused by trying to pretend you can treat the software like a line item in non-software projects that "just" need software support, ending up with 4-5 project managers trying to oversee/status a single software release.

We do the latter and if some of the other benefits were not as good as they are, it would absolutely be a deal breaker.

I suspect most other non-tech companies also operate in a similarly sub-optimal way (the blind leading the blind), but why would I put up with that level of ass-hattery for anything less than what the market can bear?

Feel free to drop me an email - alex.muir@boxmove.com

I wrote the logistics platform for our company - UK-based, £4m revenue. I'll be happy to have an honest chat with you if it would be helpful.

My take is that software is a new form of literacy - it’s that important.

So here is a slightly different question: “currently all our reading and writing of English is outsourced - should we bring reading and writing in house?”

This was a serious question hundreds of years ago btw.

Edit: As for the rest of your points:

Find a good, middle aged, experienced developer who you trust. Don’t worry too much about how you tell if they write good code - you can’t. Focus on have they spent years writing code - a Middle Aged dev who is still an IC is a good indicator. Someone you trust - this is something you know from living amoung humans.

Once you have someone you trust, build around them. Pay them well. Pay the people they hire well. Demand incredibly good comprehensive stub-based “test rigs”

Use a blog and OSS as a means to attract talent - become attractive by being pro-software - believe in literacy

Maybe the limitations of the software arise from the fact that it's being sold at a price that's relatively too low? It sounds like it's very niche software with only a handful of users like you at most. With a small number of paying users, even if each one is paying thousands per month, the tool's team might be too underfunded for it to do much more than maintenance.

To do it in-house, you'll probably hire 2-3 engineers. You'll aim to have smart people who can self-manage, design, and who can intuit the business requirements. Your part-time duty will become to be the product's "CEO" of that whole thing.

So you'll end up paying at least €16000/mo (3x€6000) in salaries alone. Data access, storage and infrastructure will probably cost a bit too. How much are you spending now?

I am a Software developer and I just wanted to say that I actually consider Logistics a very glamorous industry. I know AI and data science are the latest trends but Logistics industry challenges as with real life problems where we can use sophisticated algorithms to overcome them. In logistics KPI improvements are also measurable without too much complications. Building Logistics applications often take us back to the fundamentals of programming.

I have worked for various companies over the years and currently contracting for a company that teams up with various Warehouse teams to provide softwares to improve KPIs. And I must say I am totally enjoying the work I am doing currently!

I'm running a team of SDE's and, from my experience, bringing development in-house is the last resort simply because of high risk/high cost. You have to pay your devs hell or high water whether they are moving at a rocket or turtle speed. We have worked with oil&gas and logistics customers, and their in-house development always drags 2-3 times longer than expected. If your pocket can allow it - you may try it but about 80% of customers I have worked with or talked to moved from in-house development to outsourcing it.

My team would love to look at your project for free just to give you an option to consider. Feel free to contact me at Polarwind99@gmail.com

I have worked freelance in similar situations.

Personally, I find it really fun. It's a nice mix of development, design, and organizational understanding.

What I want to do is divide up the project. Usually, these legacy systems don't have clear division points; it's all a big bundle of interdependence. But in my experience, there's usually some less impactful secondary functionality that can be spun off.

That will allow you a few things:

Figure out what you quantify as success for such a project. Its limited scope makes it easier to identify the endpoint. Allow learnings about the legacy system, and perhaps identify what elements you can extract from it—not necessarily code, but in previous work, I've been able to wrap or scrape data in certain areas to provide a sort of external output. Figure out how to work with devs, manage your own time, and educate your organization about what you're trying to do. The third and last point is critical. The failure modes for development are obvious, but the political and design impacts are less so:

1. Lack of experience

2. Poor scope

3. Overly complicated solution

etc.

But the real failure mode is political. You need a developer with some political acumen as well. There's going to be a lot—and I mean a lot—of interviewing people about how exactly subsystem X fits into their workflow. You need the political skill to navigate that, in terms of getting buy-in and quality information.

Downstream of the political dimension, in my experience, is the possible design solution. The actual interviews with people and the regular, constant contact with staff about their job are critical to building something that replaces the existing system but doesn't replicate its design failures.

One mistake you want to avoid is building something too similar to the old solution and missing out on critical information about how the job is actually done.

Also, I'm not currently looking for work—enjoying my current role—but if you want to hit me up, feel free. I can at least impart some experience on what to do.

If this product is critical to your core. business, bring it in house. If not, then keep it 3rd party but look for a replacement/new vendor.

Do you have a clear sense of what, exactly, it is that you're trying to accomplish?

You say that your third-party product "functions, but barely". In what ways is it failing you? What do you want it to do that it doesn't? Can you articulate that? What features do you want them to implement that they aren't? And more importantly, what are they doing that you couldn't do without them?

Before my current role, I was a PM (for a company of roughly comparable size to yours). And that job exists because "just make it do X" is in fact a project that requires days if not weeks of very deep thought, because X always involves dozens of assumptions and edge cases and complexities that are not obvious even with domain expertise.

-----

To answer one of your specific questions from my perspective as the CEO of a tech recruiting company:

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

Sure. Building an exciting product is something that motivates some developers, but it's not the only or even the primary thing that does. Common motivators in our candidate pool, in rough order of most to least frequent, are:

- Being able to work remotely (this, all by itself, will 10x your candidate pool overnight even if you're not working abroad)

- Salary

- Work-life balance

- Stability / trajectory

- Autonomy / lack of non-technical meddling in technical work

- Working with specific technologies

Remote work + reasonable dev salaries is already enough to have a decent pool of candidates. And I suspect that the nature of this post means you're much more open to treating a dev team as a value add and not a cost center, which is already better than a lot of people do.

I'd be happy to talk more specifically, if you want, about how you might pitch yourself to engineers (my email's in my HN profile - and no this isn't a sales honeypot, I'll tell you what we do if and only if you give a damn).

There are likely ways to have your cake and eat it too. Rather than replace the existing system, consider augmenting it with your own and then eventually, over time replace the existing system.

Showing short term and long term wins concurrently is a good recipe for success for tech as much as it is for business.

Some questions that may help you: 1. What are the biggest problems with your existing system and how does that relate with the biggest problem for your business?

2. Is there an API or any manual process you can use to communicate between new systems and the existing system?

3. Is there an engineering leader you can bring on to help or consult?

If it would cost $X to develop this system inhouse, you could write down the requirements and offer the vendor to add the missing features to their product on NRE[1] basis for the fraction of $X (including support and warranty).

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

I think I have some similar experience. The company I've joined was solving specifically this problem: non-IT company building in house after deal with 3rd party fell through. Some good experiences: 1) I was the first on the team as PM but also I could code. That meant that looking for development solutions it was easier to evaluate offers and advise CEO on budgets etc. 2) We practised GEMBAs - going to watch colleagues work. If your tech staff is willing to do that, it's really beneficial. You get the empathy for the users and collect feedback that otherwise SME wont provide (due to their limitations) 3) Allocate time and space for meetings between tech and business people - we practice weekly meetings where people come with requests. We have a chance to understand the demand (not just written task) and find the solution - be it new feature, workaround or existing feature not introduced to the person. 4) Lesson learned for me is that management style and structure for IT and non-IT part of business differs (at least in our case). IT staff is more self-reliant meaning that higher level of freedom should be allowed.

If you're interested to discuss more, happy to do so rimantas@kuodys.lt. Greetings from Europe.

Both the strategies have their own pros and cons. For most companies having an in-house team works best, but then you would need to hire someone to manage them.

Getting work done through outsourced agency is always tough. You may try to change the vendor the the challenges would always remain.

What works best is to hire a single senior developer to begin with, who can work closely with your third party team. He can initially get hands on small bugs or features. Slowly you can start building inhouse. Finding a senior person as CTO should be done only after a major chunk of things have moved in house.

What struck me is "company-specific and mission-specific" vs "NOT mission specific such as the domain of library or platform functionality."

The current method is hurting mission-specific achievements. That doesn't mean you now need to implement a generic (say) EDIFACT library or platform. Hell no to that!

But the current platform does not allow the current people to implement these mission-specific functions quickly enough. The problem sounds like it may be at that boundary: people and quickly enough.

One direction would be to add people (freelancers easiest for a start) who can ADD better platforms and libraries' functionalities to the overall system - while the current overall system keeps doing what it's doing. That was a common issue in my world and solved readily enough. Replacing the current system is unlikely to be practical quickly or cheaply, while adding side functions and side architecture might be pretty easy, beyond what the current people can manage. And that would achieve "business requirements" without falling in love with each such solution.

After that, 80% is fine if it's the RIGHT 80%: Perhaps there are 2 EDIFACT platforms in use to achieve the specific function your business needs. In the sense of suboptimal but getting the job done.

(Added to that, to me it's normal if parts of solutions get duplicated or redone for a different platform or library. That goes with "not falling in love" with any such solution. Just parts. Not the whole thing at once.)

I actually own a studio that does just this.

I think that for a lot of businesses, they can hire internal developers prematurely before they have a clear vision of the product that they're building or need.

We structured our studio as a group of (very) senior talent, most with over a decade of experience each across Product Design, Software Engineering, and Product Management, where thee entirety of our studio is available on each project.

We focus on documentation, developer experience, and working with companies to get the initial product in a state of both product management and cleanliness to ensure that they're reading to onboard specific team members internally to carry the product forward.

It can be very cost prohibitive to create a new product without having designers, developers, product owners, all that are dedicated to your vision. A developer may miss key user experience interactions, making it difficult to use. A designer may forgot key features from a business perspective. Having access to all of the talent for a new product is hard.

As others have said here, I recommend finding very talented and experienced SENIOR Engineers. If you are intent on them being an internal team, ensure they have excellent project management skills and have built their own side project from scratch, so they know what it takes to build a full product from the ground up.

An engineer that builds their own products has experience that is invaluable when it comes to building functional tools that people want to use.

There’s a lot of advice here regarding the dangers of your plan, and I’ll add a little of my own, but I’d like to offer one note regarding why you are correct for considering this.

What exactly is the nature of this software you’re running on? Is it an aged or decaying platform? Worst case, is this a PHP thing that has to have updates carefully monitored in the event of eventual security breaches and hacks?

And what exactly is the health of the software provider? If they can’t be bothered to respond to you and the sort of budget $300M/year can afford… I’d be sweating bullets for sure. You need to have a plan for them just disappearing one day.

---

That said: I just committed the cardinal sin of helping to buy a company that had a decaying software stack, thinking that we could just straight up replace the whole software stack. Gave ourselves a big fat year of development and a big, experienced team, and still couldn’t pull it off in time. Harrowing experience.

Someone else here suggested getting a small freelance team and "letting them go nuts." I think an approach where a small team was building new, independent microservices that supplemented your main stack, and then gradually replaced features — until finally just a small core was left to be replaced with something modern — would be a feasible approach. This would need to be a very long-term plan with a lot of commitment.

> 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.

https://simonsarris.com/p/growing-software-developers

It presumes you have at least 1-2 people already as a team, though.

You would benefit from some more in depth conversations with several strategic technical consultants - essentially a CTO type person - to get some definitive immediate steps and longer term understanding of how you may want to change your business relationship with technology.

Several of the comments here are very good -

- https://news.ycombinator.com/item?id=41195008 - is probably the one I align most with.

- https://news.ycombinator.com/item?id=41193136 - is going to be a common take.

- https://news.ycombinator.com/item?id=41195910 - is an extreme stance that requires and benefits specific sorts of senior leadership.

- https://news.ycombinator.com/item?id=41196183 - is quite scary, but the point is a valid one.

I'd suggest you reach out to a few people who have responded at the strategic level and see where the conversations go; I'd also suggest you reach out to myself (contact in bio / south UK based); and finally tap on your network for others as well. You will end up doing a reasonable amount of internal and external exploration activities before a path is determined - so expectation management is a must.

Best of luck.

300M in annual revenue is a key number for me.

Right now you're making 1 million dollars a year per employee or a 10x or 20x revenue to average employee cost.

The reason your software providers probably suck is that I'm not hearing how permanent or consultant employees can provide the kind of ROI that it will cost to build even basic software.

Let's say you're based in Detroit, MI - somewhere dirt cheap - 3 engineers for 1 year is 350K in salary, another ~300k in benefits and then you'll take 2 to 3 people normally earning money off their real work to be the domain experts.

Let's say 1 million in developers and 2 people providing 10x the value of their 100k salaries as well, and that's 3 million dollars of cost + lost revenue from productive employees.

If your company has a 15% profit margin on revenue and 250M in revenue - you're making 37.5 mil in profit, and you'll be giving up roughly ~10% of the company profits on this venture.

So the question is, do you think you have greater than 70% chance of getting a 3x return on their cost? Maybe 9 million dollars more worth of revenue?

If not, the project will fail just from the ROI expectations of the bean counters.

You could try to outsource stuff to somewhere with cheaper programmers but that just means the 2 million in lost revenue from productive employees becomes 20 million in lost revenue as the outsourced engineers need 10x the handholding because they aren't onsite, watching the people that do the work and interacting with them with a tight feedback loop.

I 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.

You must bring it in house. I am few weeks away from doing what you ask for an org. New stack from ground up taking all the old learnings and pieced together existing software,no/low code pile of yarn to simply build the correct db architecture and CRUD to match. Existing software worked and props to founder who scrapped it together, but it increasingly does not match the real world abstractions of the business.

Hire from within -- promote someone who is technical enough but more importantly excited and already knows the ops/logistics and has the entire mental model in their head. This eliminates a lot of headache for leadership to explain everything repeatedly and over many hours. Support this person with a senior developer with a track record. Luckily for this company I am both of those people. Keep the team lean, support them and let them work for multiple focused months to start, requiring certain milestones but allowing for refactoring as they see fit. There will be and should be some refactoring at the beginning. You want it to happen at the beginning, not later on. Maybe two people is enough or add one more person to support misc tasks and QA labors.

Within 3-6 months (depending on the team) you'll have a software foundation that actually matches your organizational structure. (note: lot of assumptions here)

edit: grammar,typos

We recently went through a similar situation at a logistics company in Europe. We decided to bring software development in-house after facing similar frustrations with a third-party provider. It was a challenging process, especially in attracting talent, but ultimately, it allowed us to build a solution tailored to our needs.

I’ve been with the company for the past 4 years, working as a lead software engineer. If you’re interested, my contact details are in my profile, and I’m happy to setup a call

I started as a “programmer” for a similar sized company, we’ve 2.5x and I’m the CTO now.

I can share a great deal of input if you would like to chat sometime, message me/I’ll make a point to check tomorrow.

Quick notes * projects that add structure to data, but remain flexible to manual overrides are the most successful + fit logistics.

* full automation is almost never possible. You can automate PIECES of the puzzle, but focus on building software for humans.

* Broadly skilled technical jackrabbits are what you want. Fullstack Developer with great data modeling skills/dangerous with SQL (can DBA, can optimize queries, designing for future analysts)

If you can find a unicorn, that wants to be a #1 and take on the challenge - grab and grow organically. Don’t throw bodies and money at it.

Let them learn the business/bring them to meet everyone and see their processes and - if he’s good - he’ll find small improvements on existing systems/processes that help stabilize the sanity while he continies noodling the big picture.

The big picture will take time / start small and see if you like the results before going two feet in and handing over operations to them.

Attracting talent is easy for #1 show them the size of the company and potential opportunity.

The right person has a long-view in mind and so long as they’re successful, keep them happy and the rest takes care of itself.

Hard to leave an institution like that

I've been working for a software development agency in the past and one of my clients back then was (a different) mid-sized logistics company :)

For us (including the client) the following approach worked great and I'd recommend to give it a try

* hire an agency (or freelancers) to work on (requirements, architecture, design, implementation) your special software - make sure the code is yours legally and you can bring it to another software shop or internal whenever you want * you get bootstrapping important decisions done by someone with experience. because hiring the first employee for that task is hard and risky * you can transition to in house from there, if you're happy with the solution or decide to stay at that agency longer - you're very flexible * Having good and maintained software as a base, start hiring. Build your team and gradually take over development. You don't have to go in-house fully, just so much that it makes sense.

Back then we bootstrapped custom software for that logistics company and gradually migrated it over to their team - even helped them hiring a team in the first place. Over time we lost them as a client (because they happily worked on their software now) but got many more clients since they recommended us highly. So it's a win-win situation.

I work in logistics and let me tell you what I think would attract high quality developers.

#1 good benefits. More than 2 weeks pto. A paid sick leave policy. Company paid health care. Paternity leave. Company match on 401k.

#2 Leadership that cares about good engineering over deadlines. Logistics is very fast paced. There is often a lot of pressure to deploy things yesterday. Development takes time, trial, and error. You need to be able to have patience for engineering.

Here are some insights I've learned over my career:

1. Your first hire will be your most difficult. Most engineers know other engineers, and will bring them over if the work (and pay) is good.

2. You get what you pay for. Hiring very senior staff will pay for itself, even if you could get four or five junior devs for the price of one senior. Very rarely, if ever, will "more developers" mean more productivity.

3. Pick a portion of your system you need to improve and start there. Make sure your engineering team is empowered to make decisions, and that there is a "champion" with the authority to make decisions across departments. A lot of orgs can die waiting for non-engineering portions of the company to make decisions. Even worse is when they wax and wane on those decisions.

4. Following point three, if your organization is disorganized, or unable to move quickly so will your engineering team.

5. Hire remote workers. There are a LOT of folks who will never set foot in an office again. It gives you access to an immense talent pool you may not have otherwise.

6. Be flexible. Most engineers I've know have a schedule, but that schedule isn't generally a strict 9-5.

7. Whatever language and platforms you decide to build with-- make sure you can hire for them. Some are great, but difficult to find experienced engineers. I say this as an Elixir developer.

Finally, Logistics sounds pretty fun and for the right folks it will be. Don't undersell the problem space or think of it as boring. The engineering work may be the opposite of boring, or your organization may just be a good place to work.

Good luck, mate!

My advice would be: Specs specs specs.

If you're going in house, or buying in a consultant, you need to be sure about functionality and why you want it. That way you can draw up small, medium and long term goals for what you _need_ and how it affects the business.

The risk with inhouse (or contractors) is that the devs get bogged down in what tool rather than how to solve the business problem.

make sure you have a good idea about the processes the software is supposed to handle, and what data you need for that.

There is a lot to consider given your situation and you have lots of input here already. So, I would only add my 2 cents in the case you finally decide to bring the dev in-house:

1. Start the team from hiring *senior* talent. Prefer *pragmatic*, experienced, and reasonably "passionate" (about technology) people. 2. As soon as the software team starts to grow, hire at least one experienced product design / business analyst.

Initially, someone experienced from the logistics department could work together with few software engineers and explain the business. At this point you need experienced software engineers who would carefully here you out, understand and internalize your needs, and translate this understanding into software. These same engineers would also need to expose you to the *just right* amount of technical details, for you to make the informed decisions about the product. I dare to say that everything else *does not matter* in a sense that you should trust this core team to make the right decisions in the area of software development. Eventually, as the overall complexity grows - product growth, team growth, etc. - you would need dedicated people to fill in this "bridge" role. Initial core team will get tired a bit, will need to focus on other things, so they'd need some help to structure the product. It is not easy, this role exists for a reason. It is overall less efficient this way (as in "output per person"), but necessary for further growth.

---

*Most importantly of all*. Have you considered buying an out-of-the-box solution? Do they really-really not work? Replacing something that already exists... I never saw it go as expected.

I can see there's a lot of good advice in the comments. I just wanted to contibute my 2 cents to the matter. I've done a lot of conversions, interconnection of disparate systems, migrations, monkeypatching and straight abominations in my day. In your position I would hire senior freelancers to patch the system in interations. First, fixing the most anoying issues you have in order to streamline the whole process. This will allow the programmers to really understand the domain and based on that knowledge iterate and consolidate pieces of the architecture until you have what you're looking for. I don't really believe in complete rewrites or starting from scratch based on my experience. Most of the users/companies I've dealt with (small and big) don't really have documented processes and domain knowledge. Well, that's not fair. It's rare those are documented and up-to-date. That's better :-) I agree with some of the comments, the technical challenge is what attracts people (at least that's my case). If you're looking for people to tackle something like this, please send me an email :-) Cheers.

I am currently a fractional CTO and have held CTO, and Distinguished Engineer/Architect roles for Fortune 500, startups and several mid-size companies, with a single product AOR up to $2 billion ARR.

First and foremost -- document your business case and expectations of other Sr Execs as to sales-growth and OPEX comparison for the current state, and then the desired state.

Your current vendor will likely cry foul if you disconnect from them too quickly and without sufficient empathy. Consider the possibility of the current vendor stepping up to fill the gaps if you could negotiate terms with them that give you better ROI than having your own in-house team. And, would you trust them with the extra outlay?

Requirements, Requirements, Requirements -- cannot be stressed enough. Getting those right (even if they are a moving target) saves 10x development over jumping straight in with designers, and 100x savings over just hiring coders with no domain expertise. Most of your existing domain expertise is in your non-technical staff. They need to participate in a reverse-engineering of what your current system is actually doing for you, and help identify gaps in the current tech that would help their productivity or reduce other toil.

As the first hire, I would hire (contract) a top-notch software architect to lead a "requirements documentation" phase of 2-3 months before hiring anyone else to the team.

Does your current team have access to an underlying database schema? Can you quickly and clearly state how many "screens" your team uses in their current workflows? Can you quickly and clearly state how many unique fields there are on those screen? Same questions for EDI/ETL as for workflow screens. The answers to those questions can quickly reveal the size and scope of your existing system.

Your fear is correctly placed.

I've seen plenty of companies rewriting complex software written by a third party considered ineffective.

Here's why they fail:

- Underestimate the work and assign a team of 4 juniors to replace the work done by an entire company

- Implement new features during the rewrite: never do that, focus on getting a 1:1 replica first

- Business people pressure the team in various stupid ways (artificial deadlines, scrum) because they've never done software and have no idea what's a software project or because they've read blog posts from influencer and they're bad at their jobs

At 200-300M you're at the size where you can do your own software. I'd recommend to:

- Buy the third party you complain about, then improve it

- If that fails, pay people above average and good people will come. Try to find technical leaders with experience in product (think ex startuppers). Pay a bonus for good results. Give them operational freedom as long as they deliver results. It doesn't matter if they are employees or a software agency or contractors, they just need to be good and give you ownership of the code. Given you don't have talent in house, find a friend who is a good CTO or VP of eng and pay him/her to do some interviews.

Best of luck

I spent some 13 years working for a manufacturing firm writing custom management software for a similar sized manufacturing company. I now work for a SaSS firm in a different industry with a few hundred clients.

The thing that I learned from this is you either buy off the shelf software and run your company the way that the software company thinks you should run your business. You can, like some of our clients, fight the software and figure out all the janky work arounds you want, but ultimately you are bound by that software.

Or, you can write your own software and run your company the way you want it to run, with all the weird quirks of your business.

I get why smaller companies/firms buy software instead of rolling their own. It's a huge amount of overhead for little apparent benefit. It's worse when the software vendor isn't helpful or attentive to your needs.

My gut would be to say find a few software engineers you trust, hopefully with experience doing EDIFACT files (I've done this myself and the specs are a bear to dig through). I have this feeling mostly due to the unresponsive software vendor and your operating in a small niche.

For attracting talent, pay them well, and make them feel appreciated, and listened to. You'll be running a tight ship with very few points of failure (the bus factor), just one or two people leaving could paralyze your operation. You don't want the software people to start looking for jobs elsewhere in such a small department. My previous employer did not do well in that department and lost 90% of their software staff in a 3 year time span. And when your department is 4-5 people that's devastating.

I worked on the logistics IT team for a global marketplace and can assure you that all software in that space is of subpar quality, because all players in this space have to rely on global shipping and logistics incumbents who do not care about how outdated their systems are and have essentially lost ability to understand their own systems. This creates an opportunity for you to create a set of products and services that you can build to improve your own operations and to resell to other businesses in your space.

However...

Software development always costs more than "civilians" (companies whose core business is not software development) expect. I would advise you to work with someone who has built systems for logistics before and can help you describe your current baseline in a way a software developer can understand, then define the target state and break down the journey into clearly defined deliverables. Then you can have a conversation about making it happen. Happy to help you as I have worked on and delivered national and international-level projects in the banking and shipping space.

I run a software consultancy (http://www.afi.io) that specializes in transportation and logistics software. Please get in touch with me at afian at alum.mit.edu.

Here's a recent case study from one of our clients: https://www.mapbox.com/showcase/sotargruppen

I also write widely on anything related to software and logistics: https://afi.io/blog

I won't tell you whether you should build or buy, but I'll tell you what to avoid.

Avoid - large system integrators like IBM. They will charge you a lot of money and then just outsource it to someone else (source: me, we occasionally do subcontracting work). - freelance engineers from a website like Fiverr. You want someone who's done this before, many times, and has seen what worked and didn't work. Logistics is very niche, and outside of a few speciality dev shops you won't find engineers who have experience solving real world customer problems. There are really good engineers at Waymo for example, but they won't work for you (or me).

There a quote attributed to the late Charlie Munger. When asked how he would select a future investment manager for Berkshire Hathaway, he replied, "It reminds me of the young guy who went up to Mozart and said, 'I'd like to write symphonies.' When Mozart said, 'You're too young,' the young man replied, 'But you were young when you started.' Mozart pointed out, 'Yes, but I wasn't asking anyone else for advice on how to do it.'"

You want someone who's done it before.

Consider not only freelance developers but a freelance "scrum" type team with a PM or PO. Vet these carefully as a bad PO will sink the project. A good PO will gather requirements, keep the team on track, report back progress etc. Since this is an outsourced solution you must be "waterfall" as in be crystal clear on how the app will work, what is the business logic (the devil in the details) etc. Freelancers will not stop to ask questions or clarifications. They will do exactly as asked no more or no less. While I do agree if software is not your core competency you should not bring it in house it is worth mentioning most software starts as an in house solution that is then upgraded to a commercial offering in the B2B space you operate in. Its a long shot but if you stop thinking of your software as a cost center but as your actual core competency its possible to turn it into a revenue stream that is some cases outstrips the original company. I would say at least 95% of the attempts to do this fail though so don't take it as granted.

I’ve worked on internal tooling for companies for more than a decade now.

If you can get the right people, it is absolutely worth it. You gain complete alignment of incentives. You can easy access. You gain rapid turn around.

If you get the wrong devs, you also gain missed deadlines, a mess that is difficult to work with, solutions that don’t solve problems.

Basically, if you can hire the right people, it would almost certainly be worth it.

I was the technical cofounder of a logtech startup. Logistics has a lot deep problems that need to be well integrated for a smooth UX. I think this is why you tend to see people eventually try to pivot into building a TMS (and why it takes so long to build one). They start solving a specific problem. They realize it’s not worth much without the whole picture and nobody wants to let other players integrate.

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.

I used to work for a large multinational ($80b market cap; 55k+ employees) with a penchant for in-house development because vendor exhaustion is real and under-discussed in the business world.

Their trick for doing it was recruiting heavily in regions of the world with great junior dev talent at comparatively low costs (in their case Latin America, but it could be eastern Europe or elsewhere) and have them work with more senior middle and top managers to guide the architecture and technology decisions. At any given time, if you took a snapshot, you'd simultaneously have numerous SaaS subscriptions, numerous devs as described working to replace those same SaaS subscriptions, and numerous completed projects that, if purchased on the market, whether SaaS or not, would have cost exponentially more than the developers' salaries. No freelancing, no subcontracting, only proper employees - but yeah, you need to make the economics work and your milage will vary.

Full disclosure: I have since left that company and work as a consultant doing precisely that kind of work for others, it's only fair to note

I suspect the quagmire might come as much from dealing with government institutions as it does from programming. Does the provider already have relationships that facilitate that?

If you can work around that, then the EDIFACT thing means that it is very inaccurate to say you have a "straightforward CRUD app". I am a freelancer and if I saw those two statements together it would be a red flag, like you were trying to minimize the complexity to try to pay poor rates or didn't understand what CRUD was or just wasn't thinking clearly.

EDIFACT in a modern context where we have human readable formats like JSON, looks like a nightmare. I suggest that you see if there are any libraries you could build off of such as pydifact.

You should also start trying to collect a comprehensive documentation of everything that software is doing for you. In detail. No programming team can be successful without that information and aside from the EDIFACT stuff and bureaucracy that will probably be the biggest bottleneck is discovering that.

I would get an open source ERP platform that you can extend yourself - for example Microsoft Dynamics Business Central or Odoo and start building on top of that platform. These platforms already have edi modules and all other basic functions such as sales and purchase module, finance etc. That will save you tens of thousands of development hours and you can start building your custom processes straight away.

Consider acquiring the vendor. Give them a heads up that you're considering building in house and you'll at least get better service in the meantime. Make sure their leadership gets the message.

If your business is growing and this is an important part of the business, then you'll eventually regret not building in-house. Of course, you may regret poor execution on the in-house solution, but the response to that is to start small and incrementally grow scope instead of trying to switch over a big mission-critical system. All big functional systems start as small functional systems and grow incrementally. It's easy to imagine the system you'd like to end up with, it's hard to imagine a series of small changes to get there from where you are. But if you want it to be successful, you have to take the longer path that is in production the whole way through.

Consider having the new development focus on features you don't have in the current vendor solution instead of replacing features you already have. These will be more impactful and give the new team some positive inertia.

Please dont listen to the people in here telling you to just throw some devs on to this project. You will ultimately fail since it seems you yourself are not capable of leading a software development project.

Yea you can bring it in house. Can you purchase the existing software? Then rather than do a rewrite, work towards rebuilding/refactoring. Please dont listen to the people here telling you to do a rewrite. It will fail or go way longer than you expect with many issues.

If you can start hiring some devs/UX/infra people and work alongside exiting team. Once they build up knowledge and are ready to take over the project, then they can start taking proper ownership and rebuilding and extending parts of the system. Slowly slowly you will not only build up the expertise and team but be will have a fully functioning dev team owning the system end to end. Focus on hiring good people with a strong focus on senior people and building up knowledge of the software system.

I have no experience in hiring programmers at all, but here's a couple tips based on my experience working at a company, and also family member's experience who is involved in hiring

So never ever hire a freelancer until after you've talked to a bunch of their previous clients. Not sure if this is possible though, but if you can, its probably really good

I've seen what a non-software engineer hiring freelancer programmers can do to a company. The freelancer can look great on paper, but ultimately be unable to deliver at all, and thus send the company into severe financial catastrophe

Granted for a CRUD app its probably not as big of a risk as in the company I was involved in, that had tried previously to do a groundbreaking engineering project

Also, when hiring a programmer, probably pay less attention to what they know, and pay more attention to the excitement and enthusiasm in their voice

You're probably better off hiring a relatively inexperienced programmer with deep passion for their work, rather than an experienced programmer who's just there for a pay check

When you say provider, I assume you don't own the IP and that you'd be starting from scratch. At my work we owned the IP from software developed by a third-party which we then brought in-house and hired on software developers (myself included). The biggest challenge has been the loss of tribal knowledge of the codebase and the use cases that brought the system to its current state over a decade.

The boring answer is that you'd likely need to put together a business case. What's the benefit you'd get from developing it in-house? Is it worth the projected cost & time-frame (which is likely going to be inaccurate since estimating software is inherently difficult) to fix the painpoints? Would you look to offer the new solution to other potential customers (which may even be competitors to your main business)?

As for attracting talent, I've worked in the tech sector of pharmacy (Australia) for nearly a decade and while the tech sector there is small, the hiring pool is just like any other industry since we don't hire for pharmacy experience.

Currently working for the same kind of company (logistics, niche domain) with a mix of big ERPs (yes, not just one) and in-house software.

If you go with in-house you want to make sure it does not spawn multiple pet projects per need. And you don't want your software to rot. I took my current role to be part of a modernization effort because "it's old software". Well, I did not expect this kind of outdated and things are slow to replace because everything (and many "surprise" scripts and app no one use but in fact someone does) depends on the same badly setup database. But it's a "fun" challenge.

You really want easy to update / rewrite / replace software. Not just a "let's build it one time then consider it good to go for the next couple decades" politics.

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

Yes, if you can present a good software project. Also pay and perks like WFH will often trump glamour, especially with experienced devs.

Point to consider: the moment you hire to develop in-house, you are a product company on top of what you were before. Doesn’t matter if you are the sole user of this product and actually not making money with it, you will have to deal with a company in the company.

It could be a very good idea (especially if you can spin it out at some point) - I mean Dassault Systemes started this way and they are a billions dollars company but that came from an engineering company a 100 times larger than your own and for which the investment was pocket change - but it’s going to cost you more than you think, take more time than you think and be more taxing on your time than you think. Also you need to maintain it forever.

If you haven’t done it yet, I would pay for a very serious benchmark of what’s available on the market and open discussion with integrators to see if a custom integration on top of something on the shelf couldn’t be made especially if you have people in house doing low-code thing before pulling the trigger.

I'm not a business person so I don't know how insane this might sound, but would your best bet perhaps be to reach out to your competitors and other businesses you think are in the same situation and propose some sort of shared software house to replace the 3rd party solution?

It seems rather expensive for a 200 person company to start it's own software division just for internal applications.

As a business decision, having on-staff developers mainly comes down to value.

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.

I would first look for someone you can trust who is an experienced software engineer or software engineering manager to take a look at what you're trying to build and give you a gut feel on the scope and schedule. You'll need to factor in some risks on top of that basic gut feel.

I think being in Europe is a plus here in terms of being able to get talent for a reasonable cost. I think you can find good people in any industry but it's never easy. Paying well, benefits/perks and good working conditions are a good start. Count on it taking time and effort. You will need at least 1-3 strong people (one is a bit risky but can also work) and those can help you grow the team and also lead more junior engineers.

What about making some arrangements with your provider with you paying for time/people and them making changes/fixes/custom features for you? Could even be on your premises or some other similar arrangement. That can work if the software has some good bones.

I have been working for one of the client based in UK. It deals especially with fleet management. My team developed the software for them and now it’s around 90% complete. The CEO of the company is very close relation. He discussed the requirements with me and asked me for an advice. I told him that if you are going to hire someone in UK, the cost of having developers on your site or getting a deal done with a company based in UK would be way more costly. Instead get a team here in Asia (the IT market in Asia is way cheaper than that of UK or whole Europe). I started crafting the team and now the total number of the guys working on his product is 15. The thing is you have to find someone very close that is trustable. If you have idea of how the software are developed that is a huge plus point. Hiring freelancers on the remote location is good for a small project but a project like yours needs dedicated team. If you need more help in this we can have a chat.

Probably not going to see this comment but if so can you answer these questions. Have you shopped around for an alternative? Do you guy shave complicated stuff like tailing an origin of an order back to a specific sales person? Do you need 3 way matching? Do your customers prefer using an ERP you're always working with? What are the things holding you up your execution?

On the ERP stuff I've done a lot and it's usually the reason stuff gets buggy and 'hard'. Stuff like say realistically you have to complete an order of say 10 linear feet of rope but it comes in packs of 6 so they have to order 2 but the sales rep said they'd sell the remainder on another work order etc etc.

The ERP you might have one guy that's on oracle, another on something custom, and these systems all interface differently.

Another is in the quoting process if you are making quotes that are timely or have an expiration. Some things just take a lot of foresight when you set out to make them.

I have helped a company do something like this in the past. My advice is go for it, but understand that there's going to be some landmines.

The biggest benefit is that you likely have a stronger understanding of your needs than any third-party, and if there are other businesses in your niche, it provides you a pathway to build a revenue stream selling your custom solution to your competitors to capture part of their revenue. If you think about it from the perspective of value capture, it means even if you lose a deal on the front end to a competitor, you are capturing a percentage of it on the backend because it gets your competitors reliant on your platform. To do that though without running afoul of antitrust, you should try to set it up so in-house development of the platform operates relatively independently of the larger business (the legal term is "chinese wall").

As an outcome, you can actually generate a new revenue stream that's profitable while correctly serving the needs of your business.

SAP?

An alternative to this strategy might be to have your own software team that builds tools and processes for you to "work with" or "work around" your primary software without fully replacing it.

As others have mentioned, what you want is achievable, if managed the right way, with the migration done in stages.( Trying to replace the whole thing in one jump would be very risky.)

In the real world though its quite easy to miss requirements, some quirk of the existing software nobody really thinks is a feature, except that one person in the office who has gotten used to abusing that quirk to achieve a task.

There is also possibly a lot of domain knowledge that the software team you hire might not be versed in, which can be tricky, although this is partially solved by having a good project lead and strong communication between the teams (software and non-software)

Where is might get more tricky is if you to adhere to certain ISO/etc certifications.

One thing to remember is that some/most are not turned off by a non-glamorous industry like logistics but rather attracted to solving problems regardless of the industry. I’d hire someone who can actually do coding (so not a CTO, CIO level) that is also or has been a lead who can delve into your business and review existing products and can get you an 80% POC in under 3 months. It may not be pretty but it will help you better position to ask for more $$ for contractors or other employees. Start with 1 then scale from there. I’d give them 1 month to study the existing system with no deliverables other than documentation that will be used to replicate your product needs. I’d also be sure to hire a PO (Product Owner) if you don’t have one and have them also learn the product inside and out as they will be the gatekeeper between the coders and the users as to how the product functions and that the coders fulfill all the requirements.

In a lot of companies the root cause of this kind of thing is not being willing to spend the kind of money needed to achieve the desired result

You need to be honest with yourself about whether you can actually afford what you what to do.

The other side is it’s not unusual to see a company getting bled by an entrenched third party

Whichever case you are in, start small and prove the value with something tangible

I'd recommend getting a remote, third-party team of contractors, and hiring a fractional CTO to manage that particular team and any related software. Having done that pattern before; it's less liability and cost for you, and easy for you to experiment and get the job done. You can easily end the contract with the team once your software is stable enough.

My only advice would be: don't attach different freelancers to each other and expect the job to get done. That might work in some particular use cases, but most software requires (at least) the engineering team to be in-sync with each other. Freelancers rarely have that skill.

Hiring a full-time tech team in-house is beneficial only when your engineering/software is tightly coupled with the domain. We often overestimate and think that's the case every time -- it really isn't!

Btw if you want to hire such a team, I'm on the engineering end: bazaz@grayhat.com.pk

You could explore using a platform that gives you more tools and support out of the box, that allows experimenting with a custom setup, but doesn't need a big (both costs to set up a team and time to manage and get something good enough done) investment upfront.

What I have in mind is Palantir Foundry, Snowflake or similar. SAP would be overkill.

Every company is a software company, just some haven't realised it yet.

The only thing I would add to the great advice already here is start off very small, and get this tiny feature being used by the company as soon as possible and then iterate. Every two weeks the programmers should be adding value for your staff. Do not try to go with a big bang where you deliver something that does even 10% as much as the probably awful software you are currently using. This is where projects tend to fail.

If you want to filter out quite a few bad programmers I would use Elixir as the people who know about it and like it tend to be people with excellent programming taste in my opinion. Other programming languages are available of course, but using something slightly niche but excellent will attract the right sort of people to a project like this and help retain them.

If you want to chat my email is in my profile! Good luck!

As someone who did similar thing for few, little smaller business I will tell you - it depends.

Personally I did some software that saved a lot of money on licensing and hosting, almost none on-call activity as the software is stable and it is required to work 12/5, no 24/7. The only thing - I was more than „into the business”, loved the challenges and wanted to solve them.

On the other side I’m currently helping company from different industry because they collected few great talents, bought them great hardware, explained business and paid a lot. The team wasted almost a year, produced more crappy software than the existing one and left choosing someone who don’t know yet how bad SE they are.

If you will be looking for a consultation or for the team - I’m more than sad there is no contact info, because reading your description already made me way too interested

I’ve been on a team life this in the freight auditing industry. Questions I have 1) how much time and how much money are you willing to spend before you have tool usable for production? 2) if the tool does 100% of what you want, what is the benefit and payback period? 3) Do you plans for more development? How will that be funded?

Like others mentioned get a freelancer or an external team for starters. Engage them for 2 weeks. I run a dev agency. I recently made a chrome extension for a customer for the first time and it just took us 2 days instead of 2 weeks because we leveraged claude sonnet. So building a software today is incredibly easy, you can build almost anything at an incredible faster rate. So if you set 2 weeks engagement and you can see how much is done, you will know how to work with the person and team and also will be confident in your plan to move away from the software you're using. You could then have this team or freelancer document how this is setup etc and you can slowly start hiring in house. For eg, it costs like 800 USD for two weeks in our case since we are based out of India, so when you outsource to India, Vietnam etc you have low risk, you can quickly experiment instead of contemplating.

I worked in an e-commerce company before and was responsible for the logistics tech.

The first thing to keep in mind, is migration will not be easy, mainly because no one would understand how the current systems work or the decisions behind each function.

You’ll need subject matter experts from your team to guide the new devs during the migration.

Having a CTO to hire the team is two edge sword. If you get it right, you’ll save months down the line getting things right, but if you get it wrong, there is a chance you’ll have to rewrite everything again in a few years.

My suggestion hire a senior full stack developer to do one feature outside the current system but in a way that integrates with the workflow.

This experience will provide lots of learning for your company on how to manage expectations, tech stack required, speed of development, ROI. You’re not going for a large investment either, one developer will not break the bank.

> I'm an executive at a mid-sized logistics company (~200 employees, $200-300M annual revenue) getting more and more frustrated with our software situation and am considering taking software development in-house.

Would be good to know what kind of margin you have on that revenue. Software development is expensive and if this project will eat a substantial part of your profits it may be hard to see it through. One of the major pitfalls you want to avoid of course is spending a ton of money, but not enough to get a meaningful (in-house) product out of it.

> 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.

I’d start with trying to find out why this provider is understaffed, unresponsive and stagnant. Is it just a bad business they are in? If so then you run the risk of investing substantial capital in replicating their bad business in-house, except at least initially with only one customer (you). But it could also be that this is a cash cow product for them and their focus is elsewhere.

Another question that may be clarifying: How much are you currently paying for this software, and would you be willing to pay x times more if it was well adapted to your needs? (Because you probably will be paying a lot more.)

An even bigger question worth pondering: Could you do your business differently if you had your own software? Really successful companies today typically don’t build software that fits their business, they build businesses that “fits software” (in the sense that they can be highly automated and optimized through software).

Feel free to shoot me an email at bjornsmedman@gmail.com if you want to talk.

I was a hands-on engineering manager brought to lead a similar effort at an ad agency to build out their adtech stack inhouse.

Worked out fine. I've also interviewed a number of people in similar situations. Seems to work out fine when people are interested in what they are doing.

One thing to consider is the cost of it, and the size of the team you would need. I would argue you'd need at least five people regardless of the size of your project to get any semblance of dev culture that would propel the team forward.

As for attracting talent, there's a tremendous amount of talented developers that don't make the cut to get into FAANG for different reasons. Get a technical manager to bootstrap the project, set up interviews, and you should be good.

Also, don't forget about dev tools and ops expenses, a need for oncall, and hiring devops to run it.

Disclaimer: I'm extremely biased having worked as a consultant for a few companies in "Cloud-Stuff" dealing with (almost entirely) major (non-technical) F500 companies. Typically this work was "modernization"/"cloud native" blah blah development.

My firsthand experience with many of these organizations is lack of competence in a large portion of the technical staff, paired with dependency on the software systems being used.

I don't mean "nerd sniping" subjective attacks on competency (you don't know $TRIVIA about $LANGUAGE/$SERVICE, wow lol), I mean lacking basic programming literacy/ability to troubleshoot from written documentation/read simple source code for enterprise CRUD developed for their domain that they're (presumably) familiar with.

i.e getting confused responses for questions like "Did you check the logs?", despite the process being outlined step-by-step in a runbook.

The end result is these systems had a laborious, slow process for even very trivial troubleshooting.

Instead of doing what you're doing "should we find more competent people", they'd add Yet Another consulting firm of marginal skill to mash shit together until it mostly worked, at massive expense.

A short time later, when an issue was encountered, they'd repeat the process, burning money along the way.

My $0.02 is only that, if you directly depend on software for your business, at least consider having people that can manage and maintain whatever it is that you depend on (assuming its not some purchased SAAS from a reputable company)

I can't say this is relevant to your situation necessarily, nor am I in any position to advise one on how to operate a logistics company. My only position is some companies seem totally allergic to even attempting to hire competent people and waste untold sums on third-party firms doing mediocre work, directly impacting their ability to do business.

Unless you're willing to become a software development company, I would strongly strongly suggest NOT writing the software yourself.

1) Can you acquire this company?

2) Can you talk to other companies that do something similar and migrate to their platform? Or threaten the current company with them losing your business if they don't get their shit together?

I've been a logistics tech CTO for 10+ years.

There's a lot to gain by building.

If you want to chat, drop me a line: ribpx.fwd@gmail.com

I would prototype this by duplicating a vertical slice of the business that is (presumably) well understood and easy to teach. Don't start with the hardest thing and definitely don't try to plan it all up front. Hire some cheaper contract labor to begin with. If you find you can't even replicate a small part of something you thought you understood, you should probably abandon the overall effort.

The last thing I would do is make some grand decision, locate an 8-figure budget, hire a bunch of people, and then hope for the best. Incrementalism is the key to not blowing this idea up. You already have a ~working system. Leverage the hell out of that. At the end of the day this is probably going to be more of a people problem than a technology problem - managing scope and expectations throughout, etc.

If your current third-party product is barely functional and unsupported, it's clear that you need to consider a replacement as part of your mid-term strategy. It seems that there is a high risk of your vendor ceasing operations or their solution not being able to support your growth. The sooner you start the transition, the less painful it will be.

When deciding whether to build a replacement yourself, consider whether this solution could become a competitive advantage in the market. This is unlikely to be the case for a logistics company unless you plan to sell the software you build. From a business perspective, it's usually better to invest in your core strengths and outsource everything else as much as possible. Otherwise, securing the budget to hire the right talent in the right amounts will always be more challenging.

Assuming software is not your core strength, it may be wiser to search for one or several solutions that you can combine to support your strategy for decades while providing a certain level of flexibility. This might also mean building some parts of your system with low-code or even custom code, but I would try to keep that to a minimum.

If you still decide to build something custom, my recommendation would be to avoid replacing everything at once. Instead, replace your existing solution gradually. Start by rebuilding the most problematic functions first, and then add other features as you go. You might find along the way that some parts of the older solution's functionality are no longer needed.

As the founder of a low-code SaaS product (https://uibakery.io) and a service provider company (https://www.akveo.com), I can definitely relate to your challenges, which are quite similar to those of my clients. If you need any help with your transition, feel free to reach out at vlad a-t uibakery.io, and I can look at your use case in more detail or connect you with others who might help.

By the way, as a developer, I find logistics interesting, I wouldn't be concerned about the industry. Your problem seems intriguing, I'd work on it.

I don't have experience in this situation, but your assessment sounds very solid,I agree with you.

The main pitfall I keep thinking about is making sure to hire somebody very focused on getting the stuff done specifically for your business. If they go down a path of developing software, it can generate enormous waste. To clarify, they might need to be ready to create scripts to extract data from the existing software and integrate the workflows (kind of doing what you are doing with no code), rather than writing from scratch, because the alternative might have astronomical costs. I would focus on senior devs, pass on juniors for the first hire. Not sure how many people would be necessary.

I would start with a business case - what are the benefits, is it going to generate revenue or reduce costs, when do the benefits start to be realised.

Then look at the cost in starting to develop what you need, and how you’re going to get started.

Are there existing COTS systems (e.g. SAP, Dynamics, Salesforce) that are extensible but can do 60% of the base functionality out of the box? Can you start by integrating two systems or using your low code platform to prove the concept? A couple of engineers/freelancers/external shop for a few months is a lot cheaper than hiring a whole development team… others in the thread have given you a reasonable estimate of that.

Think about what’s the MVP needed to start showing ROI. Maybe do a smaller business case for that.

Look at the payback period internally and ask what hurdle rate is needed to invest from your CFO.

The issue of doing in-house is the issue of finding competent devs, meaning not only "someone who code" but someone who understand how to PROPER design things, witch is essentially a lost art.

EDIFACT is dramatically simple, far more than modern XML-based peppol alike dialects, here the issue is "just" knowing that very likely any "institution" might have injected a gazillion of personal stuff, mostly undocumented or badly documented to be take into account for a long interim, but developing a personal ERP trying the modern path is far from being digestible.

IMVHO it's feasible trying to fish common-lisp/clojure world. That's a niche enough there is not much retention issue, and there are still skilled devs because it's a kind of niche where some arrive, try, fail and go, some skillful remain and do want to be there.

You said EDIFACT - it'll cost more than you expect :)

You'll need to attract folks who care deeply about the space (yes, they exist, for some people logistics is fun), are seasoned software devs (the pool shrinks) and set them loose on the problem with as few restraints as possible.

Your best bet here is an approach that gives them a stake as well. Either as an external experiment with performance gates, or by founding a subsidiary that they co-own, or ... well, any number of solutions.

Yes, you won't be able to outcompete FAANG on salary, but you can outcompete them on autonomy. And a lot of experienced devs care about the latter part more. (Having made and saved a good chunk of big tech money)

Biggest issue will be vetting the people you find. If you don't have inhouse experience, either take an approach like davedx suggested, or reach out to somebody who has (hekker)

Long thread so I'm not sure if someone has already made this observation, but -- reading your description of the single entrenched supplier to your industry that comprises your company and a set of competitors, made me wonder about "going bigger". This is the idea: yes start a team to develop a greenfield modern solution to meet your needs, but do that with the goal to eventually spin it out as a separate company that is also a vendor to as many of your competitors as you can sign up. The benefits to this approach are that more resources can be brought to bear, meaning better developers can be hired, and the cost can be shared between the participants. This has been done in the past for example by the airlines with Orbitz, and media companies with Hulu.

I think if you put in charge a good visionary that truly understands your requirements (either a curious new hire or someone from within), you can drive development externally.

I wouldn't hire and staff for this, because it will be a hard sell for anyone with great SWE skills to work on internal software, while you can hire rockstar freelancers to build a good foundation, and evolve your own platform opportunistically with additional freelance work.

You can also leverage LCOL countries to set up your own dev shop, possibly Eastern Europe if you want good timezone overlap. Feel free to reach out if needed, this is my wheelhouse.

The only question you need to answer is supportability. If the platform is the cornerstone of your business, what happens if/when it goes down? What kind of SLO would you have internally? Who is on-call?

Just wanted to add in, even as someone who isn't super experienced in the field (1.5 years of contracting on top of 6ish years programming in grad school), I find logistics an incredibly interesting field. So yes even from youngish guys you'll be attractive even being a "non-glamorous industry."

Also I believe a large swath of developers just enjoy problem solving regardless of the application as long as solving the problem itself is a challenge. While others like steady routine, and I think both are useful to your ends. Of course there are some that like to be on the cutting edge (though IMHO logistics can very much include that, though I recognize that isn't your needs currently) and those people will choose a different company.

I lead a migration very similar to this. We had taken over a system that was handed to a business person with all the technical team leaving because of a dispute. We rewrote the system and migrated all the user accounts over to the new system in a couple of months, after which we ran it for a couple more years, until the company got sold.

I would say the most important learnings were:

- there is lot of "extra stuff" around the product that is somewhat independent of "how complicated the product is". Even a simple CRUD app needs source control, a test suite, (ideally) some automated system for source quality check (like linters, analyzers, formatters, etc), a system for deploying it to a dev / staging / production environment, etc.

- production also needs monitoring (both "is it working" and "is it working within the expected parameters" - for example is it fast enough). Ideally there would also be some alerting around this monitoring so that you don't have to wait for users to complain to find out that something is not working.

- there is a saying of "use boring technologies" (https://boringtechnology.club/), which I 100% subscribe to. That will ensure that there are lots of examples for each aspect of the product you're trying to implement (for example authentication and authorization, creating an admin dashboard, etc).

- In addition I would say "use some managed platform to offload lots of these worries". Yes, it will seem weird to look at the bill at the end of each month and say "why are we paying $Xk each month for Heroku when I can rent a server from Hetzner for less than $100?" - but managing that Hetzner server (and probably more than one server, to make sure that a single hardware failure doesn't take down your entire product), ensuring backups are working, etc would cost more. Optimizing between "buy" vs "build" is a delicate balance.

In the end I think programmers who like to start new projects are a rare bread. I'd be happy to chat about this more (I'm also in Europe). Feel free to reach out to me at cratt[at]grey-panther.net.

One solution is to partly outsource the development. You would try to build up a small team that deeply understands your business and the solution and and owns the system can maintain it long term, but cooperate with a specialized service provider for the initial development (which will probably require more developers than you will want to ratain long term). Such a service provider will also be able to support you with he generation of the initial project vision, requirements engineering and usability/user experience engineering with experienced teams, whithout you having to hire for such roles out of the blue.

While there are many such companies in Europe, I can recommend the one I just so happen to work for, mail me if you want to discuss it further.

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

Anything can be made sexy: https://www.crunchbase.com/organization/flexport

That's not the problem. The problem you have is defined in https://en.wikipedia.org/wiki/The_Market_for_Lemons

It is the information asymmetry. How do you expect to hire competent devs/providers? Yourself? A random third party HR company? (hint: still the same problem cause as today)

You have to find a way to crack this, no matter the approach you take.

There's also the problem of finding a too competent provider/developer who gets bored or is distracted with other things.

You need to accept it's a learning process and do the homework. You can't throw money at it. You can't cheat. There's no way around it. Sorry.

Start by reducing or removing legal + compliance. It's where innovation goes to die. You can have reasonable compliance and security without burying everyone. Make them concentrate on real present threats, not theoretical ones.

Next, sort out the egomaniacs... there's two types: those who are "too cool for school" to comply with some basic standards like... I dunno tabs vs spaces or code formatting, then the guy that wants to rule with an iron fist and one-size solution everything.

Finally a strong opinion: modern web development is absolute crap. I would favor server side rendering frameworks and nearly zero javascript for internal apps. We're here to get stuff done, we're not here to coddle the user.

Short answer: you need a tech partner/officer

Long answer: The model of partnership can be different. The answer depends on your company future vision. Do you want to run a business and pay for everything that's not relevant to your domain or do you want to make the best business possible and crush your competitors?

There is a "Not invented here" principle software companies use to eliminate distracting factors and focus on what matters. However if every software you use isn't good, why not make your own? Plenty of companies do that.

A few options to consider:

1.Software provider

2.1. Re-negotiate software services with current provider. They can be irresponsible, underpaid or bad at negotiation and cannot explain you why they don't want to or cannot provide basic support.

2.2. Find a better software provider. There are plenty of outstaff companies in europe who'll be happy to help you with regular EU wages with a decent quality.

Better to transition slowly if you plan to abadon current contractor. Think of it as a drug use, come off slowly to make it easier.

2. In-house department

2.1. Find a tech lead (freelancer) and start educating one in your domain. Upwork, your network, whatever way is more comfortable for you to find an engineer. Don't worry about sexieness of your business domain, there are plenty of people who'll be willing to help. But one must become an expert in your domain, engineers do what they told to unless you make them understand what your company actually needs, so they can ask you reasonable questions.

2.2. Do you want to start a side software business in 2-5 years? This can be an opportunity for you to run a second/third/Nth company that provides SaaS logistics companies. I don't believe you are the only fish in the logistic sea, neither software providers or engineers are.

Feel free to ping me if you have any questions or need assistance: smart.hope1473@fastmail.com

(I'm in Europe and will be happy to meet over a beer)

Can someone explain me how this post works? I see here it's 5 hours old, but when I go to the OP profile it says it's 3 days old https://news.ycombinator.com/submitted?id=45HCPW

If you do bring it in house look for very senior folks, ideally ex-founders who’ve built a product from scratch. You want someone who can help figure out requirements, feasibility, and write code. Pragmatic engineers are always the best.

happy to chat about this if helpful, email is in my profile

You are asking two different questions here. In house vs contractors is one. The second is whether you should be using a third party product.

My advice would be to continue using contractors, but different ones, and focus their attention on building a better product.

I hear you loud and clear! In robotics, every company has the same make-vs-buy dilemma with respect to fleet management software (quite comparable to logistics). I've been in your shoes. This is why I believe in third-party solutions that don't try to be one-size-fits-all, but instead enable you to build your own, perfect system yourself, and that's what I'm working on now. I've recently written about it here: https://transitiverobotics.com/blog/make-vs-buy Feel free to find me if you want to chat and compare notes.

Weird way to approach this... since its a critical business decision, wouldn't you like a formal professional opinion? Seems like it would be worth the $500/hr for a week to get real information that you can use to get a decent view of what your options are...

I would start by defining an MVP. What do you really need to support operations, and what can wait until later? If it can be done by hand for a while, don't put it in the MVP. If you can manage with Excel for a few months, don't put it in the MVP. That should give you insight into how big of a project you are looking at. The bigger the project, the greater the chance it's not going to go well.

EDIFACT is a bit of a mess, but not that scary. IME the details of logistics are more complex.

If you are in Europe there are a lot of people in software development in non-glamorous industries. I see more risk in judging tech talent. How do you know if you're talking to the right people?

Don’t replace with in-house solutions anything that’s already working. Bring in-house just the thing you want to add next and go from there. At the very least it’ll kick your existing provider into gear when they know they (might) have competition.

Building a single tenant system is 10x simpler than building a multi-tenant SaaS. App development is so much faster these days and you can build a significant system with just couple of remote devs. Even easier when there is an app from which they can copy from.

No.

As a software engineer, I will never again work at a company where the product is not software. Software at non-software companies is a cost center, not a profit center, and cost centers get fucked. It's thankless, depressing, soul destroying work.

Maybe start a new company whose goal is to write software for companies like yours. I have worked at a startup launched by execs from established industry with inside knowledge of what is required, and it was truly fun, even though the great recession brought it to an end (acquired for pennies).

If you do it yourself, in house, there are plenty of thirsty contractors and consultants who will be very happy to bleed you dry.

Basically, if you have to ask, then the answer is no, you can't afford it.

I work with companies that hire us to do exactly what you're describing. I've seen this go bad every way you can imagine. Here's some of the top mistakes.

1. Expecting employees to support a project like this and do their regular day jobs. They can't. One will suffer, probably the one that is new and unfamiliar. This will frustrate the team working on the project (whether it's in house, freelancer or contract firm).

You can hire some new people first and train them up in a short time to take simple tasks off longer term employees plates so they can spend some percentage of their time supporting the project. Don't hire new people to support the project, they don't understand your business well enough. This is a cost of doing this type of project that is often ignored. And don't allocate something small like 10% of employees time. It should be at least 50%.

2. Expecting the project team to get all the requirements. Understand, in detail, what you need to build. This is not the time for agile. You have a known system that you want to replace. You aren't discovering a new application space. You can run the project with sprints, agile rituals etc. But don't do requirements throughout the project. Get them up front so the team knows what they are building and can architect it appropriately. This is a topic that I could write pages about but you will wish you had better specified requirements no matter how well you do them. You can carve out a small piece of the application at first to limit the scope but that piece needs full reqs.

3. Get something done and in the hands of your users now. I like to start with a checklist of a process. Replace one item on that checklist. Repeat.

     login to system
     click shipping
     fill in manifest -> identified as the piece to replace. 
     check schedule on calendar tab

becomes

     login to system
     click shipping
     fill in manifest
         login to new system
         export manifest data
         import into new system
     check schedule on calendar tab

4. Setup your development, testing and production environments and keep them in sync.

The scenario “stuck at 80% completion” is likely.

Focus on the functions/features you currently use and can not live without.

Try to build an MVP (or as many microservices as needed) which serve as a proof that you can build the missing 20%.

Don’t bother building flashy GUIs, try to build the actual logic first. If you fail building this 20%, you avoid wasting funds for the flashy 80%.

Been there, done that. We built the flashy 80% and everything came to an abrupt stop when leaders realized we can not build the most important parts because the underlying platform does not support what was supposedly supported (miscomm with standard platform supplier during req engineering).

Do you have any people in your company who could build what you need if given the time? Sometimes there are people who are pretty handy with coding who aren't called "programmers". They may be analysts or engineers or something like that. And is there anyone who understands the domain, has solid leadership skills, and at least a bit of tech skill, enabling them to serve as a project lead?

If you have both of these, you could conceivably use your existing staff to build at least a limited-functionality version 1, and backfill the jobs they used to do with new people. If not, you have the harder problem of needing to hire people to do something you don't know how to do at all.

I've been an early engineer in multiple start-ups, have co-founded 2 startups, and about a year ago, took a position where my primary role was to in-house logistics software in the healthcare space being developed by a 3rd party for about 4 years.

To succeed, you need a founder-type person IMO, who's full-stack, and has built great engineering teams. Hard to find, but possible.

The company I joined was also not a software/tech company, and they put the trust in me to define our engineering policies, how product-management happens, and put an emphasize of knowledge transfer for my first 3 months.

If you want to connect + talk more I'm at michael[at]mat.tax

Hi! I've done this exercise for multiple companies of different sizes as a CTO. One of them was a bit bigger than yours (org which is a retail arm of the Singapore Changi Airport), and 5 others were smaller, usually startups & scale-ups. Some of my happy customers are listed here: https://a2zweb.co

Please let me know if you need a hand with bringing tech fully in-house.

Cheers Dawid

https://www.linkedin.com/in/makowski/

As someone that quit a job in this very industry then went back to rebuild when his boss left - people that worked in this domain will always look fondly upon joining such a company.

It's a fascinating domain, and if you're the type of person that can do code but can also see edge cases and understand business logic - you're going to be one of the top paid people around. So, maybe look for people that aren't the usual cut of coders or experts, of course - if your organization allows the "freethinking" type crowd which sometimes might be prone to accepting toxic people (which can and should be filtered out, eventually).

I've worked at a large company that ran internally developed logistics software. It worked for them.

> Strategies for attracting and retaining tech talent in a non-tech industry

While you might be in a sector that isn't tech, you have tech. Put yourself in a software engineer's shoes, from a career perspective. We tried to keep up to speed with respect to things like framework/platform version, development practices, etc.

Make it clear and obvious that you will continue to invest in technology. We went to mobile early because it made sense for our business. We continued to invest as mobile changed with the introduction of iOS, and as computer vision got better.

Feel free to reach out if you want to discuss further.

Have you thought about / are you big enough to buy that vendor?

Otherwise: Find a really good HandsOn CTO, give them enough budget to build up a team and have freelancers, build it out.

But before that, have good people analyse the business requirements first.

Interesting questions. I Work in the logistics/B2B area for quite some years and know this kind of problems well. I think in-sourcing development can be beneficial if your niche has so many special requirements and this is a core application. Or you can go with a trustworthy software house as a partner to be a bit more worry-free. Our customers usually do the project management and the requirements and we are taking care of the solution's technical aspects. In my experience this makes a perfect match especially in technically "non-sexy" environments like B2B, EDIFACT. On the other hand it takes time building trust from both sides.

I 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.

I'm a logistics consultant that specialises on the software side of things!

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.

Pulling something like this off is pretty serious business, there are a million things that can and often do go wrong, which is why so few software projects are successful.

And you're in a pretty shitty position, to be honest. Because you don't even have the skills required to hire the right people. Much less handle the project yourself and delegate tasks.

My advice would be to find someone you trust with plenty of software experience, explain the situation and LISTEN to what they have to say, especially when it's not what you want to hear.

Or you're likely going to waste a lot of time and effort making the situation even worse, happens every day.

I think it’s certainly doable and sustainable.

Pitfalls you’re not considering:

Maintaining it. It will have an ongoing cost of keep things running, secure, up to date. This will get bigger and bigger as the project becomes more integral.

The right mindset. You don’t want devs who approach this as is they’re building the next Amazon or Google. You don’t want it over engineered and have devs trying to be too clever/ padding out their own CVs. This might also make it pretty boring.

Unless you have some dev who is very interested or experienced in logistics you’ll need a some people from the business investing time helping explain what the feature is and acceptance testing it.

Here's what I would do.

Hire some people to start building it, publish the code under a copyleft license such as the GPL and start hiring consultants to contribute to it. This will give you control over the critical "must haves" while making it possible to eventually spin a lot of the maintenance off to third party companies.

Software that's developed this way has a long history of being very high quality as there's much more cohesion and communication of theory when the developers and costumers work for the same company while at the same time the GPL will protect the project from potential takeovers via internal politics.

If you're having this pain, and there's no better provider, other companies in this business might be struggling too.

Are the companies that do well in this business also deploying in-house software? Are they partnering with someone, or are they suffering? I would try to benchmark this first.

If you go ahead and decide to deploy in-house software, you'll have to make the case that this isn't a cost center and is an actual strategic investment, otherwise it won't work.

My take: every company that has an edge in today's market eventually turns into a software company too.

I know it's not popular, but it could also be a place where a 3rd party engineering / development / managed services firm could be useful. Your labor requirements in building and transition may be different than long-term run, and if it's relatively simple, maybe the long-term run/maintain will be different.

disclaimer: I work in the research org as part of a company that specifically advises the contracting and management of outsourcing relationships. This does work, but is not risk-less and effort-free. But, in logistics, you're probably used to managing critical 3rd parties.

Hi, my ex colleague pointed me here.

This is exactly what we specialize in: logistics and transport digitization. we are www.lowcode.co.nz and have experience and connections in EU, but NZ needs some help with digital maturity (and much nicer weather here too).

We are currently building our SAAS platform for cranes and hiabs called mothertrucking.co.nz (sign up for free as we are in stealth beta)

What you have mentioned is exactly the pain we see a lot in this industry, (tools get made, then the budget stops, and it becomes hard to maintain, and all the original devs have moved on to more fun projects.)

Id be keen to have a talk to understand your struggles.

Since you can't find another vendor, it might be time to bring on software consulting practice that specializes in this area or at least doing something similar.

If you can find a firm that is capable of doing the work, then you can figure out how you will maintain the software. You'd have to determine whether it would be better to engage that firm for the maintenance or hire someone. Possibly a combination of both. This could be done while the software is being built.

Large software projects are more likely to take longer than estimated and go over budget, so be sure to factor this in to your calculations.

IMHO I believe nearly every organisation I have worked with at this size always has a management problem.

The reality is if you want your teams to be competitive adding contractors competing with your in-house staff can be a really good thing.

Most in-house teams are jaded with management and having contractors set to do jobs (of course they have to be good) injects some life into the organisation.

If your in-house team is toxic you need to go and be the one to monitor that.

I worked on a team where when the CPO was there it was actually amazing but the moment he left their idiot head of engineering and middle management had a field day doing nothing

What you don't say is what the product is, what you spend on it, and what its value is to your organization.

I'm in the software side of logistics, and I can imagine very different things you could be referring to, with different levels of effort and different levels of benefit/risk to you.

If it's just cost-savings, then this product has to be quite expensive to justify your time. If you're hoping that a better version of this product could make your operation more reliable and efficient or unlock new business opportunities, that's a much better proposition, though still hard.

We specialize in creating custom software for businesses in your exact same situation at https://glideapps.com, and we have a large community of consultants who can build for you as you develop an in-house capacity. Our top experts can build a POC for you starting around $5k if you want to quickly test the platform–you can get a quote here: https://www.glideapps.com/solutions

Having been in that situation and developed SW in house as well as hired third-party firms to do so, based on my experience I would go with in-house if 1) you have very specific requirements that need to be well understood and implemented, and which may require close collaboration with the teams who are actually using the SW; 2) the SW in question is mission critical; 3) you want to be able to make changes/adjustments fairly quickly without the overhead of administrative/contractual dealings with a third party (i.e., whether it fits under existing SOW etc.).

>I'm an executive at a mid-sized logistics company.

Curious, what are your hard skills, or what aptitude do you have?

>Strategies for attracting and retaining tech talent in a non-tech industry

Old saying: Treat others as you want to be treated. ( other have enumerated it: good pay, stability of employment, autonomy etc.) This is true for most skilled professions. It's probably less true for professions that require less hard skills - where behavior like coercion may work, though temporarily.

We had a client with a similar need in the logistics sector.They also struggled to get a custom online software solution that is suitable for their company. The biggest issue with these projects is that development costs can increase alot especially if the scope of work is not clear. If you want some more information or want to learn more about our logistics solution you can contact me on divan@fleetwise.app

Depending on how niche the third party company is, and how large your company is, is it feasible to consider a takeover? You can then get your issues solved without having to prioritize features you don't need, you get to keep the technical staff and don't have to train up a new team in something your business may not have the expertise in.

You also get to keep the same UI, the same business logic and it means less disruption to migrate to new software.

Just a stab in the dark, probably not feasible but you are looking for interesting suggestions...

As some others suggested I would also recommend to try to make an experiment. Identify one part of your software suite you think you can build, operate and do the maintenance for. Aim to do it as fast as possible. Test if you can resolve the issues, you have with your vendor, if you do it yourself. If that fails, it propbably isnt a good idea to go full scale on it. Again: aim to get some real world experience with your own build software AS FAST (and cheap) as possible. Dont go for a perfect solution.

This is what I saw a company in smart metering do in this case, and it worked for them very well:

They had all of the seniors on their own staff. Architects, Tech Leads etc. They chose the tech stack, planned the development roadmap and in theory could've done it all themselves.

Then they used contractors to build the actual code with their in-house seniors overseeing and advising (and doing some coding themselves)

This way the essential knowledge was in-house, but they could vary the resources used for development depending on the need for new features.

My opinion, warranted by experience, is that no SMB should be in the software development business for their core systems.

The likelihood, even in 2024, is that you'll do a poor job, spend too much, and suffer along the way.

There are exceptions.

The safest course would be to evaluate the packaged systems used in your vertical and license the one that best fits your current and future needs.

That'll get you 75-80% of the way there. The rest can be made up with help from the vendor or external consultants that can tweak the system.

I worked for a customs-logistics company and did some integrations with european cargo firms. EDI is definitely something a senior developer can figure out and parse/generate. Wiring your system through api/sftp servers won't be that hard.

The main problem will be the UI. Use existing frameworks! Telerik, devex, anything you can get your hands on. Don't let your project become hindered by someone's half-ass attempt at reinventing a data source and pivot grid. It already exists and it is a solved problem.

I’m doing project like this for more then a decade now. What worked?

- evaluate the new team on some thing very special for you for example try to take from the 20% you never realized

- if this work don’t feel you are on right rails.

- go next creating the smallest project that bring the most value to you

- piece by piece you will have replaced the most important parts of the old system

What didn't worked?

- if the management is not very convinced and involved

- if the old system doesn't have api or in general has poor interoperability

- don’t change target, try to keep the target frozen until the job is done and testable

> The provider is understaffed and unresponsive and the platform is stagnant.

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.

If your company is part of a large ecosystem underserved by software vendors, building solutions for yourself and others may be transformational (as AWS has been for Amazon).

The thing with software is that it is rarely (not never) commercially successful to develop single customer solutions. So if you can build something that works for your business and can be used by your suppliers/partners/customers in enough volume to pay for developing and maintaining it, you win.

Reasons not to do this: - you don't really understand the full complexity of the domain or regulatory environment yourself - you don't have the funding available to commit to not only the development team but also the infrastructure to support them (tooling, cloud environments, security team, policies to support this, technical writer, ...) - you're not prepared to pay for top talent (assuming you can even judge it, see the point below). Starting something from scratch successfully requires a really experienced team who understand how to model and build things well. Who know how to build in sucha way that frequently changing things effectively become configuration rather than code etc etc. Most likely this means people who have 10+ years in the industry and preferably people with some product and industry experience. - you expect this will be a one-time cost hit and then effectively free in perpetuity; software is expensive to maintain, requires ongoing security patching, keeping up with library and technology updates, and ongoing commitment even if from a business perspective nothing is charging. - you don't have experts on hand who you can afford to have spending more of their time than you think is reasonable with your development team explaining in detail all of the lessons you've learnt from the current poorly performing software and what they really need. - you're not prepared for it to take at least four times as long and be four times as painful as even your worst-case initial estimates. - you're in an environment that requires eg. purchase of vendor libraries and/or integration to proprietary platforms and this impacts the economics of boutique development - you're highly regulated and software you build/use has additional complications like certification/audit/... requirements - especially if you don't fully understand or can't communicate this effectively to the build team - you don't know how to judge the competence or experience of your founding technical team; this will be critical to your success - more critical than almost anything else. One bad hire can derail your entire effort. - you want an entity that you're bound to contractually and that you can sue for remedy when things go really wrong. And they will go wrong. Of course there are lots of reasons to try to build the software yourself too, but hopefully the above gives a few counter points to think about.

To me, the question is, can you build a better software team than your current product provider has? If you are planning to hire developers as if they are just construction workers, you're in for a bad surprise. Plus, attracting talent to such an industry would be very hard unless you are willing to pay high amounts, often with equity.

If you're going to hire one guy to start, check their portfolio to see that have build apps from scratch, and evaluate the quality. Many can't ship.

Given the domain is well known and solution is in use already that can be used to model new solution, if I were in your shoe, I would have started with one dba, and a couple of oracle APEX developers. Oracle APEX, with a solid database in background, can get a lot of development done in a short time. In 2-3 months time, a review of development activity would have provided a decent idea if development should be taken inhouse or left in current state.

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

Money! Work life balance. Good benefits.

I currently have zero interest in the business idea of the place I work. But they pay well, aren't on my ass if I wake up late or need to visit a doctor appointment, and provide zero cost benefits. I have no interest in making even more money or trying to climb. Take care of your people and the business line doesn't matter. Just make sure you get what you're paying for.

One extremely common pitfall is that attempts to build dev teams in non-tech companies end up creating a clique of "big thinkers" who unfortunately can't code much themselves. They end up convincing the management to contract out the lowly work and essentially become middlemen to other people's work.

You possibly can avoid that via good hiring policy if you know what you are doing. However once you quit the chance of things deteriorating is huge.

I know you're asking for advice and not looking for someone to hire here, but the company I work for does just what you are asking for: Creating custom made software for B2B companies.

Check us out at www.bizzomate.com

We are focused on low-code solutions but we try to understand the customers needs through service design. We also have our own business rule engine that might be useful to your case. We also have experience building mission critical ERP-systems.

Anyway, check us out and feel free to contact us!

I'm an engineer in this space and would be interested in learning more about your business and why you feel you are unique and under-served. My contact info is in my profile.

I do find that the biggest challenge as a vendor in logistics is highlighted by, "Our business operates in a specific niche and there are no other providers who cater specifically to our industry." This makes it difficult to make software that works for everyone even if we are all in the same industry.

If you choose to stick with your existing provider, you can negotiate a service contract where the provider hires and manages engineers that work exclusively on your account. We did this in the past with pretty good success. We were planning to exit in 1-2 years and didn't want to invest in an entirely new platform or build it ourselves when we knew the acquiring company would end up rolling up our service into their existing platform/infrastructure.

Hi, I’ve done this exact thing for a client of mine in freight. The approach was similar - build an “internal” team and develop out a replacement product for their customs and general freight systems.

The EDIFACT / EDI stuff is annoying but once you crack that it’s basically CRUD.

The other challenge is ingesting carrier prices and the management of the rates. No carrier has the same format and API’s get mixed results (if they have them!)

Since you are trying to implement it inhouse. How about choosing a better stack? Hire a high profile consultant like Saša Jurić and get the best stack implementation (i.e. Elixir). Here's talk by him on how he solves customer's problems.

Simplifying Systems with Elixir • Sasa Juric • YOW! 2020

https://www.youtube.com/watch?v=EDfm2fVS4Bo

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

Yes. There's overlap between transit nerds and software devs. I'm one example.

If you go down this route, try to hire someone from your provider that knows the current product well from the inside. If there is someone left, of course.

At a previous company, when the provider of our software started stagnating, we brought the development inhouse by hiring his best engineer and a few good freelancers, then slowly phased them out in favor of employees. But an important difference was we owned the code because it was a bespoke solution from the start.

One pitfall to consider: software development is often its own culture, and nourishing and valuing (or merging!) multiple distinct cultures in a company requires real effort from leadership/management/team leads/senior ICs/...

I'm sure that e.g. truck drivers and software developers can be made into a strong team, but don't just assume that cross-culture collaboration will work "by accident"/"automatically".

I've not worked in the logistics industry or with edifact specifically but have dealt with phased removals of large "turn key" products in a several heavily regulated industries. I've also gone the other way where we've replaced in house solutions with vendor provided software.

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.

Seems to me that you got a quality management problem. Does not matter if your team is in-house or remote, software quality is a problem. I would try to understand why your code has those problems.

> 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.

You need to hire few very skilled software people, it seems you can afford them.

It's really hard to give advice without knowing the complexity of the software, desired SLOs, how much you currently spend on your currentvendot, and how many $$ your current solution is costing in lost productivity/growth.

You haven't named the third party product. I presume because it reveals too much, but perhaps you could name it along with its competition so that we can get an understanding of complexity?

Your goal is to get a quality output and get your work done in a right manner. It can make sense the developer can work from anywhere to meet the desire goal. Let's hit me on email so we can have indepth conversation for the assistance. Here is my email : vivekp@intuz.net

Yes, yes yes.

I've worked in a consultancy and seen a customer go in house. It was the best thing for them. Then I left to work for a customer and it's great. Internal development is so much better than external. Everything aligns so well. You get developers that understand the business inside the business.

We have offshore contract developers as well but managing them as a dev is much easier than it would be for a non technical person.

The single most important thing is to hire the right person for leading (technical) this project. Even a tiny (<=3) (but well-paid) team can deliver you results beyond your expectations.

There're interesting things to build in all industry; logistics is not an exception.

I've seen stuff like this before and the most common reason for failure is the "technical" person focusing on entrenching their position instead of focusing on delivery.

This seems like the story in "The Phoenix Project". If the outsourced software is critical to your operations, it seems it should be brought in-house. Software design is best done when the feedback loop is very tight. It never is with outsourced software.

As for how to go about building a team, you are better placed than I am to figure it out. Probably start with a small team with the most critical bits and build from there.

I work for a SW house where we specialize in projects such as this (as far as I can tell from your description). We have very experienced people, and are well-known in our niche (we are big on Clojure, which gives us a lot of leverage for pulling off difficult projects with a fairly small team). If you're interested in knowing more, I'd be happy to have a chat with you.

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

Perhaps it's perceived as non-glamous, but earlier in the week I met with a logistics team in another company who we're working with and the problems they address are absolutely fascinating. The complexity of the domain certainly made it intellectually appealing to me.

I'm late to the game on this thread, but I am a lead SWE at a medium size logistics company. Been in logistics SWE since 2015. I'd be interested to hear how your company fits into the industry, who your service provider is, which no code platform you're using, etc and at the very least give you a sounding board based on my experience. Shoot me a DM if you're interested!

There are companies out there (full disclosure, I work for one[1]) that create and maintain custom software for companies such as yours, including websites. They work with you to make sure you have exactly what you need. That direction may prove more effective than trying to bring tech talent onboard.

[1]: https://www.miriamtech.com/

> [I'm] getting more and more frustrated with our software situation and am considering taking software development in-house. I've been lurking here for years, so looking at the HN community to talk me out of it.

For the opposite perspective, https://danluu.com/nothing-works/ .

I built and maintain internal and external web services at the shipping agent I work for (agent for one of the top container carriers) and I released my edifact Library on GitHub if you need you can find my email there, although it's all php so it may not be glamorous enough for HN crowd. Also advice on standards as I seat in some industry working groups

Can you purchase the provider and then own the existing code, and hire up to build on top of it? Tear It All Down might be an expensive fallacy.

As an alternative you could appoint a software services business to build it for you, to your specifications, then they step back responsibly handing it off to your business. It's more expensive but they will be off your books in 6 to 12 months unlike if you hired your own team. You'd hire a small team to maintain the system, rather than a large one to build it.

I would highly recommend first of all reading "Peopleware" and "Mythical Man-month" which are all about making this type of decision. Since this is data exchange, you need to map out the data flows your company does and where things are working and failing currently. At that point you should have enough information to start making decisions.

We do contract base software development in India, and have worked with https://haulog.com/ recently. If you’re considering to start with outsourcing to jump start, Let’s exchange few mail ( patelgopal@gmail.com ) and see if we are compatible enough to try and make a demo or something.

I’ll caveat my response here: this is provided as general guidance and should be seen as such.

1. Have you considered managing your providers performance? What could you do in this area?

2. Have you considered going to market for other providers to start new or to take the solution over? Is that even feasible?

3. Have you considered the long term capability build you need in your company if you decide to bring this in?

Invest in high quality software kernels and professionals that can comfortable build with them; divest from low-quality "wrappers" around said kernels, which is most SaaS.

>90% of SaaS are some (expensive, low-quality) wrapper around (free, high-quality) Node/Rails/Django/Spring + a FOSS RDBMS, with more features than you want and less than you need.

TBH it sounds like you need a tech business consultant (an actual consultant, not just a contract programmer) to help you work through this.

If you add your contact details to your profile I'm sure some people will contact you.

Ideally you'd want someone with a postgrad in business and a decade or so tech experience to help guide you through this (cough)...

Hi, I'm thinking about exactly the same problem right now. Bringing in house devs to a "legacy" industry business, that has poor use of some digital services... This could really brings an advantage, and I'm sure nowadays software engineers could really be interested in working on "tangible" subjects rather than some bullshit saas...

Sound like you should be doing a proper cost/value/risk analysis of the current solution along with a proposal for change.

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.

Don't try to rewrite the whole system in one go. Move incrementally. You can start by creating your own UI that performs most common functions and uses existing system as a backend. This way you can automate what you need and work around bug. If it goes well then later you can gradually move to your own backend.

As you mention it explicitly, EDIFACT is a big standard, but the documentation is excellent and machine parsable to generate schema/code.

Years ago I wrote a library to enable an ~80 person record (vinyl/CD) distribution company to use EDI to deal with Amazon/Virgin/HMV/etc.

It’s not that scary - happy to discuss more if it would help.

Hi, I built a low-code platform WebWidgets.io (WWIO) specifically for companies that are too unique for cookie-cutter SaaS products to work well, but not big enough to do their own development work. I've built several WWIO apps for small businesses/nonprofits that have saved multiple FTEs worth of manual data work in Excel.

WWIO achieves high productivity by moving all the logic into front-end JS code, which accesses and persists data to SQLite DBs on the backend with a simple, standard API (for VIP clients like you, I would augment this with some backend Python scripts). This approach makes it super-easy to build the CRUD features, while allowing a backdoor when you need special functionality. For a sports camp nonprofit, we did a backend integration with Google's OR Tool library, to solve their scheduling problem with a single click:

https://webwidgets.io/blog/sportscamp.html

I would love to do a call to discuss your needs. If WWIO seems like a good match, I'd be happy to build an MVP at no charge and create a strategy to move forward with minimal risk. If not, I'd be happy to share my thoughts as a seasoned engineer. Contact info in profile.

The three big logistic systems we looked at where Rex11, Manhattan, and Hopstack. Expensive, but less than the cost of a dev team.

We ended up staying with our ERP as we spend six figures a year on support for that already. We're about the same revenue as you (manufacturing with our own warehousing and trucking company)

Without having a ton to add, logistics might not be the sexiest industry but you can do a lot to make the role more sexy, especially to senior engineers. Making the role remote is worth $50k or more in and of itself, and vastly broadens your talent pool. Juniors are the ones more likely to be willing and able to relocate and commute.

Seems like a good fit for a development contractor/consultancy: get pros to try to gin up a v1 clone fast. If they show that it's not too bad, no gnarly gotchas, have them help you hire folks who can get to v2 and beyond. Starting a software dev practice is daunting without prior applied experience, use the cheat code.

It's complicated. Building software is very expensive and high risky. You can try with a small project in-house and get your learnings from.

Yes you can find people that want to work in a non-glamurous company easily. These places are excellent if you want to see your work doing direct impact in improving peoples lives.

"attract experienced developers to a non-glamorous industry like logistics" -- Pay them well and offer a remote work environment. If you're interested in chatting with a senior / lead developer who's owned a lot of projects from the ground up I would love to chat adam.bourg@gmail.com - 720 491 0562

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

I've been building advanced web apps for 14 years, and I'd happily spear-head something like this, especially for a field as "non-glamorous" as logistics. And I have a feeling there are many developers out there like me.

I read: "I'm an executive at a mid-sized logistics company (~200 employees, $200-300M annual revenue)"

I think about: https://www.bloomberg.com/graphics/2015-paul-ford-what-is-co...

You may want to hire someone to really dive into this question.

That allows you to set up a NDA that allows you to go into the nitty gritty details of your niche and why this product is out of headroom.

A fresh technical perspective may also provide insight into a path forward that doesnt include rip-and-replace.

My team worked remotely from the EU for a similarly sized ($100-$200M) US-based company in the print-on-demand space for over 8 years as an external provider, building much of the core infrastructure and services. We are looking for new projects; contact information is in my profile.

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

I would certainly love the opportunity to do a greenfield data integration / crud application project in logistics. This is definitely the right thing for a passionate senior developer

A bit of a naive question but can you acquire your provider's company, or poach their programmers ?

Regarding retention, since you already have revenue, binding the revenue/package delivery/cost saving with the talent’s contribution. Even for the contractor, might could try this way.

I don’t think bringing software in-house makes sense since that’s not your core competency.

First try getting into a real talk with your provider where you would get access to the codebase and be able to make changes yourself. Hire a few senior freelancers to assess the project and solve the most urgent things. Form there you'll be able to make informed decisions.

Great thread, similar to my "company" migrating from a platform to our own custom software solution using a team of contractors (through a freelancing website).

Then we built an ongoing relationship with them, going on to do multiple projects after just the first one.

Agree with many of the other commentors. I think you need someone to talk the details with. Someone experienced can tell you how big the scope will be. Lowest risk is to get some freelancers to create an MVP and go from there.

Happy to chat about this with you. Contact details in my profile.

Whatever you decide, don't assume that it would be hard to find devs.

There are a lot of us who prefer to work for real businesses offering real products/services, and avoid working in the startup world with all its concomitant pipe dreams, wishful thinking and scams.

I observe that the question is focused on “should”, not “how”. So my first question is less about the “how” and I am more curious about whether differentiated tech builds your competitive advantage?

Suspect you can further differentiate with a bespoke team, then defer to others on how to execute.

Having the assets made in house for IT is only going to grow the value of your company. The software ends up being worth more than the sales of the business. t. former logistics company partner, sold to vanguard for IPI shipment rating software alone.

What size is the software you are using? If it's niche, you might be able to straight up aquire them.

Or at least get a source code license so you can have an inhouse time improve it.

I would recommend against building something from scratch without having the necessary experience

If you decide to do it in house, make sure the team spends a lot of time understanding the existing app, inside and out, before they start coding the new one. You really don't want to be "agile" here as you are replicating an existing system.

I'd be happy to share my experience with you. We've solved problems like this for a lot of folks with small or non-existent internal tech teams. I agree with the small team of experts approach, but there are pitfalls there too.

Feel free to reach out pete AT lincolnloop.com

One thing that doesn't seem to have been mentioned, if you do go in-house, get a good designer as well. Ideally someone used to working solo, doing deep research, and who understands balancing great UX, technical considerations, and business needs.

My email is in my profile. Here's an offer.

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.

I would look at what you could buy off the shelf before building it yourself. I know some of the guys at Rygen.com and they're building some great logistics software. I don't work there or have any financial interest in it myself.

Could this be part of your competitive advantage in the future? or is the software a commodity and just kind of annoying at times?

Changing ERP systems takes a long time (months to years) and for the whole transition period you have TWO systems to maintain.

If you want to talk to someone who has been in the industry (both non-tech industry, to tech industry, to tech industry giants) for 20+, you can reach out to me. I'm happy to hop on a zoom/teams call. Contact info in bio.

Here's a thought: "just" buy the vendor.

We don't have any of the details, but have you considered that? They already have the code to do what you want and know the problem space very well. Then your problems with them becomes a problem with themselves.

Deciding between sticking with off-the-shelf software or building something custom in house is a significant decision. In my experience, the key advantage of bringing development in-house is the ability to create a solution aligned with your business needs. When your team understands your specific challenges, they can craft solutions that off-the-shelf solutions often can’t match. That said, this approach does come with the challenge of staffing a capable development team.

There are of course ways to mitigate this. You could build a local team or leverage outsourced options to access a broader talent pool. You could even start with a hybrid model that combines in-house leadership with external development support. Each path has its trade-offs, but if your long-term goals require flexibility and customization, investing in an in-house team is likely the way to go.

From the inside, I’d recommend that if you bring software dev in house, you bring it entirely in-house. There’s nothing worse (as an in-house developer) than having to work with contractors that have zero skin in the game beyond their paycheck.

Bringing development in house also means managing the operational aspects of it. And QA as well.

You mentioned low code tools. Can you push that tool more, and potentially add an integration platform for EDI?

I would try that first, before committing to a large in-house footprint.

What are your differentiators and what are commodities that can be better served by better SaaS alternatives? Whatever you do invest in the differentiators and manage risk (secure and compliant solutions).

As a freelancer myself, I am delighted by the amount of freelancers in the comments. We're very often heavily underrepresented in the wider software world. Guess it has to be that we are still the minority, lol

It’s actually great to read your story (apologies!)

The answer is YES and we have built Openkoda* as an open-source alternative to Salesforce Platform and other closed low code vendors specifically for these reason.

Happy to connect and share our story.

* openkoda.com

I've done that kind of movement at least once as a CTO of similar-sized companies. There are risks involved. Over engineering this system would be my biggest concern.

Hit me up if you want to talk. Contact info in my profile.

Also consider you're asking this question to a forum of mostly developers.

And developers love to build things.

So be aware, you might be getting biased responses by people who don't have anything to lose if they are wrong.

I'm a CTO and scaled multiple companies from zero to multiples of TBs of data (also to millions in revenue). I also worked on companies such as yourself that have an existing solution and want to revamp their entire technology base.

The short answer is yes, you should hire an in-house team so you can execute faster and also reduce the red tape of the provider not being more proactive.

How to do this is more nuanced:

1. I would start by documenting and/or asking for documentation on how the whole system works. This is key. I would start with a high level diagram. Even if you're not technical, this would allow you to evaluate the existing stack and see what could be worked on in parallel to the existing tech if any. I feel like you are technical enough to understand this since you understand CRUD and other terminologies. You can even set a time for the provider to explain the services to you if needed. I say parallel because I'm assuming you can't just quit using the system entirely, it will need to function until you do the switchover.

2. Once you have a good understanding of the system, this will allow you to be more specific on your needs. I almost never recommend a re-write but based on the statement that you are using a third-party product, this might be the case here. If it is indeed a re-write, I would approach it so that it's 1-1 parity with the existing system first, and if not, maybe with some ample planning and product grooming make the features even better. Furthermore, this will allow you to make a basic PRD for the requirements of what you are building. Doesn't have to be really specific but it will make it clear to yourself and others on what the task would be.

3. Hiring. At this point, I would start hiring a CTO/VP/senior engineer. Describe the problem from 2., maybe deep dive even if needed and start to get technical leadership going. I'm assuming cash is not a problem so if you start at $175k/year salary (maybe some stock/benefits) you can find many technical leaders that would go for this. Once you make that first hire, if they have a good network and or social clout it should be easy for them to hire people and/or consultants to do the job.

4. Iterate. Once you have that amazing team and if they have a good process in place they should keep iterating on the product and continue doing this on a steady pace.

5. Once the product is ready or any point that is it deployable make the switchover. At this point, you should have full in-house control of the product and have competent tech team in hand to do whatever is needed.

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.

Incidentally, "Domain Driven Design" was written around a theoretical logistics/shipping platform. That book didn't make it seem "non-glamorous." Everything is exciting to someone.

Depends on your complexity, if the business is standard logistic process. Then there are plenty of ERP products to choose. Let the ERP company do the work, it won't be cost more than have your own team.

You can first write software to work around shortcomings of the existing solution, and then gradually start replacing more and more of their functionality with stuff you've written in house.

Regardless of whether you hire in-house developers or hire a software studio that does contract work - I believe the key to success is giving the developer unfettered access to an experienced subject-matter expert who really understands what is needed.

No offense meant - but by my personal experience, executives like yourself are a bad choice for this - some experienced longtime employee that's deeply involved in day-to-day operations in the trenches, would be preferable, I think. Ideally somebody who went through process changes before - like was already working there before your current software had been introduced.

Don't get a developer who wants to start programming right away - you want somebody who asks for time to first really learn and understand the processes the software needs to cover - and who actually questions all the underlying approaches your current software takes - but does not just rule those out out of hand.

Then get that senior employee to mentor them and teach them the job - not the existing software. I would even advise have the developer DO the work for a while - under the supervision of that senior employee.

This thread is downing in replies but I just want to add one major thing: Focus on the data. Where it is, where it's going, who needs it, when they need it. Build up from there.

It sounds like you're running with your breaks on, because of the software issue. So, finding someone who can make the software work right can at least remove that obstacle from your business.

For this, I would hire an experienced developer who can look at the current solutions you are using, the third-party product + your low-code solutions. If you find a good developer, they can at least design a product that integrates the functionalities from your 2 existing solutions. Even better if they understand User Experience.

Another good sign is if they want to build it in a "boring" technology. Java would be a good choice, because it's robust and also because it's easy to hire for it in Europe.

Frankly, for starters, you need Design + Frontend + Backend + Infra. You either get one person for each, or a person that does the first two and another for the last two.

Also, I recommend doing a fixed-rate project with milestones. You can use a generous budget (50k - 100k), depending on the complexity of the software. This way it's in the best interest of the people you hire to deliver on time. You release payments when features are delivered and meet standards.

If you want to talk more, my contact is in my profile.

One more thing, which I think is very important. If you build the software right, it can become a force multiplier and enable your company.

I think asking here is a good idea but you should also try this question on the LLMs like perplexity, chatGPT , etc. This question might be too high level and not contain enough context, but you can ask the model how to focus your question to specific aspects of your business. The models can outline the tradeoffs you can expect once you pick a tech stack and a team. The models can also suggest how things might go wrong and what you should watch out for. Try and get the LLMs to design your test suite.

Remember: There's no one-size-fits-all answer. The best approach depends on your specific circumstances, goals, and resources.

Have you thought about investing in the third party provider? Getting a share might give you a say on where development should go and what support requests get resolved first.

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!

  Obstacles & Patterns To Maximize Flow in IT Operations • Ben Rockwood • GOTO 2013

  https://www.youtube.com/watch?v=O2IfgkL5_po

Shoot me a message, I am VP of Engineering at large European software logistics company, where I had exactly the same challenge (outsource vs insource). Email is in my profile.

It's not as difficult as you might think, because copying the functionality of an existing system is way more easy than building a system from scratch.

What industry, what software, and what is your budget? If it is profitable to build and more than one customer, I am sure numerous people here would jump on the idea.

Find one or a few freelancers. Start first with small must-have features and expand afterwards. Pick technologies and frameworks that are widely used.

I you still need some help after reading all the comments, feel free to reach out, i will consult you for free to get you started (or maybe even after).

Possibly dumb question:

How large is the company supplying the existing software? Can you just buy them, or even just that one team supporting the product line you need?

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

Yeah, if you're willing to pay slightly above market rates.

An acquaintance and former colleague of mine is in a very similar situation to you, working in logistics using a platform that's just terrible and causes the company a lot of stress and headaches. I offered to come on board, I have a proven track record of success in this space and could have fixed all their issues in probably six months.

But the company wasn't willing to pay the salary I was asking for, so I moved to a company who would. Apparently, they are not in this situation where they are getting bids of like $5MM and two years to complete a handful of data integrations and some dashboards.

I feel like leadership in "non-glamorous industries" do not like the idea of technical ICs commanding higher salaries than they do.

Hi, I have a lot of experience in this space - software for logistics, supply chain, shipping.

I have helped companies procure off-the-shelf software, helped them build in-house technology, and have a lot of connections with companies like yours in both sides of the table (from largely in-house all the way to the other side to largely subscriptions), so I’ve seen broad examples of what works and what doesn’t, and how businesses can leverage technology to get a competitive edge.

If you want to chat and learn more, I’m happy to make some time - email address is in my profile.

My team has been building custom software for a large german multinational shipping and freight forwarding company for 18 years now. Happy to chat, my email is in my username @ gmail.

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.

I run a one-man dev agency that staffs up a team to help non-technical execs build their v1. Here are some learnings:

1. There are three common dev team models: in-house, individual freelancers who eat what they kill, or agency (where you're sold by a principle and then juniors do the work). I recommend to all my prospects that if they can find a trusted lead dev, they should go that route - it's more economical for them and when I roll off a gig I set my clients up with the senior dev that built their app. Next best is eat what they kill freelancers - more expensive, but faster and incentives are pretty aligned. I would recommend NOT working with a fully staffed agency - they make money by having juniors do the work and incentives are often not aligned - they have staff on the bench they need to feed work to, so their incentive is to keep running the project until the client is out of money.

2. I just wrapped an MVP build in logistics for a European client. There are lots of devs who want to work on interesting technical problems, and for whom the industry doesn't matter. I hired two devs to build the MVP and both were keen on the gig. That said, it's hard to attract and evaluate good talent without at least one of those folks in house, which is what I do when I staff up a dev team to build my client's MVP.

3. Transitioning from third party to in-house - I'd pick the key pieces that are isolated from a business process perspective from the rest of your existing tool, spec them out with wireframes (https://www.reemer.com/consulting/roadmap), and build those. One of the biggest failure modes with building software in general is not enough definition of what "done" looks like when it's cheap to iterate and change (i.e. before code has been written). It's painful to write a long spec and wireframes (I've been doing it for 20 years) but once you've fleshed our your v1 and agreed on ~95% of what the final product looks like, it's generally pretty straight line to writing the code and shipping the product.

4. Re: quagmires - you need someone wearing the product management and engineering manager hats. Product will ensure the app's functional and technical requirements are clear, and an engineering manager will ensure your dev team doesn't get stuck spinning its wheels. In early-stage projects one person often wears multiple hats. Later on you can scale it up to an individual PM and Eng Manager in addition to your devs, if necessary.

Happy to chat more if you like - no sales pitch... just drop me a line a k@reemer.com.

As a Principal Engineer in FAANG, I’d caution against bringing software development in-house without someone who deeply understands how software is built at the leadership level within your company.

Software can be intangible, making it difficult to manage budgets and timelines. You might find yourself asking, ‘We’re spending all this money, but what exactly are we getting for it?’ What’s the point of all this CapEx?

Moreover, it’s easy to place unrealistic demands on software development. If you, the business, change your mind every two weeks about what the software should be or do, the constant churn in feature requests can bog down the code and hinder development—through no fault of the developers.

While you don’t necessarily need a CTO, it’s crucial to have someone you trust, even when the answers you receive aren’t what you want to hear.

Is it possible to find a new outside vendor?

I'm a CIO/CTO in a similarly-sized (revenue, although we have roughly 900 employees) company in the distribution space. We do almost all development internally, but I have been developing for decades so I know what good looks like. I've had good luck attracting a jolly band of developers and devops.

I despise outsourcing development to third parties unless I absolutely have to. The quality of work is just better with the internal devs, and we retain the knowledge of our entire stack.

Our software is the life blood of our business, so that's a big win for us and it sets us apart from our competitors. I'm able to outpace them from an innovation perspective.

All that said, unless you're very technical or you have a strong IT executive on your team, this approach won't work.

I've been on both sides of this question so my views are both biased, and experience driven.

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 you're comfortable spending $2M+ and 2 years building, then maintaining and renewing that software continuously for the life of the business then go for it!

In reality all big business become software companies eventually, but the really big ones tend to lean towards customizing a vendor product (e.g. SAP) to replace their collection of built-from-scratch tools. I'm not in the logistics business but if that's not SAP then I'm not sure what is.

I always recommend having in house IT and software development. If you don’t, then you are captive to your vendor.

Do you really employ 200 people, all of whom don't know how to code? What kind of sweatshop are you running?

Get 1 cracked dev and pay him a lot of money. Problem solved in a month.

The hard part is finding that "cracked" dev.

A 200 people logistics company with no software expertise building it's own softare in-house. Just madness.

Yes. Don’t just bring it in-house, bring it “in-brain,” learn to code yourself and lead by example! Make sure you can write tests (gherkins at a minimum and ideally E2E tests with some browser automation or whatever you need to simulate a user) for your team’s code to know it does exactly what you want and make sure you can run the tests on the dev branch yourself. Then you can trust AND verify!

If you’re happy working remotely then you potentially have a much larger pool of talent to choose from.

Why not go to tender? For a solution, either SaaS and custom modules or pure bespoke.

Also WisetechGlobal might be a choice.

Get some experienced freelancers ( small team ) give them a proof of concept application to build. Review.

Is acquiring the third party software provider an option? And then staff them with a few more ppl maybe.

Whatever you do, try to do it incrementally in phases. That way, you'll learn iteratively :)

I joined a logistics company with a history of two unsuccessful outsourced software development projects. Their third attempt was also failing due to the developer prioritizing their own startup over delivering the contracted software. This resulted in unaddressed bugs, lack of client on-boarding support, and lack of the developer delivering functionality they were contracted to deliver.

I was brought on board to salvage the third system, but this proved unfeasible. As an interim solution, I built a system to enhance data from the third system, enabling the operations team to utilize it for planning and execution.

Collaborating with the CEO, we analyzed strategy, risk mitigation, and evaluated alternative vendors. Unfortunately, proof-of-concept trials were unsuccessful due to vendors not meeting our requirements.

To gain deeper insights, I initiated direct meetings with stakeholders at our client companies to understand their specific needs and business rules, recognizing the importance of minimizing localized exceptions while providing a solution that would work for all clients.

I then conducted meetings with the CEO and a key client to observe their utilization of the third system and pinpoint areas of success and failure from their perspective. Understanding client reporting and data needs is crucial, especially for those submitting reports to their local boards and international logistics teams.

I advocated for developing an MVP to automate manual tasks performed by control room staff, ensuring timely operations. The MVP was successfully launched first with a different customer and then rolled out to the original client. The original clients second site also adopted the system, and we transitioned from the legacy system during a holiday break. Benefits included reduced scheduling time due to zoning and suburb storage, resulting in significant time savings for planners.

Key takeaways include developing a comprehensive needs analysis document outlining your company's requirements, documenting business rules, noting pain points, and evaluating if the current system adequately supports business needs and figuring out what your wish list for a system is. You can then write a requirements document referencing back to the needs analysis document before starting to develop the software.

Software development projects fail when execs / management do not understand their requirements. Something they think is shiny today may not be tomorrow and their focus shifts.

I'm in the process of similar transition in global manufacturing company, where my role is to build internal engineering team to essentially increase ownership and remove reliance on external vendors. So far I would say it worked, but with a few caveats. One key thing to note is that usually you don't have to build e2e team to replace your current vendor, as replacing key roles might be good enough to drive visible positive change.

What I would suggest is to divide the work scope into smaller chunks, eg. isolate applications / systems. This will allow you to distribute the work to other vendors or your own in house IT team. The change usually requires a lot of work in different areas, such as clearly defining people functions, R&Rs or work organization. Then you insource key roles, and see if the effects are what you're expecting. Having some local CTO type of person to drive the change would definitively help.

Overall I would expect the process to take several quarters, highly depending on your system complexity and vendor lock-in (they will not be happy about the change!).

I've seen in the other comments reco to find freelancers instead of FTE, and it could work depending on local market specifics. In some countries you have to watch out for employment laws and potential issues. I'm based in Poland so can provide more info if you want to chat (myr11242@gmail.com). Good luck regardless :)

Just pick a popular ERP solution and work with an official partner company to that ERP.

I've done this at the CTO level in a non glamorous industry (construction). We spent about 3 months understanding the business top to bottom before building the software. We then took the best of the SaaS software that wasn't flexible enough and layered on what was needed with an eye towards massive growth. There's no way it would have ever got done correctly and be as stable/maintainable as it is now without that time up front. As others have said, you need someone who is vested in the business. Otherwise the dev team frankly won't care. You can't just throw some random devs at a problem like this one.

Do you have technical people local to manage your near/off shore resources?

I've scrolled past the top 30 comments and somehow the absolute most basic question is only asked in a roundabout way in 1.

What are the financial rewards if you do? You say speed of execution & lacking crucial insight.

The crucial insight is most likely wishful thinking. I've seen too many useless BI dashboards to take your word for it. If this were true, you'd hire a contractor to make that very specific tool to give you that very specific insight that is going to pay for itself within a year tops.

The speed of execution might be important. But do an honest accounting on how much money you're expecting this to make. If its about missing customers, call the one you missed and ask them if a faster execution was the dealbreaker.

The relevant third aspect is supply risk. Are you renting some hosted service from a failing company that might drag your current business down tomorrow? Hopefully not. Most - decent - software can keep working fine for years if the updates stop coming.

Now plot the extremes.

1) Build in-house and it turns into chaos and wasted money (do not underestimate the potential for chaos)

2) Don't acquire the skills in-house, miss out on the speed/insight ROI, and the supplier fails

Decide which plans laid out in the other comments are the best for the situation.

Drop me an email at coffeemug@gmail.com. Lots of ideas I can't share here.

So a little backstory, I have worked in Logistics and warehousing, albeit as a senior dev on robotics solutions and its needed implementations.

What you don't want to do is hire a team inhouse if your pain timeline needs fixing in < 1 Financial Year.

As someone mentioned. Senior freelancers preferably with some domain exposure.

Don't think of this as a software problem, but a house rennovation project!

Here is the playbook we have recommended and executed for many clients,

- Hire a documentation guy. Start writing/drawing out all business processes your current third party system serves. Use BPMN if possible.

- Sit down with a senior dev to draw a High Level Design of this system. And find subsystems or funcitons which you can live with, vs things which absolutely need retrofit/rewrite.

- See how you can define a scope of work where what's good keeps running, and a new smaller better subsystem starts taking over functions you need replacement.

- rinse repeat.

--- Strategically speaking, Hiring is a bit painful. Depends on geography. Retaining someone beyond 3-5 years is difficult. People churn out of boredom as the work gets repetitive and they don't get to flex their tech stack itch.

Money wise, is the third-party company a potential acquihire target? If its small, why not take it over and inhouse the team. You would get the "catered to us" part sorted and you can still sell to other customers if you so desire. This has its own risk-reward. But I will let you be the judge of it.

And in anycase, get an independent technical consultant to cover your blind side.

Don’t see contact info in your profile. Feel free to email me at gmail - lots of experience leading tech teams, but none in the logistics space. Currently mid transition and exploring opportunities. Might be interested depending on opportunity and details.

If you should decide to go inhouse, I can warmly recommend checking the *frappe framework*, with which the open-source ERPNext was built. Compared to other such things this is truly open source (not like odoo and others, which really try to catch you in with being "open-source" and then let you pay up for the features you really need).

It is very powerful and comes with so many batteries included and is actually quite fun to develop with.

https://frappeframework.com/

Here is a story of a big financial institution betting on inhouse dev using frappe. (There is a TLDR on the bottom of that page ;) )

https://zerodha.tech/blog/being-future-ready-with-common-sen...

All the best <3

This is something you want to have an ongoing conversation about. With someone competent and experienced enough to ask the right questions. I can help you with that. Look me up and reach out if interested.

Randy Syring, Chief Executive Developer, Level 12

I'd take a middle approach.

Is their an open source solution to your needs? Do you really just need 3 or 4 people ( pay them top of the market, find senior level folks) to slightly tweak it ?

Otherwise you might be looking at a very complicated and expensive development process just to get to V1. Software development for any thing complex takes a lot of time.

>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.

Do you NEED an app. A simple internal website will be infinitely easier to build and maintain.

This is worth hiring a consultant to just talk about what options are available. Preferably someone you know personally, a lot of contractors will try to take you for a ride.

Do you have any programmers on staff right now ? You need someone on your side with a technical background.

Do you understand taking this in house will probably cost and take more time than you expect ?

If you have over $200M annual revenue, I can't see how you couldn't afford to build this thing in-house, but then I don't really know what kind of product we're talking about since it's so stealthy.

When it comes to actual suggestions, from a developer's point of view I'd say the following:

1. Migrate slowly. Don't try to build an entire replacement for what you already have at one go. Tackle the low hanging fruits first. Plan the big replacement after the small replacements are already up and running.

2. You'll need at least one person to be the glue between business and tech, and that person must be developer-first, not business-first.

3. Don't overhire. You probably don't need a big team. I'm sure you'd be able to begin with no more than two or three developers.

4. Attracting talent should be easy since the job market has been terrible for developers. You can see job postings with thousands of applications.

5. Hire remote whenever possible. This will increase the talent pool enormously.

6. Always consider the possibility of SAASing whatever you'll build.

Good luck.

id 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)

One thing to consider with in-house dev is there's no one to yell at except the man in the mirror. Think about this, you need an application as part of your workflow, you're not in the business of selling the software development. What you risk happening is employing a dev team who's job becomes writing code 9-5. Your developers don't have much of an incentive to deliver a v1, they get paid no matter what.

A small, experienced, eat-what-they-kill consultancy may be better. If they don't deliver they don't eat. A firm like that is motivated to get things done on budget and on time. You'll get the application you need to move on with your business rather than having an internal software development firm 100% funded in perpetuity by your real business.

>On the other hand, while our current solution seems like a straightforward CRUD app

So I have been on both sides of this. Not as a dev but in IT.

1 - As IT support for customers of a CRUD software.

The truth was, the company did not know their own software.

Coded in the 90s, touched up in the late 00s.

Original devs long gone, all quit en-masse.

Current dev team forced to bolt on new features.

Rework of the entire app needed (on-prem IIS and MSSQL dependant).

Sales & Management (they were the same people) selling features to customers that did not exist or were not on roadmap (straight up lying to customers)

"Project management" consisted of them calling devs/support cellphones wanting $New_Feature coded they just showed a mock-up of to a customer.

2 - As an MSP IT technician. Customers have no idea what we do or what they buy.

"Why are you so expensive/Why is this not just included when ur so expensive!!!"

- vmware servers in secure DC, management of windows server and linux (updates & backup, installation of software etc, monitoring for cpu, ram, disk, network)

- management of on-prem AD and Office 365 Entra users and groups

- Exchange and Office 365 management for email

- Endpoint management (Hardware, GPO settings, Entra policy, windows updates, software inventory and install & updates, remote support for users over RMM)

- Antivirus management (SOC not included)

- DNS filter

- Office 365 Backup (This is needed, MS has no care for your data on Sharepoint)

- Network (WAN, Firewall, L2 Switch, WiFi & management/troubleshoot and updates for all of it)

Then we get a "deer in headlights" look and "but you are just IT"

Just my 2c. I have no idea what to do in your situation. Maybe you are getting ripped off, but it will also not be easy.

I’ve built custom logistics, warehouse picking, and inventory software before, interacting with Amazon, EBay, and others before. Send me an email: rob@bottled.codes

I'm gonna go out on a limb here without knowing much about your situation and say that you're intuition about "...our current solution seems like a straightforward CRUD app, I fear the devil is in the details" is spot on. CRUD is inflexible when modeling processes. It doesn't have time as a core part of its design.

But the problem isn't about the details, it's that most developers don't want to actually do the job that they're trying to automate with software. They won't shadow the warehouse workers, they won't pick product, they won't work with the tools to do the job. Thus, they won't understand how to write software that models your businesses processes because they won't venture to experience the pain and gain the knowledge. They'll just end up building a CRUD app that uses the latest frameworks and "Best Practices", which, unfortunately, have nothing to do with making your business adaptable.

Sure, there's exceptions, but they're hard to find and demand a high pay because of the daily value they create. Hi ;)

You can attract experienced developers to a non-glamorous industry like logistics (I would LOVE THIS JOB). They don't even need to be experienced developers, they need to be willing to gain empathy by "going and seeing" the work to model it correctly.

Look for people who want to create value, who want to "go and see" for themselves before writing any software. The curious shall inherit the earth.

You don't need to hire a bunch of people, so pay well.

I hate saying this, but marketing is everything. Start posting on LinkedIn. I know. Everyone hates it. But software developers are on it. And so are tons of people looking for jobs.

When you do finally hire someone to do the work, go live every day. And the only way to do that is to identify small wins in the processes. Start chipping away at the bottlenecks. This is the way.

Good luck. You're not alone. So many people have the problems you're experiencing.

The question that you need to answer is do you want to be a technology company, or a platform company.

If you want to be a technology company and own your stack you need to ask yourself questions such as:

- Can we attract and _retain_ the necessary talent with the resources we have in order to build software? It's no use if you can't attract quality talent, or keep them. - Do we have the resources to maintain this software for however long is required by the business? - How much resources are required to match feature-parity with the existing solution, and can you meet the requirements of all existing stakeholders based on the assumptions you have today?

... and a gazillion other questions. But it all boils down to the fundamental first question.

If you move it in-house, I would recommend changing your application process to include a video portion. Unless they can point to a long track record of open source.

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.

Many of us, myself included, will be predisposed to controlling our own SDLC, largely because of bad experiences with vendors. Personally I've had vendors shutting down a product that was core to our offering with basically no notice, performing poorly but not accepting responsbility, just milking T&M, and just straight up lying.

The problem is, all those outcomes exist with hiring your own developers, and it's really difficult to mitigate unless you yourself are a strong developer who can run projects and teams and look beyond what people are telling you.

Reality is, it's impossible to answer the question without really getting more information. Specifically around what you spend on outsourcing / licensing, what the feature set you're going, what the budget for the new team would be, and what the expected outcomes and timelines are.

Without the context though, some quick fire opinions.

- You probably at least want the dry powder. i.e. the person making the outsourcing decisions should at least have the technical accume to bring it in-house if required. If they're not a person that could, then outsource is the only decision they can realstically make, then they'll tell you it's the right decision even when it isn't.

- You need someone mature. If they just want to build everything from scratch always because of some personal bias, you'll end up amassing tech debt in areas where there were limited risk / benefit. Developers will 100% tell you you need to building things because it's interesting to them, even when you don't really need it.

- If you're going to do this with any near-term success your first hires are really key, and they likely won't be cheap. I see people debating brining in a team vs a CTO, but both strategies fail if the quality isn't there. Figure out how to validate quality.

I was CTO of from ~25m to ~£75m ARR UK Point-of-Sale org with ~100 tech employees. Those roles are hard to find. This sounds like a great opportunity. Lots of folks will likely do the hard sell. Good luck.

How much does the third-party software cost?

Do you have an email address? Shameless plug but this type of project is exactly what my small agency does, have done for several companies similar to yours.

I'm an NA-based freelancer actually looking for work. I've got team-lead experience to take this in-house; Got contact info listed somewhere?

> Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

I'd love to be the provider on this.

Whatever you do, don't hire some tech bro who tells you that you should build this in Ruby On Rails or Elixir or Elm or Rust or something on the cutting edge in any way.

This is standard corporate technology and needs standard ordinary technology. There is zero requirement for this sort of application to use anything fancy. Indeed if you use fancy technology that scratches the itch of a tech bro then you are buying yourself problems hiring and recruiting developers - this is one of the worst problems you can have. Not such an issue right now while the employment market is down, but a massive issue when it is not.

Use ordinary technologies, any of these things are fine:

Java

C# .NET

Python

TypeScript

Postgres

Also, don't use cloud specific technologies such as serverless. Just write software that can run on an ordinary Linux server. Once you start using serverless you are bound to that code and that cloud forever. Also, and other may argue against this, but my experience of building application using cloud technologies is that way too much developer time and effort goes into making the cloud work and not enough into writing application code. Have a general directive in place to use the cloud for running compute instances and avoid using cloud application services unless really necessary and have a process where doing so requires signoff from the top. Nothing wrong with cloud virtual machines and email sending but just run most other things on Linux - own your own computing infrastructure and be in a position to pick it up and move it elsewhere or even on premises if you choose.

In summary, beware tech bros advocating anything except Java/C#/Python/TypeScript/nodejs/Postgres, don't use serverless and use cloud computing for virtual machines, email and DNS and not much else.

Hire a development manager with experience building corporate applications and let them hire three developers, a tester and a business requirements analyst and that's phase one of your "bring it in house project". Build a series of small chunks of functionality, don't bite of more than you can chew.

So, base your decision only two factors:

1. Budget (perform a thorough cost estimate before making any changes)

2. Quality of service expectations

The risk part of this is that your company has never had a software team before. This means you have nothing to build upon. The level of risk here is tempered by the flexibility within your available budget, which means how much cost are you willing to absorb outside of plan if this goes to shit.

Now, set your expectations right. Software teams never ever make money. They only cost money. Will moving dev in house cost less money than the current solution? No, at least not at first, but you have to build from nothing. Moving dev in house will allow future scale the outside party does not provide.

Secondly, absolutely forget technology. Don't fucking go there and if you do you have already failed. Think only in terms of leadership. What that means for this effort:

1. Hire a leader who can perform risk analysis, measure things, work within a budget, is super assertive, and communicates brilliantly both in person and in writing. The assertive part is important because opinionated technicians/developers will attempt to drive the plan. Don't ever let that happen. A real leader will own this in both failure and reward.

2. Set realistic goals and accomplish those goals. Don't do anything else. Once the first goals are achieved you will have the foundation to do other things. Every distraction wastes more of your budget.

3. Form, in writing, policies that you are willing to fire people for violating. These should enshrine conduct, ethics, and appropriate standards for quality of service.

4. Do not (ABSOLUTELY NOT) think about this in terms of a startup. You are an established company already generating revenue/profit with margins. Proceed with a well planned vision always accounting for risks and make adjustments to the plan very carefully. Distractions and deviations will cost more money.

5. Finally, transition from the current solution to the in house software team carefully and progressively. This will cost more upfront, but dramatically less in the near term due to lower risk.

Good luck.

Do you have contact information?

I work at an in-house software development team, although it's a very small one at a non-profit, so not directly comparable.

But I would say you should know you are not going to save money by going in-house. The success criteria should be getting a better product that supports your business, not saving money. It will cost more than your current software costs.

i don't know what size team you are considering, but you certainly can't do this with less than 3 people, and that's probably too small. (not all of them are necessarily 100% "programmers", there are management and other tasks, more below)

I don't actually think logistics is particularly unglamorous, I think it's as interesting as most and more interesting than lots -- but it may not be interesting enough to attract talent at significantly less than they can make elsewhere. So you're going to have to be paying at least somewhat competitive salaries -- good news for you of course is that the job market isn't great now. But still.

So think about how much it will cost to have 3-5 (possibly more) staff at competitive for tech jobs salaries... is it still potentially worth it to your business?

If it is, then great. You've got to hire good talent, including especially someone skilled at figuring out what the software should do. Product management/product ownership with a dose of user research thrown in. This may or may not be a developer (probably not, but maybe), it may or may not be a manager of developers (maybe). This will be the hardest part of execution. Just doing everything you think you as the boss need, counter-intuitively, won't actually lead to a successful product at an affordable price -- you are wrong thinking you know what you need. (Yes, I can say this with confidence not even knowing you, it's always true).

Trying to copy everything your existing software does but then adding more -- or trying to keep all the workflow exactly the same while switching software -- won't lead to a successful product at an affordable price. Part of the product design isn't really product design at all, but business/workflow design.

You could considering hiring a consulting firm to write and then maintain this software as well. That will probably not be cheaper than doing it in-house -- (although it could be if your in-house plan goes seriously awry!) -- but may have a higher chance of success than building an in-house team (and getting the right team!) if you pick the right consultant. It also of course gives you more flexibility to cancel or scale down the project at any time if it's not going well, vs the emotional and sometimes legal or financial pain of laying off employees.

Senior programmer here. Yeah. You’re in a spot where you need a senior programmer and a couple of juniors but can’t guarantee steady work for them long term.

Also, in house software needs to retain knowledge, otherwise the knowledge disappears when the senior resigns.

I’ve 20+ years experience with business like yours. Contact me.

https://x.com/eduardoarandah

My two cents:

You have a greenfield development project with a very well understood set of business needs and requirements, and you have the budget (I'm guessing) to run some small-scale experiments without the usual sort of time pressures; to a certain kind of developer (hi!) this is super attractive.

I would spend a few weeks getting to know big chunks of the core use cases, and then architect a system designed from the beginning to handle those needs, and the prototype a bunch of that system over a couple of months.

Although these time estimates are totally armchair bullshit, what I'd actually do is timebox both steps to something like "two weeks" and "two months" - that'll help mitigate scope creep that'll come from not having the usual sort of time pressure. It's not about getting it done, it's about finding out what it would take to get it done, and seeing how much can be accomplished in a set amount of time is a good way to do that.

The key bit in all cases is (1) hiring good people (2) getting out of their way except for (3) keeping them on track. (One trick for #3 is to have them propose plans, and then always ask "okay but is there a simpler way to do it?", 2-3 times, kinda like 5-why's).

For #1, I'd look at talks people give at conferences, and then either try to hire those people, or ask those people for referrals.

For #2, that's your executive-level corporate culture. Unfortunately, from what I've seen, you either already have it or you don't, and that's probably not something you can change because if you don't have it, you also don't have the psychological safety necessary to find out that you don't have it - although, you can look for where you've got high employee churn, and that's where your problems are.

For #3, I'd use a combination of what I call the "wine trick" with "ELI5". The "wine trick" is that you don't actually need to know anything about wine to find out if someone else does: just get them talking about the details of their special interest, and if they can, they know a lot about their subject. Combine that with "Explain It Like I'm Five" to find out if they're actually just bullshitting, and because the other way to find out if someone knows a lot about something is if they can teach it. (Plus, they'd need those communication skills during the rest of this process anyway).

One thing to be aware of is your existing supplier might play hardball with your data.

I’ve known companies in this situation try everything from price gouging (“it’ll cost you $10 a record to export your 2 million records”), to just flat out refusing to pick up the phone, answer emails, or reply to legal threats: in principle a court can tell them they need to hand data over, in practice they can drag their feet.

As a former CTO I think you might need help to help you figure out your strategy in more detail and then get it delivered. Plenty of non-tech businesses have dev teams, and it’s becoming more and more frequent in my experience. You can attract a team with flexibility, autonomy, a promise they can learn new things and a great mission. A good CTO with experience in startups can probably help you get that lined up right.

I'm late to the game, so my post will be buried. But I'll toss in my 2 cents.

I think, for a company of appropriate size (and I think yours is at least that), that you should have internal development.

The IT department is a service organization within the company, and the dynamics of business never seem to stay static. They're always changing, always in flux. Either internally, through external competitive pressures, or external regulatory and other policy pressures.

Nobody knows your business better than you do.

I've worked on the small dev teams of several companies and organizations like yours, and we were never without work to do. Also, having in house dev simply makes that resource available to your company. It's a sunk cost, they may as well use it for their new programs for marketing, for analysis, etc.

And if something comes up, a problem in the system, an external event, you have staff who's priorities you directly control that you're able to focus on such an event.

A simple example of that was when I was working for a magazine publisher, and they canceled one of their new magazines. So, suddenly, we have this need to print 5000 checks. You may have never printed a check, I can assure you there's all sorts of controls and gates in the system around printing checks, and when your normal routine is to print "dozens" of checks per week, 5000 is "a lot".

We basically had to go in through the "backdoor" of the accounting system to convince it that it had properly printed the 5000 checks. I can say it was with trepidation when I threaded the boxes of checks into our large printer, as this was the moment when all sorts of things can go wrong. Normally, there were done on a smaller printer in Accounting. Maria printed the checks. Always be on Marias good side. She was a very nice lady.

The point being that your contracted help may not have the bandwidth to adapt to your internal emergencies when they happen.

One thing I learned installing accounting systems is that as generic as accounting is, everybody does it, at the same time, everybody does it differently. Off the shelf systems almost always hit that 80-90% of "what we need". It's that remainder that's always the challenge. That part of how you do business vs how the accounting software does business.

And being on the busy end of the outsourced consulting contractor, I know how painful it can be when we're busy, and a customer has an urgent need.

As a developer, I enjoyed working for mid size companies. There's tangible value handing over a new report or point out a new field, or piece of functionality that's there specifically to make Suzy in Shippings job easier.

I watched a lady running the Trial Balance at the end of each day. TB are busy and slow reports (particularly back in the day of slow machines). She'd run the report, print out the 3/4" plus of paper that comes flowing off the printer, grab the last page, tear it off, and dump the rest into the recycle bin. She was after a single number off of the summary page (open balances I think). This process took over a 1/2 hour. You can imagine the delight when I saw her doing this, asked what she was doing, acknowledged that it was a slow process at the end of the day, and came back the next day with a single page report that ran in 10 seconds to do that same thing.

All that said, maintaining institutional knowledge coded into software is REALLY hard. It really hard to not have That Guy that Knows Everything. Not just what's where, not just how things work, but also how things don't work. Why certain fences are put in place that may not be intuitive to someone not well versed in the business. As my friend says, it's always important to understand why a fence was put up, why a process does some "silly" thing, before you go tearing the fences down. And it's really hard to communicate that kind of thing.

But this is a problem intrinsic to computer software and organizations. Whether the folks are in house, or not. Even if folks write up the best documentation in the world, it doesn't mean it gets read, or even found by the person who simply doesn't know what they're looking for.

One place I coded up new pricing incentive plans that were different every year. All sorts of deals, volume discounts, combo offers, and what not (I won't even get into the royalty agreements, oh man). Even by the third time there wasn't really enough commonality to make me go "lets write a generic pricing system that they could configure". But the key thing, is that the orders had to be calculated with regards to the pricing system that was in effect at the time of the order. It's not as if you could toss out the old code each year, oh no. Several years later, the people that even conceived of the pricing model in marketing, may well not even be with the company any longer. But, institutionally, you had to retain that knowledge, particularly in case of challenges or credits to old invoices, or lawsuits, or all sorts of things.

That stuff is just plain hard to deal with. But it's simply the truth of it. And it's hard to get management to pay for it. It's just a friction in the system. But it's also another reason to perhaps keep it closer and within the company.

I've helped "bring software dev in-house" a few times in my career. Never in the domain of logistics. My (biased) perspective.

If you don't already have an existing (and talented) development team, it's still possible to kickstart things, but be careful how you go about it. Imo, the ideal early team in this context is small and multi-faceted. I'd look for good pragmatic coders with an entrepreneurial streak (e.g. experience having worked as part of an early stage startup, or having started one, even as a solopreneur). Why? Because although this type understands tech, they also have genuine concerns for business goals, not just with playing with cool toys. There's a lower risk of painting your company into a corner and racking up technical debt, because of unnecessary complexity and a propensity for shiny stuff. You want people that can look at your org, its goals, and make good technical trade-offs for the next year, the 5 after that, and beyond. The result will probably be a simpler and unsexy tech stack, that still works great. You want good coders that can make stuff, but can also recommend that you use an Excel spreadsheet, or subscribe to an API, where it strategically makes sense.

That's the kind of profiles I'd look for as my first hires. You can certainly reach a successful outcome with non-entrepreneurial coders too and I'll be the first to admit that my outlook is biased. But having been around this particular block a few times, it'd be difficult to change my mind that at least one adult must be present that understands both the tech and the business concerns.

Now here comes the caveat.

This type of profiles will likely not stay for the long haul... and frankly it's perfectly fine if they give you 6 months to a year. You just need to be up-front about it. Having devs who aren't looking to become dependencies in your org, if approached openly, also insures that there's a stronger focus on replaceability and long term maintainability as a core concern. You'll get people that are genuine in their interest to see you succeed, but maybe not looking to be passengers in your ship, or members of your tribe, or whatever. That's ok. They'll still give you their best to get you to your moat, even establishing the baseline and readying you for a smooth transition.

Just another perspective. Good luck.

I was part of a team for 12 years and watched it for longer, that helped a company on a journey exactly like this. I don't really want to get caught up in phone calls because I need to focus, but here's some of it.

Rough version:

- Outsourced to a company. Supposedly top people.

- My friend joined that company. He threw his heart into it. Eventually, he got the contract. He was the only person fully committed to the success, and the outsourced company was committed but not to the same extent. The key here is that he had extreme ownership over it and threw his being into making it work, and he was (became) very good with people - devs, execs etc., while helping to make enough of the right technical choices.

- He made a lot of money, because he was helping a significant business during a lot of churn as they grew. He helped them a lot, over 25+ years.

- At some point I joined them for far too long, but I learned a ton of what was good and bad about this.

- The company bought a few others as they grew, rolled this system out to those companies. It worked well for them.

- Even in this case, helping them be the biggest in their (local) industry, they eventually wanted to move to a big-boy system. The lines of custom code become paper cuts. Arguing over budget, infinite demands from across the company. Friend, as always, helped them in every way possible to get the right result.

- Friend helped them move from a custom system to an ERP + custom. That hasn't been plain sailing, it's extremely hard to move from a custom solution because it fits like a (sometimes hairy) glove. Over the long term, probably the right move. But you lose a lot of time in the switch, time that could be spent beating competitors.

He was fully dedicated to the customer success. He charged extremely well, it made him financially. He owned it. You absolutely need ownership, and you need a smart person owning it. He knew that his success lay in always putting them first. If you can hire that person, great, but in this case the money helped him be fully committed, for an extended period of time.

I later spent time at a startup bank, where we assembled an incredible system out of build + buy, with a SAP core. This will absolutely trigger the HN crowd but it was an excellent base. You do not want to be figuring out how you do rounding, or multi-currency, or storing user data. You do not want to be responsible for every line of code in your stack indefinitely. You want to know what is yours to own and build and will help you differentiate, and what is important to have but will just get you parity (e.g. accounting, invoicing, marketing, whatever). You don't want 100% custom code unless software is a big part of your business and it'll give you an edge over competitors, because it's both an asset and a liability. The thing to keep in mind here is TCO - Total Cost of Ownership. A good ERP will help you roll out business features really fast without having to reinvent the wheel. Don't modify too much of the ERP where it's not really important to do so, rather use as much standard tooling as possible, because you need to own all the changes. There are also absolutely risks here. SAP deployments can crush companies.

Skills. You want a setup that has easy access to skills, indefinitely. It's very hard to build something and know that it'll always be in fashion. React will one day go the way of COBOL. The team replaced the front-end a number of times and kept the core database. That stable core was the best thing they had, for a very long time.

Remain agile. If a component or team isn't working, switch. Don't marry every technology. In the bank, we switched very large pieces out and it was always the right choice. CRM, API Gateway, messaging technology, hosting technology for some parts of the stack.

Be careful what you depend on. Every part of the stack wants to make you dependent on them.

Try to avoid a big boolean switch when you turn off the whole system and move to the other one. If you can strangle the old system and chip off pieces as you learn, great. Sometimes it's not possible and you're in for a lot of weekends while you check the new one does everything the old one did, and doesn't fail in some weird way.

I am in a very similar situation, working for a mid-sized logistics (300 employees with small offices around the globe, 400-500M annual revenue), but with a completely different side, we do practically everything in-house with a very old software that does everything, (Multivalue D3).

My experience on your points:

>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.

We also use low-code applications like Talend and TIBCO, to fill some gaps, the older folks that don't want to deal with our ERP prefer using them this way for example.

Have you tried taking a look to https://www.flexport.com/ or https://www.shipbob.com/? Afaik, these are 2 of the most overrall used in the logistics industry.

We are very slowly migrating our system in different departments to more modern solutions, but always keep in mind that as soon as you start migrating, you will need to keep both systems up for a long period of time while this happens, and that means money and workers.

>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.

Europe is slowly moving outside of the EDIFACT standard fortunately and slowly implementing SOAP/XML based systems, you will have a problem here in an in-house solution because Europe systems are usually convoluted and hard to implement from different countries, from a business-side pov exclusively. ( I can tell you from first hand experience ), so indeed, a big problem will arise here. If you also do customs clearance, this will get even harder, as laws vary from place to place in small and big details.

>Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning...

Finding them is hard, but keeping them is harder, any other logistics company that sees a trained IT specialist with deep business knowledge will try to poach it with a higher wage inmediatly, I had tons of offers from close companies because of my customs knowledge. Pay them well and keep them happy. There is no strategy here, devs move for money like everywhere else, some end up in banks or insurance after some consultancy job with business experience and stick there, you will have to risk training them in house or poaching them from elsewhere.

For an industry as complex and in my opinion, enterprise customizable company, I highly recommend you to try an in-house solution, users sometimes don't need a lot to do their work and the most important thing in logistics is being able to do it quickly and efficiently.

What I can tell you absolutely that it doesn't work is trying to migrate from a big swoop, I saw companies close to us do it and it just didn't work out, their processes slowed down a lot and clients started fleeing to other forwarders because of the time they took to process any shipment. Move slowly in your smallest department ( reefer, customs, import or export, invocing, anything that in your company isn't as importante) and move efficiently, make their work as fast as possible, then grab that feedback and start moving other departments.

I wouldn’t necessarily focus on “retaining talent.” Instead, I’d build a system where losing talent won’t hurt you. (Although, you can usually avoid losing talent at inopportune times with some simple performance bonuses -- "Get me through to X point, and you get a bump.")

A project like this will require a variety of people. New builds, problematic builds, or maintenance projects all demand different skill sets -- and different personalities.

If you need someone to jump in and untangle a mess, the right person for the job will have a take-charge attitude. However, that same attitude might cause issues once the project is running smoothly.

If you want someone to get it done and build it right, that’s great. But that person might be bored to tears when you transition from an all-hands-on-deck build phase to a skeleton crew for maintenance.

If you need someone who can maintain the code, tirelessly clean it up, polish the rough edges, and fix bugs, chances are that person wouldn’t have been the right fit to kick off the project.

These are all oversimplifications, but you get the point.

So, build the system assuming you’re going to lose staff. Hire people who are productive and get things done. Ensure you have good documentation and a solid handover process in place. Make sure everyone on the team knows how to do builds and has a designated backup.

What I’ve seen work really well are small teams -- like an “agency within the company” model. I’ve done a lot of digital transformation projects over the years, mostly in eCommerce and mar-tech systems (all systems with many integration points).

The single biggest thing that dooms projects is bad requirements. For example, "Oh, I don’t know how XYZ system works, but I’ll be damned if I’m extending that old agency’s contract by another year, so we’re losing access to the data on Friday -- just do what you can!" (This actually happened on a past project, and we lost the entire Product Information Management (PIM) system, forcing us to manually redo a lot of data. Don’t be that guy.) Make sure your system is fully mapped out and that you understand how it works before replacing the team.

When building your team, start small, as others have suggested. A product owner (who can double as your UX designer in a pinch), a tech lead (who can double as your QA automation engineer) -- look for people who can wear multiple hats. Over time, the team can grow, but start with a small team and challenge them to impress you. Then, sit back and see if they do.

Give them plenty of leeway. Don’t burden them with a bunch of “this is how we do things” processes. Hire smart people, empower them to make changes and challenge you, and let them tell you what they need to be successful.

From experience, I can’t stress enough that bad requirements kill projects. Someone creates a totally BS PowerPoint, hands it to a dev, and says, “Build this!” Or some junior dev says, “Yeah, I don’t really understand, but we can do five years’ worth of effort in three months…” That’s a recipe for disaster. They panic, cut corners, and leave you worse off than where you started. No junior folks for mission-critical roles -- seriously.

Look for pragmatic, honest, and hardworking people. Anyone who isn’t comfortable telling you to “fuck off” when you deserve it shouldn’t be in a leadership role or on a mission-critical project. Look for people who strive for a deep understanding.

You’ll also need to give them the right tools. I’m constantly shocked when I show up at a company where the cheapest person on my team is billing $1,200 a day, yet the company wants to saddle everyone with five-year-old Dell laptops and no external monitors, mice, or keyboards. Or worse, they say, “Here’s our 12-year-old Jira instance, but you don’t have admin privileges…” or, “You can VPN in and use a remote desktop client that runs like it’s on a 56.6k modem!” (I’m trying not to be outrageous, but both of these are issues I’ve faced in the last year.)

As the stakeholder who will own this team, make sure all the other BS is cleared off their plate. Give them whatever equipment they want, give them the project management systems they prefer, and don’t try to shoehorn them into your existing setup. Provide them with all the admin privileges they need. Your job is to knock down all the barriers that slow them down.

So, look for a strong leader who’s willing to dig into the details and isn’t afraid of hard work. That should be your point person to start with. “I want you to move a mountain for me -- what do you need to get it done?”

Happy to chat, my email is in my profile.

Firstly, it's important to note that on Hacker News, responders are probably going to be biased towards writing software that solves your problems.

Secondly, it sounds to me as if you are jumping ahead, and favoring one particular solution, rather than looking at this as business problem. If I were tackling it, I'd be making a list of all the possible solutions: - Stay as you are - Stay as you are but make a deal to buy the source code/or perhaps the company that makes the product if that's feasible/or the division - Buy-in an entirely different commercial platform - Build your own as a clone of what you already use, and extend out - Build your own as an entirely new system - something that exactly right for you - Glue systems together to get something that works for you - Probably there are more.

Then I'd list the advantages and disadvantages, the risks, and guesstimates on costs and monetary benefits. This does not need to be a long process - a month and a spreadsheet.

At the end of this process, I'd be thinking about next steps to facilitate the likely candidates. E.g. initial talks to vendors or approaches through an agent about buying the company.

If build-your-own is still on the list, then I'd look at having someone spend a few months documenting and thinking about your existing software, specifically with the aim of mapping out the likely pain-points - e.g. does the system use an interesting scheduling algorithm and if so, what is special, and where does it fail?

This stuff will eventually form the basis of spec for the backbone of a new system. But it's first job is to build some organizational expertise in the software, rather than the use of the software. You want some maps of the territory.

If at the end of this, you have a sense of the pitfalls, then I would think about mapping out what is really needed - interviewing all the levels of your org that have an interest - from the end-users/operators, through to the board. You want to find the stuff that's not documented. You probably don't want to get to a spec, but you do want to have a document that accurately reflects your needs (and also the love-to-haves, and the opportunities to extend)- and it can be used to judge whether a buy-in or a build-your-own can successfully meet your needs.

If you even get this far, this is the point at which you should be deciding between build-your-own and buy-in.

And if it's build-your-own, then this is where you take all the stuff you've learned to spec it.

And if this is the solution, I'd be thinking about what technology will serve you best at least cost, now and ongoing. E.g. should you be building a web app, and if so, what tech could function as the core, so that you don't have to spend money on re-inventing layouts.

Strategies - these are not secret: - Make your business a place that people want to work - that means getting rid of bullies and trouble-makers, and encouraging a supportive environment - Make sure there are challenges, and they are achievable - Offer excellent packages - this can be a mix - work-from-home, healthcare, pay, etc - it's the whole package that matters - Understand that if you don't offer people a pathway to improvement, then you will lose them - Ensure that the actual physical work environment is conducive to concentration - Ensure that the software team are a proper part of the fabric of your company, and not an afterthought.

Transitioning software too, is not rocket-science. You need a solid plan for the transition. You need to train people constantly. You need changes to be small, incremental wherever possible, and clearly communicated ahead of time; you want the people who use the software to feel in control - that this is to help them, rather than to hinder them. And if there are organizational changes as a result, then you need to be sure that you are not shafting staff; you want people on your side, not against you.

I work for a company in the decidedly not-sexy area of pet hospitality. We began building our own software when revenue was under $1M and we're now about 1/4th the size of your company and operate completely on our own software platform. The CEO of my company would convince you to at least try it in a heartbeat. As the original freelance developer and now the CTO, I'll give you the pros and cons from my perspective.

For the first few years as a single shop, they used one then another suite of SaaS designed for the industry. These had some basic public-facing reservations website and a billing system tied to a database of customers, pets, vets, and calendar entries that employees could manage. But the owner was developing his own operational techniques in all areas of the business, with an eye toward building a franchising platform. Operational "secret sauce" he wanted to add in software included: How animals are separated and managed in groups, intelligent maximization of kennel space over time given inter-pet relationships (e.g. family, friend, enemy), tracking pet health and eating habits, matching employee schedules to volume, how reservation slots are filled or saved for most-loyal customers, rewards programs, seasonal rates, franchise-level business variables, getting customer feedback, daily photos and communication with customers, a mobile app for employees to track pets around the facilities in realtime, custom printed collars, projecting volume to fine-tune upcoming sale prices or peak rates, and on and on. It was difficult or impossible to get any features or even bug fixes from the SaaS developers.

He hired me, as a lone freelancer, and paid me half of my estimate up front to spend a year writing him a software platform from scratch. Version 1 did all the basic things he was getting from the SaaS, and then we began iterating on all of the ideas and unique methods. It's been 15 years and one complete rewrite in a more modern language. The company has grown to 8 locations, managing roughly 200 pets per facility at any given time. I have - very rarely - brought on other developers to help, but basically the entire platform is easily manageable by one person and it's not even a full-time job. Our entire operating cost for servers, storage and backup is about $500/mo.

Upsides: They can get pretty much any feature they want, built quickly and cheaply. I understand the business model inside out by now, so I'm able to quickly spot any potential operational or technical pitfalls in new ideas, and work with them to align the software to exactly what their intentions are in new policies, as opposed to just following a feature spec. Just as a small example, when they changed their rules about deposit amounts and cancellation deadlines and fees a couple times over the years, it became much easier to write a subsystem that allowed them to manage those things themselves. Being so tailored, the software prevents employees from making common mistakes. Rollouts are VERY fast, sometimes in the same day as a minor feature is ordered up. We can make new versions available to one facility to test in production and see what bugs crop up, then roll out to the rest. Over time it has been more expensive than any SaaS, but at this point it would be impossible for the company to do what it does without the custom software. Owning the software has itself been a tremendous value addition for both investors and franchisees.

Downsides: As my friends in the tech industry love to point out, all of this constitutes a lot of technical debt. If I die or something, they're gonna be pretty screwed for awhile. As it stands, it would take someone else awhile to come up to speed on the 500k LOC we have across 5 different apps in the suite. The software runs itself, it hasn't gone down in years, and it's recoverable if it does, but as far as bug fixes or new features or dealing with forced upgrades it would take awhile. It didn't have to be this way; they could have hired a team or transitioned to one. Given the CEO's outlook on building things himself, he would have built a team if he felt he needed to. Knowing what I know, they're lucky they chose me as a single point of failure and not someone who might decide to switch careers or retire early. But those are avoidable pitfalls.

Final advice: Take time to choose well-supported technology stacks that will be around a long time. Documenting code. Most importantly, have your coder(s) work directly with the people responsible for writing and developing your operational / business procedures, and have them collaborate on writing the software manual. That way the logic of the business is understood by the coders and the logic of the software is understood by the people responsible for creating and implementing operations.

It doesn't have to cost a fortune to get up and running and it's way, way cheaper than hiring an outside firm. Personally I love working for companies outside the tech industry who need in-house software, it's a much better culture and the results are immediate and tangible.

Having built one of the largest tech-enabled 3PLs from ground up and serving as CTO for a logistics tech startup with client 20M - 1B annual transportation spend, my take below

> 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.

Most successful and agile 3PL and LSP (non VC backed) do not build all their tech, but rather glue tech together. They leverage pre-built TMS, WMS, YMS and build out in-house middleware layer for analytics and control points. Key is to guarantee portability of data and analytics with a unified view of the business.

> 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.

The Devil is definitely in the details. We regularly ignore what C/VP/Dir-level's description of tech and business process. Talking with the direct team member or their manager reveal so much more of the real painpoints than what higher up learns. The risk here is not business adopting tech but rather tech team understanding business. Have a senior leader here who are technical with strong business domain expertise is critical. They need to form a culture of domain understanding throughout the tech org.

> 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).

It is very hard. Mostly due to comp, EPD treated as a cost center (and engineers do not want to be devs), lack of recognition of the industry.

There is one thing going for logistics, it touches physical world and is extremely complex (not hard). It attracts certain types of people prefer complex problems. Aside from senior tech leaders and a few senior engineers, you will be aiming for the diamond in the rough profile here.

There are rare cases such as Ryder acquiring Baton and use the latter as their core Engineering while keeping some old IT groups hanging around. Ryder is large enough to pay tens of engineers 300k+ salaries.

> Potential pitfalls we might not be considering. Alternative solutions we should explore.

Instead of building a tech team to build everything, you have an artifact, who is a domain expert on your own business, define a business middleware and analytics ingress for the company. Start by normalizing against the middleware and analytics ingress with consultants before building your own tech team.

Logistics has been the most fascinating industry I have worked in and I see my whole career in this industry. Excited to chat more tech strategy in logistics, email shu at loop dot com.

Hello,

I've only done B2B transformations (revisiting all software systems and realigning/reimplementing them in parallel) like this in multiple verticals, both physical and digital, for the past 20 years as a Fractional CTO for companies in your revenue range and larger.

As needed I can traverse the entire pyramid from top to bottom from business strategy, finding partners and vendors, and informing everything down to the nuts and bolts alone for maximum alignment, and ensure it's learned alongside team members in the organization.

I often help with the budgeting and estimating process and find customers save significant time and money with the right strategy, approach and oversight.

Here's my take:

1. ATTRACTING TECH TALENT:

- Consider a contract-to-employment model. I've built teams where contractors who prefer employee life can switch over. There's other options too depending on your current mix and structure.

- Emphasize training at all steps. I guarantee clients a trained and productive resource, regardless of employee or contractor status.

2. THIRD-PARTY TO IN-HOUSE TRANSITION:

- Success: Helped clients reduce days-to-cash by 50% with custom solutions, projects relatively on time, and staff that remained able to work in the new system.

- Caution: Seen projects stall due to underestimated complexity, or avoiding realities (ie., data may not be as good as they thought)

- Run fast from anyone who wants to build only code from scratch from the outset. Also run from buying an all-in-one system until you know what your critical path is. I have worked around and through both, including from the start, and rescuing projects.

3. POTENTIAL PITFALLS:

- Underestimating current system complexity.

- Cloud lock-in: It's the new software/vendor lock-in, just sneakier. There are ways to have your cloud cake and eat it too while maintaining options.

- Over-engineering: Build software has become horribly overcomplicated. It's hard to keep things simple and flexible, easy to make it complicated. Helping everyone understand the data and process together sheds a major light on the path ahead and create a better sense of ownership.

4. ALTERNATIVE SOLUTIONS:

- Hybrid approach: Develop core competencies in-house while using strategic third-party solutions.

- Agency acquisition: I've facilitated M&A deals where companies purchase agencies.

- Vendor-as-internal-department: Set up external vendors with internal SLAs.

KEY CONSIDERATIONS:

- I would start with an honest assessment of where your organization truly is and where it wants to be. Beyond advisory or building, learning where your business needs to head and measurable ways to get there is critical.

- In-house dependency is important, but there may be better external options too that can be much more stable than an agency with interests with multiple clients.

- Any culture change and planning for it is critical.

- Industry standards (SOC, HIPAA, etc.) and architecture will ultimately decide the fate in 5-10 years.

- I keep software sales promises honest and accurate to the company, ensuring clarity on current state and future direction. Includes negotiating contracts that work for the business, not the vendor alone.

I have a lot of conviction about what I do because I've done it and still do it, keeping up with where things are headed to provide input on where things could be. I train to process, and so the process is central.

If you'd like to chat more, I'm happy to offer an hour of my time.

I'm genuinely curious to see how much actual valuable information and insight I can provide to help you think through your situation. Firehose, or key points. My email is in my profile or reachj45@gmail.com

My goal is to give you as much food for thought as you like, knowledge as possible, regardless of any direction you ultimately take. My email is in my profile if you're interested in a no-strings-attached discussion, except I'd like you to bring the most painful issues.

The world is an odd place where people who don't understand software sell it to people who don't always know how to buy it, let alone roll it out. Navigating this can be an outlier for impact. I'm here to help change that where it crosses my path and get technology working for people instead of the other way around.

Note: Edited from a laptop instead of written from a phone. :)

In case anyone's thinking of reaching out, offer is open to anyone relative to my availability.

Honestly, 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.

This is going to be a long reply. Sorry about that.

# Full Disclosure

- I am part of an agency that helps companies like yours build products either for internal use or for their customers. - We are partners for a couple of large enterprises, but most of our customers have between 50 to 300 employees.

# Experience

- We have worked with a company in a specific niche that was using a platform from a small provider. - We ended up rebuilding their entire platform from scratch. Spoiler - it was not easy. - I prefer being called a technology partner rather than an agency/vendor. Our clients' success is how we define our success.

# Thoughts

- Your own product will never be 100% complete - If you are someone who loves to optimize things and wants efficiency, then every single workflow or process can be optimized or even entirely removed. And, it is absolutely okay, as long as you are always in a better place than you are currently and are growing your revenue while reducing stress/manual overhead with every single update.

- The only way this works properly is if a senior team member from the agency is embedded as part of your team.

- Only work with companies/agencies/partners who come via a referral. Picking agencies from Clutch etc. is not the way to go. All those listings are always paid, even the ones which say they are not.

- This has been said before - When working with a tech partner, start with an extremely small but challenging project. Set clear milestones for them to hit and for you to be able to measure success.

- IMPORTANT - Define one product owner on your team who will be responsible for all decisions. This is a bigger deal than you would think. You have domain experts in your team, who can be consulted, but that product owner will be the primary decision maker.

- IN-HOUSE TALENT - Use the tech partner to help grow and train your team. They are in the industry to hire tech people and can find the right people for your team.

- DESIGN - Do not skimp on this. I am sure there are workflows and processes which have been present for a long time. People in your team are used to them. But this new phase gives you an opportunity to redefine/reevaluate everything. Delete. Redesign. Implement.

- Don't be a stickler for Agile vs Scrum vs any other new shiny methodology. Figure out the system that works best for you, your existing team, and your extended team. Yes, this takes time, but it is possible to agree on some things and then build from there.

- Communication - When working with an agency, working with a partner who has someone embedded allows you to bring them into all conversations early. The right partner will help you make better decisions. And this senior embedded person will be able to communicate and manage the extended team using off-the-shelf tools which you have visibility on. Example - Our core tools for communication include Slack, Airtable, and Figma.

- Long-term thinking - having the correct incentive structure for your tech partner allows them to make better decisions for the product and the business instead of thinking about getting done with one project and making a profit.

- Legal Contract - It does not always work, but it is important to have a good contract with timelines and SLAs for your work.

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.

I work on a team that produces sensors, sensor analysis routines, and web infrastructure to distribute the sensor analysis to clients. We manufacture in house, and our in-house software team is roughly 5 people depending on how you include roles. I do the actual analysis routines, math-heavy native-compiled stuff. The others do web frontend dev, mobile dev, and backend server stuff. Our current strategy has worked so brilliantly that after 20 years of ancient codebases and constant fires, we've had a year of relative quiet as everything "just works". We now have the most advanced analysis package in our industry. Here are the main points, with a small dev team in mind:

1) Silo responsibility and keep the structure flat. Minimize how much people are stepping on each other's toes by giving them one whole "piece" of the puzzle and letting them take ownership of that piece.

2) Give them freedom to approach the problem with the best methods and tools they know how. Tasks should be long-term goals that allow the engineers to flex their creative and problem-solving muscles. Competent engineers will find ways to communicate and coordinate with who they need to, when they need to.

I must emphasize tools. If a problem could benefit from a new language, let engineers explore that path. In replacing some maliciously obfuscated 20-year-old C and PHP code, I entertained several languages before settling on Nim for our analysis routines. It slots easily in to our servers and is invoked via scripts, makes fast C executables, and the maintenance, refactoring, and readability jump has almost made my job too easy. You will need to balance against "bus factor", but keep your competitive advantage in mind. Take a strong look at web technologies like Clojure and HTMX that can attract talent, keep head count low, and increase product quality and maintainability.

3) Use team interviews. Your team will work together to suss out fakes and find good fits far better than any single interviewer, especially a single interviewer without the requisite expertise. Don't just ask technical questions, ask open-ended critical and creative thinking questions.

4) Do entertain the possibility that young and fresh engineers can integrate well, learn quickly, and explore possibilities you never thought of. Our hardware team has a couple of much older (60s) engineers with very old-school practices who are dragging them through a quagmire. Keep an eye on your competitive advantage.

5) A note on our company's old issues: Eons ago, they hired a VERY expert (PhD qualified) engineer as a contractor years ago to build all of their systems. He fought them over the intellectual property and deliberately obfuscated code to keep his job. Make sure your team is in-house and salaried, and that you own everything they produce.

Also, avoid desktop applications. The current state of desktop is a disaster. It's difficult to make anything truly useful, and you'll probably need a web view anyways to make use of JavaScript libraries that actually do what you want. As much as it sucks to say, your software probably needs to be a web application. KISS, and again, look towards tools like Clojure and HTMX to simplify things.

Host as much as you can in-house. The decline of "cloud" has already started. Make sure your IT person is competent and can architect solid infrastructure, because you can't expect the same from Microsoft or Amazon these days.

If you're in logistics and have an ARR in the $200-$300M range then you are not a big player. Logistics is a massive field with a lot of variation. It would help if you could share at least some details: where in the chain do you sit?

My experience is in the car industry with factory-to-dealer and some of the supplier-to-factory. The core systems were built by SAP, they were very expensive but they were reliable thanks to some smart architectural choices. Those were supported by various bespoke solutions to solve very specific requirements over the company.

In general, at your size, and assuming that you're doing something with retail-like margins (1-2%) then you're almost always going to be better off buying and running some COTS solution. The time look away from that is if there is nothing suitable on the market and if there is a strategic move on the table. Software systems can give you a big competitive advantage. It could even be a way to build a sister business - I can give you a number of examples where companies have "scratched their itch" and then spun off their software as a product company.

So what do you do? You know your business. Can you afford to waste ~1M EUR a year (3-4 really good freelancers in Europe + cloud/license costs) for a couple of years next to what you're already doing?