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, [email protected] (I'm in Europe too)

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

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.

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.

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.

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

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

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.

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

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

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

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

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.

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.

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

If you're interested in following this strategy, don't hesitate to reach out to [email protected] -- 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.

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.

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.

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

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

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.

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

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.

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

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.

Funny that sales and marketing sells and markets itself.

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.

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.

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.

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.

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

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.

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?

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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

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.

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.

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.

Maybe your strangling software is still too ambitious.

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

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

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.

Nothing off the shelf does that.

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

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

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

This is all DDD play book.

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

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

That adopted mentality pays off tech debt fast.

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

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.

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

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

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.

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

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

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

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.

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?

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.

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

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.

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

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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

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

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.

So it all comes down to what you said about operating in a specific niche. If that niche is your value prop, and the reason software is difficult for you, then yes, in-house it and build what you need.

As far as retaining talent, money talks. Put a number on the value that solid software would bring to your business, and if that number can support compensating a software team at market rates or higher, you have the potential to retain a team. However, it also needs to be a good team -- solid leadership, with a culture that matches what is expected by software devs: respect, autonomy, flexibility, and trust.

If all of that sounds reasonable, go forth and build. If not, accept the struggle of having to buy.

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

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

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

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

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

This used to be standard.

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

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

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.

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.

   * 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

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

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

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

It has one customer (initially).

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

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

Great approach advice IMO.

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

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.

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

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

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

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. [email protected].

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

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

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

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

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

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

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

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

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

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

Pay a decent amount + meaningful perks (yes insurance, no tennis table), be decent people, give them agency and let them see they're making an impact, allow them to use whatever hardware and software they think it's best to do their job, don't force them out of remote work if remote work is what they want, be decent people, be decent people, keep bureaucracy and excessive process out of their way, and last: be decent people.

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

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

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

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

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

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

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.

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

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.

It depends. In the end EDIFACT is just a protocol. If you go the Java route Smooks, for example, has pretty decent support to read/write EDIFACT messages.

If you do not want to do the heavy lifting yourself, both AWS and Azure provide SaaS services to do the heavy lifting for you (AWS: B2B Data Interchange, Azure: Azure Logic Apps)

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

If you can provide a good salary and conditions: absolutely. And I should know, because my previous stint WAS in logistics :)

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

Provide a great work environment, good salary and conditions

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

Start as easy as possible and don't hire anyone who wants to build a microservices based platform from scratch w/ almost zero domain knowledge at your org. Because that road will lead to nowhere. (Ask my previous colleagues who decided "we" should. I was against. They are still working on it, 3 yrs later, and nothing has been deployed yet because it still does not work properly.)

> Potential pitfalls we might not be considering.

Do not go the microservices road unless you really, really, really have to (and with good arguments!)

Need any more tips? Happy to help.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

For the software in question, a few considerations come to mind:

- how critical is the software to your company’s competitive advantage?

- how big is the vendor team supporting the software?

- how much revenue/customers does the vendor currently support?

- how much of the software is entirely custom developed vs modules built on top of other platforms?

- where does the software reside (on-prem/in-house acct vs mix vs vendor)?

Without knowing too much detail about the situation, if it’s an application that is easily testable and verifiable (I.e. perform an action results in observable actions), then it’s much easier to rewrite than an application with background functions and procedures so some level of due diligence or discussion with the vendor maybe useful.

Other alternative solutions that may make sense if software is critical:

- joint venture with vendor

- code acquisition + in-house team

- code/team acquisition

- short feasibility project to determine migration strategy

I’ve worked fairly extensively in transition/acquisition projects so happy to share more if there’s anything specific you’re interested in knowing.

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

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

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

Good luck!

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

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

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

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

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

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

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.

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

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.

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

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.

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.

1. You don't necessarily need to bring your development in-house. But you are looking to move away from your current provider. You might want to think about using contractors to build a new platform - possibly hire a software house to do it for you, rather than hire individual contractors. There are lots of small software houses who would love the opportunity to build a long term relationship with a client of your size

2. You need to be clear about your budget. How much are you paying your current provider? What would the development cost? What are the opportunity costs of the missing insights you are suffering from. What is the RoI on a new platform?

3. The absolutely critical thing you need to think about from day 1 is the migration onto the new platform. How are you going to get data off the old platform onto your new platform? How are you going to introduce the new platform. Can it be a phased introduction or is it a "big bang".

4. You need to have some good people in your organisation to manage the migration. People you trust to tell it like it really is, not to tell you what you want to hear.

5. I would recommend that you start by identifying the absolute minimum functionality you need to keep your business running smoothly. That is your initial platform (the MVP). The data you need for that MVP is the data you need to migrate initially. Don't try to do anything more than this in your initial migration - keep everything as simple as possible.

6. Do put procedures / checks etc in to ensure you maintain data quality across the migration. And if you can clean up the data as you migrate, so much the better. Do test all your data migration and platform migration before doing it for real!

7. After the migration, you then keep building the functionality, and bringing more data in. But concentrate on stability and keeping your business running. Your migration should be invisible to your customers. If you are having to making excuses to customers about why you suddenly can't do things, or meet your normal standards, then you are doing it wrong!

Hope this helps :-)

Feasibly, we could replace functionality bit by bit.

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.

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.

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.

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?

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.

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.

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.

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