Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Should we bring software dev in-house?
565 points by 45HCPW 3 months ago | hide | past | favorite | 594 comments
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. I've been lurking here for years, so looking at the HN community to talk me 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.

As we are growing we're running in to the limits of what this product can offer. We're being hampered in our speed of execution and missing crucial insights. I feel like we could do much better with a product catered specifically to us.

On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.

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

We'd particularly appreciate input on:

Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning from third-party to in-house software (success stories and cautionary tales). Potential pitfalls we might not be considering. Alternative solutions we should explore.

Has anyone here navigated a similar transition? What worked? What didn't? Any advice would be appreciated.




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)


This is excellent advice but I would back up a few steps and do a few things before bringing in a freelancer team.

Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible. Then document the requirements for this part thoroughly. This allows you to:

- Have something smaller for your new team to cut their teeth on.

- Ensure you have collected all the diffuse domain knowledge for this part in one place in the form of structured requirements.

- Forces you to think in terms of what you need and what is acceptable delivery,

If need be you can bring in a Senior/Staff level engineer to help you through this discovery and definition phase.

In my experience the most common difference between success and failure for a project often comes down to clear requirements and expectations. Your employees are the domain experts. You need to collect that expertise and document it in a way that this team can reasonably consume. This is difficult and time consuming so start now.

They will still have questions and get things wrong but this gives you a roadmap. They are going to be learning your industry while you are learning how to build software.

Best of luck

EDIT: formatting


> This is difficult and time consuming so start now.

A specific difficulty you are likely to face:

Your expert employees are busy doing their jobs. Writing requirements means taking attention away from that work - a difficult proposition, especially if they have managers who will ask why their KPIs are slipping.


Maybe a nit pick, but I would not accept the expert employees writing requirement documents that are "thrown over the wall" to the dev team.

You need personal access to talk to the experts anytime some question comes up. This means 1-2 experts work part time as PMs more or less, which will impact their regular work.

Costly, but I don't trust any other way.


I think there are variations of this. Yes, your experts need to give an amount of time to the effort. Making them a PM, in any sense of the word, is a step beyond contributing their expertise and can be avoided.

What you need is someone with significant dev experience, but enough outside exposure to step into the PM role. Ideally, it'd be someone with interest in user experience research, or a personality that connect outside of a dev team. They should be able to perform this role in a mechanical fashion to avoid a dedicated PM.

Doing this will be effective enough until things are at the point where a dedicated PM can be justified. If there is a struggle with the user experience aspects and getting knowledge out of the experts, you can get expertise from an agency on a short-term basis.

Adding a pure PM is going to significantly slow you down unless are one of the rare switchers who flip between dev, PM, and dev manager roles. People don't know what to make of these people, but they exist, especially in the freelance contract world. People will only full-time experience tend to look down on them because they can't understand it.


These experts may also be hesitant to change.

It could be due to many different reasons. One the personal spectrum, they can overvalue themselves or have fear of loosing their jobs.

On the technical spectrum, they can be stuck in old tracks without computer knowledge and not thinking outside of the box. For example, in their eyes the objective is to move PDF file from directory A to directory B. In the ideal automated world, why is there a PDF in the first place? Basically "if you asked what they wanted they would have said faster horses...".


For the technical side, this is a part of what a good software engineering team should be teasing out from the verbal requirements. Check if the intermediate PDF is needed, if it is, it still shouldn't be part of the automation path, but instead serialize/send the data properly and output the PDF on the side.


Oh - you're so right. I see this probably around 20-25% of the time. Schedules slipping because you can't get time with the main SME.


would it be possible to just work on writing everything down and use all the time it takes?

I imagine the complicated part would grow wordy enough to stick out like a sore thumb.

Perhaps eventually have a freelancer turn it into technical documentation. The stuff we admire (if done right) but hate to do. (or in my case clueless how to)

(disclaimer: I know nothing, im just reading the comments.)


What is being expressed here is not a new problem. The challenge with solving it is that there isn't an easy set of steps that works every time. Someone's experience with the challenges of getting time with SMEs is highly dependent on the culture of the org, incentives, structure of the engagement, personality of the SME, actual workload, SMEs situation/feelings/stress, etc.

You can solve or mitigate these problems, but it takes experience and expertise that most coming from more pure software development backgrounds may not have. From experience, someone coming in with some consulting experience will tackle the situation differently.

Writing stuff down isn't always the best approach. Having a written record may be a good end goal. It may be better to have the small implementation soak up that experience through co-location with the experts. That way they are close by for interviews (probably too formal) but more likely sit and observe as the experts work. OP can then focus on building relationships between the experts and dev team. On this foundation you can add in more formality.

As part of the relationship management, OP will have to help the experts free time by working with their management. Without details of the company, we can't give real examples, but it might include supporting their requests for contractor support or giving their leadership political help.

When you can't come to some sort of co-location situation, you have seriously undermined your ability to execute the project. You will not have a true picture of the situation. Getting PMs or user experience people to engage with the experts will be lower value and require more clarifications. Developers can be low threat to the experts versus other types of people you can bring in.


>> project often comes down to clear requirements and expectations

Here you are just copying an existing system. Reverse engineering requirements from domain experts unnecessarily turns this into a green field project.


Want to second the two parent comments to this. Small freelance / contract team of very very senior very experienced people. 3 to 4 max.

I was fortunate in that I, for the first part of my career, joined teams that were structured like this.

Some additional thoughts:

- keep things small at the start - task your team with at least two goals for the first 90 to 180 days

       i ) to define a small but critical piece of work (actually designing and coding something related to what you need to do). Cannot be part of your core platform but will need to eventually be in the platform. Picking the right piece of work here is critical.

      ii ) to define a design, roadmap and project plan for completing everything you want done with cost, staffing, tech and effort estimates

Then use the 90 to 120 days and the two tasks above to evaluate:

    i) if the folks and team you have put together works:

        a) as a team and 

        b) with your existing business ( can they do the work, can they work effectively with the rest of your business, is the design the come up with solid and does it give you confidence that they can tackle the real core work you need done)


   ii) if you can get a sense of what it will cost (what did the 90 day project cost and was it delivered on time and budget per the team's estimate )

   iii) if the team can put together a road map with support of the business for the broader objective in parallel to executing the piece of work chosen

   iv ) if the solution if palatable from a cost perspective ( money, people, tech, disruption ) 

   v) if the staffing model , architecture and integration proposed for the project by your new team could work (get feedback from the rest of the business about what is proposed by your new team ) 

    vi) if your business can work with this new tech team ( feedback from your existing staff about the folks doing the work and their product for the small piece of work they tackled )


- It is really critical that they be 'senior' people - 'senior' here meaning they have done and seen a lot. The title will not tell you if they are. You have to actually look at what they have done. Look for senior free-lancers with a variety of (longish 4 to 5 years) experience using a variety of technologies (C / Java / PL-SQL / Perl / Rust / C++ whatever etc etc - but boring old tech is better, you will eliminate another variable from your project complexity ) in variety of industries / verticals ( 3 to 5 industries. This is a signal of effectiveness at learning new things and delivering effectively in new fields with new people in new environments.

- it is critical that your freelancers not just be developers: they have to be "business-goal oriented". Consider asking for references who are not developers and consider filtering your freelancer hires through their networks in LinkedIn - do they have a good mix of senior and non-senior people in their network who are NOT developers? That is a good indicator they worked effectively enough with other non-software parts of the business that the people on that side of the fence (marketing, ops, finance etc etc ) are comfortable being associated with them. Pick the areas that matter to you.

- Consider filtering for delivered results when you talk to candidates and in resumes: look for achievements / projects / work delivered rather than work done as this 'could' be a signal that the person is focused on actually 'owning' projects (not work ) and closing out on projects / goals (could also be a signal that the person did not not consider put delivered work in their resume so there is that - so, if you don't see it, just ask something like "what projects have you owned start to finish and how did you architect, design and execute on them" and interpret the response ).

- Key skills to look for in free lancers:

               - systems integration (making systems 'talk' to each other - you will have to make your existing system talk to your new system + you will eventually have to get your data off wherever it is now to your new environment and you will have to make the new system work with all the other tech systems you have now)

               - system architecture: designing software solutions

               - database architecture & design

               - project & program management 

               - lean six sigma / green belt ( means they have may have worked with ops people to optimize operations )

All the difficult stuff is going to happen in the background (batch processing, integration etc etc) so don't bother with front end development skills at the start - that is actually relatively easy to hire for.

You will definitely find folks who have the right profile who will work with you - the key is decent (not crazy) pay, benefits and elements of stability attached (contracted duration with pay guarantees for performance, performance bonuses if possible etc etc).

- Plan on developing a bench from the freelancers so hire some mid-level junior folks to work alongside them for when the freelancers inevitably move on. You will have to hire from outside (try and get mid-level people in the industry, not senior folks, so that it is clear that your senior freelancers are the leaders / owners of work ) but try really hard to source at least a few of these folks from existing staff if possible ( people in other job functions - and are good at those jobs - who are programming inclined ) as they are a good source of how things work to integrate into the team or as new hires. They do not have to be as as senior but they have to be able to keep up. These people start as grunts for your freelancers and learn the system as it is built - they are your future tech staffing.

- Plan ahead for what WILL go wrong. I strongly strongly strongly recommend reading two books

                - The Phoenix Project - https://www.amazon.ca/dp/0988262592
                - The Unicorn Project - https://www.amazon.ca/dp/1942788762
They deals with how executives and staff tackled a situation very similar to what you are dealing with and explains how to tackle some of the key structural problems you WILL run into. It is also a great resource for understanding how to run a project like this and understand how things could go right and more important, how things can go wrong and what to do WHEN they do go wrong (because they WILL ). The books will give you a very strong set of foundational thoughts about how to think about running this project if you decide to commit to doing it.


I've been going through a similar situation in a smaller company, and this is one of the best comments I've ever seen on HN.

Any given operation may not be able to follow all of it to the letter, but all of it is really sound advice and can be tweaked/customized for a variety of settings.


>> Identify a part of this system that can work somewhat in isolation and is non-critical if at all possible.

I'm probably thinking about this at a different level, but when I start something new I like to find the core pieces and the most difficult pieces and see if I can tackle those first. Everything else builds on top of that. I'm assuming you mean to start at a higher level piece that will need to use all of the lower level pieces. That's good too because it may help identify what those difficult core pieces even are that I'd like to go after first.


It’s a new team. This non-critical part is your shakeout cruise before heading off into the open ocean. You can identify how well you hired as well as how well you prepared for these contractors to begin work. Make appropriate calibrations or worst case scrap it and let the whole team go.

If they produce some big mess you will find out much quicker than if you set them loose on the big project. Small deliverables which incrementally get larger is how you roll on a new team. It allows you to get fast feedback and make small calibrations as you go. Hopefully avoiding the “fire them all” failed project scenario


Strongly agree here. It's hard to find a CTO if you don't have access to any engineering talent that you trust and have vetted. A small, focused project with a team of very senior freelancers both gives you a chance to dip your toes into the idea of running your own in-house software development, and an opportunity to vet individuals who can help you make good hiring decisions down the road.

If you're interested in following this strategy, don't hesitate to reach out to poetic.artifice@gmail.com -- I'd be happy to help on both fronts.

As for your concern about logistics being not sexy enough - I've found that the best programmers (and the ones you'd want) are more interested in the technical aspects of the problem and business and customer impact, rather than the sexiness of the business domain.


> I've found that the best programmers (and the ones you'd want) are more interested in the technical aspects of the problem and business and customer impact, rather than the sexiness of the business domain.

Just want to heartily agree with this point here. Certainly many of us do get excited about particular business domains from time to time, but in my own experience, I get more excited about technical challenges, and -- critically -- solving real problems for real customers that I can see first- or nearly-first-hand. The customers for this "product" would be internal to OP's org, so the people who end up building this would have front-row seats to how it's being used, what's good, what's bad, etc.


For me red flag is that for OP as a developer I will end up being a cost.

Even with all the good words he wrote how company can improve by doing own dev - reality is that company makes money in logistics and as a software dev I would be second class citizen and cost center.

That is why I much rather work in company that makes money on software, because here I am money making.


It's possible to treat software close to a first-class citizen even technically as a cost center. Probably the key is to have a lean team that is effective and management trusts, in a business whose profit margin or stability can be greatly enhanced by good software. If you're relatively lean then nobody sane would be looking to cut fat in your team. On top of that, the attitude of management and the culture is really important, and this CEO's attitude is at least a good start.

I hear Meta Ads has one of the more toxic environments for SWEs, even though Ads make money.


> company makes money in logistics and as a software dev I would be second class citizen and cost center

If software can make the company provide better logistics more efficiently, it's not a cost center, it's an enabler. It pays for itself in reduced costs and increased revenue.


A cost centre is, by definition, somewhere that only produces costs and is never attributed with any revenue or profit.

A smart management team can figure out that investing in IT, Software, etc is going to have a positive ROI overall by increasing efficiency among other things.

Unfortunately my experience (and many others') is that only the balance sheet will be considered and the goal will always be to reduce the costs in cost centres as much as possible.

Even in a company that doesn't fall fully into that trap, often times a lot of effort needs to be expended to keep funding at current levels, never mind the rituals involved in getting increased funding for new projects, hardware, staff, etc.

Generally the more obvious the connection between your work and company revenue, the easier your life will be.


> A cost centre is, by definition, somewhere that only produces costs and is never attributed with any revenue or profit.

Which means that if investing in IT is an enabler for gaining revenue or profit, it's not a cost center by this definition--it's necessary to gain revenue or profit. As you note, many companies don't appear to be smart enough to see this, but that doesn't make it wrong.


What customer has paid the company for IT's services directly?

None?

It's a cost center in the same way the janitorial staff or legal are. The company won't be there without contracts or with overflowing trashcans, but it doesn't mean the company is making money off of janitorial services or drafting contracts.


> as a software dev I would be second class citizen and cost center

Everyone’s a cost. The myth of revenue centres was made up by sales & marketing.


Well I do agree everyone is a cost.

But it still doesn’t make company dynamics not true. Logistics company will have bunch of logistics specialists as management and they will see it as revenue center and will see „their own kind of people” as more important.


The management sets the company dynamics to whatever they want.

That idea of costs and profit centers is bullshit that only bad manager believe in. It may or may not be the case with the one company of the OP, we don't nearly enough information to judge.

(But the fact that the OP is reaching into IT with the goal of improving their people's productivity is a very weak indication that they are better than that.)


Yes so I am indirectly replying to OP question if he will be able attract and retain tech talent and I cannot imply anything really about his specific company.

I am only pointing out my view on it based on my years of experience working in different companies. Looking by up votes it seems my experience to be applicable for other people as well, so I guess it might be useful for the OP.


>The myth of revenue centres was made up by sales & marketing.

Funny that sales and marketing sells and markets itself.


I dont know if it always works this way. A software-first company has more experience at hiring/firing software devs and is better at "screwing you over", extracting maximum work for the least money. Its their bread and butter. Not all companies but some are like this.


I’ve been on one of these teams and we accomplished pretty amazing stuff in a short time span. Keeping the team lean and senior, ensuring we each had a specialization yet broad enough skills to interact and collaborate well, and providing us with agency to make decisions was a magic recipe.

I’d love to do that again. It was by far the most fun I’ve had working on software. These days I do pretty boring work that’s significantly below my capabilities, but it pays the bills and there’s not much else to pick from at the moment.

As for if someone hypothetically did choose to build a new solution in this scenario, it would almost certainly make sense to build it in tandem with your existing process. Going totally greenfield and trying to port your business over in 6 months would be misery. I’d look at ways to incrementally build a new system which you adopt gradually, probably starting with replacing the no/low code pieces you’ve already built.

Any kind of monolithic approach to replacing an existing system gives me deep, deep tingly creeps due to past disasters.


I'm gonna go against this heavily tbh:

If you don't have a 'trusted wrangler' freelancers won't build anything worthwhile as they're not interested in the long term unless forced.

There must be somebody you know, or friend of friend, to get a warm intro to an experienced developer you can pay to oversee said team on an interim basis. No consultants, agencies etc. they'll fleece a non-tech like you, save your money and drop it on somebody good who can actually help execute your vision.


If you don't have a 'trusted wrangler' freelancers won't build anything worthwhile as they're not interested in the long term unless forced.

Freelancers' careers live or die based on where future work is coming from. Happy clients are good for repeat business. Happy clients refer other potential clients. Happy clients are good for portfolios or case studies. Smart freelancers are all about keeping their clients happy in the long term. It's just good business.

Of course there are people in the freelance world who are hopeless and will never build anything useful just like there are people in the employment world with the same problem. But it's much more career-endangering to be incompetent as a developer and/or as a communicator in the freelance world because freelance gigs can often be terminated relatively easily if the client isn't happy with the work.

Maybe this is different in the parts of the US where compensation for tech employees can be way higher than anywhere else but in most of the world freelancers tend to be relatively good at what they do and part of the attraction of going the freelance route is that it doesn't have the glass ceiling on compensation that being an employee often does so if you're good enough to justify higher fees then you can actually charge what you're worth.


> Freelancers' careers live or die based on where future work is coming from. Happy clients are good for repeat business. Happy clients refer other potential clients. Happy clients are good for portfolios or case studies. Smart freelancers are all about keeping their clients happy in the long term. It's just good business.

Not a freelancer, but this is a classic "market for lemons" situation: designing things for the long term takes a significant amount of extra thought and expertise. If two freelancers give two different quotes, one of which has a higher hourly rate and will take a longer time, there are one of two possibilities:

1. The more expensive quote is way overpriced, trying to extract money out of the buyer and possibly double-dip

2. The cheaper one is a low-quality "cowboy" job that's going to cost way more to maintain in the long run

If buyers in general can't tell the difference, then the market will end up pressuring even the high quality people to cut corners and produce "cowboy" jobs. In other words, it may not be 100% the freelancer's fault they're "not interested in the long term unless forced".

So part of the job of a "wrangler" is to understand what's worth investing in and what's not -- to know that it's worth spending double in this particular area because it's a long-term win -- and to be able to evaluate the output of the work, to make sure that what was delivered actually is higher value.


If buyers in general can't tell the difference, then the market will end up pressuring even the high quality people to cut corners and produce "cowboy" jobs.

There are enough buyers who can tell the difference. Good freelancers just gravitate towards good clients and vice versa.


In practice this simply doesn’t pan out. There are many many terrible freelancers out there. And without someone technical in-house vetting their work, you’ll have no choice but to judge their based on their output. This is a huge problem.

Software needs to be designed with an understanding of the business needs and goals. You need someone who understands how to keep the software well designed (ie. Easy to debug, update and extend in the future).

Judging solely as a user of the software gives you no insight into whether or not a plate of spaghetti code could be holding behind the scenes.

Good code has two traits: It does the job it was designed to do. It is easy to update and maintain.

Everything else you read online is nonsense. And you need someone trusted inside your company to ensure the second trait is being adhered to.


In practice this simply doesn’t pan out. There are many many terrible freelancers out there. And without someone technical in-house vetting their work, you’ll have no choice but to judge their based on their output. This is a huge problem.

Why? There are many terrible everything out there. Eventually you are always relying on the quality of your developers' output and their honesty in explaining it whether they are hired as employees or working freelance.

Crucially that is as true of the technical in-house person as the outside freelancer. I've seen scenarios with my own eyes where an experienced freelancer was better - sometimes much better - than the in-house "senior" people but the latter made critical reports about the freelancer to management. Maybe they were defensive because someone better than them was brought in. Maybe - and I suspect this is more likely in at least some of the situations I'm remembering here - the in-house person was so far below the outside freelancer in ability that they simply didn't realise how much better the freelancer's work was than their own or understand the reasons the freelancer was following certain good practices and the risks they were mitigating by doing so.

So my question to you is this: Why do you believe you can trust someone to evaluate the quality of the work more accurately and honestly just because they are inside your company?


My experience as an in-house dev working together with freelancers and body shops (in Europe) is less positive.

A pattern I commonly see is that they are heavily technology focused and don't really care about the domain, because domain-specific skills are not transferable. They are snake-oil salesmen, every problem can be solved by adopting some hot new piece of technology which can be added to their CV and increase their market value. What's frustrating is that their contribution is in the end often negative rather than merely zero - adopting over-architected solutions looking good on CV will result in great costs. If you have a strong technical leadership, you can catch their bullshit, but in the op's situation, they would be pretty much relying on freelancers' good will and abilities without much of a chance to verify their claims.

To be fair, I've met also a number of very good freelancers, usually staying with the company for years.

This same danger exists also with the normal employees, but I think this "pad the CV, move on" is more common in freelancers since they generally operate on shorter timescales.


I've worked as a freelancer for a while, and have often worked with mixes of freelancers, permanent employees and everything in between.

I think there's a big difference between bringing on a boutique consulting shop and hiring freelancers who sit together in your office. The sense of ownership and professional responsibility is way higher in the latter case. In fact I'd even go as far to say that many freelancers have MORE professional pride than permanent employees, many of whom just want to draw a paycheck and live their life.

YMMV of course!


I work for a small company, around 10 devs. We've picked up quite a few projects over the years where a freelance team came in, built something and when the going got tough, walked away. That said, I've seen the same happen at renowned companies, so perhaps it's just an issue of generally people taking advantage of the shortage in experienced devs. I would aim to get some longer term stability, either by working with a company you trust through your network, or engage a tech Lead/CTO for a longer term who can oversee the contractors.


> It's a hard role to hire for, especially at the start.

The approach of "I'm going to hire someone to build me a team" only works if you know someone excellent. It is a very low percentage strategy if hire #1 is from the market.

That doesn't mean you can't find excellent people through the market, but you'll have to see them work first, and it might take a few tries. You won't be able to spin up your own interview funnel and get good results. Hiring freelancers and seeing who gets it is probably the only way your organization can reliably detect talent (whereas a software company would have an interview funnel as a core competency). Once you have a freelancer who gets it, you can ask them if they want to join, or if they want to get paid to interview for you. Talent likes to work with talent, and the freelancer will be better at interviewing than you. Repeat this process until you have a team.

Eventually you may want management, but by the time you need management, you should have a pool of engineers large enough that one of them would be willing and able to manage the rest. They will be more competent than any manager you try to hire from the market by a mile.


Having had the fun of taking over a project from a bunch of clever contractors I would caution: It may be too clever. There is value in simplicity and a stake in long term ownership. Some article here recently associated technical debt as lost institutional knowledge so handing the most key decisions to contractors has also drawbacks. One needs an integrated approach for design, build, maintenance and operation.


Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality. Those foundational architectural decisions have a way of becoming set in stone, long after the freelancers have left, dooming the project to scalability and latency problems which seem to linger forever.


I've seen equally many projects never achieve lift-off because they were stuck in analysis paralysis trying to architect MVP for scalability, extensibility etc.

And even if that succeeded you often end up with fear of change because the complicated architecture can't be touched.

It's really important to have the right balance here, but KISS and YAGNI are often easier to scale when you need it, than the reverse. If you don't have the mentality that the MVP must never be rewritten.


> Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality

That, plus "they're probably going to fire us in a year anyway, who cares" thinking

And "we don't need to understand the business domain, let's just MVP", which they get away with because they would get accused of not being agile if they did boring stuff like trying to understand the business

I refer more to bigger off shore consultancy shops than individual freelancers


Yes! This also happened in the team I mentioned. Sometimes during design/architecture meetings we'd run into the "too many chiefs" problem. That's why I think it's also important to make clear who the lead is from day one.


Agreed. Take long term ownership. Don't farm this out. There are some companies out there that provide support and consulting on open source projects. Rather than look for a freelancer to build an in-house application, find someone that can help you capitalize on tools that already exist.

My company does exactly this. We build and maintain an open source project (SpiffWorkflow, for process automation) and help our clients build internal skills to deploy it and use it. No license fees or SAAS lockin - and no team of developers that walk out the door when things get difficult.


Agreed. The important thing is the senior part. Find and pay the hefty premium for a small, experienced team. The code quality questions, etc are answered by that.


My caution is at the end of working with free lancers you have no technical retention.

My company worked with freelancers/consultants for years, it just delayed the inevitable. You need to start building your in house team.

Find the ONE. See if he can build anything on their own. If they can/thinking is good, then scaling with freelancers seems good because you retain knowledge and long-term vision/oversight.


That's the whole point - at this point they don't know if they want to build out a full team. Start small and measure progress, you can always add permanent employees along the way. (We did this too)


Yup. My consultancy is this- collective of very senior folks who have worked together for years, with experience in most business domains, most tech stacks, and most compliance regimes. This is what we do- accelerate the transition from either internal legacy or external dependency onto new solidly architected appropriate/ergonomic stack for internal team to maintain/extend. You can't hire the experience to get you started in the right way. We leave once you are transitioned because you don't need to pay premium to operate. Feel free also to reach out, email in profile.


Excellent advice - this matches exactly with my experience. Get a core team of very senior freelancers and let them run it as a parallel project. You don't need a huge team (2-5) but you do need quality and people who can work together.

Quality isn't always easy to find - avoid agencies, hire the kind of freelancer who dares to work on complex / hard projects (there aren't that many of them) and ideally.

The pitfalls are mainly hiring:

a) Inexperienced people who happen to work for themselves. b) Agencies, they have an incentive to sell bodies: two mid-level bodies are 1.5-1.8x the cost of 1 senior and they do less work. Especially if they sell you a team of them.

Pick a small vertical slice or process and have them implement that. Run in parallel (the costs in these projects is when operations are negatively affected). Treat it as a learning process. Iterate. Then grow based on what you learn.


Oh and whatever you do, don't hire anyone who is a "scrum master" or "project manager" - if you're hiring from the top you won't need that; people like us are highly professional/communicative/focused. Having someone come in to "take charge" is a bad idea.

I'll disagree with Dave on one thing: I personally prefer not having a single lead developer. I've come to appreciate the advantage of having multiple, aligned leaders in a team. Teams like that are absolutely awesome to work on and you can specifically hire for it.

You will absolutely need buy-in from your company, you'll need to give them access to the people doing the job and likely have one of your senior employees do the job. Based on my experience the best internal people are the same people who you'll be putting through a management development program - the type where they get to know the entire business. They'll have the right attitude (can-do, hard workers, personable) and ideally are good with people / nice to work with.

Have the team as a whole report to you. It's a small team (3-4 devs + 1 internal full time).

Also make sure that the team are in control of their own destiny. You'll need backend/frontend/ops/dev-ops skills covered in that team, you don't want them crying for the sake of having a server made available for them. Give them an AWS / Azure account and let them work there.


+1 to this take. I think hiring a CTO at the start might lead to its own distinct challenges, especially if that's not something familiar. Hiring a small excellent team of builders could be an effective solution, especially folks with sufficient experience and very strong communication skills.


Agree with the general approach, whether the devs are contractors or employees. In my industry we might call this a Skunk Works project. Get a small, talented team and turn them loose on a focused problem. If they make fantastic progress, great, if not, at least it wasn't a huge expenditure.


I took over after such a situation at a company, them working for 5 years(!). Some of them were still around but over such a long span the team changed multiple times over.

In short, please no. No documentation, awkward separation of inhouse/external employees (regardless of team setup, you have different access to resources), there is just no creativity, everything is done loveless and cookie cutter.

If you plan long term, hire long term.


Genuine question: how do you suggest for that code to be maintained long-term if the original team was just freelancers?


Acknowledge and incent the exit plan from the beginning

Incrementally, it might make sense to hire an independent audit on occasion. This might be hiring a senior to jump into the codebase for a week or two to see if they can make sense of it or see any glaring red flags. The important part is them knowing this will take place and them not knowing exactly when or by whom.


The important part is them knowing this will take place and them not knowing exactly when or by whom.

I recommend caution with this kind of approach. Even if you're bringing in a team of freelancers instead of hiring employees trust is still an essential foundation for the relationship. Clients who play silly games tend to get fired abruptly because it creates a toxic working relationship that isn't good for anyone involved.

You should be able to have an open and ongoing conversation with your team of freelancers about the long-term intentions for the system they are building for you and they should transparently and proactively work towards your goals without being nannied. If that's not happening then you don't need some kind of surprise audit - you need to find different freelancers who are on the same wavelength as you.


Code is often written for an audience: yourself on a year, maybe a younger team member you have In mind. Knowing you won't be around to explain can help drive some decisions and write docs for the audience.


It’s can be less about code and more about supporting the evolution of the business process.


There is a whole class of hybrid incubator/vc firms in the US ("VC Studios") that have used this model and achieved success. Sometimes the model is inverted, in that the VC studio will build the MVP with their small, in-house engineering team before staffing the "real" company and eventually handing the codebase off to founding engineering team.


If you do go this freelancer route I would assume that there will be no code to maintain long-term. The freelancers should be building a prototype, not something intended to last decades.

Either the freelancers work out and you begin hiring a permanent team (hopefully converting some freelancers to full-time) who will promptly rewrite / revise the prototype or you will go back to paying for software. Either way the prototype code should die or be taken over.


Is it common to build a prototype to throw away, and then actually throw it away and build the "real" thing? I've never seen that, ever, in 20+ years of software work. The prototype ends up being the long-term production version, for all its faults and weaknesses.


I don't think so sadly, even an iron willed CTO will have to risk a lot of c-level trust to justify rewriting something "that works" (at first glance).


The artificial distinction between a prototype and a production system rarely survives reality in my experience. But that doesn't matter because the situation with long-term maintenance is not so different with freelancers doing the development to what you'd have to do with an in-house team.

It's rare for anyone to be around to look after the code they write for you forever. Ironically you might have more chance of a good long-term relationship with some of your freelancers - having a few good clients who come back to you from time to time is an excellent strategy as a freelancer.

So you always need the system and processes to be designed with future maintainability by other people in mind. Good developers will do that whether they're employed or freelance. Bad developers will mess it up either way too. Choose the people you work with wisely and try to make sure when you do bring in new people they have a good way to get up to speed so they can naturally take over as others leave. There's not much else you can really do.


Not my experience: freelancers have often built the initial versions of a product that have then become the permanent version. Even products that start as prototypes, if not total trash, often end up evolving into real software projects.

Why throw away software when you can iteratively improve and build on it? Unless the tech stack was wrong.


The same way as with permanent employees. Agree on technical standards and documentation policies from the start. Build a good engineering culture.


Consider where the company is right now - they're entirely reliant on a third party product that doesn't suit their needs. Every codebase is maintainable (to a certain extent), and the first step in getting a long term maintainable code base is... getting a code base.

Freelancers don't inherently write better or worse code than FTE's. Some of the most braindead, unreadable, undefendable code I've seen has been written by FTE's while contractors are leaving them in their dust.


Agree with this advice. Our consulting agency, also based in Europe, specializes in exactly this - bootstrapping software solutions for companies that lack the in-house experience to do so. After a successful launch our clients usually transition to hiring employees to take over our work - a transition we actively support. It works out quite well in our experience. (contact/website is in my profile if interested)


I do this kind of work in Europe as a freelancer since 25 years. I really enjoy it because technology is not an end in itself for me, but a tool to help companies to work better.


This is a great set of suggestions. I've been on just such teams (and led them as well) and the way it went for us was:

- small team hired (via a well regarded agency) - small team creates and releases initial, limited POC - company retains the freelance lead to staff up an in-house team - in-house team takes over and starts moving to a more complex phase 2 product - initial project ends up being maintained by an offshore team while in-house team goes gangbusters on everything else the company needs.

We had a freelance team for each major product (web, iOS native and Android native). In house teams existed for backend and devops but freelancers create all of the customer facing products for at least phase 1.

It was useful to have an architect level person involved at the start but once development was moving everyone had enough experience to make the need for a higher level tech person a non-issue (the freelancers ranged from senior dev level to architect level). It helped to have someone in-house overseeing things (timelines, scope, etc.), of course, but someone at the CTO level would have probably not moved the needle much in that first year of work.

The "move fast, break stuff" phase benefited from a small crew of experienced devs without too much bureaucracy while later phases needed more structure.


As a freelancer doing exactly this for nearly a decade now I wholeheartedly agree. Freelancers also tend to know other freelancers who are used to laying the tracks while the train is running, and can usually get a high quality team together real quickly. Downsides are that you don't really retain any of the expertise in-house, unless you also staff up internally and do a proper handover.


Did you find freelancers are motivated to really learn the business like an employee (hopefully) would? In my experience of having freelancers/contracters on the team they learn things in a very shallow way, just enough to get things working. They also aren't often motivated to make things easy to maintain because they know they won't be the ones maintaining it.


I think a key here is making sure those people talk to everyone who uses the current solution, not just the executives. They need to understand the actual use cases and pain points of the day to day, not just what the executives think it is.

Where I’m at we brought some software in-house and that part was skipped, or ignored. Years later, in talking with the lead on that project, he will admit that was a big miss. On the one had, to make change he didn’t want to be tied down and pushed around by past politics and issues, but on the other hand, some big fundamental problems were carried forward from the old solution to the new, and there was no way to really fix them after the fact, without effectively starting over.


This is good advice, and a way to test the feasibility of bringing the work in house.

Probably the best way to think about this whole project is not as a project, but as a capability to grow internally. As a big project, you'll get stuck at 80% and never deliver. If you start small and deliver continuously, you'll get stuck at reducing the pain by 80%, which is probably a huge win.

Software is grown. Start small and focus on delivering value quickly to build momentum and credibility, but make sure that the team lead knows that your vision is to eventually replace the other systems.


Im a product designer who loves these types of roles the most. Im biased obviously but having a designer work with the dev team speeds up results as you will have someone focused on identifying prioritizing and solving important problems for the team.


Great advice, perhaps I can share some personal experience.

I had a similar experience working with a large agricultural company, where we developed a track-and-trace system to manage their entire workflow. This system provided them with insights into all aspects of their processes. They gained full insight into their margins, mass-balance and quality control, from field to fork.

Our agreement included the agreement that we would own the system, with the option to eventually resell the system in the market, ensuring we could establish a company to support the system after development was completed. As you don't want to loose the knowledge after the system is finished and don't want to have a complete team of developers on your payroll.

We only developed the components that were crucial to the business process, relying on existing software packages, such as the accounting system, and ensured seamless integration between them.

One approach that worked really well for us was working on-site and providing support to the people using the system. This was invaluable in resolving issues that users were experiencing, and it also kept us focused on delivering quality—otherwise, we would be the ones responsible for providing support.

Please note that if you begin development, don’t expect the first version to be the final one. This was a major pitfall for us. The first version was good but not future-proof. Only after developing the second version, essentially a complete redesign and redeveloped from scratch, did we achieve the best solution for the business.

Ensure you maintain an open dialogue with the development team and allow for quick iterations. For us, a significant challenge was aligning expectations. Budgets were tight, and expectations were high, which created a high-pressure environment, that worked great for us and helped us focus. However sometimes this led to a lack of appreciation for our work, as expectations where not met. Keep in mind that developers think differently from business owners. We addressed this by having a technically proficient, data-savvy production manager in the company who understood most of our challenges and helped realign expectations.

Unfortunately for us, the company we built this system with didn’t respect our contract, preventing us from distributing the system and killing future opportunities. This resulted in legal action, which didn’t end well for us, as the company was much larger. We were naive in thinking we could make it work, assuming it would be in the best interest of both parties, but they didn't share the same intention.


If you take this route OP, I hope that you'll ensure the freelancers are in person and on site. It's much easier for them to build the right software if they can sit next to the users.


Good freelancers are expensive and don't stick around long-term.


Good freelancers are expensive because they know the value they provide. In this sort of situation you tend to get what you pay for.

I don't know why you think they won't stick around long-term. I've seen many freelancers maintain relationships with clients for a decade or more - not necessarily full-time as if they were employees of course but with a genuine connection and coming back to do more work with the same client from time to time. If you want to retain access to the knowledge and insights of your early developers but also want to bring things more in-house - often because you don't need an all-star team to do every little thing once the system is in production and hiring a more mixed team is sensible financially - then this kind of occasional recurring contact can work well for everyone.


That's fine; this would be an experiment, after all. If it goes well, those freelancers can be tasked to help hire a more permanent team, and/or be offered permanent positions, if they're interested.


It depends! I've probably stuck around longer term more often than not. You can also write contracts that enforce the term if you want. Agree on things like this up front.


I cant beleive people actually are telling the guy that letting some developers loose on this project is actually a good idea. Some issues with this approach

- How does this team with just a lead determine the business and domain rules? It sounds like the application is quite complex. Letting some freelancers go at it is the worst thing you can do for an application that is meant to handle hundreds of millions in revenue - Long term maintenance. Who is going to do the knowledge transfer and maintenance of this application as it grows and the freelancers leave? - Who is interfacing with the clients? With the existing software developers? Do you really think devs are going to be doing this?

So many things wrong with this approach. Please stop telling the guy to adopt this? And top sending him your emails when he is just asking for advice. Just because you want to jump onto this project as you see $$$ signs. Jesus.


As a developer who became this kind of a CTO a decade, maybe two before it became fashionable, I would have agreed with this in the past until I learned why otherwise with companies this size.

All the devs in this comments can do what I share below. 1000%. It’s a different way to make an impact and help make healthier spaces for technical teams to do what they want.

I’ll share one example. Clever architecture and leverage can beat most coding especially in the B2B space. I find I am fast at both architecting and uncovering useful system integration paths for the short and long term along with the flexibility in mind.

That being said, I have also seen a team of 100 devs flown in to write an ERP from scratch and it worked too because the process was fixed.

I won’t rule out a world beating team where 5-10 senior devs can beat a team of 50-100. I have got to be a part of those kinds of teams and also lead them. The caveat is being able to deliver world beating stuff is different than aspiring to it as well. It’s just not always sustainable way to live.

Since A company usually sells to companies the same size or larger. Anyone who comes from scratch can have their goose cooked pretty quick when a new client demand a different level of scrutiny in systems and data if coding from scratch.

Having deep enough experience to poke my head out in this thread both on my own as IC leading the charge, or or taking in my team, the orchestration of internal and third party vendors and resources is a big part of this. I deeply believe in external vendors operating in a client side platform I help implement and leave them with training that works.

A technically functional CTO who is still technical en putty to simplify and leverage to help deliver impact helps bring in different kinds of architectural and framework approaches.

I loving call it what management consultants talk about it don’t do. I’ve made learning and implementing that my craft to leverage solutions for anyone I put my time towards. It’s a life changer. Everyone wants the kinds of devs on YC to help their companies if they can learn a little bit of business.

It works well enough that I don’t need to pursue a public profile (although that is not changing), and warm introductions are a reality.

I share this because it’s possible for anyone who wants it instead of downplaying it. I help clear the path for the doers and builders, as one.

You have a fair indirect point that there’s a lot of different kinds of CTOs too.

If a business wants steady operation while switching over it will ultimately place a heavier loads on their teams.

If a business wants capacity to operate more smoothly to either grow capacity or increase flexibility for other things with their existing workforce.

This kind of thing may not always be built to success with the number of surprises and landmines discovered along the way.

Part of a transformation can become agile, parts of it water fall, all while holding the business and staff increasingly hostage while deciding to do a big bang switch over or daring to run in parallel.

Lots of people side things come up as well when changes happens to them instead of with them. It’s not uncommon for subject matter experts choose not to share information what itself can take some time.


OMG. GPT? Claude?


Not even sure they can come up with a word soup that thick.


Nope, those usually get basic grammar right.


Nope, just me, I promise.

It could have been shorter as it's not my target audience, not really able to edit it now.


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.


This is my experience it's almost always better to continue working with the existing solution as you slowly replace it's features with your own until you no longer need it. The replace everything at once approached is fraught with risk.


Strangler Fig pattern works really well: https://martinfowler.com/bliki/StranglerFigApplication.html

You split out segments of the old application and rewrite it, slowly moving traffic over - eventually slowly strangling the old application and replacing it with new parts.


It's a good pattern in theory, and the main route I'd personally choose most of the time.

However in practice, depending on the kind of application, it can be really hard to do those gradual rewrites in practice, especially if you want to modernize by introducing new programming languages.

E.g. for a legacy project on the JVM, how do you gradually shift things over to Kotlin? Or for the same project how do you go from Java to Rust? Of course you can also do that by splitting things out into REST services, but now you have to handle reliability issues of your transport layer and have to figure out how to pass large data through it and/or how to handle a barage of calls that were previously swift in-memory function calls. So in practice there are a boatload of potential challenges when doing gradual rewrites, and in my experience very few people have the expertise to pull them off in practice.


On the case of the OP, with a database, different pieces of software interact over the database. It's the simplest case.


Ive never seen it work in practice. Every time I see it end up with Appv1, Appv2, Appv3 all running at the same time because the new systems cant move quick enough to add new features so they get added to the older versions. But the newer systems offer unique things the older didnt. So they all coexist and never die.


There's something wrong with your experience, because the entire point of making a new system is that it will eventually move faster than the old one.

Maybe your strangling software is still too ambitious.


That sounds like you're trying to rewrite the whole app, NEVER do that[0].

You shouldn't end up with appv1, v2, v3.

You should have appv1 along with appv1-foobarmeasurement-v2 running. Then you slowly move traffic to v2 of foobarmeasurement until it can handle 100% of the load and has all the features - then you remove that feature from appv1 completely.

Then you GOTO 10 and pick a new feature to slowly strangle.

[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...


My point is that if the rewrite is not able to be classified as a refactor, it wont work. It has to be entirely invisible to the user (and product side of the org). Otherwise, it is never going to be completed.


That's literally the point of the strangler fig pattern :)

The difference between a rewrite and refactor is a bit vague and nor easy to determine when talking theoretically.


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.


Second this. Cross functional knowledge is the secret sauce of in-house designed software.

Nothing off the shelf does that.

Integration is where cross departmental solutions live and that’s an underrated nightmare


Third this. If the software team (at least the lead) does not know the business requirements, you are not doing in-house development. Otherwise, it is just equivalent to off shore development, that happens to sit in the same building as yourself.


Fourth this.

Other than making sure you find the right person/people from a raw skills+personality/capability perspective, it's the next most critical item.


I'm not sure they necessarily need to know it cold at the start, but they do need to have access to someone who knows the business cold, and they need to care a lot and be willing to dive into the business details.


> but they do need to have access to someone who knows the business cold

Yes. Very close access, to the point where that someone will spend almost as much time working on the software as the software developer.


For sure. Ideally you should be able to talk with them at depth about schema design.


Understanding the domain is mission critical for projects. As the lead/architect/PO/... You need to balance what stakeholder say and what the really need. You can not get that, if you do not know the domain.

This is all DDD play book.


However the problem domain that this fellow has 'Logistics' Can be a big scape, but more importantly the nature of the logistics is important whereas "shipping logistics for a parcel" is a hell of a lot different than logistics with specialized compliance, handling, security, discretion, coordination-of-other-entities, does.

It would be interesting to know what niche is ~$300-400 million ARR thats being handled by 3rd party contracted infra?

---

However, having worked as a high-paid consultant on high ticket/visibility/risk projects -- HN is giving some great advice. (hire and empower a great lead - allow a new approach. Ivolve your staff and have what you need built.

Continue to work with the external that you have, and as a requirement (where appropriate - have them respond to your lead on any questions your lead comes up with)


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 have a fully staffed team it’s not 5m a year. For a company twice his size.

These are very generous consultant pitch #s not reality. We doubled running 1-$200k/guy … 2x full stack devs (me) 2x data guys 1x MSP for IT.

That team was awesome and did serious buzz saw damage because we shipped solutions that made the company better every day.

Didn’t have to be huge. Just help someone do something better.


> I have a fully staffed team it’s not 5m a year. For a company twice his size.

I don't think the numbers OP chose really matter. The point is to do the exercise. Try and work out some numbers on how much the current software is costing, how much room there is for improvement and how much investment it will take to get there. Add a big margin to account for all the uncertainty with building something out.

If the numbers still work out significantly in favour of writing your own software then it may be a project worth considering.


What does on-call look like for you?


Most business do not require on call for their internal tools


Depending on the area of logistics OP is in, it's not unlikely that he'd need on-call engineers for his logistics management system. Blockages in supply chain can be extremely expensive.


At my company, downtime is approximately $50k/hr in a 24/7 environment for manufacturing and logistics. We're ALL on call.


It was brutal, but the mentality was - it's brutal now but you have the power to fix it, so engineering hours went into fixing broken windows.

That adopted mentality pays off tech debt fast.


Sure; but eventually you've got a bus number problem and a "I want to be able to take a vacation and I want my coworkers to be able to take a vacation" problem, and that requires more people.

At least that's how I feel about team sizes.


With a company OP's size, I'd definitely look at it from this perspective.

Funding (and related longevity) are key drivers of technical debt. If a team has to constantly pivot projects to politically justify their existence, bad technical things happen.

So figure out a budget model that works, is sustainable, is justified on ROI (as logistics dev will be compared to capex alternative investments).

As a "halfway" solution, you could find 1-2 senior inhouse architect type people (ideally, who have reasons to stick around like quality of life) and pair them with project-based freelance/outsourced development teams. (Hard to find good small dev firms, but they exist)

That way, if dev screws up the project because they're incompetent, you have more options. But you retain the core institutional knowledge and some dev ability inhouse.

And it maximizes budget flexibility and gives you time to find the right people for the inhouse team.

I would caution... the goal of this arrangement should always be to grow the inhouse team until it's big enough to ship projects on its own.

But it's easier to slowly grow a good team than to hire one all at once.


$5M/year? In the US maybe.

A team of 5 senior freelancers in Europe will cost about 150-200k per person.


For compensation. The carrying cost of an employee is usually twice their total compensation.


He said freelancers.

Median compensation for senior engineers in Europe is nowhere near 150k. Even in Switzerland.


Any sensible freelancer will have an hourly rate nearly double that of a fulltime employee for obvious reasons. Please stop telling him just to hire a bunch of dev freelancers. Projects like this require UX and business domain understanding. Devs are not going to be doing that. This thread is full of amateurs parading as experienced CTOs.


Freelancers.


Any sensible freelancer will have an hourly rate nearly double that of a fulltime employee for obvious reasons. Please stop telling him just to hire a bunch of dev freelancers. Projects like this require UX and business domain understanding. Devs are not going to be doing that. This thread is full of amateurs parading as experienced CTOs.


My freelancer estimate is based on 100/hour, that’s actually quite high for Europe


Employer tax contributions

Office space

Hardware and software, SaaS licensing, cloud costs, etc.

Hiring costs (recruitment, recruiters, time lost in selection and hiring)

Secondary cost to rest of the business to change processes, retrain, integrate, help the dev team understand requirements, effectively build and iterate, etc.

Quite possibly a bunch of compliance, security, audit, pen testing, and other regulatory costs depending on the demands their clients have, etc.

Running a team != hiring a bunch of freelancers as a one-off.


Do you know what a freelancer is?

You don’t make tax contributions for them. They bring their own hardware and usually software unless otherwise agreed.

The rest of the stuff is just a laundry list you made up to try and blow costs way past what they actually could be if you’re prudent. Come on


Stop giving the guy horrible advice. IF you think throwing some freelance devs with no business support/product/UX support is going to help him, you are so mistaken. Trying to rebuild an existing complex software system that handles hundreds of millions in revenue is not going to be an easy task. You are going to put the man into a corner and ruin him. Jesus.


He has his own brain, some advice based on actual experience is not going to ruin him. Please don’t be so dramatic


The point is still valid even at that price.


seems like a good ballpark number with some leeway for unexpected things


To me this sounds like an ad.


The original question was the perfect setup for an ad, more or less asking “have you ever done this before?”, “What should I be concerned about?”, and “How do I even start this?”. This response may seem ads-y, but it also answers the questions and provides interesting original thoughts (e.g., to start with a cost/benefit analysis). Even if it’s an ad, imo it’s a useful one


I saw a presentation on e-commerce back in the 90s, and this was an astroturfing strategy that was pitched even back then. Don't post a thread about your company, post a question on one account, and then on another account post that your company is the answer. Really it's a strategy that's been around for a lot longer than the internet.

Not saying that this is astroturfing, just that this format has been around forever.


Ya, if it’s two accounts controlled by the same person I agree it’s disingenuous. I think (hope?) that’s not the case here though


For the record, I have no connection to the original poster, and I’m not in the business of doing this anymore. I wanted to respond because I didn’t see any other threads pushing the OP to think about the basic economics and do some basic fermi estimations of the business case.


Yeah, I mean the easy to spot ones are usually the first ever post on a few days old account. Actually…


Yeah, ad like, but he is not wrong.

$5m is a solid number to ballpark any new initiative from scratch.


I get that but the suggestion would work even without dropping any company name.


"Pivotal Labs". That's the first issue with the basic economics.


> Building and running your own software team is probably around $5M/year

Do people just pull random numbers out of their ass with no actual experience? 99% of developers do not live in Silicon Valley on 1m salaries.


> Do people just pull random numbers out of their ass with no actual experience?

That’s a weird question to ask someone who stated their relevant experience in the first sentence of their comment. I just looked him up on LinkedIn and it checks out, you can do the same.

If you have substantive objections to what he wrote, perhaps it’s better to state them explicitly? You seem to say that the figure he suggested is based on developers being based in a very expensive location, and therefore not generalizable.

What numbers have you come up with that contradict his?


His prices are so wild that I would be surprised if anyone agrees with him.


~10 FTEs, US, 75% percentile salaries, fully loaded, 1.5-3M. Figure that team salaries is probably about 50% of the total software cost (hosting, support, tooling, on call, management overhead, recruiting, training etc)$3-$5M. Rounded to the nearest 0.5 for convenience. We got about ~4 bits of data from the OP, so I didn’t put too much work into making my estimate precise. I prefer to get the ‘software is fucking expensive and terrible’ experience on the front end and go from there, if people are still into it.


Lol

Avg salary in the U.S. is 105k. Better to go on average as you’re not going to high 10 seniors. That would be dumb. Hell getting 10 for an in house app is just as dumb. Hosting? On an in house app. If they spend more than 100k in the first year that’s dumb too. Support for an in house app? That’s part of the dev team. Tooling? For what? Some IDEs and few dev tools like slack etc. Let’s bundle it with their equipment. 100k for some computers and software.

I don’t understand how HN has to always look at the extreme pessimistic side to everything. The type of people here are the ones who go into a business and spend insane amounts of money building junk software wanting to pull in 5 different databases, 3 caches, elastic search and host their 10 years on 25 “microservices” hosted in docker that falls over multiple times a day when 95% of the software people on HN build could be hosted on a couple of load balancer servers with a single db instance. Spend way too much money trying to solve non existent problems.


Cost is not just salary. To begin with, health insurance and other benefits. And they'll need dev environments, they may need additional cloud resources depending on how the project goes, and there will be additional overhead when the team interacts with other departments.


OP is in Europe - no idea in which country but just as an anecdotal example, building a world-class dev team in Estonia is ~100k per senior engineer (total cost, including health insurance etc). Of course there are auxiliary costs in addition to the team itself but not anywhere close to 4.5 mil/year for a 5 person team.

And to be honest, I'm not convinced a moderately complex in-house crud app would really require 5 senior developers but impossible to have a strong opinion on that based on the details that OP provided. It might be a one man job, it might take a team of 10..


I agree that the cost seems overblown but having worked on several very small teams I'd be hesitant to start anything new with fewer than four people. It is possible to get things done with a one or two person team, it's just a lot harder because the moment someone gets sick or goes on holiday everything grinds to a halt. If what the team is working on is on the critical path for doing business it effectively becomes impossible for anyone to have a real holiday, if something breaks then they're going to get roped in to fix it regardless.

If you have a four person team you drastically reduce the bus factor. It also means you can have people routinely pairing on things which can be hugely impactful when working on new software in a new domain like this.


So you’ve barely added anything to the cost on top of salary. Depending on where you live in the world there is no extra costs on insurance or other benefits. Cloud resources on a brand new app in development? Let’s be generous and say 100k/yr for the first year. (If they were using more than that I would fire them as they clearly have no idea what they are doing)

But let’s say they have a 5 man team for in-house development. 1.5m/yr would be a stretch to spend.


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.


It's also worth mentioning that the economics of software may be very painful. Right now, the cost of building all that software is being shared across all the customers of this company. OP is proposing his/her company bears the entirety of it.

Assume you can hire good sr engineers. This project badly needs some scoping to figure out how much eng time and how much risk it will take to replace what exists.

I've worked on software for small-run scientific instruments: think 200 to 400 sold. The cost of software can be 30% of the total cost of the projects. It may well be that, given what customers are willing to pay, there isn't enough money in this to build good software.

And for OP, for core software, if customers interact with it as well, you likely need follow-the-sun ops too.


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

I'm not in the market, but FYI, the tone of your post wouldn't make me want to buy your stuff. You sound too eager to lecture your customers instead of being eager to learn from them.


I didn't get that from the tone. I inferred this person was trying to convey the perceived importance of some critical things and gave good examples with clear knowledge of the problem domain in a limited space. IOW, I thought it was very well articulated and helpful, FWIW.


It's fine to convey the importance of these things. It's another thing to do it with an implied assumption that OP doesn't know better themselves, which context doesn't really give a lot of clues about. Obviously in the end it's a personal thing anyways.


Sometimes when you really do have something less noticeable to offer, you have to toot your own horn a bit.

Not everyone is going to like the sound of it no matter how well-played.


Fair enough. To clarify, my point was not necessarily “I know better”, but that it is incredibly difficult to get a broad view of the market from a single perspective. This market is by definition a chain of steps with parties that may be antagonistic. It is atypical in that way, and writing software in-house may be more difficult in this sector than in others because of it.

While writing software in-house gives you software better tailored to your exact situation it is at the cost of losing the overview of the business and the perspective of the parties you interact with. Whether that trade-off is worth it I’m probably pretty biased on, so take my stance with a grain of salt, but imo the business is intrinsically relatively ill suited for in-house dev considering the high degree of collab with other parties.

Apologies if it came off as arrogance, that was not what I was going for.


> Apologies if it came off as arrogance, that was not what I was going for.

No need to apologize, just wanted to make you aware of how it came off to me.

> my point was not necessarily “I know better”, but that it is incredibly difficult to get a broad view of the market from a single perspective. This market is by definition a chain of steps with parties that may be antagonistic. It is atypical in that way

Maybe? That description sounds like it could probably be applied to any highly fragmented vertical though...

> imo the business is intrinsically relatively ill suited for in-house dev considering the high degree of collab with other parties.

I think this hits a reasonable point — if most of the development is related to internal operations, it could be a different calculus than if it is mostly related to interchange with other parties, which implies knowing enough about their business to make sense to them.

Then again, if all you have to interchange with other parties is a choice of third-rate bottom-of-the-barrel software providers anyways, I think it can still be reasonable to switch to in-house dev.


I think he’s toeing the line of “listen build it yourself but you’re missing a decade of expertise I can add to your stack tomorrow”

That said, my feeling is the guy doesn’t have a prebuilt fit for his company / he’s already shopped extensively.


A counterpoint: I didn’t detect that from the post you’re replying to at all.


> You sound too eager to lecture your customers instead of being eager to learn from them.

One does not necessarily exclude the other, in my experience. Personally I love being told when I’m wrong, and I think the OP was actually fishing for this kind of feedback.


My cheesy tagline for this is “The customer is always right about their problems, rarely about the solution to it”. They know their business inside and out, and I’m not about to tell them otherwise. Metaphorically: if they need to cross a river, that doesn’t make them bridge engineers. But boy will they tell me if the bridge is in the wrong place.


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.


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

You seem to be making that assertion with 0 evidence. I've seen plenty of businesses fall behind because their tech is old and becomes an anchor, and I've seen businesses whose primary competitive advantage is their tech.


I've also seen businesses fall behind because they were chasing the latest tech fads even though those did nothing for their business.


I totally agree, but OP's post doesn't seem to be of that type - it's not like he's chasing some nebulous tech buzzword ("Sprinkle in some blockchain!", "Be sure to utilize AI!"), but he has a good idea of the specific pain points, at least in broad strokes.

At the very least, similar to other comments about hiring a small group of senior freelancers, I think to start it makes sense to find a very good contract product manager who can map out, very explicitly, exactly what the pain points are and what a software solution would look like to fix them, stack ranked by "biggest bang for the buck" (i.e. most positive impact to revenue or reduced cost, divided by rough estimate of size of the fix). At that point the total investment would be very low, and then they can make the call of whether the risk of doing something not using COTS tools makes sense.


In fairness, they aren't making that assertion, they are asking for OP to consider and pressure test that assertion


I agree with your general thoughts. I've been designing+developing+managing ERP/SupplyChain/WMS/Shipping systems+projects for a loooong time and the chance that a person with no background in it will build the right small team to pull this off correctly on the budget any small to medium size company has, while running their business, is generally low.

> You might get around the drudge work of automating some of the toil work by hiring freelancers/consultants.

Finding the right people with the right experience and right aptitude is tough (for any role). Whether internal or external resources, my rule of thumb is that maybe 20% are fully capable, 50% are reasonably valuable to some degree, 20% have limited value and 10% are just not in the right role at all.

Whether trying to find a PM or solution architect or technical lead or dev, these same percentages apply. You have to really have experience to have a reasonable shot at finding that 20% person for your most critical position, the technical lead (whatever you call them in your org or project).

If you look at all of the talent out there today, you will see a zillion candidates with extensive experience moving workloads onto the cloud etc. etc., which is a good and valuable set of skills. But those skills and similar tech skills are not what you need to build your core systems.

You need people with the following:

1-Domain experience (you don't want people that have been designing+building streaming video systems their entire career)

2-Experience extracting business requirements, and organizing and managing that information. This is an art that takes a long time to acquire.

The business will tell you they need an alert when inventory is too low, but the real question is why is the inventory low? You need to follow the chain back to the planning system where they are excluding transactions they should not be excluding.

3-Experience creating solutions (functional and technical) that meet the business requirements and other domain requirements not explicitly stated by the business as well as a reasonably pragmatic design that accounts for the various gotchas that a good designer will account for (otherwise you will play a painful game of whack a mole of small/medium issues for years and years never realizing it's because the design was not good enough)


Responding to my own post to respond to one of OP's questions:

> Alternative solutions we should explore.

When I am working with a vendor's app with critical gaps and I know the vendor will not solve the problem (because they don't have the talent or it's functionality that doesn't apply broadly to their market), then I try to work with them to just add a hook (on our dime) to link to our external custom functionality.

The easier you can make it on the vendor the more likely they will incorporate it. Typically I will design the interface of info in a way to make their lives as easy as possible to incorporate the results in to their systems.

Some examples where I used this very successfully:

1-Cubing/Cartonization for outbound orders - we have many unique requirements from our customers as well as from our internal business channels. Vendor calls our system, passes relevant info, we produce the result and return it, they do all of their normal app updates as if they were the ones that produced the result.

2-Picking/batching optimization - same issue, nobody has any out of the box optimization that supports all of our requirements and dependencies - same flow, we perform our own prioritization+optimization and return the results, they update their app/db.

3-Generalized Rules engine - most workflows are controlled with normal ERP style configurations in the app, but some require much more flexible logic, for those we had the vendor insert a call to our rules engine, they pass in key relevant data, we crunch it, we return the result, they update their app/db.

An example usage of this one is in our order routing across different DC's. The business can target all kinds of special conditions to support their business requirements (e.g. product X should ship from DC Y for special customers A, B and C due to some special processing in that facility).

4-Generalized external function - in one system we had the vendor add the capability to call an external function at any point in the workflow (they have configurable processes where multiple steps can be linked together). This one one is not designed to return anything to the calling system other than success or failure, it's more about inserting external actions within the workflow (e.g. external action might be a function in a separate system that is fully self-contained).

These are just a few examples but we've made use of it extensively. I think it's a really effective compromise when trying to work around vendors app limitations.


Agree with pretty much everything you said. It's the devil you know vs. creating a whole new devil you don't know.

I wonder if it's viable for OP's company to buy the company they depend on for this software, and then staff it up and get the bugs fixed. That way they retain the domain knowledge from this company, and they get everything they want done to be prioritized. This would also likely prevent any future competition if they own the company that's making this one-of-a-kind software.


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.


Yes, and also when you hire software developers you want someone who understands that they are running internal tools which is COMPLETELY different from building consumer apps. Simplicity is key. Keep the team small and lean.

Also the build vs buy decision has to be made with every feature. If its not your competitive advantage just buy it. Dont make a new database, just use postgres etc.

There are a different set of developers that can navigate through this than the ones who will reinvent the wheel if they can.


Yes, those are great points. You'd really want a team of devs who have worked in the enterprise IT world, as that is the business environment we're talking about here. You'd want a group who will get everything working, coding only what is needed, and integrating other solutions when the feature is a commodity.

Code is an important tool, and also a liability. Hire devs that understand that.


This is a huge thing.

Way too many internal teams build their tooling "too well", to a point where it could be a separate startup product in itself with a tiny amount of extra work.

Like game companies writing their own engine and ending up as a game engine company eventually =)


>Like game companies writing their own engine and ending up as a game engine company eventually =)

This used to be standard.

PS1 and PS2 was coded in Assembly basically. No OS. All games had "drivers" in them. There was only renderware as a ready-made engine. Every Final Fantasy game was a new engine, FFX and FFXII are 2 very different engines. Bespoke only for that game. And beautiful. Same with RE4. Same with God of War 1 and 2. Unbelievable. Same with xbox and gamecube. Even in the 365 era, the Halo games were its own engine.

Look back at the dark Unreal 3 period 2006-2010. Most UE3 games looked like shit. A brown bloomy mess.


Software developers are the blacksmiths of this century.


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.


I think there's a big risk there of hiring a "CTO" who hasn't coded in 10 years and it's just a paper pusher. Ask to see the GitHub.


This will filter out 90% of candidates, but yes. Problem though is you need another turtle layer to evaluate the git commits. They might have been just changing CSS.


Maybe chatgpt can assess!


>hire somebody rather senior to be a "CTO"

The right person fulfilling that kind of role can make all the difference.

When there were no comments I wrote a little message which instinctively favors focused CTO effort myself:

At the one extreme you write all new code.

At the other you have a turnkey system using code that is already written, perhaps a system brought together by combining various task-specific apps.

Or anything in between.

You still may never be able to hammer everything to perfection.

Either way as much code as possible should be built against a completely non-moving target, with a core that ideally meets a stable unchanging foundational requirement, the objective here is to have a digital enhancement/replacement of a highly-performant optimized manual workflow, whatever can go forward with no further updates or maintenance. Quite simply this makes for the best long-term investment if the code just plain lasts longer after it's paid for.

The moving-target stuff or component (which might include government regulations) might be better off "leased" since it might never be a very good investment anyway, especially not long-term.

Either way a CTO or equivalent should be the ultimate expert on how this gets done in your specific company, having more than just domain expertise, but specific-company expertise on top of that. The deeper and longer-term familiarity the better, must be an absolute master of the detailed workflow before any type of irreversible commitment should be made. The level of trust needs to be up to the highest integrity of executives, there can not be a doubt that decisions are in the best interest of the company.

You may already be a true master of the workflow and with enough mastery be more suitable for directing a team that could craft the most ideal solution, as long as you actually know how to program computers. You wouldn't really need to be up-to-date on any specific languages that are popular now.

Someone needs to fill or acknowledge a CTO role, pick up the ball single-handedly and don't make another move without making sure where the correct goalpost is. A little lonely indecision when you first pick up the ball is worth it if a CTO can then lead a team most directly to the desired end zone. Building a team from the ground up if necessary. It may not be completely necessary, but when that's not off the table, it's a whole new ball game anyway. More options, but probably gives rise to additional levels of uncertainty that need to be resolved.


Right, and notably you want the CTO whether or not the answer is:

   * build a team in house
   * bring in some contractors
   * make the most of the existing vendor through API integrations
   * switch to a different vendor
   * some combination of the above
because somebody with the right skills, attitude and integrity has to be in charge of it.


Yes the right person should be able to handle any or all of it.

If you don't do it right it won't necessarily be more suitable than it already is, and when that's the stakes there's got to be a responsible individual who can put in full-time effort however much it takes, with the resources appropriately allocated to back it up. The same CTO needs to be capable of single-handedly being the only "tech" employee, served by their own carefully orchestrated select contractors, or at the other extreme capable of building an in-house team to make things better from the ground up if more beneficial.

One person will have to make sure it comes out better than it is no matter what, or it's less likely to come true.

Regardless, it can be like servicing airplane engines in flight, so that's another outstanding skill to keep an eye out for.


there's another option: buy the vendor. in the absence of details, it's unclear if this is even feasible, but the vendor already has the software they need, it just needs additional work done on it. so instead of reinventing the wheel, buying the vendor allows you to fix the existing one.


I was wondering if a starting a new company was a better way.

It has one customer (initially).

If it doesn’t pan out you can drop that shitty vendor.


Or just the principal person behind the product. Careful approach and they may jump ship.


Your and Fuzzfactor’s points are very well noted. To do this well we’d need someone who understands the domain/industry/business and who is able to set a coherent strategy. The rest follows from there.


Hi, are you looking for support to build a team out? Thank you.


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


100% this. This would be a dream job for the right candidate, too.


This summarizes my career nicely.

Great approach advice IMO.


This summarizes my career nicely.

Great advice IMO.


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


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

That’s taking the second step before the first. If this is going to work at all, first try to build a solution that works for you. Once you have that, then there may be a chance that others will find it useful as well, but it is a whole lot of additional work to turn an in-house solution into a proper product, and your in-house needs are unlikely to translate 1:1 to other companies, and vice versa.


+1. Last startup I worked at basically tore itself apart because certain leaders fantasized about spinning of "AWS for X" before we had even met our own needs.


On this point it’s worth noting that internal users are very very different from external users too.

An internal user that can wander over to Bob and say hey, this thing isn’t working quite right, I’ll grab a coffee with you and we can talk through it, is very different from a paying corporate who will not tolerate service falling below a certain standard. I joined a company where they were trying to transition an internal piece of condition monitoring software to be a SaaS app and it went really badly wrong, the sales people seemed to assume it was ready for this but it just wasn’t and needed a huge amount of hardening and security work, not to mention features to make it easier to use.


Same here, C-staff tried to start a cloud service company "but X".

There was no market for it, it was too expensive, too unwieldy and too nonstandard.

AWS could do 90% of what the custom cloud product could and the last 10% was regulatory stuff, not technical.


You’re both correct. Absolutely you need to start small and build confidence over time. However, it’s important to know early if you plan to eventually make the product a profit center. You can establish legal and technical foundations that will make your life much easier down the road.

Another option is to consider building in the open. If the technology is not a differentiator in your industry, then maybe you build it open source under GPL. That way you can build a consortium of similar firms to build a genuine alternative to the status quo while preventing lockout.

You don’t have to decide about proprietary vs open source release now… but you should consider taking steps to preserve those options down the line.


People often ask me about potentially selling software I’ve built for our company (a similar situation to OP), but one important factor to remember is that part of what makes the software great for us is its focus. As soon as you start selling it, you have to add feature after feature to meet the various customer needs, which then makes it worse for us. This may be a worthwhile trade off if the potential revenue is large enough, but it’s important to consider in advance.


Remember that writing bespoke internal software and general-purpose commercial software are very different things with very different budgets, and you will need support staff. Do your research and talk with someone who understands commercial software before planning any kind of spin off. These are two very different goals, even if one would hypothetically fulfil the other.


Yes. Clear goals is the big one. There is a lot to gain in our industry, in terms of technology. We’ve seen a lot of disruption plays coming from VC backed tech companies but I hope coming at it from the ‘other’ side, the industry side, can create great value too.


Love your username - I had a friend who used to live in one of those :)

Sorry I missed this thread, I think it was meant for me.

I currently work for a small logistics company as a senior engineer. I am pretty happy and not looking for work (like many of the comments here), but I am happy to converse or schedule a call sometime if you're interested to discuss. 0x03e14@protonmail.ch.

Other commenters had I think the correct answer - you just need ONE REALLY GOOD IT co-founder or vice president to help coordinate that, who can both leverage outsourced solutions but also build things on their own, and most importantly who truly understands and cares about the logistics and cost savings.

I see a lot of dysfunctional and large tech teams building out over-complicated solutions with zero industry awareness, instead of lean solutions.

Did you see this article [1] here from a couple months ago about Temu's semi-managed delivery model? I was pleasantly surprised to see logistics on YC. We don't talk about it enough but it's the backbone of global economy.

Best of luck! Let us know what you decide to do and shoot me an email if you want to connect.

[1] https://news.ycombinator.com/item?id=40497472 - Temu's semi-managed model could change everything


IMO spinning off comes with it's own complexities in terms of product - If you are writing it for 'in house' you are writing bespoke software to your own requirements, but there are players out there in the logistics software market (across most verticals) that are making products designed to support different configurations / businesses / processes by default (i.e. the business logic isn't as rigid as you would build it for your own in-house software, and you build the software differently if you are designing it to be used as configured software rather than just to support your own requirements).

Would be interested to know the industry and any specific requirements that are very unique!


Definitely could attract talent, not only is stable job but it is green fields with flexibility to choose your own technologies and build something ground up.

Most engineers don't love joining a giant co. and using tech we are not fond of.


Don’t build it to sell - explicitly. Build it to solve your business problem and tell the guy building it “after we’ve separated ourselves from our competitors and we’ll either declare our company a software company that does logistics, or we’ll set an environment for you to pitch the sale of the software to competitors”

A startup mindset is importantly for the first hires, but selling software is an aspiration not a requirement.

That aspiration can be distracting from simpler business problem solving solutions too, so be clear “new codebase” when we are ready to sell…

Shortcuts for us, no shortcuts on the software resell company.


Also logistics sort of famously has interesting computer science problems to solve.


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


Nailed it.

Pay them well, treat them well, and let them do their jobs. If a company could only do 2 of those 3 for me, my expectations for those 2 would be through the roof:

- Pay sucks? I need to feel like the most wanted person in the world and have free rein.

- Management sucks? I better be getting rich from this, and I’m working on what I want to work on.

- I’m going to be micromanaged? Hey, let’s talk about contractor pay, and the CEO needs to name a kid after me.

If a company does all 3 things reasonably well, I’m your guy. 2 of 3, they’ll need to make up for the missing bit. Only have 1 of the 3? No way.

(Miss me with any “you sound like a prima donna” nonsense. I don’t have crazy high expectations of those things. I do have a reasonable baseline though. I don’t work for free, I don’t work for jerks, and I don’t work where I can’t have freedom to do my best job for the person paying me.)


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.


> You could probably find someone pretty good willing to build it in Elixir without much trouble.

While I agree with that assessment, you’ll also spend the rest of your days cursing yourself if they were to leave.


It's not hard to learn and my current Fortune 100 has had zero trouble hiring for it.


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.


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

You can also do shim servers to translate between protocols - a long time ago, I had to interface with a Rails app (by another team, so I couldn't modify it) with an Emerson (the industrial giant) SOAP API, and what turned out to be effective was a Sinatra shim server that only converted JSON to SOAP. Now I could plug the two together without worry.

So - I'm guessing you could have a Java Smooks applet that translates from a JSON API to the EDIFACT protocol, and then you can write your main app in anything you want.

PS - Seconding the "don't go microservices", even though I'm advocating for one here - IMO, you only want microservices if they can be fully defined, independent products; a JSON/EDIFACT translation service would probably qualify.


I think in this case a well defined modular monolith would be a excellent starting point, especially if you need to (1) build from zero and (2) hit the ground running with a small team (without all the extra things you need to pay attention to and create solutions for when going the microservices route).

The great thing about the modular monolith is that it gives you a fantastic foundation to grow: You can still invest in multiple teams each handling a certain part of your problem domain (due to the modularity); and because it is modular you could easily break it apart, and evolve it, into a microservices architecture if and when there comes a time you need to do so (due to extensive problems getting code shipped, or difficulties concerning NFRs defined for the architecture, for example scaling issues in production).


IDK. I don't have much experience with modular monoliths. What experience I do have says they'll just become regular old monoliths...

...unless you still do the same thing I'm advocating for when considering microservices: defining, and treating, each chunk as a discrete product.

If you can do that, great! MM or MS will both work, and you can probably decide between them based on the other factors you're dealing with.

If you can't, I would expect you to end up with a regular old monolith, so you might as well lean into it.


I'm not familiar with EDIFACT, but just from the context I'd assume that

a) there is something on the other end that expects the data to be exactly in a specific format, which may not be documented correctly or in a language your devs can read,

b) the consequences of not getting it 100% right are expensive,

c) there are a lot of these "somethings", each potentially requiring their own format/special quirks for which the provider may have already built workarounds.

Is that the case? If so, trying to build anything yourself will be a nightmare, and my first approach would be to find something that handles this part and beat my data into it, even if it means using some fully-featured software package just for this feature.


EDIFACT is designed to fix _exactly_ this. It does not only specify the _what_ but also the _how_

Wikipedia provides a pretty good explanation: https://en.wikipedia.org/wiki/EDIFACT

The beauty of EDIFACT by the way, is that with enough time and effort it can get parsed and validated using any text processing tool at your disposal because everything is _rigorously_ specified by the UN.

For example I once had to do it with a set of specs, standard Linux text processing tools and a sprinkle of shell scripting for a school assignment.


I would have assumed that it's meant to fix it, but I wouldn't expect it to actually have fixed it.

Has it? If so, that's a pretty remarkable feat, and I'd love to be wrong about this one. And are the open source libraries good enough at it?


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)


There's something about creating software that lasts for decades and is actually used by actual people every day.


>I wouldn't trade a "cool project" for any of that.

something-something "Life is short to deal with problems we didn't have to have"


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.


Lots of good comments in this thread, but I think this is a critical one. It seems you've (OP) almost already decided, but you're unsure about details such as how to retain software developers. Before you go into such details you need to be sure you want to make this move. This must be a strategic move, meaning a long term move where you're sure you're gaining a strategic competitive advantage through this being a core competence (in the academic/theoretical strategic sense). There are very few quick fixes in IT. Most projects are grossly underestimated - in particularly if you lack the competence in-house today (easily 10-100x).

At it's core, it should be a decision that is not only about control over the software, it's about bringing the knowledge about the processes and technical complexities of doing your business in-house. You might think you know all about it, but most likely you don't (otherwise most IT projects wouldn't fail). The big cost in IT is specifying exactly how things should work (that's basically what coding is all about). If you're not a developer (and even most developers underestimate/don't fully understand this) it's highly likely you underestimate this part of it (otherwise it would be easy for you to code it yourself - again, how to code is not a big deal, it's specifying exactly how it should work).

Software development is a lot about managing and documenting processes, aka knowledge, about your business.

Otherwise I agree with lots of other comments. Make sure you and the rest of the business is sure and have enough budget/resources allocated for a long time forward. Bring in a CTO/leader with the experience/skills of doing something like this. Make sure that person has the mandate to do what's needed (hiring, culture, etc). Could be a good idea to do it step by step to test out (again, a good mindset is to see this as an investment in learning about how to do your business, using IT/automation). A hybrid approach could work (take over existing code, use another platform/ERP/system as a base) - all depends on the specifics of your business, how custom your business and processes really are, how core to your business they are, etc.

Good luck!


This comment lists most of the questions I would ask. Couldn't agree more. Only advice I would add for the OP:

Check if your contract with the vendor includes any business continuity clauses. What happens to their solution, their code, and your data if they go out of business or get acquired (by someone else)?

One relatively common option is to have them put their code in escrow, and get access to it if certain events happen. You can probably negotiate this into your contract if you have enough leverage.

If their software is critical to your business, and you feel they are stagnant and underfunded, there may be some risk here you can address today - check with your lawyers.

(also, just noticed the username I'm replying to... hi Teren!)


Hey Alex!

Indeed - good point to ensure business continuity. There should also be a transition period to ensure OP, you’re getting support (like 6 months of service) in addition to code that allows you to address the issue if the vendor does disappear.


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


In a similar domain and in NZ.

We solved the accounting problem by not doing it. ERPs try to do everything but there are lots with nice integration points. If you outsource your actual accounting to an accounting package life gets very easy. Accounting doesn't change much business to business but everything else does. If you focus on the bit that is special to your company life gets very easy.

But even integrating with an accounting packaged does require understanding of accounting and accounting systems. We had an internal accountant working closely with us.


Hi Matt of NZ We are currently setting up logistics SAAS specifically for NZ crane and hiabs, and will later branch out to other industries and countries. we are MotherTrucking.co.nz find us, and let's have a talk, you sound like someone we should get to know.


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


How did you land that part time gig?


Friend of a friend of a friend. :) I wish I knew a better way, but that is what actually works.


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.


Product management is really important and must not be delegated too far down. As main sponsor you need to be involved as well. A lot of key decisions must be made and ability and power to say no is vital as is the ability to move the other parties around your system at least a little once in a while.


Were you at the company before they brought things in-house, or were you brought on for that job explicitly?

I haven't been in this situation before, but I imagine one of the trickier challenges in a role like what OP is describing is that whoever leads this also needs the ability to manage scope for the team, including persuading the existing COO or whatnot that "yes, we _could_ bring this in-house but you really really do not want to."


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


Thank you. This is very helpful. Getting the data of the old platform should not be a huge issue. Because we’re filling some gaps with a low-code solution, the infrastructure to get data out is already there.

Feasibly, we could replace functionality bit by bit.


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


What's the use of buying a team that doesn't do management right? The only possible reason for wanting to buy a software provider and turn them into an in-house team would be if they were a stellar team, with stellar management.


Ah, but it is quite possible that they are only in the situation they are in because they are so niche and they have to focus on unnecessary new features in a vain attempt to get new business.

If you purchase them, you just focus on bug fixes and features you actually need. The developers might be great, you might find you need to get rid of management dead wood. Or it might be that you get a very nimble team who in all likelihood have been itching to fix bugs for years and yet who haven't been able to due to competing interests in the business.


> The developers might be great, you might find you need to get rid of management dead wood.

In my experience great developers do not stick with mediocre managers, because they quickly find better options. My experience with poor managers is that they are only able to retain middling engineers.

> Or it might be that you get a very nimble team who in all likelihood have been itching to fix bugs for years and yet who haven't been able to due to competing interests in the business.

That would be closer to a win scenario, but I think OP would have had a strong feel about it - from the way they describe there interactions, it doesn't seem to be the case?


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


Or offer to pay them more.


second this 1000%


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 doesn’t need to be a big React app, Ruby would be fine,

This just made me feel incredibly old. I remember when Ruby was the new, unstable technology.


Don’t worry, I’m old too - that’s why I recommended it. That or Django or even NestJS running in SSR mode.


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.


Last time I looked 80% of developers were building software for in-house use.


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.


Sounds like outsourcing the development to Poland


No, from Asia. I'm a part of this story. Now they hire massively there to scale the business. From the time they reached unicorn status, the budget engineer was about 3M, around 100 engineers.


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.


Worst case is that you don't know how to run a software team and you end up spinning your wheels for ages and then have to onboard a Dev team and convince them they want to clean up someone elses tech debt. Thus making everything cost 10x what management initially thought.

This is probably the last thing I would suggest.


If the agency devs are so mismanaged that the project is a disaster, why on earth would you then hire in house devs instead of reverting to the external platform?

Agencies serve as a good middle ground between buy it (not working for OP at the moment) and going through a hiring process for an entire engineering org you’re not convinced you’ll need. Agency not working? Terminating the project is so much easier than firing the 6 devs you just got through HR.


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


literacy is a really good analogy here


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.


This is exactly the situation my company ran into. Don't hire a contractor, their incentive won't be aligned with your company and you'll overspend.

My company hired me to replace their terrible software vendor and by their own account it's been a clear success. I visit the factories and stores and work with the employees to tailor make the software for their needs.

We're finally about to hire our second developer next year using the money we've saved by ending out contract with our old software vendor.

We're even at the point now where we can sort of brag about it. Here's the customer story we did with Heroku: https://www.heroku.com/customers/leatherspa


Amazing to know


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


I agree, take an internal which is able to abstract and understand logistics and your niche and combine the person with a lead engineer/team you hire. Send the internal on some PO, scrum and requirement engineering trainings. The lead engineer can then also fix the quality and process issues your internal has.

Like that you can start relatively quickly compared to hiring someone and make them understand your business


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.


> Start the team from hiring senior talent...

This is very important! Once you hire the first couple members of a development team, subsequent hires will almost certainly be at the same level of technical skill or weaker.


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.


Do not; absolutely DO NOT hire a specialized PO for a project like this.

One of the developers should be senior enough to wear that hat, and do it part time. Optimally, the entire team will do that task part time.

The most effective way to add risk into an inherently risky project is to put somebody on the way between the developer and the software users.

This project has the best possible configuration where both the developers and the users answer to the same boss. If you need somebody to filter their interaction, the management has failed big time.


Also DO NOT CHEAP OUT ON THE FREELANCERS. A good team of freelancers is going to cost MORE then in house developers. The plus side is they are relatively temporary so not a long term financial burden. The projects I see that fail with freelancers are the company gets greedy and pays the bare minimum but as always you get what you pay for. In most cases the work just ends up being thrown away as a CRUD app that does no have your business logic and work flows is actually harmful.


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.


I recommend using frappe framework, as the ones mentioned are not as "open" as frappe. Odoo was quite a disappointment, because everything you really need is locked behind a paywall...

https://frappeframework.com/


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


I think I may be the kind of person we're talking about here. I wouldn't ever let a new prospect client talk to previous clients. They'd all immediately compare rates and try to low ball me. Conversely, I'd never take on a client "cold". Too many a-holes, crazy people and fraudsters out there. I only work for people I have a long history with, or on occasion the next transitive hop out on the network from those people. I would suggest that the counterparty do the same: reach out into their network and find someone where they can get a strong recommendation based on years of collaboration. If you can't achieve that, don't proceed with the project.


doesn't finding someone with a strong recommendation through your network also result in talking to previous clients?


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.


Building software in two weeks?

It would probably take more than two weeks just to understand their business enough to be able to get your mind around what they need.


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.


These are really great questions - if it will take a 4 person dev-team a year to build what you have at the moment at $100k per engineer, what would $400k in co-development spent with your existing vendor get you? Often quite a lot!


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.


If it's actually unsupported, it could be a bargain.

Maybe OP should approach the company and offer to buy it, rights/source code etc, then build on top of that (it is doing what they want, even if barely...)


Very risky. It would only make sense if that solution does exactly what the OP needs but lacks stability and some new features. However, it's very likely that the product is a generic one, and the OP will end up spending the next couple of years supporting features they don't need but are interconnected with the ones they actually use. This would be especially challenging if they buy only the rights/code without the development team behind it.


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.


SAP does nothing out of the box, except maybe some parts may fall off and you'll find them under the couch later.


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.


I agree with @kkfx. lisp/clojure world is good to help with long-term maintainability, etc. To get an idea search for Rich Hickey's talk "Simple Made Easy"



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.


Can you provide some examples?


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.


In my experience most folks stay at a company because of the relationships they form, not necessarily because of the work.

If you have a team of great people with an awesome attitude and human leadership, you could be doing almost anything (tech wise) and be happy.

The best technologists tend to follow each other around, if you have an exceptional leader, folks will follow them to the company, regardless of the business domain.


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.


Having seen this from the other side, you have to be aware that this will only help with prioritization.

If the provider has a hard time delivering because of internal issues, they will still have a hard time delivering with dedicated development resources.


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


Concur. In house can work wonderfully, but you have to get the dev team integrated into the soul of the business… and you have to be willing to bend when they tell you the current system is insane.


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


by the way, we could discuss that further if you want, you can send me a message on twitter: @pierre_ia


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.


A friend is in a similar situation, they work for a small, state government (US) agency and pay for the only solution on the market. My friend often complains about the software and lack of support. The kicker is they’re only paying $25k a year to use it.

I think this is the lens OP should be using. A small team of “in house” developers is going to start at close to $1 million a year (a senior and a couple of mids; adjust for European salaries of course) with someone already on staff managing and defining the product. Does OP have anyone who can lead the effort?


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.


What’s the difference between an employee that only cares about their paycheck and a contractor that only cares about their invoice? In my experience you can get burnt by both, and at the end of the day the character of the person matters a lot more than the kind of legal docs they work under.


Theoretically, sure. In my experience there’s fewer employees that care only about their paycheck than contractors though.


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.


I feel this is pretty accurate. How much does the off the shelf solution cost? How big is their team? You can take that into account when pondering on a dollar amount that would actually get what you want done. I mirror mywittyname's sentiment. If you get the right person in there they can probably do it solo. But its going to be a large number that you are not going to like. Otherwise you can hire more, less qualified people, at a lower rate and end up with the same or worse result and it will take 10 times longer. E.g. probably the team the solution you are using now has.


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.