return to table of content

Ask HN: Should we bring software dev in-house?

davedx
80 replies
23h57m

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

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

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

alemanek
13 replies
20h7m

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

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

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

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

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

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

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

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

Best of luck

EDIT: formatting

danielheath
7 replies
17h45m

This is difficult and time consuming so start now.

A specific difficulty you are likely to face:

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

afpx
2 replies
15h20m

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

throwaway14356
1 replies
14h44m

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

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

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

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

zerkten
0 replies
1h50m

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

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

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

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

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

Too
1 replies
10h49m

These experts may also be hesitant to change.

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

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

carlmr
0 replies
10h19m

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

BurningFrog
1 replies
5h46m

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

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

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

zerkten
0 replies
2h38m

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

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

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

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

throwaway201606
1 replies
12h42m

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

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

Some additional thoughts:

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

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

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

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

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

        a) as a team and 

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


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

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

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

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

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


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

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

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

- Key skills to look for in free lancers:

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

               - system architecture: designing software solutions

               - database architecture & design

               - project & program management 

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

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

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

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

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

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

slfnflctd
0 replies
7h25m

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

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

phkahler
1 replies
3h38m

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

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

alemanek
0 replies
3h5m

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

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

osigurdson
0 replies
13h10m

> project often comes down to clear requirements and expectations

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

alberth
12 replies
23h6m

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

henryfjordan
4 replies
22h24m

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

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

kelnos
1 replies
20h39m

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

intelVISA
0 replies
15h38m

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

davedx
0 replies
9h7m

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

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

Silhouette
0 replies
17h35m

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

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

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

ragebol
1 replies
23h1m

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

j45
0 replies
22h4m

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

conductr
1 replies
22h2m

Acknowledge and incent the exit plan from the beginning

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

Silhouette
0 replies
17h45m

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.

ssousa666
0 replies
6h1m

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

maccard
0 replies
21h20m

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

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

davedx
0 replies
9h9m

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

poeticsilence
11 replies
22h17m

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

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

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

kelnos
10 replies
20h42m

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.

ozim
9 replies
19h6m

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

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

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

mr_toad
4 replies
13h18m

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

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

ozim
2 replies
11h13m

Well I do agree everyone is a cost.

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

marcosdumay
1 replies
4h57m

The management sets the company dynamics to whatever they want.

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

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

ozim
0 replies
46m

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

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

carlmr
0 replies
11h50m

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

Funny that sales and marketing sells and markets itself.

pdonis
2 replies
16h38m

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

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

nucleardog
1 replies
3h13m

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

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

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

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

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

pdonis
0 replies
1h28m

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

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

dchftcs
0 replies
18h31m

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

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

intelVISA
6 replies
15h53m

I'm gonna go against this heavily tbh:

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

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

Silhouette
3 replies
13h46m

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

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

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

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

gwd
0 replies
11h39m

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

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

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

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

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

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

The_Colonel
0 replies
10h24m

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

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

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

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

JCW2001
0 replies
6h35m

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

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

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

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

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

nirse
0 replies
5h38m

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

davedx
0 replies
9h11m

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

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

YMMV of course!

heisenbit
5 replies
20h58m

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

cellularmitosis
2 replies
20h40m

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

switch007
0 replies
7h49m

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

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

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

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

carlmr
0 replies
11h44m

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

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

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

davedx
0 replies
9h15m

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

danfunk
0 replies
4h32m

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

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

j45
4 replies
22h13m

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cvladan
3 replies
20h4m

OMG. GPT? Claude?

j45
0 replies
19h9m

Nope, just me, I promise.

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

MrDresden
0 replies
19h25m

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

EVa5I7bHFq9mnYK
0 replies
13h46m

Nope, those usually get basic grammar right.

treprinum
3 replies
20h43m

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

kelnos
0 replies
20h41m

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

davedx
0 replies
9h5m

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

Silhouette
0 replies
17h29m

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

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

th3byrdm4n
1 replies
11h47m

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

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

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

davedx
0 replies
9h13m

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

radicalbyte
1 replies
3h29m

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

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

The pitfalls are mainly hiring:

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

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

radicalbyte
0 replies
3h19m

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

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

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

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

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

tikkun
0 replies
2h10m

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

steve_adams_86
0 replies
18h39m

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

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

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

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

nadis
0 replies
23h32m

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

mstade
0 replies
1h31m

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

lastofthemojito
0 replies
23h6m

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

jongpieter
0 replies
2h51m

Great advice, perhaps I can share some personal experience.

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

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

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

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

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

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

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

jonahbenton
0 replies
20h22m

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

holri
0 replies
4h10m

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

globular-toast
0 replies
9h9m

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

gaoshan
0 replies
3h43m

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

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

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

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

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

foxtacles
0 replies
19h52m

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

datadrivenangel
0 replies
25m

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

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

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

cut3
0 replies
6h17m

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

christophilus
0 replies
22h30m

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

alphazard
0 replies
18h31m

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

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

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

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

carlcoryell
25 replies
13h19m

I used to run the Singapore and Seattle offices for Pivotal Labs and helped a couple of companies build in-house teams to do exactly this.

My first question is to check the basic economics:

$2-300M in annual revenue, ~15% margins, you’re probably looking at earnings/profits around $30-45M. Building and running your own software team is probably around $5M/year, which feels like it could be a substantial hit to your margins. Is there a clear story for how this software will allow you grow to $300-500M in revenue or more? I like to have a credible story for 5-10x ROI on software development because the costs end up being so variable and uncertain.

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

xandrius
6 replies
12h22m

To me this sounds like an ad.

pinkmuffinere
3 replies
12h13m

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

AmericanChopper
2 replies
8h51m

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

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

pinkmuffinere
1 replies
2h28m

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

AmericanChopper
0 replies
1h7m

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

nrivoli
1 replies
12h16m

Yeah, ad like, but he is not wrong.

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

xandrius
0 replies
32m

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

davedx
5 replies
8h56m

$5M/year? In the US maybe.

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

hiddencost
2 replies
5h17m

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

davedx
0 replies
3h13m

Freelancers.

ahtihn
0 replies
2h57m

He said freelancers.

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

ghiculescu
0 replies
7h43m

The point is still valid even at that price.

HereBeBeasties
0 replies
1h52m

Employer tax contributions

Office space

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

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

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

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

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

wordofx
4 replies
10h48m

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

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

rty32
2 replies
7h57m

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

tauntz
1 replies
7h24m

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

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

jon-wood
0 replies
3h45m

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

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

StackRanker3000
0 replies
4h52m

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

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

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

What numbers have you come up with that contradict his?

th3byrdm4n
4 replies
11h46m

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

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

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

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

t-writescode
3 replies
9h38m

What does on-call look like for you?

gbalduzzi
2 replies
5h7m

Most business do not require on call for their internal tools

flqn
1 replies
1h38m

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

FuriouslyAdrift
0 replies
43m

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

te_chris
0 replies
10h1m

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

ethbr1
0 replies
7h2m

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

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

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

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

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

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

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

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

uticus
13 replies
4d2h

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

Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

If you decide to do in-house, I’d recommend thinking about competing against existing as a new revenue stream, and spinning it off as a separate business unit as much as possible. I imagine this is implied in your question but it wasn’t specifically mentioned.

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

Yes. Are you kidding? Non-glamorous reads as safe in uncertain times. It’s a positive point that will be a marketing multiplier for attracting talent, if coupled with other indications that your business has clear goals and good ideas.

layer8
4 replies
1d

If you decide to do in-house, I’d recommend thinking about competing against existing as a new revenue stream, and spinning it off as a separate business unit as much as possible.

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

hamandcheese
2 replies
23h15m

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

theshrike79
0 replies
10h54m

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

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

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

physicsguy
0 replies
21h34m

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

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

pbronez
0 replies
23h45m

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

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

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

45HCPW
1 replies
4d1h

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

notarealllama
0 replies
57m

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

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

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

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

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

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

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

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

th3byrdm4n
0 replies
11h12m

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

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

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

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

jmarbert
0 replies
17h47m

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

ericmcer
0 replies
21h43m

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

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

empath75
0 replies
22h12m

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

bobertlo
0 replies
22h49m

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

Closi
0 replies
1d1h

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

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

PaulHoule
11 replies
4d4h

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

You first need to hire somebody rather senior to be a "CTO" or "Engineering Manager" who is first of all supposed to help you consider "potential pitfalls" and "alternative solutions." Next I can picture that person putting together a 3-5 person team which could take a big bite out of your problem in the course of a year.

Personally I have done many projects in e-commerce and I find logistics to be meaningful because I like knowing my system controls activity in the physical world. Today is a good time to be hiring software devs because the job market for software devs is softer than it's been in a while.

fuzzfactor
7 replies
4d3h

hire somebody rather senior to be a "CTO"

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

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

At the one extreme you write all new code.

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

Or anything in between.

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

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

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

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

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

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

PaulHoule
6 replies
4d2h

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

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

fragmede
2 replies
23h44m

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

nonrandomstring
0 replies
21h23m

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

lostlogin
0 replies
23h38m

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

It has one customer (initially).

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

45HCPW
1 replies
4d2h

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

mmdesignsldn22
0 replies
2d23h

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

fuzzfactor
0 replies
4d2h

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

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

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

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

yyyfb
2 replies
16h8m

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

dboreham
1 replies
12h2m

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

yyyfb
0 replies
11h46m

Maybe chatgpt can assess!

superice
10 replies
21h52m

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

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

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

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

yyyfb
8 replies
16h9m

Your biggest pain point is most likely that you know your business very well, but you probably do not know enough about the business context of your partners.

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

superice
1 replies
12h58m

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

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

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

yyyfb
0 replies
12h23m

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.

morning-coffee
1 replies
1h36m

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

fuzzfactor
0 replies
54m

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

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

bjornsing
1 replies
14h1m

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

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

superice
0 replies
12h36m

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

th3byrdm4n
0 replies
11h37m

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

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

scott_w
0 replies
8h11m

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

x0x0
0 replies
21h14m

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

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

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

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

rurp
7 replies
22h22m

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

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

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

theshrike79
5 replies
10h58m

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

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

JamesSwift
2 replies
5h19m

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

theshrike79
0 replies
7m

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

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

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

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

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

marcosdumay
0 replies
4h47m

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

Maybe your strangling software is still too ambitious.

hobofan
1 replies
10h22m

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

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

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

marcosdumay
0 replies
4h45m

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

L-four
0 replies
20h22m

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

jmarbert
7 replies
17h29m

I’m part of a 20-person company that was in a similar situation. We have since built our software in-house, replacing the software we previously struggled with, and it’s worked out even better than I originally hoped because it felt so audacious at the time.

One thing I think is key is making sure that whoever is leading this project (the lead developer, not just the person they’re reporting to) needs to know the business cold. They should spend serious time learning the roles of the people who will be using the software so they can design it well to solve the problems those roles face. I lead the development for us, and I attribute most of the software’s success to simply having spent so much time in so many roles in the company. It’s that cross-section of knowledge that makes all the difference.

th3byrdm4n
2 replies
11h41m

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

Nothing off the shelf does that.

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

Too
1 replies
9h52m

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

RaftPeople
0 replies
59m

Fourth this.

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

TehShrike
2 replies
15h22m

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

oaiey
0 replies
13h24m

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

This is all DDD play book.

marcosdumay
0 replies
4h49m

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

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

samstave
0 replies
16h18m

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

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

---

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

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

agentultra
7 replies
3h23m

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

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

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

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

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

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

Update: spelling.

hn_throwaway_99
3 replies
2h54m

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

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

bluGill
1 replies
2h26m

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

hn_throwaway_99
0 replies
1h34m

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

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

101011
0 replies
2h47m

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

RaftPeople
1 replies
2h20m

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

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

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

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

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

You need people with the following:

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

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

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

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

RaftPeople
0 replies
1h10m

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

Alternative solutions we should explore.

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

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

Some examples where I used this very successfully:

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

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

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

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

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

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

leptons
0 replies
2m

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

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

codingdave
5 replies
2d1h

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

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

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

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

from-nibly
3 replies
23h33m

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

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

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

theshrike79
1 replies
10h56m

This is a huge thing.

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

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

heraldgeezer
0 replies
13m

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.

codingdave
0 replies
4h18m

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

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

loa_in_
0 replies
8h20m

Software developers are the blacksmiths of this century.

trollbridge
3 replies
18h58m

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

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

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

yyyfb
2 replies
14h18m

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

chris_wot
1 replies
12h54m

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

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

yyyfb
0 replies
12h35m

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

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

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

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

neilv
3 replies
15h50m

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

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

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

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

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

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

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

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

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

th3byrdm4n
0 replies
11h35m

This summarizes my career nicely.

Great approach advice IMO.

th3byrdm4n
0 replies
11h20m

This summarizes my career nicely.

Great advice IMO.

TheDudeMan
0 replies
14h49m

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

mindcrash
3 replies
1d22h

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

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

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

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

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

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

Provide a great work environment, good salary and conditions

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

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

Potential pitfalls we might not be considering.

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

Need any more tips? Happy to help.

RangerScience
1 replies
23h33m

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

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

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

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

mindcrash
0 replies
20h20m

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

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

tgsovlerkhgsel
0 replies
38m

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

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

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

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

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

ensemblehq
3 replies
1d19h

Whilst I don’t have a ton of experience in logistics, I have helped executives in other industries map out transition strategies.

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

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

- how big is the vendor team supporting the software?

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

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

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

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

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

- joint venture with vendor

- code acquisition + in-house team

- code/team acquisition

- short feasibility project to determine migration strategy

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

alex_c
1 replies
16h43m

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

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

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

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

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

ensemblehq
0 replies
6h0m

Hey Alex!

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

cjblomqvist
0 replies
21h36m

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

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

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

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

Good luck!

vlugovsky
2 replies
9h36m

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

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

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

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

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

jmkni
1 replies
8h7m

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

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

vlugovsky
0 replies
4h30m

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

simonbarker87
2 replies
9h52m

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

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

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

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

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

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

newswasboring
1 replies
8h48m

It doesn’t need to be a big React app, Ruby would be fine,

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

simonbarker87
0 replies
6h34m

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

rossdavidh
2 replies
4h5m

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

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

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

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

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

mmckelvy
1 replies
3h54m

How did you land that part time gig?

rossdavidh
0 replies
2h17m

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

kkfx
2 replies
1d1h

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

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

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

mxvanzant
1 replies
22h38m

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

kenoyer130
2 replies
5h40m

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

marcosdumay
0 replies
4h6m

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

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

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

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

kenoyer130
0 replies
5h37m

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

jvdongen
2 replies
22h34m

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

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

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

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

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

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

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

joatmon-snoo
0 replies
22h10m

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

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

heisenbit
0 replies
20h44m

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

dayjah
2 replies
3h6m

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

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

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

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

taylorhou
0 replies
2h59m

second this 1000%

sroussey
0 replies
1h24m

Or offer to pay them more.

darkmarmot
2 replies
17h47m

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

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

I would only pursue it if:

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

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

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

Aeolun
1 replies
14h5m

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.

darkmarmot
0 replies
13h54m

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

bdcravens
2 replies
23h58m

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

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

theshrike79
0 replies
10h53m

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

RangerScience
0 replies
23h40m

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

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

MattOfNZ
2 replies
22h53m

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

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

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

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

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

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

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

xupybd
0 replies
15h59m

In a similar domain and in NZ.

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

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

jasonteunissen
0 replies
21h10m

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

Aeolun
2 replies
14h12m

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

bjornsing
1 replies
13h46m

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

Aeolun
0 replies
7h34m

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

wkirby
1 replies
1d

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

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

from-nibly
0 replies
23h31m

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

This is probably the last thing I would suggest.

trumbitta2
1 replies
2d5h

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

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

kstrauser
0 replies
18h20m

Nailed it.

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

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

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

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

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

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

steve_gh
1 replies
4d4h

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

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

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

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

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

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

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

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

Hope this helps :-)

45HCPW
0 replies
4d2h

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

Feasibly, we could replace functionality bit by bit.

spoonfeeder006
1 replies
12h43m

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

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

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

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

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

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

dboreham
0 replies
11h53m

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

ruzig
1 replies
14h34m

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

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

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

rvba
0 replies
4h3m

Sounds like outsourcing the development to Poland

pipesorter
1 replies
22h46m

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

HeyLaughingBoy
0 replies
22h32m

Building software in two weeks?

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

pierreia
1 replies
4d

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

pierreia
0 replies
3d19h

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

owenm
1 replies
10h46m

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

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

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

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

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

actionfromafar
0 replies
3h47m

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

nocubicles
1 replies
2d13h

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

Arjuna144
0 replies
10h28m

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

https://frappeframework.com/

mywittyname
1 replies
2h6m

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

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

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

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

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

nwellinghoff
0 replies
2h2m

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

mindcrime
1 replies
23h6m

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

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

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

HeyLaughingBoy
0 replies
22h29m

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

maxsavin
1 replies
15h0m

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

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

claytongulick
0 replies
14h20m

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

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

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

lifeisstillgood
1 replies
9h20m

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

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

This was a serious question hundreds of years ago btw.

Edit: As for the rest of your points:

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

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

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

hayri
0 replies
9h2m

literacy is a really good analogy here

katzinsky
1 replies
1d2h

Here's what I would do.

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

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

webel0
0 replies
23h56m

Can you provide some examples?

intechideas
1 replies
2h1m

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

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

le-mark
0 replies
1h52m

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

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

casesandberg
1 replies
21h12m

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

hyperpape
0 replies
7h2m

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

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

bjornsing
1 replies
13h8m

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

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

We're using a third-party product that functions, but barely. The provider is understaffed and unresponsive and the platform is stagnant. It's a fight getting basic bugs fixed let alone new features implemented. We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

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

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

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

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

Closi
0 replies
10h11m

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

andrewstuart
1 replies
21h48m

Whatever you do, don't hire some tech bro who tells you that you should build this in Ruby On Rails or Elixir or Elm or Rust or something on the cutting edge in any way.

This is standard corporate technology and needs standard ordinary technology. There is zero requirement for this sort of application to use anything fancy. Indeed if you use fancy technology that scratches the itch of a tech bro then you are buying yourself problems hiring and recruiting developers - this is one of the worst problems you can have. Not such an issue right now while the employment market is down, but a massive issue when it is not.

Use ordinary technologies, any of these things are fine:

Java

C# .NET

Python

TypeScript

Postgres

Also, don't use cloud specific technologies such as serverless. Just write software that can run on an ordinary Linux server. Once you start using serverless you are bound to that code and that cloud forever. Also, and other may argue against this, but my experience of building application using cloud technologies is that way too much developer time and effort goes into making the cloud work and not enough into writing application code. Have a general directive in place to use the cloud for running compute instances and avoid using cloud application services unless really necessary and have a process where doing so requires signoff from the top. Nothing wrong with cloud virtual machines and email sending but just run most other things on Linux - own your own computing infrastructure and be in a position to pick it up and move it elsewhere or even on premises if you choose.

In summary, beware tech bros advocating anything except Java/C#/Python/TypeScript/nodejs/Postgres, don't use serverless and use cloud computing for virtual machines, email and DNS and not much else.

Hire a development manager with experience building corporate applications and let them hire three developers, a tester and a business requirements analyst and that's phase one of your "bring it in house project". Build a series of small chunks of functionality, don't bite of more than you can chew.

diavelguru
0 replies
17h27m

Agree with this re serverless cloud computing

alentred
1 replies
22h9m

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

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

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

---

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

alexdowad
0 replies
14h4m

Start the team from hiring senior talent...

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

JoachimSchipper
1 replies
23h57m

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

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

pbronez
0 replies
23h53m

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

4b11b4
1 replies
13h28m

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

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

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

edit: grammar,typos

oaiey
0 replies
13h22m

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

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

zurfer
0 replies
3h1m

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

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

zlstone1992
0 replies
1h44m

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

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

zizee
0 replies
11h50m

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

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

zehaeva
0 replies
1d1h

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

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

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

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

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

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

yyyfb
0 replies
16h18m

First off, as an occasional customer of logistics providers who sees so much crappy software held with duct tape and a wish, I completely agree that it is smart to bring it in house.

You need a solid team of at least two - a product person and a builder, preferably who have worked together before. Notice I didn't say CTO because some CTOs are admins rather than builders. Notice I also said product because you don't just need to build, you need to know what to build - and that might be part of the problem, if you're the one spec'ing the features and prioritizing bugs, you need someone to do this full time for you.

I'd look for one of the two to start with and make it clear that you will expect them to build the team up as their very first responsibility. Most great engineers have product people who they can recommend and most great product people have software engineers they can recommend.

I have come across people who operate very well with a specific offshore software dev team. If they can come in and bring their offshore connection, all the better (can be 1/2 as expensive as US). But in the formative stages, if you can afford it, I highly recommend an in-person team rather than off shoring, because it's a crapshoot that can be very expensive too if it doesn't work.

ypeterholmes
0 replies
39m

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

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

y1426i
0 replies
20h50m

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

xupybd
0 replies
16h10m

Yes, yes yes.

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

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

xkcd1963
0 replies
3h42m

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

wombatpm
0 replies
17h39m

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

withinboredom
0 replies
5h26m

I’ve built custom logistics, warehouse picking, and inventory software before, interacting with Amazon, EBay, and others before. Send me an email: rob@bottled.codes

wiresurfer
0 replies
6h51m

So a little backstory, I have worked in Logistics and warehousing, albeit as a senior dev on robotics solutions and its needed implementations.

What you don't want to do is hire a team inhouse if your pain timeline needs fixing in < 1 Financial Year.

As someone mentioned. Senior freelancers preferably with some domain exposure.

Don't think of this as a software problem, but a house rennovation project!

Here is the playbook we have recommended and executed for many clients,

- Hire a documentation guy. Start writing/drawing out all business processes your current third party system serves. Use BPMN if possible.

- Sit down with a senior dev to draw a High Level Design of this system. And find subsystems or funcitons which you can live with, vs things which absolutely need retrofit/rewrite.

- See how you can define a scope of work where what's good keeps running, and a new smaller better subsystem starts taking over functions you need replacement.

- rinse repeat.

--- Strategically speaking, Hiring is a bit painful. Depends on geography. Retaining someone beyond 3-5 years is difficult. People churn out of boredom as the work gets repetitive and they don't get to flex their tech stack itch.

Money wise, is the third-party company a potential acquihire target? If its small, why not take it over and inhouse the team. You would get the "catered to us" part sorted and you can still sell to other customers if you so desire. This has its own risk-reward. But I will let you be the judge of it.

And in anycase, get an independent technical consultant to cover your blind side.

winterbloom
0 replies
22h41m

I'm an NA-based freelancer actually looking for work. I've got team-lead experience to take this in-house; Got contact info listed somewhere?

will5421
0 replies
7h47m

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

wickedsight
0 replies
1h53m

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

Why do developers slow down

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

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

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

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

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

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

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

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

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

westoque
0 replies
9h45m

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

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

How to do this is more nuanced:

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

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

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

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

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

webprofusion
0 replies
13h24m

If you're comfortable spending $2M+ and 2 years building, then maintaining and renewing that software continuously for the life of the business then go for it!

In reality all big business become software companies eventually, but the really big ones tend to lean towards customizing a vendor product (e.g. SAP) to replace their collection of built-from-scratch tools. I'm not in the logistics business but if that's not SAP then I'm not sure what is.

vlovich123
0 replies
20h3m

Don’t see contact info in your profile. Feel free to email me at gmail - lots of experience leading tech teams, but none in the logistics space. Currently mid transition and exploring opportunities. Might be interested depending on opportunity and details.

varjag
0 replies
1h25m

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

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

ushsnebsz
0 replies
2h34m

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

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

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

uptownJimmy
0 replies
5h33m

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

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

unholyguy001
0 replies
1d1h

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

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

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

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

ulfw
0 replies
12h3m

A 200 people logistics company with no software expertise building it's own softare in-house. Just madness.

tristor
0 replies
1d2h

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

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

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

tpm
0 replies
22h48m

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

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

tonyennis
0 replies
1d2h

Do you have an email address? Shameless plug but this type of project is exactly what my small agency does, have done for several companies similar to yours.

tincholio
0 replies
1h57m

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

tikhonj
0 replies
16h13m

Honestly, this sounds like a project I would enjoy working on: designing and building a brand new system, learning about a new kind of business, encoding some complex business rules into code, being able to work closely with the people who would be using my software (ie other folks at the company).

However, I would be worried that software development at a non-software company would be a second-class citizen. Lots of pressure, and unhealthy culture, upper management that didn't understand the nature of software development... How would I know that I would have the space and the support to do good work in a good environment?

I actually had a good time doing this at Target of all places, where I got to work on building a new supply chain optimization system from scratch. It was a lot of fun and had a lot of impact, but largely because our team was insulated from the "normal" way of working at Target for several years. But, eventually, the Target way of doing things caught up to us and most of the best people on the team left within a couple of years. (Side note: we were transitioning from a third-party system that ran on a literal mainframe, but I was never involved too directly with the legacy system.)

So, my advice? You can definitely hire legitimately strong programmers even in a non-tech company, but you need to solve two problems: how can you show-not-tell that the software team won't just be a cost center without the space and scope to do good work, and, once you can do that, how do you get the word out to strong programmers? I've seen companies do this well but always in pretty context-specific ways; there's no universal solution. Just saying something "we're like a startup inside a bigger company" won't do because a) everybody says that and b) it's too fuzzy. And how to get the word out, well, I really don't know much about that.

Side note: happy to talk more about this if you're interested.

thnetcoder
0 replies
22h40m

I've done this at the CTO level in a non glamorous industry (construction). We spent about 3 months understanding the business top to bottom before building the software. We then took the best of the SaaS software that wasn't flexible enough and layered on what was needed with an eye towards massive growth. There's no way it would have ever got done correctly and be as stable/maintainable as it is now without that time up front. As others have said, you need someone who is vested in the business. Otherwise the dev team frankly won't care. You can't just throw some random devs at a problem like this one.

thijsvandien
0 replies
2d14h

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

No matter what you decide, it sounds like in the short term there's no getting away from them. As such, I would attempt to open a dialog focussed on mutual success. If this is a niche, chances are you are as important to them as they are to you. Show genuine interest in the problems they are facing, rather than expressing frustration. Are they struggling in general? Perhaps there are ways to help them get back up to speed. What about you as a customer (e.g., too distinct a workflow) makes things extra complicated? Look for specific points of friction, and how to address those.

A viable option, at least to get started, could be to use them as a building block. For example, handling that data exchange you mentioned. Establish a simplified format that is still detailed enough for them to do what they need. Then have your own logic, however complex, construct the input to their system. Add something in the opposite direction as well. Over time, you'll have more and more components that are easier to replace, because of their limited scope. Finding another vendor or building more custom solutions won't be all or nothing anymore, which is exactly where you want to be.

Doing this in-house? I feel the challenges are already plentiful without that. Instead, lean more to the side of having a couple subject matter experts interact with a small(ish) software house. It wouldn't be the first time that eventually one of theirs jumps ship, tagging on a colleague or someone else from their network. Basically the team would build itself, organically.

On a final note, I just wanted to say this sort of stuff fascinates me. Likely you wouldn't have time for anything like that, but I'd love to see in detail what your business is doing, and how said software is holding you back.

theshrike79
0 replies
11h4m

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

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

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

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

thaumasiotes
0 replies
10h1m

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

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

th3byrdm4n
0 replies
12h3m

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

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

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

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

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

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

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

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

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

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

Hard to leave an institution like that

tess0r
0 replies
12h0m

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

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

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

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

te_chris
0 replies
10h0m

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

tacitusarc
0 replies
4h44m

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

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

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

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

surfingdino
0 replies
6h43m

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

However...

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

spyckie2
0 replies
1h23m

Let me break down how to think about it. The key question to ask - is the software revenue generating?

1) IF the software is revenue generating, then you can spend 10-40% of your annual revenue on your software team, because you're anticipating that the spend will grow your revenue and you can factor that growth budget into the software team's budget.

2) IF the software does not help the company make money, expect to spend 5% of the revenue on IT (and maybe 30% of that budget is software dev). 10% if it's extremely important to the business. Sometimes as low as 2.5% or lower. This number dependent on the operating margin / COGS in your industry.

Should be somewhat easy to look up these percentage spends in various departments for public companies in your space to have a comparison.

Note: You have a 3rd party product and team because it is cheaper than in-house. So unless you have extreme inefficiencies with your current vendor, an on-site team will be more expensive.

Once you get your IT budget as a % of revenue, then look at it in the 5 year picture. Is it $5m/y? Does it grow based on the projected company's growth? Map out the yearly budget, because it will be capped.

3) From a yearly topline budget, map out what you can afford as a combination of build, buy, and build + buy. Do not think of it as one unit, categorize the spend into several key layers that are important to you. Day to day product. Support. Key issues. Future roadmap. Estimate the amount of spend you commit to each.

The key question is if will you have to build your own product from scratch? Or can you build on top of your vendor? You can bring in a consultant who can do that analysis for you, don't skimp here, get someone super qualified/overqualified with plenty of real world experience in your industry. You want him to have gone through pretty much every possible problem you may go through, so he can flag them down preemptively. You'll pay him a set amount of hours to give you insights on how your next 5 years of spending (25-125m$ of money) are going to play out.

4) Deep evaluate your vendor's issue. Is it complexity or complacency? Don't guess and don't be biased.

Software vendors are able to spend more money on engineers than you because of simple economics. Their entire revenue is spent on 3 functions, sales, engineers, and support. Your entire revenue is likely spent mostly on COGS and sales.

The key question you need to ask is can you allocate your IT budget more efficiently compared to your software vendor's IT budget? They may have a 10x bigger budget than you. But they also have to support many other company use cases that may not apply to you.

Here, you really don't want to get it wrong. If it is complexity that is the vendor's issue, then you don't want to take on their complexity with less budget - that's just making things much harder on yourself. But if it is complacency, there may be a lot of room for a new, modern software. But real red flag is that logistics is a notoriously complex industry.

Look for alternatives to reducing complexity, or to creating robustness, without rebuilding core functionality however you can. This may be impossible, but you never know. With a large enough budget, you can hire some really smart people who can figure out something clever.

5) Create a budget to figure out what the plan would be.

A budget where you identify the key questions, and send freelancer senior engineers to figure out those issues and solve them - is a really good place to start. Think of this budget like insurance, or like a multiplier of your success chance, which starts off at probably 10%, and goes up the more you dig, plan, and know.

The core business issue is never about building an in-house team or not, its about finding the key bottlenecks and finding intelligent and creative people to craft human-capital solutions around those key bottlenecks.

Good luck.

solardev
0 replies
1d17h

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

I worry that without a culture to sustain and nurture a software team over time, whatever you build this year will become nightmarish tech debt a few years later. Dev turnover might be high due to limited advancement potential / lack of resume building opportunities / not enough sexy problems to work on. Institutional memory between generations of devs might be hard to maintain and your totally custom software might get harder and harder to work on and use as the years to by. It doesn't seem like a great way to run an essential part of your business.

Can you switch to a more responsive vendor but then find an agency to do the day to day dev work and add custom code as needed?

I've spent much of my career working in tech roles for non tech companies, and I've seen a lot of bespoke custom garbage that's really hard to work on. It ends up being more forensic than engineering work, with a lot more reverse engineering and landmine avoidance than new feature development or UI improvements. I try to steer these types of businesses into commercial off the shelf software whenever possible, but maybe building custom webhooks and such into them.

It's a lot easier to have a solid base built and maintained by a good vendor, with some small snippets of modular code (webhooks, plugins, extensions, etc.) added on top. No one feature is tied into everything else, so less experienced devs can fix or replace it modularly without having to reverse engineer your entire custom stack.

sokoloff
0 replies
5h49m

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

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

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

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

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

snow_mac
0 replies
21h12m

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

snihalani
0 replies
1d2h

Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

I'd love to be the provider on this.

snegrus
0 replies
10h17m

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

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

smilliken
0 replies
23h16m

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

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

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

smarri
0 replies
12h55m

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

siver_john
0 replies
4h17m

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

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

simonz05
0 replies
13h43m

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

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

simonsarris
0 replies
22m

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

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

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

silisili
0 replies
22h45m

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

Money! Work life balance. Good benefits.

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

shulu
0 replies
23h31m

Having built one of the largest tech-enabled 3PLs from ground up and serving as CTO for a logistics tech startup with client 20M - 1B annual transportation spend, my take below

We're using a third-party product that functions, but barely. The provider is understaffed and unresponsive and the platform is stagnant. It's a fight getting basic bugs fixed let alone new features implemented. We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

Most successful and agile 3PL and LSP (non VC backed) do not build all their tech, but rather glue tech together. They leverage pre-built TMS, WMS, YMS and build out in-house middleware layer for analytics and control points. Key is to guarantee portability of data and analytics with a unified view of the business.

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

The Devil is definitely in the details. We regularly ignore what C/VP/Dir-level's description of tech and business process. Talking with the direct team member or their manager reveal so much more of the real painpoints than what higher up learns. The risk here is not business adopting tech but rather tech team understanding business. Have a senior leader here who are technical with strong business domain expertise is critical. They need to form a culture of domain understanding throughout the tech org.

Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning from third-party to in-house software (success stories and cautionary tales).

It is very hard. Mostly due to comp, EPD treated as a cost center (and engineers do not want to be devs), lack of recognition of the industry.

There is one thing going for logistics, it touches physical world and is extremely complex (not hard). It attracts certain types of people prefer complex problems. Aside from senior tech leaders and a few senior engineers, you will be aiming for the diamond in the rough profile here.

There are rare cases such as Ryder acquiring Baton and use the latter as their core Engineering while keeping some old IT groups hanging around. Ryder is large enough to pay tens of engineers 300k+ salaries.

Potential pitfalls we might not be considering. Alternative solutions we should explore.

Instead of building a tech team to build everything, you have an artifact, who is a domain expert on your own business, define a business middleware and analytics ingress for the company. Start by normalizing against the middleware and analytics ingress with consultants before building your own tech team.

Logistics has been the most fascinating industry I have worked in and I see my whole career in this industry. Excited to chat more tech strategy in logistics, email shu at loop dot com.

sghiassy
0 replies
1d1h

As a Principal Engineer in FAANG, I’d caution against bringing software development in-house without someone who deeply understands how software is built at the leadership level within your company.

Software can be intangible, making it difficult to manage budgets and timelines. You might find yourself asking, ‘We’re spending all this money, but what exactly are we getting for it?’ What’s the point of all this CapEx?

Moreover, it’s easy to place unrealistic demands on software development. If you, the business, change your mind every two weeks about what the software should be or do, the constant churn in feature requests can bog down the code and hinder development—through no fault of the developers.

While you don’t necessarily need a CTO, it’s crucial to have someone you trust, even when the answers you receive aren’t what you want to hear.

Is it possible to find a new outside vendor?

semanticjudo
0 replies
2h51m

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

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

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

satya71
0 replies
22h22m

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

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

sabas_ge
0 replies
3h44m

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

rufugee
0 replies
21h58m

I'm a CIO/CTO in a similarly-sized (revenue, although we have roughly 900 employees) company in the distribution space. We do almost all development internally, but I have been developing for decades so I know what good looks like. I've had good luck attracting a jolly band of developers and devops.

I despise outsourcing development to third parties unless I absolutely have to. The quality of work is just better with the internal devs, and we retain the knowledge of our entire stack.

Our software is the life blood of our business, so that's a big win for us and it sets us apart from our competitors. I'm able to outpace them from an innovation perspective.

All that said, unless you're very technical or you have a strong IT executive on your team, this approach won't work.

rsyring
0 replies
22h30m

This is something you want to have an ongoing conversation about. With someone competent and experienced enough to ask the right questions. I can help you with that. Look me up and reach out if interested.

Randy Syring, Chief Executive Developer, Level 12

robust-cactus
0 replies
2h33m

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

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

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

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

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

rmoskal
0 replies
2h3m

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

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

There are exceptions.

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

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

richiebful1
0 replies
4h39m

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

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

richardw
0 replies
25m

I was part of a team for 12 years and watched it for longer, that helped a company on a journey exactly like this. I don't really want to get caught up in phone calls because I need to focus, but here's some of it.

Rough version:

- Outsourced to a company. Supposedly top people.

- My friend joined that company. He threw his heart into it. Eventually, he got the contract. He was the only person fully committed to the success, and the outsourced company was committed but not to the same extent. The key here is that he had extreme ownership over it and threw his being into making it work, and he was (became) very good with people - devs, execs etc., while helping to make enough of the right technical choices.

- He made a lot of money, because he was helping a significant business during a lot of churn as they grew. He helped them a lot, over 25+ years.

- At some point I joined them for far too long, but I learned a ton of what was good and bad about this.

- The company bought a few others as they grew, rolled this system out to those companies. It worked well for them.

- Even in this case, helping them be the biggest in their (local) industry, they eventually wanted to move to a big-boy system. The lines of custom code become paper cuts. Arguing over budget, infinite demands from across the company. Friend, as always, helped them in every way possible to get the right result.

- Friend helped them move from a custom system to an ERP + custom. That hasn't been plain sailing, it's extremely hard to move from a custom solution because it fits like a (sometimes hairy) glove. Over the long term, probably the right move. But you lose a lot of time in the switch, time that could be spent beating competitors.

He was fully dedicated to the customer success. He charged extremely well, it made him financially. He owned it. You absolutely need ownership, and you need a smart person owning it. He knew that his success lay in always putting them first. If you can hire that person, great, but in this case the money helped him be fully committed, for an extended period of time.

I later spent time at a startup bank, where we assembled an incredible system out of build + buy, with a SAP core. This will absolutely trigger the HN crowd but it was an excellent base. You do not want to be figuring out how you do rounding, or multi-currency, or storing user data. You do not want to be responsible for every line of code in your stack indefinitely. You want to know what is yours to own and build and will help you differentiate, and what is important to have but will just get you parity (e.g. accounting, invoicing, marketing, whatever). You don't want 100% custom code unless software is a big part of your business and it'll give you an edge over competitors, because it's both an asset and a liability. The thing to keep in mind here is TCO - Total Cost of Ownership. A good ERP will help you roll out business features really fast without having to reinvent the wheel. Don't modify too much of the ERP where it's not really important to do so, rather use as much standard tooling as possible, because you need to own all the changes. There are also absolutely risks here. SAP deployments can crush companies.

Skills. You want a setup that has easy access to skills, indefinitely. It's very hard to build something and know that it'll always be in fashion. React will one day go the way of COBOL. The team replaced the front-end a number of times and kept the core database. That stable core was the best thing they had, for a very long time.

Remain agile. If a component or team isn't working, switch. Don't marry every technology. In the bank, we switched very large pieces out and it was always the right choice. CRM, API Gateway, messaging technology, hosting technology for some parts of the stack.

Be careful what you depend on. Every part of the stack wants to make you dependent on them.

Try to avoid a big boolean switch when you turn off the whole system and move to the other one. If you can strangle the old system and chip off pieces as you learn, great. Sometimes it's not possible and you're in for a lot of weekends while you check the new one does everything the old one did, and doesn't fail in some weird way.

ribpx
0 replies
2h36m

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

There's a lot to gain by building.

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

rgblambda
0 replies
1d

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

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

raphar
0 replies
14h50m

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

What worked great to me as dev?

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

. I learned a LOT about the business and loved it

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

What worked great for the business?

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

. they understood the strategic constraints and possibilities of their software

what was tough for all?

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

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

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

randomtree
0 replies
8m

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

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

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

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

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

random_savv
0 replies
17h30m

How much does the third-party software cost?

ragebol
0 replies
22h58m

Is acquiring the third party software provider an option? And then staff them with a few more ppl maybe.

radicalbyte
0 replies
2h56m

If you're in logistics and have an ARR in the $200-$300M range then you are not a big player. Logistics is a massive field with a lot of variation. It would help if you could share at least some details: where in the chain do you sit?

My experience is in the car industry with factory-to-dealer and some of the supplier-to-factory. The core systems were built by SAP, they were very expensive but they were reliable thanks to some smart architectural choices. Those were supported by various bespoke solutions to solve very specific requirements over the company.

In general, at your size, and assuming that you're doing something with retail-like margins (1-2%) then you're almost always going to be better off buying and running some COTS solution. The time look away from that is if there is nothing suitable on the market and if there is a strategic move on the table. Software systems can give you a big competitive advantage. It could even be a way to build a sister business - I can give you a number of examples where companies have "scratched their itch" and then spun off their software as a product company.

So what do you do? You know your business. Can you afford to waste ~1M EUR a year (3-4 really good freelancers in Europe + cloud/license costs) for a couple of years next to what you're already doing?

rachofsunshine
0 replies
21h27m

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

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

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

-----

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

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

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

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

- Salary

- Work-life balance

- Stability / trajectory

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

- Working with specific technologies

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

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

qqqwerty
0 replies
2h37m

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

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

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

purpleblue
0 replies
1d2h

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

1) Can you acquire this company?

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

prewett
0 replies
1d

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

You absolutely can attract talented developers; this company preferred to hire very experienced people, and that translated into minimal management. (Which also created a high level of ownership by the devs, because they can proactively fix what needs to be fixed and directly add/fix what people/users are complaining about.) They also used a functional language, which tended to limit the pool of available people to people who were capable of quickly coming up to speed.

Even after you have something working, you'll probably end up having to do a fair amount of development just to "stay in place", since the needs of the business are (presumably) constantly changing. Sometimes this can take longer than you'd like. But the advantage is that you get exactly what you want. If you're struggling with your current software, it seems reasonable to write your own. You might want to start with writing just the most frustrating part, and then the next frustrating part, etc., rather than trying to implement the whole thing. Especially at the beginning it makes the project smaller, lower risk and you get more successes along the way. And if it doesn't go well, you'll find that out earlier.

pphysch
0 replies
22h50m

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

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

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

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

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

physhster
0 replies
18h11m

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

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

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

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

penetrarthur
0 replies
6h40m

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

You are pretty much ticking all the boxes:

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

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

pbrum
0 replies
14h32m

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

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

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

ownagefool
0 replies
19h48m

Many of us, myself included, will be predisposed to controlling our own SDLC, largely because of bad experiences with vendors. Personally I've had vendors shutting down a product that was core to our offering with basically no notice, performing poorly but not accepting responsbility, just milking T&M, and just straight up lying.

The problem is, all those outcomes exist with hiring your own developers, and it's really difficult to mitigate unless you yourself are a strong developer who can run projects and teams and look beyond what people are telling you.

Reality is, it's impossible to answer the question without really getting more information. Specifically around what you spend on outsourcing / licensing, what the feature set you're going, what the budget for the new team would be, and what the expected outcomes and timelines are.

Without the context though, some quick fire opinions.

- You probably at least want the dry powder. i.e. the person making the outsourcing decisions should at least have the technical accume to bring it in-house if required. If they're not a person that could, then outsource is the only decision they can realstically make, then they'll tell you it's the right decision even when it isn't.

- You need someone mature. If they just want to build everything from scratch always because of some personal bias, you'll end up amassing tech debt in areas where there were limited risk / benefit. Developers will 100% tell you you need to building things because it's interesting to them, even when you don't really need it.

- If you're going to do this with any near-term success your first hires are really key, and they likely won't be cheap. I see people debating brining in a team vs a CTO, but both strategies fail if the quality isn't there. Figure out how to validate quality.

I was CTO of from ~25m to ~£75m ARR UK Point-of-Sale org with ~100 tech employees. Those roles are hard to find. This sounds like a great opportunity. Lots of folks will likely do the hard sell. Good luck.

osigurdson
0 replies
13h17m

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

nyarlathotep_
0 replies
2h57m

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

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

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

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

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

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

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

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

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

nurettin
0 replies
22h5m

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

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

nsiemsen
0 replies
21h25m

I agree with a lot of the "how to" suggestions here. One addition is that you need to have a small number of key non-development employees really guide the development with strong opinions on functionality. This will likely mean your strongest folks in the departments that the software will serve. I would avoid building this by committee. 1-2 of your best folks who will be the ultimate end users should have massive decision-making power in what gets developed, in what order, and for what purpose.

Also, don't underestimate maintenance in your cost assumptions. Even after you've developed the product, you will need several people full-time just to maintain, update, and bug fix, let alone add new features that got sidelined during the initial development in order to meet the MVP.

nprateem
0 replies
9h5m

TBH it sounds like you need a tech business consultant (an actual consultant, not just a contract programmer) to help you work through this.

If you add your contact details to your profile I'm sure some people will contact you.

Ideally you'd want someone with a postgrad in business and a decade or so tech experience to help guide you through this (cough)...

novia
0 replies
23h55m

Besides, can we even attract experienced developers to a non-glamorous industry like logistics?

Yes. There's overlap between transit nerds and software devs. I'm one example.

noduerme
0 replies
22h10m

I work for a company in the decidedly not-sexy area of pet hospitality. We began building our own software when revenue was under $1M and we're now about 1/4th the size of your company and operate completely on our own software platform. The CEO of my company would convince you to at least try it in a heartbeat. As the original freelance developer and now the CTO, I'll give you the pros and cons from my perspective.

For the first few years as a single shop, they used one then another suite of SaaS designed for the industry. These had some basic public-facing reservations website and a billing system tied to a database of customers, pets, vets, and calendar entries that employees could manage. But the owner was developing his own operational techniques in all areas of the business, with an eye toward building a franchising platform. Operational "secret sauce" he wanted to add in software included: How animals are separated and managed in groups, intelligent maximization of kennel space over time given inter-pet relationships (e.g. family, friend, enemy), tracking pet health and eating habits, matching employee schedules to volume, how reservation slots are filled or saved for most-loyal customers, rewards programs, seasonal rates, franchise-level business variables, getting customer feedback, daily photos and communication with customers, a mobile app for employees to track pets around the facilities in realtime, custom printed collars, projecting volume to fine-tune upcoming sale prices or peak rates, and on and on. It was difficult or impossible to get any features or even bug fixes from the SaaS developers.

He hired me, as a lone freelancer, and paid me half of my estimate up front to spend a year writing him a software platform from scratch. Version 1 did all the basic things he was getting from the SaaS, and then we began iterating on all of the ideas and unique methods. It's been 15 years and one complete rewrite in a more modern language. The company has grown to 8 locations, managing roughly 200 pets per facility at any given time. I have - very rarely - brought on other developers to help, but basically the entire platform is easily manageable by one person and it's not even a full-time job. Our entire operating cost for servers, storage and backup is about $500/mo.

Upsides: They can get pretty much any feature they want, built quickly and cheaply. I understand the business model inside out by now, so I'm able to quickly spot any potential operational or technical pitfalls in new ideas, and work with them to align the software to exactly what their intentions are in new policies, as opposed to just following a feature spec. Just as a small example, when they changed their rules about deposit amounts and cancellation deadlines and fees a couple times over the years, it became much easier to write a subsystem that allowed them to manage those things themselves. Being so tailored, the software prevents employees from making common mistakes. Rollouts are VERY fast, sometimes in the same day as a minor feature is ordered up. We can make new versions available to one facility to test in production and see what bugs crop up, then roll out to the rest. Over time it has been more expensive than any SaaS, but at this point it would be impossible for the company to do what it does without the custom software. Owning the software has itself been a tremendous value addition for both investors and franchisees.

Downsides: As my friends in the tech industry love to point out, all of this constitutes a lot of technical debt. If I die or something, they're gonna be pretty screwed for awhile. As it stands, it would take someone else awhile to come up to speed on the 500k LOC we have across 5 different apps in the suite. The software runs itself, it hasn't gone down in years, and it's recoverable if it does, but as far as bug fixes or new features or dealing with forced upgrades it would take awhile. It didn't have to be this way; they could have hired a team or transitioned to one. Given the CEO's outlook on building things himself, he would have built a team if he felt he needed to. Knowing what I know, they're lucky they chose me as a single point of failure and not someone who might decide to switch careers or retire early. But those are avoidable pitfalls.

Final advice: Take time to choose well-supported technology stacks that will be around a long time. Documenting code. Most importantly, have your coder(s) work directly with the people responsible for writing and developing your operational / business procedures, and have them collaborate on writing the software manual. That way the logic of the business is understood by the coders and the logic of the software is understood by the people responsible for creating and implementing operations.

It doesn't have to cost a fortune to get up and running and it's way, way cheaper than hiring an outside firm. Personally I love working for companies outside the tech industry who need in-house software, it's a much better culture and the results are immediate and tangible.

nmaley
0 replies
16h26m

I think you are asking the wrong question. Before you decide what to bring in house, you need to have an IT strategy That sets out what components of your desired solution should be built, and what should be bought. You need to have a view about which technologies you will use, and why. What is your end state IT architecture? Have you prioritised your objectives and requirements?

I understand your current systems are holding you back and there may be no appetite to get a bunch of expensive consultants in to answer all these questions. But just hiring a bunch of devs without a plan for what you want them to do is a recipe for disaster.

nivertech
0 replies
2d15h

If it would cost $X to develop this system inhouse, you could write down the requirements and offer the vendor to add the missing features to their product on NRE[1] basis for the fraction of $X (including support and warranty).

NRE means that the IP remain their, and they will be able to amortize the costs across multiple clients.

Assuming that this vendor is unresponsive because they're not incentivized enough (e.g. fixed pricing or SW licensing fees), not because they're incompetent.

Also, most software projects fail[2], especially inhouse ones. I would expect vendors to have a much higher "not fail" rate (but not necessarily "success").

--

[1] Non-Recurring Engineering

[2] stagnation is also considered failure

nicolasrod78
0 replies
20h18m

I can see there's a lot of good advice in the comments. I just wanted to contibute my 2 cents to the matter. I've done a lot of conversions, interconnection of disparate systems, migrations, monkeypatching and straight abominations in my day. In your position I would hire senior freelancers to patch the system in interations. First, fixing the most anoying issues you have in order to streamline the whole process. This will allow the programmers to really understand the domain and based on that knowledge iterate and consolidate pieces of the architecture until you have what you're looking for. I don't really believe in complete rewrites or starting from scratch based on my experience. Most of the users/companies I've dealt with (small and big) don't really have documented processes and domain knowledge. Well, that's not fair. It's rare those are documented and up-to-date. That's better :-) I agree with some of the comments, the technical challenge is what attracts people (at least that's my case). If you're looking for people to tackle something like this, please send me an email :-) Cheers.

netbioserror
0 replies
14h44m

I work on a team that produces sensors, sensor analysis routines, and web infrastructure to distribute the sensor analysis to clients. We manufacture in house, and our in-house software team is roughly 5 people depending on how you include roles. I do the actual analysis routines, math-heavy native-compiled stuff. The others do web frontend dev, mobile dev, and backend server stuff. Our current strategy has worked so brilliantly that after 20 years of ancient codebases and constant fires, we've had a year of relative quiet as everything "just works". We now have the most advanced analysis package in our industry. Here are the main points, with a small dev team in mind:

1) Silo responsibility and keep the structure flat. Minimize how much people are stepping on each other's toes by giving them one whole "piece" of the puzzle and letting them take ownership of that piece.

2) Give them freedom to approach the problem with the best methods and tools they know how. Tasks should be long-term goals that allow the engineers to flex their creative and problem-solving muscles. Competent engineers will find ways to communicate and coordinate with who they need to, when they need to.

I must emphasize tools. If a problem could benefit from a new language, let engineers explore that path. In replacing some maliciously obfuscated 20-year-old C and PHP code, I entertained several languages before settling on Nim for our analysis routines. It slots easily in to our servers and is invoked via scripts, makes fast C executables, and the maintenance, refactoring, and readability jump has almost made my job too easy. You will need to balance against "bus factor", but keep your competitive advantage in mind. Take a strong look at web technologies like Clojure and HTMX that can attract talent, keep head count low, and increase product quality and maintainability.

3) Use team interviews. Your team will work together to suss out fakes and find good fits far better than any single interviewer, especially a single interviewer without the requisite expertise. Don't just ask technical questions, ask open-ended critical and creative thinking questions.

4) Do entertain the possibility that young and fresh engineers can integrate well, learn quickly, and explore possibilities you never thought of. Our hardware team has a couple of much older (60s) engineers with very old-school practices who are dragging them through a quagmire. Keep an eye on your competitive advantage.

5) A note on our company's old issues: Eons ago, they hired a VERY expert (PhD qualified) engineer as a contractor years ago to build all of their systems. He fought them over the intellectual property and deliberately obfuscated code to keep his job. Make sure your team is in-house and salaried, and that you own everything they produce.

Also, avoid desktop applications. The current state of desktop is a disaster. It's difficult to make anything truly useful, and you'll probably need a web view anyways to make use of JavaScript libraries that actually do what you want. As much as it sucks to say, your software probably needs to be a web application. KISS, and again, look towards tools like Clojure and HTMX to simplify things.

Host as much as you can in-house. The decline of "cloud" has already started. Make sure your IT person is competent and can architect solid infrastructure, because you can't expect the same from Microsoft or Amazon these days.

neeleshs
0 replies
18h29m

Bringing development in house also means managing the operational aspects of it. And QA as well.

You mentioned low code tools. Can you push that tool more, and potentially add an integration platform for EDI?

I would try that first, before committing to a large in-house footprint.

necheffa
0 replies
1d1h

Strategies for attracting and retaining tech talent in a non-tech industry

As someone who is a tech lead at a non-tech company that does software in house for a niche product in a niche market...

You can either treat the software as a product in it of itself (as opposed to bolting it on to other projects for your core business) or you should expect to include some hazard pay to compensate for the mental and spiritual trauma caused by trying to pretend you can treat the software like a line item in non-software projects that "just" need software support, ending up with 4-5 project managers trying to oversee/status a single software release.

We do the latter and if some of the other benefits were not as good as they are, it would absolutely be a deal breaker.

I suspect most other non-tech companies also operate in a similarly sub-optimal way (the blind leading the blind), but why would I put up with that level of ass-hattery for anything less than what the market can bear?

mrwyndham
0 replies
22h8m

IMHO I believe nearly every organisation I have worked with at this size always has a management problem.

The reality is if you want your teams to be competitive adding contractors competing with your in-house staff can be a really good thing.

Most in-house teams are jaded with management and having contractors set to do jobs (of course they have to be good) injects some life into the organisation.

If your in-house team is toxic you need to go and be the one to monitor that.

I worked on a team where when the CPO was there it was actually amazing but the moment he left their idiot head of engineering and middle management had a field day doing nothing

mpeg
0 replies
1d2h

So this kind of "platform independence" approach is something I have been hired to figure out a few times before as a tech consultant

Often a very similar story to yours, what I find that works consistently:

- Start small, don't plan to replace the whole platform in one go, but instead figure out what elements can be separated and replaced individually. Even if this means having to integrate with the existing platform it will be the better approach

- Have a migration plan, even if you are replacing individual pieces of functionality each piece will involve retraining users and have its own quirks, so have a plan not just for the data and tech migration but for the user side of it

- Focus your development efforts in the core of the business, leverage open source and SaaS for the rest – with a rebuild it's very easy to end up going way above budget and time if you focus on the wrong thing, this should also reduce scope creep

- When it comes to onboarding developers the most important thing you can do is document everything as well as you can – that way if developers leave half way through the project you reduce the impact, and new developers will be able to ramp up quickly and overall be less frustrated

motherfsck
0 replies
2d

I've not worked in the logistics industry or with edifact specifically but have dealt with phased removals of large "turn key" products in a several heavily regulated industries. I've also gone the other way where we've replaced in house solutions with vendor provided software.

Email is in my profile, feel free to reach out. Full disclaimer, we're a small consulting/contracting agency but I'm still happy just to talk shop.

monkfish328
0 replies
18h3m

Whatever you do, try to do it incrementally in phases. That way, you'll learn iteratively :)

mmattax
0 replies
4h35m

I've been an early engineer in multiple start-ups, have co-founded 2 startups, and about a year ago, took a position where my primary role was to in-house logistics software in the healthcare space being developed by a 3rd party for about 4 years.

To succeed, you need a founder-type person IMO, who's full-stack, and has built great engineering teams. Hard to find, but possible.

The company I joined was also not a software/tech company, and they put the trust in me to define our engineering policies, how product-management happens, and put an emphasize of knowledge transfer for my first 3 months.

If you want to connect + talk more I'm at michael[at]mat.tax

mlhpdx
0 replies
5h43m

If your company is part of a large ecosystem underserved by software vendors, building solutions for yourself and others may be transformational (as AWS has been for Amazon).

The thing with software is that it is rarely (not never) commercially successful to develop single customer solutions. So if you can build something that works for your business and can be used by your suppliers/partners/customers in enough volume to pay for developing and maintaining it, you win.

misiek08
0 replies
51m

As someone who did similar thing for few, little smaller business I will tell you - it depends.

Personally I did some software that saved a lot of money on licensing and hosting, almost none on-call activity as the software is stable and it is required to work 12/5, no 24/7. The only thing - I was more than „into the business”, loved the challenges and wanted to solve them.

On the other side I’m currently helping company from different industry because they collected few great talents, bought them great hardware, explained business and paid a lot. The team wasted almost a year, produced more crappy software than the existing one and left choosing someone who don’t know yet how bad SE they are.

If you will be looking for a consultation or for the team - I’m more than sad there is no contact info, because reading your description already made me way too interested

milesward
0 replies
23h12m

Seems like a good fit for a development contractor/consultancy: get pros to try to gin up a v1 clone fast. If they show that it's not too bad, no gnarly gotchas, have them help you hire folks who can get to v2 and beyond. Starting a software dev practice is daunting without prior applied experience, use the cheat code.

michealr
0 replies
2h54m

I have worked freelance in similar situations.

Personally, I find it really fun. It's a nice mix of development, design, and organizational understanding.

What I want to do is divide up the project. Usually, these legacy systems don't have clear division points; it's all a big bundle of interdependence. But in my experience, there's usually some less impactful secondary functionality that can be spun off.

That will allow you a few things:

Figure out what you quantify as success for such a project. Its limited scope makes it easier to identify the endpoint. Allow learnings about the legacy system, and perhaps identify what elements you can extract from it—not necessarily code, but in previous work, I've been able to wrap or scrape data in certain areas to provide a sort of external output. Figure out how to work with devs, manage your own time, and educate your organization about what you're trying to do. The third and last point is critical. The failure modes for development are obvious, but the political and design impacts are less so:

1. Lack of experience

2. Poor scope

3. Overly complicated solution

etc.

But the real failure mode is political. You need a developer with some political acumen as well. There's going to be a lot—and I mean a lot—of interviewing people about how exactly subsystem X fits into their workflow. You need the political skill to navigate that, in terms of getting buy-in and quality information.

Downstream of the political dimension, in my experience, is the possible design solution. The actual interviews with people and the regular, constant contact with staff about their job are critical to building something that replaces the existing system but doesn't replicate its design failures.

One mistake you want to avoid is building something too similar to the old solution and missing out on critical information about how the job is actually done.

Also, I'm not currently looking for work—enjoying my current role—but if you want to hit me up, feel free. I can at least impart some experience on what to do.

michaelsalim
0 replies
8h42m

Agree with many of the other commentors. I think you need someone to talk the details with. Someone experienced can tell you how big the scope will be. Lowest risk is to get some freelancers to create an MVP and go from there.

Happy to chat about this with you. Contact details in my profile.

mgl
0 replies
21h23m

It’s actually great to read your story (apologies!)

The answer is YES and we have built Openkoda* as an open-source alternative to Salesforce Platform and other closed low code vendors specifically for these reason.

Happy to connect and share our story.

* openkoda.com

mekoka
0 replies
15h53m

I've helped "bring software dev in-house" a few times in my career. Never in the domain of logistics. My (biased) perspective.

If you don't already have an existing (and talented) development team, it's still possible to kickstart things, but be careful how you go about it. Imo, the ideal early team in this context is small and multi-faceted. I'd look for good pragmatic coders with an entrepreneurial streak (e.g. experience having worked as part of an early stage startup, or having started one, even as a solopreneur). Why? Because although this type understands tech, they also have genuine concerns for business goals, not just with playing with cool toys. There's a lower risk of painting your company into a corner and racking up technical debt, because of unnecessary complexity and a propensity for shiny stuff. You want people that can look at your org, its goals, and make good technical trade-offs for the next year, the 5 after that, and beyond. The result will probably be a simpler and unsexy tech stack, that still works great. You want good coders that can make stuff, but can also recommend that you use an Excel spreadsheet, or subscribe to an API, where it strategically makes sense.

That's the kind of profiles I'd look for as my first hires. You can certainly reach a successful outcome with non-entrepreneurial coders too and I'll be the first to admit that my outlook is biased. But having been around this particular block a few times, it'd be difficult to change my mind that at least one adult must be present that understands both the tech and the business concerns.

Now here comes the caveat.

This type of profiles will likely not stay for the long haul... and frankly it's perfectly fine if they give you 6 months to a year. You just need to be up-front about it. Having devs who aren't looking to become dependencies in your org, if approached openly, also insures that there's a stronger focus on replaceability and long term maintainability as a core concern. You'll get people that are genuine in their interest to see you succeed, but maybe not looking to be passengers in your ship, or members of your tribe, or whatever. That's ok. They'll still give you their best to get you to your moat, even establishing the baseline and readying you for a smooth transition.

Just another perspective. Good luck.

meiuqer
0 replies
9h7m

I know you're asking for advice and not looking for someone to hire here, but the company I work for does just what you are asking for: Creating custom made software for B2B companies.

Check us out at www.bizzomate.com

We are focused on low-code solutions but we try to understand the customers needs through service design. We also have our own business rule engine that might be useful to your case. We also have experience building mission critical ERP-systems.

Anyway, check us out and feel free to contact us!

mdbmdb
0 replies
1h36m

I'm running a team of SDE's and, from my experience, bringing development in-house is the last resort simply because of high risk/high cost. You have to pay your devs hell or high water whether they are moving at a rocket or turtle speed. We have worked with oil&gas and logistics customers, and their in-house development always drags 2-3 times longer than expected. If your pocket can allow it - you may try it but about 80% of customers I have worked with or talked to moved from in-house development to outsourcing it.

My team would love to look at your project for free just to give you an option to consider. Feel free to contact me at Polarwind99@gmail.com

mattbillenstein
0 replies
16h41m

It all hinges on hiring the right people for the job - you may want to find someone very senior who perhaps doesn't want to build it themselves, but can help you evaluate tech talent - help you hire the first few key senior people to get started.

And I'd say, if whoever you hire can get the database schema nailed down more or less correctly in the first iteration or two - you'll be good. It all hinges on finding someone who's done this sorta thing before, won't over complicate it, and can wring out the first level of mistakes before implementing an entire software system around it. Knowing the business in and out would definitely help here.

lowbloodsugar
0 replies
18h57m

No.

As a software engineer, I will never again work at a company where the product is not software. Software at non-software companies is a cost center, not a profit center, and cost centers get fucked. It's thankless, depressing, soul destroying work.

Maybe start a new company whose goal is to write software for companies like yours. I have worked at a startup launched by execs from established industry with inside knowledge of what is required, and it was truly fun, even though the great recession brought it to an end (acquired for pennies).

If you do it yourself, in house, there are plenty of thirsty contractors and consultants who will be very happy to bleed you dry.

Basically, if you have to ask, then the answer is no, you can't afford it.

loandbehold
0 replies
2h3m

Don't try to rewrite the whole system in one go. Move incrementally. You can start by creating your own UI that performs most common functions and uses existing system as a backend. This way you can automate what you need and work around bug. If it goes well then later you can gradually move to your own backend.

leowoo91
0 replies
16h7m

Just pick a popular ERP solution and work with an official partner company to that ERP.

kyrofa
0 replies
21h40m

There are companies out there (full disclosure, I work for one[1]) that create and maintain custom software for companies such as yours, including websites. They work with you to make sure you have exactly what you need. That direction may prove more effective than trying to bring tech talent onboard.

[1]: https://www.miriamtech.com/

kylehotchkiss
0 replies
20h7m

Can you purchase the provider and then own the existing code, and hire up to build on top of it? Tear It All Down might be an expensive fallacy.

kraig911
0 replies
14h41m

Probably not going to see this comment but if so can you answer these questions. Have you shopped around for an alternative? Do you guy shave complicated stuff like tailing an origin of an order back to a specific sales person? Do you need 3 way matching? Do your customers prefer using an ERP you're always working with? What are the things holding you up your execution?

On the ERP stuff I've done a lot and it's usually the reason stuff gets buggy and 'hard'. Stuff like say realistically you have to complete an order of say 10 linear feet of rope but it comes in packs of 6 so they have to order 2 but the sales rep said they'd sell the remainder on another work order etc etc.

The ERP you might have one guy that's on oracle, another on something custom, and these systems all interface differently.

Another is in the quoting process if you are making quotes that are timely or have an expiration. Some things just take a lot of foresight when you set out to make them.

koliber
0 replies
1d1h

First, get a senior person to lead the effort. They need to have experience hiring and managing developer teams. Ideally, it is NOT going to be someone with a lot of wizz-bang shiny tech on their CV. You need someone who wants to understand your business, and will focus on business value, and swallow the elephant one piece at a time.

Strategies for attracting and retaining tech talent in a non-tech industry

This varies, but if you manager to hire and retain 200 employees, I'm guessing that you'll do alright.

Experiences transitioning from third-party to in-house software (success stories and cautionary tales).

If you have a decent manager and someone who can make sound technical decisions, you'll do well.

Potential pitfalls we might not be considering.

You seem to have good awareness of the danger areas. Devil is in the details. Figuring out how to slice the problem and building things piece by piece will be important.

Alternative solutions we should explore.

In general, outsourcing companies are hit or miss, but if you find a good one, you will get many of the benefits without the downside of managing software dev in house.

Having a more seasoned person supporting the lead engineer will help you avoid costly pitfalls. I'm being self-serving, but a fractional CTO working a few hours per week might bring the kinds of safety check that will make such an endeavor more successful.

klu_
0 replies
10h0m

I'm in the process of similar transition in global manufacturing company, where my role is to build internal engineering team to essentially increase ownership and remove reliance on external vendors. So far I would say it worked, but with a few caveats. One key thing to note is that usually you don't have to build e2e team to replace your current vendor, as replacing key roles might be good enough to drive visible positive change.

What I would suggest is to divide the work scope into smaller chunks, eg. isolate applications / systems. This will allow you to distribute the work to other vendors or your own in house IT team. The change usually requires a lot of work in different areas, such as clearly defining people functions, R&Rs or work organization. Then you insource key roles, and see if the effects are what you're expecting. Having some local CTO type of person to drive the change would definitively help.

Overall I would expect the process to take several quarters, highly depending on your system complexity and vendor lock-in (they will not be happy about the change!).

I've seen in the other comments reco to find freelancers instead of FTE, and it could work depending on local market specifics. In some countries you have to watch out for employment laws and potential issues. I'm based in Poland so can provide more info if you want to chat (myr11242@gmail.com). Good luck regardless :)

kkoppenhaver
0 replies
2h16m

Full disclosure: I'm a Technical PMM at Retool, which makes me a little biased, but I'm also a developer who’s seen these sorts of projects from both sides.

I generally agree with most of the commenters here, that you need a team of just a couple experienced people to start building your in-house platform. But when you're constrained with that small of a team, building something full-code can make it tough to find the momentum you need to get any one solution over the finish line.

If you already have a solid software development process or a team already in place, maybe going with full-code could work. On the other hand, we have a customer that replaced a custom-built React dashboard that was powering their whole business with an app entirely built in Retool, and let them work with the team they already had in place. Empowering the entire team is one the reasons Retool exists. They’ve been prototyping new features incredibly fast, even the non-technical folks on their team can contribute, and they haven’t had to worry about managing freelancers or attracting and hiring a team.

You've got a lot of choices ahead of you and a lot of good advice here in the comments. Feel free to reach out to keanan@retool.com if I can help sort through any of it!

kissmd
0 replies
9h6m

I you still need some help after reading all the comments, feel free to reach out, i will consult you for free to get you started (or maybe even after).

kingkongjaffa
0 replies
2d19h

We do a lot of data exchange via EDIFACT

I dunno how technically difficult this is, but consider either hiring an expert on this stuff, or hiring your core software engineering team, and hiring a consultant/freelancer type who is an expert in this stuff to get it done / up and running.

Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning from third-party to in-house software (success stories and cautionary tales). Potential pitfalls we might not be considering. Alternative solutions we should explore.

Part of outsourcing, is you're not just buying the technical solution, but the support and potentially the liability if something goes wrong. So it's important to consider what secondary benefits are baked into using a third-party, and deciding if you have the ability and appetite to support those as well as developing the tool.

I sort of imagine that replicating the tool / business process is the easy part, it's stuff like setting up and wrangling EDIFACT that will be the hard things.

kareemm
0 replies
3h26m

I run a one-man dev agency that staffs up a team to help non-technical execs build their v1. Here are some learnings:

1. There are three common dev team models: in-house, individual freelancers who eat what they kill, or agency (where you're sold by a principle and then juniors do the work). I recommend to all my prospects that if they can find a trusted lead dev, they should go that route - it's more economical for them and when I roll off a gig I set my clients up with the senior dev that built their app. Next best is eat what they kill freelancers - more expensive, but faster and incentives are pretty aligned. I would recommend NOT working with a fully staffed agency - they make money by having juniors do the work and incentives are often not aligned - they have staff on the bench they need to feed work to, so their incentive is to keep running the project until the client is out of money.

2. I just wrapped an MVP build in logistics for a European client. There are lots of devs who want to work on interesting technical problems, and for whom the industry doesn't matter. I hired two devs to build the MVP and both were keen on the gig. That said, it's hard to attract and evaluate good talent without at least one of those folks in house, which is what I do when I staff up a dev team to build my client's MVP.

3. Transitioning from third party to in-house - I'd pick the key pieces that are isolated from a business process perspective from the rest of your existing tool, spec them out with wireframes (https://www.reemer.com/consulting/roadmap), and build those. One of the biggest failure modes with building software in general is not enough definition of what "done" looks like when it's cheap to iterate and change (i.e. before code has been written). It's painful to write a long spec and wireframes (I've been doing it for 20 years) but once you've fleshed our your v1 and agreed on ~95% of what the final product looks like, it's generally pretty straight line to writing the code and shipping the product.

4. Re: quagmires - you need someone wearing the product management and engineering manager hats. Product will ensure the app's functional and technical requirements are clear, and an engineering manager will ensure your dev team doesn't get stuck spinning its wheels. In early-stage projects one person often wears multiple hats. Later on you can scale it up to an individual PM and Eng Manager in addition to your devs, if necessary.

Happy to chat more if you like - no sales pitch... just drop me a line a k@reemer.com.

jtriangle
0 replies
1d1h

As a business decision, having on-staff developers mainly comes down to value.

Can those employees generate their salary in value? How long can they do so?

It makes little sense to in-source dev if you have 6 months of work that revolves around bugfixes. Less still if what you're building isn't saleable, which in your case it sounds like it isn't.

The other side of this coin is, you suck at dev management. Your whole company does. All companies start at that point. Any project you pickup at this point is going to feature creep to the moon and cost 2-3x as much as it should because it's not going to be well defined, and it's not really going to accomplish what you'd like to accomplish.

The best advice I can bring you is, take on a SMALL project first, very small, like a single-purpose app, pick one thing at your company that really sucks to have humans do and isn't complex, build an app to do that. Probably use outsourced contract dev/devs to do it, have them bid on it. Make sure your product requirements are bullet pointed out and crystal clear. Your mother should be able to understand them. Do not set an open ended timeline, because you're going to get high bids as it's a clear sign you're a newbie and are going to be expensive to work with. Project check-ins/meetings should be defined and scheduled, create stages and meetings for those stages, and review them upon completion, again, all defined in the project pitch.

Basically, you want a developer to be able to take what you've written, and complete the project with no surprises.

Do that a few times, make the project a little bigger each time. You will learn alot, and once you have a few things under your belt, you can start to consider hiring your own dev team.

jrochkind1
0 replies
3h2m

I work at an in-house software development team, although it's a very small one at a non-profit, so not directly comparable.

But I would say you should know you are not going to save money by going in-house. The success criteria should be getting a better product that supports your business, not saving money. It will cost more than your current software costs.

i don't know what size team you are considering, but you certainly can't do this with less than 3 people, and that's probably too small. (not all of them are necessarily 100% "programmers", there are management and other tasks, more below)

I don't actually think logistics is particularly unglamorous, I think it's as interesting as most and more interesting than lots -- but it may not be interesting enough to attract talent at significantly less than they can make elsewhere. So you're going to have to be paying at least somewhat competitive salaries -- good news for you of course is that the job market isn't great now. But still.

So think about how much it will cost to have 3-5 (possibly more) staff at competitive for tech jobs salaries... is it still potentially worth it to your business?

If it is, then great. You've got to hire good talent, including especially someone skilled at figuring out what the software should do. Product management/product ownership with a dose of user research thrown in. This may or may not be a developer (probably not, but maybe), it may or may not be a manager of developers (maybe). This will be the hardest part of execution. Just doing everything you think you as the boss need, counter-intuitively, won't actually lead to a successful product at an affordable price -- you are wrong thinking you know what you need. (Yes, I can say this with confidence not even knowing you, it's always true).

Trying to copy everything your existing software does but then adding more -- or trying to keep all the workflow exactly the same while switching software -- won't lead to a successful product at an affordable price. Part of the product design isn't really product design at all, but business/workflow design.

You could considering hiring a consulting firm to write and then maintain this software as well. That will probably not be cheaper than doing it in-house -- (although it could be if your in-house plan goes seriously awry!) -- but may have a higher chance of success than building an in-house team (and getting the right team!) if you pick the right consultant. It also of course gives you more flexibility to cancel or scale down the project at any time if it's not going well, vs the emotional and sometimes legal or financial pain of laying off employees.

jppope
0 replies
23h49m

Weird way to approach this... since its a critical business decision, wouldn't you like a formal professional opinion? Seems like it would be worth the $500/hr for a week to get real information that you can use to get a decent view of what your options are...

jokethrowaway
0 replies
19h29m

Your fear is correctly placed.

I've seen plenty of companies rewriting complex software written by a third party considered ineffective.

Here's why they fail:

- Underestimate the work and assign a team of 4 juniors to replace the work done by an entire company

- Implement new features during the rewrite: never do that, focus on getting a 1:1 replica first

- Business people pressure the team in various stupid ways (artificial deadlines, scrum) because they've never done software and have no idea what's a software project or because they've read blog posts from influencer and they're bad at their jobs

At 200-300M you're at the size where you can do your own software. I'd recommend to:

- Buy the third party you complain about, then improve it

- If that fails, pay people above average and good people will come. Try to find technical leaders with experience in product (think ex startuppers). Pay a bonus for good results. Give them operational freedom as long as they deliver results. It doesn't matter if they are employees or a software agency or contractors, they just need to be good and give you ownership of the code. Given you don't have talent in house, find a friend who is a good CTO or VP of eng and pay him/her to do some interviews.

Best of luck

johnwatson11218
0 replies
2h15m

I think asking here is a good idea but you should also try this question on the LLMs like perplexity, chatGPT , etc. This question might be too high level and not contain enough context, but you can ask the model how to focus your question to specific aspects of your business. The models can outline the tradeoffs you can expect once you pick a tech stack and a team. The models can also suggest how things might go wrong and what you should watch out for. Try and get the LLMs to design your test suite.

Remember: There's no one-size-fits-all answer. The best approach depends on your specific circumstances, goals, and resources.

johan_larson
0 replies
20h43m

Do you have any people in your company who could build what you need if given the time? Sometimes there are people who are pretty handy with coding who aren't called "programmers". They may be analysts or engineers or something like that. And is there anyone who understands the domain, has solid leadership skills, and at least a bit of tech skill, enabling them to serve as a project lead?

If you have both of these, you could conceivably use your existing staff to build at least a limited-functionality version 1, and backfill the jobs they used to do with new people. If not, you have the harder problem of needing to hire people to do something you don't know how to do at all.

jeroen
0 replies
6h18m

I would start by defining an MVP. What do you really need to support operations, and what can wait until later? If it can be done by hand for a while, don't put it in the MVP. If you can manage with Excel for a few months, don't put it in the MVP. That should give you insight into how big of a project you are looking at. The bigger the project, the greater the chance it's not going to go well.

EDIFACT is a bit of a mess, but not that scary. IME the details of logistics are more complex.

If you are in Europe there are a lot of people in software development in non-glamorous industries. I see more risk in judging tech talent. How do you know if you're talking to the right people?

jerdthenerd
0 replies
15h8m

I'm late to the game on this thread, but I am a lead SWE at a medium size logistics company. Been in logistics SWE since 2015. I'd be interested to hear how your company fits into the industry, who your service provider is, which no code platform you're using, etc and at the very least give you a sounding board based on my experience. Shoot me a DM if you're interested!

jbs789
0 replies
21h14m

I observe that the question is focused on “should”, not “how”. So my first question is less about the “how” and I am more curious about whether differentiated tech builds your competitive advantage?

Suspect you can further differentiate with a bespoke team, then defer to others on how to execute.

jbjbjbjb
0 replies
21h2m

I think it’s certainly doable and sustainable.

Pitfalls you’re not considering:

Maintaining it. It will have an ongoing cost of keep things running, secure, up to date. This will get bigger and bigger as the project becomes more integral.

The right mindset. You don’t want devs who approach this as is they’re building the next Amazon or Google. You don’t want it over engineered and have devs trying to be too clever/ padding out their own CVs. This might also make it pretty boring.

Unless you have some dev who is very interested or experienced in logistics you’ll need a some people from the business investing time helping explain what the feature is and acceptance testing it.

jasonteunissen
0 replies
20h56m

Hi, my ex colleague pointed me here.

This is exactly what we specialize in: logistics and transport digitization. we are www.lowcode.co.nz and have experience and connections in EU, but NZ needs some help with digital maturity (and much nicer weather here too).

We are currently building our SAAS platform for cranes and hiabs called mothertrucking.co.nz (sign up for free as we are in stealth beta)

What you have mentioned is exactly the pain we see a lot in this industry, (tools get made, then the budget stops, and it becomes hard to maintain, and all the original devs have moved on to more fun projects.)

Id be keen to have a talk to understand your struggles.

jart
0 replies
11h34m

Do you really employ 200 people, all of whom don't know how to code? What kind of sweatshop are you running?

janalsncm
0 replies
20h33m

Without having a ton to add, logistics might not be the sexiest industry but you can do a lot to make the role more sexy, especially to senior engineers. Making the role remote is worth $50k or more in and of itself, and vastly broadens your talent pool. Juniors are the ones more likely to be willing and able to relocate and commute.

j45
0 replies
23h40m

Hello,

I've only done B2B transformations (revisiting all software systems and realigning/reimplementing them in parallel) like this in multiple verticals, both physical and digital, for the past 20 years as a Fractional CTO for companies in your revenue range and larger.

As needed I can traverse the entire pyramid from top to bottom from business strategy, finding partners and vendors, and informing everything down to the nuts and bolts alone for maximum alignment, and ensure it's learned alongside team members in the organization.

I often help with the budgeting and estimating process and find customers save significant time and money with the right strategy, approach and oversight.

Here's my take:

1. ATTRACTING TECH TALENT:

- Consider a contract-to-employment model. I've built teams where contractors who prefer employee life can switch over. There's other options too depending on your current mix and structure.

- Emphasize training at all steps. I guarantee clients a trained and productive resource, regardless of employee or contractor status.

2. THIRD-PARTY TO IN-HOUSE TRANSITION:

- Success: Helped clients reduce days-to-cash by 50% with custom solutions, projects relatively on time, and staff that remained able to work in the new system.

- Caution: Seen projects stall due to underestimated complexity, or avoiding realities (ie., data may not be as good as they thought)

- Run fast from anyone who wants to build only code from scratch from the outset. Also run from buying an all-in-one system until you know what your critical path is. I have worked around and through both, including from the start, and rescuing projects.

3. POTENTIAL PITFALLS:

- Underestimating current system complexity.

- Cloud lock-in: It's the new software/vendor lock-in, just sneakier. There are ways to have your cloud cake and eat it too while maintaining options.

- Over-engineering: Build software has become horribly overcomplicated. It's hard to keep things simple and flexible, easy to make it complicated. Helping everyone understand the data and process together sheds a major light on the path ahead and create a better sense of ownership.

4. ALTERNATIVE SOLUTIONS:

- Hybrid approach: Develop core competencies in-house while using strategic third-party solutions.

- Agency acquisition: I've facilitated M&A deals where companies purchase agencies.

- Vendor-as-internal-department: Set up external vendors with internal SLAs.

KEY CONSIDERATIONS:

- I would start with an honest assessment of where your organization truly is and where it wants to be. Beyond advisory or building, learning where your business needs to head and measurable ways to get there is critical.

- In-house dependency is important, but there may be better external options too that can be much more stable than an agency with interests with multiple clients.

- Any culture change and planning for it is critical.

- Industry standards (SOC, HIPAA, etc.) and architecture will ultimately decide the fate in 5-10 years.

- I keep software sales promises honest and accurate to the company, ensuring clarity on current state and future direction. Includes negotiating contracts that work for the business, not the vendor alone.

I have a lot of conviction about what I do because I've done it and still do it, keeping up with where things are headed to provide input on where things could be. I train to process, and so the process is central.

If you'd like to chat more, I'm happy to offer an hour of my time.

I'm genuinely curious to see how much actual valuable information and insight I can provide to help you think through your situation. Firehose, or key points. My email is in my profile or reachj45@gmail.com

My goal is to give you as much food for thought as you like, knowledge as possible, regardless of any direction you ultimately take. My email is in my profile if you're interested in a no-strings-attached discussion, except I'd like you to bring the most painful issues.

The world is an odd place where people who don't understand software sell it to people who don't always know how to buy it, let alone roll it out. Navigating this can be an outlier for impact. I'm here to help change that where it crosses my path and get technology working for people instead of the other way around.

Note: Edited from a laptop instead of written from a phone. :)

In case anyone's thinking of reaching out, offer is open to anyone relative to my availability.

ipmb
0 replies
21h35m

I'd be happy to share my experience with you. We've solved problems like this for a lot of folks with small or non-existent internal tech teams. I agree with the small team of experts approach, but there are pitfalls there too.

Feel free to reach out pete AT lincolnloop.com

insane_dreamer
0 replies
1d2h

Having been in that situation and developed SW in house as well as hired third-party firms to do so, based on my experience I would go with in-house if 1) you have very specific requirements that need to be well understood and implemented, and which may require close collaboration with the teams who are actually using the SW; 2) the SW in question is mission critical; 3) you want to be able to make changes/adjustments fairly quickly without the overhead of administrative/contractual dealings with a third party (i.e., whether it fits under existing SOW etc.).

imoverclocked
0 replies
19h13m

I’m just an engineer so I’ll leave the “shoulding” to others.

Can you attract experienced developers? Yes.

Do all of your developers need to be highly experienced? No.

EDIFACT is an old standard with lots of code floating around to parse it. I don’t know the ins/outs of its usage but an in-house team should be able to tackle this kind of data exchange without too much difficulty. You will likely want to ask candidates about experience with this data format explicitly. You can also ask about related data formats or information exchange in general but you’ll probably want at least one developer with solid experience with the format.

ilaksh
0 replies
1h38m

I suspect the quagmire might come as much from dealing with government institutions as it does from programming. Does the provider already have relationships that facilitate that?

If you can work around that, then the EDIFACT thing means that it is very inaccurate to say you have a "straightforward CRUD app". I am a freelancer and if I saw those two statements together it would be a red flag, like you were trying to minimize the complexity to try to pay poor rates or didn't understand what CRUD was or just wasn't thinking clearly.

EDIFACT in a modern context where we have human readable formats like JSON, looks like a nightmare. I suggest that you see if there are any libraries you could build off of such as pydifact.

You should also start trying to collect a comprehensive documentation of everything that software is doing for you. In detail. No programming team can be successful without that information and aside from the EDIFACT stuff and bureaucracy that will probably be the biggest bottleneck is discovering that.

ibash
0 replies
1d2h

If you do bring it in house look for very senior folks, ideally ex-founders who’ve built a product from scratch. You want someone who can help figure out requirements, feasibility, and write code. Pragmatic engineers are always the best.

happy to chat about this if helpful, email is in my profile

iamthepieman
0 replies
4h22m

I work with companies that hire us to do exactly what you're describing. I've seen this go bad every way you can imagine. Here's some of the top mistakes.

1. Expecting employees to support a project like this and do their regular day jobs. They can't. One will suffer, probably the one that is new and unfamiliar. This will frustrate the team working on the project (whether it's in house, freelancer or contract firm).

You can hire some new people first and train them up in a short time to take simple tasks off longer term employees plates so they can spend some percentage of their time supporting the project. Don't hire new people to support the project, they don't understand your business well enough. This is a cost of doing this type of project that is often ignored. And don't allocate something small like 10% of employees time. It should be at least 50%.

2. Expecting the project team to get all the requirements. Understand, in detail, what you need to build. This is not the time for agile. You have a known system that you want to replace. You aren't discovering a new application space. You can run the project with sprints, agile rituals etc. But don't do requirements throughout the project. Get them up front so the team knows what they are building and can architect it appropriately. This is a topic that I could write pages about but you will wish you had better specified requirements no matter how well you do them. You can carve out a small piece of the application at first to limit the scope but that piece needs full reqs.

3. Get something done and in the hands of your users now. I like to start with a checklist of a process. Replace one item on that checklist. Repeat.

     login to system
     click shipping
     fill in manifest -> identified as the piece to replace. 
     check schedule on calendar tab
becomes

     login to system
     click shipping
     fill in manifest
         login to new system
         export manifest data
         import into new system
     check schedule on calendar tab
4. Setup your development, testing and production environments and keep them in sync.

iamgopal
0 replies
20h30m

We do contract base software development in India, and have worked with https://haulog.com/ recently. If you’re considering to start with outsourcing to jump start, Let’s exchange few mail ( patelgopal@gmail.com ) and see if we are compatible enough to try and make a demo or something.

iamatoool
0 replies
10h7m

Why not go to tender? For a solution, either SaaS and custom modules or pure bespoke.

Also WisetechGlobal might be a choice.

hyperpape
0 replies
23h52m

What you don't say is what the product is, what you spend on it, and what its value is to your organization.

I'm in the software side of logistics, and I can imagine very different things you could be referring to, with different levels of effort and different levels of benefit/risk to you.

If it's just cost-savings, then this product has to be quite expensive to justify your time. If you're hoping that a better version of this product could make your operation more reliable and efficient or unlock new business opportunities, that's a much better proposition, though still hard.

huijzer
0 replies
22h59m

I have not navigated a similar transition, but I have studied CS and read tons of business books.

I think if you do this and take the development seriously, it will be a ridiculous good return on investment. The success to Tencent according Mohnish Pabrai was that they had ROI on their developers over 10 years. They just put everything they could in development and if it was too much they would spend the rest on lower ROI categories. Overall 50% ROI. (IIRC).

It’s also essentially vertical integration if you do this. If you think it can make your beer taste nicer, as Jeff Bezos put it, then it’s probably worth it. Note that Amazon’s in-house team spawned a new industry. Also, Tesla is currently much ahead on competitors due to their software. I think many car manufacturers underestimate how much Tesla is ahead. The apparently even have their own ERP system called Tesla OS.

For attracting and retaining, I think you can definitely do it. There are engineers who like to see physically how their product is being used. Short feedback cycles can be very rewarding. Also, to retain I would look at Napoleon. What is the best for morale? Winning. Give ambitious projects and make them succeed.

hooby
0 replies
13h3m

Regardless of whether you hire in-house developers or hire a software studio that does contract work - I believe the key to success is giving the developer unfettered access to an experienced subject-matter expert who really understands what is needed.

No offense meant - but by my personal experience, executives like yourself are a bad choice for this - some experienced longtime employee that's deeply involved in day-to-day operations in the trenches, would be preferable, I think. Ideally somebody who went through process changes before - like was already working there before your current software had been introduced.

Don't get a developer who wants to start programming right away - you want somebody who asks for time to first really learn and understand the processes the software needs to cover - and who actually questions all the underlying approaches your current software takes - but does not just rule those out out of hand.

Then get that senior employee to mentor them and teach them the job - not the existing software. I would even advise have the developer DO the work for a while - under the supervision of that senior employee.

hippari2
0 replies
11h2m

A bit of a naive question but can you acquire your provider's company, or poach their programmers ?

heraldgeezer
0 replies
21m

On the other hand, while our current solution seems like a straightforward CRUD app

So I have been on both sides of this. Not as a dev but in IT.

1 - As IT support for customers of a CRUD software.

The truth was, the company did not know their own software.

Coded in the 90s, touched up in the late 00s.

Original devs long gone, all quit en-masse.

Current dev team forced to bolt on new features.

Rework of the entire app needed (on-prem IIS and MSSQL dependant).

Sales & Management (they were the same people) selling features to customers that did not exist or were not on roadmap (straight up lying to customers)

"Project management" consisted of them calling devs/support cellphones wanting $New_Feature coded they just showed a mock-up of to a customer.

2 - As an MSP IT technician. Customers have no idea what we do or what they buy.

"Why are you so expensive/Why is this not just included when ur so expensive!!!"

- vmware servers in secure DC, management of windows server and linux (updates & backup, installation of software etc, monitoring for cpu, ram, disk, network)

- management of on-prem AD and Office 365 Entra users and groups

- Exchange and Office 365 management for email

- Endpoint management (Hardware, GPO settings, Entra policy, windows updates, software inventory and install & updates, remote support for users over RMM)

- Antivirus management (SOC not included)

- DNS filter

- Office 365 Backup (This is needed, MS has no care for your data on Sharepoint)

- Network (WAN, Firewall, L2 Switch, WiFi & management/troubleshoot and updates for all of it)

Then we get a "deer in headlights" look and "but you are just IT"

Just my 2c. I have no idea what to do in your situation. Maybe you are getting ripped off, but it will also not be easy.

hekker
0 replies
23h26m

Shoot me a message, I am VP of Engineering at large European software logistics company, where I had exactly the same challenge (outsource vs insource). Email is in my profile.

hcarvalhoalves
0 replies
3h32m

If you're having this pain, and there's no better provider, other companies in this business might be struggling too.

Are the companies that do well in this business also deploying in-house software? Are they partnering with someone, or are they suffering? I would try to benchmark this first.

If you go ahead and decide to deploy in-house software, you'll have to make the case that this isn't a cost center and is an actual strategic investment, otherwise it won't work.

My take: every company that has an edge in today's market eventually turns into a software company too.

haolez
0 replies
19h30m

I've done that kind of movement at least once as a CTO of similar-sized companies. There are risks involved. Over engineering this system would be my biggest concern.

Hit me up if you want to talk. Contact info in my profile.

hammadfarooq
0 replies
15h3m

I have been working for one of the client based in UK. It deals especially with fleet management. My team developed the software for them and now it’s around 90% complete. The CEO of the company is very close relation. He discussed the requirements with me and asked me for an advice. I told him that if you are going to hire someone in UK, the cost of having developers on your site or getting a deal done with a company based in UK would be way more costly. Instead get a team here in Asia (the IT market in Asia is way cheaper than that of UK or whole Europe). I started crafting the team and now the total number of the guys working on his product is 15. The thing is you have to find someone very close that is trustable. If you have idea of how the software are developed that is a huge plus point. Hiring freelancers on the remote location is good for a small project but a project like yours needs dedicated team. If you need more help in this we can have a chat.

hahamrfunnyguy
0 replies
22h24m

Since you can't find another vendor, it might be time to bring on software consulting practice that specializes in this area or at least doing something similar.

If you can find a firm that is capable of doing the work, then you can figure out how you will maintain the software. You'd have to determine whether it would be better to engage that firm for the maintenance or hire someone. Possibly a combination of both. This could be done while the software is being built.

Large software projects are more likely to take longer than estimated and go over budget, so be sure to factor this in to your calculations.

gwbas1c
0 replies
22h44m

The best developers I've worked with, in my career, were all from contracting firms. (Distillery, Ralabs, EPAM.)

First thing: If you outright fire your contracting firm, you'll loose all of their knowledge. This could harm your company more than you realize, depending on how much your business relies on their knowledge of the code and your processes.

What I would do is have some employees who work for you, who are experts and "in charge." They should be experienced in hiring and screening, and should be able to give you an honest assessment of your code base's maintainability.

At that point you can decide, with your expert employees, how much to outsource with your current firm, how much to outsource with a new firm, how much to insource, and most importantly, what you are doing wrong in your relationship with your developers.

The thing is, software development can fail for many reasons, and a lot of them have more to do with you than your vendor. You might have unrealistic expectations, you might need to work more closely with your contractors, or your contractors might be "warm bodies punching a clock." It's hard to know unless you have people you can trust hands-on.

groby_b
0 replies
23h16m

You said EDIFACT - it'll cost more than you expect :)

You'll need to attract folks who care deeply about the space (yes, they exist, for some people logistics is fun), are seasoned software devs (the pool shrinks) and set them loose on the problem with as few restraints as possible.

Your best bet here is an approach that gives them a stake as well. Either as an external experiment with performance gates, or by founding a subsidiary that they co-own, or ... well, any number of solutions.

Yes, you won't be able to outcompete FAANG on salary, but you can outcompete them on autonomy. And a lot of experienced devs care about the latter part more. (Having made and saved a good chunk of big tech money)

Biggest issue will be vetting the people you find. If you don't have inhouse experience, either take an approach like davedx suggested, or reach out to somebody who has (hekker)

gijoeyguerra
0 replies
14h31m

I'm gonna go out on a limb here without knowing much about your situation and say that you're intuition about "...our current solution seems like a straightforward CRUD app, I fear the devil is in the details" is spot on. CRUD is inflexible when modeling processes. It doesn't have time as a core part of its design.

But the problem isn't about the details, it's that most developers don't want to actually do the job that they're trying to automate with software. They won't shadow the warehouse workers, they won't pick product, they won't work with the tools to do the job. Thus, they won't understand how to write software that models your businesses processes because they won't venture to experience the pain and gain the knowledge. They'll just end up building a CRUD app that uses the latest frameworks and "Best Practices", which, unfortunately, have nothing to do with making your business adaptable.

Sure, there's exceptions, but they're hard to find and demand a high pay because of the daily value they create. Hi ;)

You can attract experienced developers to a non-glamorous industry like logistics (I would LOVE THIS JOB). They don't even need to be experienced developers, they need to be willing to gain empathy by "going and seeing" the work to model it correctly.

Look for people who want to create value, who want to "go and see" for themselves before writing any software. The curious shall inherit the earth.

You don't need to hire a bunch of people, so pay well.

I hate saying this, but marketing is everything. Start posting on LinkedIn. I know. Everyone hates it. But software developers are on it. And so are tons of people looking for jobs.

When you do finally hire someone to do the work, go live every day. And the only way to do that is to identify small wins in the processes. Start chipping away at the bottlenecks. This is the way.

Good luck. You're not alone. So many people have the problems you're experiencing.

frankfrank13
0 replies
23h58m

The provider is understaffed and unresponsive and the platform is stagnant.

You need a new vendor, if you can't afford it, you may not be able to afford a proper in-house team. I've worked with great vendors that would not give you this experience, and vendors that would you give you far less than you're getting now.

Besides, can we even attract experienced developers to a non-glamorous industry like logistics?

Yes of course you can. But reach out to engineers in your network that work for non-FAANG companies and understand why.

fragmede
0 replies
22h24m

Here's a thought: "just" buy the vendor.

We don't have any of the details, but have you considered that? They already have the code to do what you want and know the problem space very well. Then your problems with them becomes a problem with themselves.

foxbee
0 replies
5h17m

Consider using a low code platform to test your thesis first. Use a platform like Budibase or something, that's open source, you can self-host and use your own database for security reasons.

flareback
0 replies
1h57m

I would look at what you could buy off the shelf before building it yourself. I know some of the guys at Rygen.com and they're building some great logistics software. I don't work there or have any financial interest in it myself.

fhars
0 replies
6h48m

One solution is to partly outsource the development. You would try to build up a small team that deeply understands your business and the solution and and owns the system can maintain it long term, but cooperate with a specialized service provider for the initial development (which will probably require more developers than you will want to ratain long term). Such a service provider will also be able to support you with he generation of the initial project vision, requirements engineering and usability/user experience engineering with experienced teams, whithout you having to hire for such roles out of the blue.

While there are many such companies in Europe, I can recommend the one I just so happen to work for, mail me if you want to discuss it further.

exabrial
0 replies
1h22m

Start by reducing or removing legal + compliance. It's where innovation goes to die. You can have reasonable compliance and security without burying everyone. Make them concentrate on real present threats, not theoretical ones.

Next, sort out the egomaniacs... there's two types: those who are "too cool for school" to comply with some basic standards like... I dunno tabs vs spaces or code formatting, then the guy that wants to rule with an iron fist and one-size solution everything.

Finally a strong opinion: modern web development is absolute crap. I would favor server side rendering frameworks and nearly zero javascript for internal apps. We're here to get stuff done, we're not here to coddle the user.

eqkRZX_wmv0jqp7
0 replies
22h17m

Get some experienced freelancers ( small team ) give them a proof of concept application to build. Review.

ensocode
0 replies
1d11h

Interesting questions. I Work in the logistics/B2B area for quite some years and know this kind of problems well. I think in-sourcing development can be beneficial if your niche has so many special requirements and this is a core application. Or you can go with a trustworthy software house as a partner to be a bit more worry-free. Our customers usually do the project management and the requirements and we are taking care of the solution's technical aspects. In my experience this makes a perfect match especially in technically "non-sexy" environments like B2B, EDIFACT. On the other hand it takes time building trust from both sides.

empath75
0 replies
22h9m

You can first write software to work around shortcomings of the existing solution, and then gradually start replacing more and more of their functionality with stuff you've written in house.

elbear
0 replies
11h0m

It sounds like you're running with your breaks on, because of the software issue. So, finding someone who can make the software work right can at least remove that obstacle from your business.

For this, I would hire an experienced developer who can look at the current solutions you are using, the third-party product + your low-code solutions. If you find a good developer, they can at least design a product that integrates the functionalities from your 2 existing solutions. Even better if they understand User Experience.

Another good sign is if they want to build it in a "boring" technology. Java would be a good choice, because it's robust and also because it's easy to hire for it in Europe.

Frankly, for starters, you need Design + Frontend + Backend + Infra. You either get one person for each, or a person that does the first two and another for the last two.

Also, I recommend doing a fixed-rate project with milestones. You can use a generous budget (50k - 100k), depending on the complexity of the software. This way it's in the best interest of the people you hire to deliver on time. You release payments when features are delivered and meet standards.

If you want to talk more, my contact is in my profile.

One more thing, which I think is very important. If you build the software right, it can become a force multiplier and enable your company.

eitally
0 replies
5h8m

I used to run the "Enterprise Apps" org in a low budget F500. My team of about 125-135 (globally distributed in US, MX, BR, IN) managed dozens (hundreds?) of internally developed apps and a number of externally licensed SaaS & on-prem systems.

The reality is this: if you are not a software product company and you decide to create internal tools yourself, your life will become one of perpetual technical debt, and deciding whether to prioritize new development vs refactoring vs platform modernization. When you license products, you just throw money at the problem, but when you DIY it, you end up also needing to implement things like Change Control Boards, a real PMO, more security & privacy controls/competency, and internal tech support functions. This can work and be cost effective, but you really need to go in with your eyes open and account for all this "mess" you'll be creating as you create this new team.

It can absolutely work and save money, but it requires 1) xfn executive buy-in and clear agreement around change management and feature development prioritization, and 2) a budget for things that go beyond just the software development.

Fwiw, if this is an "IT" function and you're not a product company, you'll be able to save money by employing "enterprise software developers" (e.g. IT staff) rather than SWEs (tech product company folks). You'll also benefit from their experience navigating the complexity that comes with all the crap I listed up above, much of which is fairly foreign to small tech companies.

edpichler
0 replies
10h5m

It's complicated. Building software is very expensive and high risky. You can try with a small project in-house and get your learnings from.

Yes you can find people that want to work in a non-glamurous company easily. These places are excellent if you want to see your work doing direct impact in improving peoples lives.

dyeje
0 replies
2d4h

I was the technical cofounder of a logtech startup. Logistics has a lot deep problems that need to be well integrated for a smooth UX. I think this is why you tend to see people eventually try to pivot into building a TMS (and why it takes so long to build one). They start solving a specific problem. They realize it’s not worth much without the whole picture and nobody wants to let other players integrate.

If your specific problem is well contained enough, it could be a good fit for in house. You mention that you’re filling the gaps with a low code platform. You could perhaps experiment with moving that piece in house as a trial run. You also say that your existing platform is stagnant, perhaps you could acquire them or the specific IP you utilize. You might learn some valuable insights about what you’d need to do in house even if you don’t end up seriously engaging in an acquisition or if it ends up falling through.

I wouldn’t be concerned about attracting talent, plenty of engineers in logistics already and it’s a hirer’s market right now.

Anyway, the devil’s in the details as you mentioned, my contact info is in my profile if you’d like to chat, happy to give what perspective I can.

dvdsgl
0 replies
42m

We specialize in creating custom software for businesses in your exact same situation at https://glideapps.com, and we have a large community of consultants who can build for you as you develop an in-house capacity. Our top experts can build a POC for you starting around $5k if you want to quickly test the platform–you can get a quote here: https://www.glideapps.com/solutions

dualogy
0 replies
2d11h

We're using a third-party product that functions, but barely. The provider is understaffed and unresponsive and the platform is stagnant. It's a fight getting basic bugs fixed let alone new features implemented.

If that product (area) could be named or sufficiently-described, the audience size & substance here on HN might lead to 10 new hungry sleek alternatives popping up within a quarter, which won't be satiated=stagnant for years to come and keep it maintained and improved to customer feedback (if they find takers and a keeping-the-lights-on adoption curve). It's a hacker but also startup forum. Why not, while gathering all this good advice on your question, also share what this is all about in terms of _what_ in your niche / b2b market corner is currently badly and under-served?

Plenty currently-underoccupied top talent here noodling on their techie pet projects while hoping to hit on some obscure / vertical / niche-specialized but promising real-world making&shaking (ie. sth to found build launch & expand) opportunity. =)

domgio
0 replies
14h42m

I’m doing project like this for more then a decade now. What worked?

- evaluate the new team on some thing very special for you for example try to take from the 20% you never realized

- if this work don’t feel you are on right rails.

- go next creating the smallest project that bring the most value to you

- piece by piece you will have replaced the most important parts of the old system

What didn't worked?

- if the management is not very convinced and involved

- if the old system doesn't have api or in general has poor interoperability

- don’t change target, try to keep the target frozen until the job is done and testable

dilippkumar
0 replies
1d

My email is in my profile. Here's an offer.

Let me build this thing for you. Exactly, to your specification, by sitting and working with you and your team, and solving exactly your problems.

Once the solution is done, you can either buy the software org from me or chose to license it from me.

Happy to talk details.

diavelguru
0 replies
18h31m

One thing to remember is that some/most are not turned off by a non-glamorous industry like logistics but rather attracted to solving problems regardless of the industry. I’d hire someone who can actually do coding (so not a CTO, CIO level) that is also or has been a lead who can delve into your business and review existing products and can get you an 80% POC in under 3 months. It may not be pretty but it will help you better position to ask for more $$ for contractors or other employees. Start with 1 then scale from there. I’d give them 1 month to study the existing system with no deliverables other than documentation that will be used to replicate your product needs. I’d also be sure to hire a PO (Product Owner) if you don’t have one and have them also learn the product inside and out as they will be the gatekeeper between the coders and the users as to how the product functions and that the coders fulfill all the requirements.

devdudect
0 replies
1h23m

I joined a logistics company with a history of two unsuccessful outsourced software development projects. Their third attempt was also failing due to the developer prioritizing their own startup over delivering the contracted software. This resulted in unaddressed bugs, lack of client on-boarding support, and lack of the developer delivering functionality they were contracted to deliver.

I was brought on board to salvage the third system, but this proved unfeasible. As an interim solution, I built a system to enhance data from the third system, enabling the operations team to utilize it for planning and execution.

Collaborating with the CEO, we analyzed strategy, risk mitigation, and evaluated alternative vendors. Unfortunately, proof-of-concept trials were unsuccessful due to vendors not meeting our requirements.

To gain deeper insights, I initiated direct meetings with stakeholders at our client companies to understand their specific needs and business rules, recognizing the importance of minimizing localized exceptions while providing a solution that would work for all clients.

I then conducted meetings with the CEO and a key client to observe their utilization of the third system and pinpoint areas of success and failure from their perspective. Understanding client reporting and data needs is crucial, especially for those submitting reports to their local boards and international logistics teams.

I advocated for developing an MVP to automate manual tasks performed by control room staff, ensuring timely operations. The MVP was successfully launched first with a different customer and then rolled out to the original client. The original clients second site also adopted the system, and we transitioned from the legacy system during a holiday break. Benefits included reduced scheduling time due to zoning and suburb storage, resulting in significant time savings for planners.

Key takeaways include developing a comprehensive needs analysis document outlining your company's requirements, documenting business rules, noting pain points, and evaluating if the current system adequately supports business needs and figuring out what your wish list for a system is. You can then write a requirements document referencing back to the needs analysis document before starting to develop the software.

Software development projects fail when execs / management do not understand their requirements. Something they think is shiny today may not be tomorrow and their focus shifts.

devbent
0 replies
12h52m

Possibly dumb question:

How large is the company supplying the existing software? Can you just buy them, or even just that one team supporting the product line you need?

debacle
0 replies
2d2h

Strategies for attracting and retaining tech talent in a non-tech industry

Treat your product team like wizards, not a cost center. Make sure the product director is a tech hire with business chops, not a sole tech hire (will let the team resume build) or a sole business hire (wont understand the peaks and troughs of velocity).

Ensure that the customer is clearly defined internally, that the KPIs are oriented towards the bottom line, and keep things well-oiled but lean.

Your best solution would be to spin off an internal company with eventual plans to commercialize what you build. You want someone with startup/entrepreneurial experience.

Anyone who promises you a product within 3 months or tells you it will take more than 12 months for an MVP is snowing you.

Happy to chat more, my email is in my profile.

deanebarker
0 replies
23h1m

Incidentally, "Domain Driven Design" was written around a theoretical logistics/shipping platform. That book didn't make it seem "non-glamorous." Everything is exciting to someone.

deanc
0 replies
7h28m

The question that you need to answer is do you want to be a technology company, or a platform company.

If you want to be a technology company and own your stack you need to ask yourself questions such as:

- Can we attract and _retain_ the necessary talent with the resources we have in order to build software? It's no use if you can't attract quality talent, or keep them. - Do we have the resources to maintain this software for however long is required by the business? - How much resources are required to match feature-parity with the existing solution, and can you meet the requirements of all existing stakeholders based on the assumptions you have today?

... and a gazillion other questions. But it all boils down to the fundamental first question.

dboreham
0 replies
11h45m

Long thread so I'm not sure if someone has already made this observation, but -- reading your description of the single entrenched supplier to your industry that comprises your company and a set of competitors, made me wonder about "going bigger". This is the idea: yes start a team to develop a greenfield modern solution to meet your needs, but do that with the goal to eventually spin it out as a separate company that is also a vendor to as many of your competitors as you can sign up. The benefits to this approach are that more resources can be brought to bear, meaning better developers can be hired, and the cost can be shared between the participants. This has been done in the past for example by the airlines with Orbitz, and media companies with Hulu.

dbg31415
0 replies
14h30m

I wouldn’t necessarily focus on “retaining talent.” Instead, I’d build a system where losing talent won’t hurt you. (Although, you can usually avoid losing talent at inopportune times with some simple performance bonuses -- "Get me through to X point, and you get a bump.")

A project like this will require a variety of people. New builds, problematic builds, or maintenance projects all demand different skill sets -- and different personalities.

If you need someone to jump in and untangle a mess, the right person for the job will have a take-charge attitude. However, that same attitude might cause issues once the project is running smoothly.

If you want someone to get it done and build it right, that’s great. But that person might be bored to tears when you transition from an all-hands-on-deck build phase to a skeleton crew for maintenance.

If you need someone who can maintain the code, tirelessly clean it up, polish the rough edges, and fix bugs, chances are that person wouldn’t have been the right fit to kick off the project.

These are all oversimplifications, but you get the point.

So, build the system assuming you’re going to lose staff. Hire people who are productive and get things done. Ensure you have good documentation and a solid handover process in place. Make sure everyone on the team knows how to do builds and has a designated backup.

What I’ve seen work really well are small teams -- like an “agency within the company” model. I’ve done a lot of digital transformation projects over the years, mostly in eCommerce and mar-tech systems (all systems with many integration points).

The single biggest thing that dooms projects is bad requirements. For example, "Oh, I don’t know how XYZ system works, but I’ll be damned if I’m extending that old agency’s contract by another year, so we’re losing access to the data on Friday -- just do what you can!" (This actually happened on a past project, and we lost the entire Product Information Management (PIM) system, forcing us to manually redo a lot of data. Don’t be that guy.) Make sure your system is fully mapped out and that you understand how it works before replacing the team.

When building your team, start small, as others have suggested. A product owner (who can double as your UX designer in a pinch), a tech lead (who can double as your QA automation engineer) -- look for people who can wear multiple hats. Over time, the team can grow, but start with a small team and challenge them to impress you. Then, sit back and see if they do.

Give them plenty of leeway. Don’t burden them with a bunch of “this is how we do things” processes. Hire smart people, empower them to make changes and challenge you, and let them tell you what they need to be successful.

From experience, I can’t stress enough that bad requirements kill projects. Someone creates a totally BS PowerPoint, hands it to a dev, and says, “Build this!” Or some junior dev says, “Yeah, I don’t really understand, but we can do five years’ worth of effort in three months…” That’s a recipe for disaster. They panic, cut corners, and leave you worse off than where you started. No junior folks for mission-critical roles -- seriously.

Look for pragmatic, honest, and hardworking people. Anyone who isn’t comfortable telling you to “fuck off” when you deserve it shouldn’t be in a leadership role or on a mission-critical project. Look for people who strive for a deep understanding.

You’ll also need to give them the right tools. I’m constantly shocked when I show up at a company where the cheapest person on my team is billing $1,200 a day, yet the company wants to saddle everyone with five-year-old Dell laptops and no external monitors, mice, or keyboards. Or worse, they say, “Here’s our 12-year-old Jira instance, but you don’t have admin privileges…” or, “You can VPN in and use a remote desktop client that runs like it’s on a 56.6k modem!” (I’m trying not to be outrageous, but both of these are issues I’ve faced in the last year.)

As the stakeholder who will own this team, make sure all the other BS is cleared off their plate. Give them whatever equipment they want, give them the project management systems they prefer, and don’t try to shoehorn them into your existing setup. Provide them with all the admin privileges they need. Your job is to knock down all the barriers that slow them down.

So, look for a strong leader who’s willing to dig into the details and isn’t afraid of hard work. That should be your point person to start with. “I want you to move a mountain for me -- what do you need to get it done?”

Happy to chat, my email is in my profile.

davidelettieri
0 replies
13h17m

Have you thought about investing in the third party provider? Getting a share might give you a say on where development should go and what support requests get resolved first.

datadeft
0 replies
9h16m

Seems to me that you got a quality management problem. Does not matter if your team is in-house or remote, software quality is a problem. I would try to understand why your code has those problems.

As we are growing we're running in to the limits of what this product can offer. We're being hampered in our speed of execution and missing crucial insights.

You need to hire few very skilled software people, it seems you can afford them.

d_burfoot
0 replies
20h8m

Hi, I built a low-code platform WebWidgets.io (WWIO) specifically for companies that are too unique for cookie-cutter SaaS products to work well, but not big enough to do their own development work. I've built several WWIO apps for small businesses/nonprofits that have saved multiple FTEs worth of manual data work in Excel.

WWIO achieves high productivity by moving all the logic into front-end JS code, which accesses and persists data to SQLite DBs on the backend with a simple, standard API (for VIP clients like you, I would augment this with some backend Python scripts). This approach makes it super-easy to build the CRUD features, while allowing a backdoor when you need special functionality. For a sports camp nonprofit, we did a backend integration with Google's OR Tool library, to solve their scheduling problem with a single click:

https://webwidgets.io/blog/sportscamp.html

I would love to do a call to discuss your needs. If WWIO seems like a good match, I'd be happy to build an MVP at no charge and create a strategy to move forward with minimal risk. If not, I'd be happy to share my thoughts as a seasoned engineer. Contact info in profile.

d883kd8
0 replies
17h12m

You could try posting here the specific industry/niche and the software that’s not working for you, and chances are they’ll have three new competitors before Monday morning!

cynicalpeace
0 replies
4h32m

Get 1 cracked dev and pay him a lot of money. Problem solved in a month.

The hard part is finding that "cracked" dev.

cxmcc
0 replies
19h22m

I'm working on digital transformation for a traditional company. Challenges are from both culture (80%) and technology (20%, EDIFACT/COBOL is ok, not the worst part for us). Traditional companies can retain talent -- they definitely can compete with big tech if they want to. Especially in current tech talent market, you still have a good window to hire enough talents. A few key questions that you need to answer: - Can you get support from the top (board/CEO) to modernize HR to create competitive comp structure? - Can you identify real engineering leaders that can commit to the job? -- You can't just hire non-hands-on random middle managers. Good engineers don't want to work for politicians. - Do you have political stability to invest in the transformation long-term (3yr+ or more if you are more massive)?

coffeemug
0 replies
21h24m

Drop me an email at coffeemug@gmail.com. Lots of ideas I can't share here.

codr7
0 replies
20h6m

Pulling something like this off is pretty serious business, there are a million things that can and often do go wrong, which is why so few software projects are successful.

And you're in a pretty shitty position, to be honest. Because you don't even have the skills required to hire the right people. Much less handle the project yourself and delegate tasks.

My advice would be to find someone you trust with plenty of software experience, explain the situation and LISTEN to what they have to say, especially when it's not what you want to hear.

Or you're likely going to waste a lot of time and effort making the situation even worse, happens every day.

codegeek
0 replies
2d

If this product is critical to your core. business, bring it in house. If not, then keep it 3rd party but look for a replacement/new vendor.

claytongulick
0 replies
14h36m

Hey, CTO of a healthcare company here, been doing the CTO thing for over a decade, and in tech leadership for nearly three.

My advice is to work to find a partner that has both deep technical experience (they should write code most days) and practical business experience. That's hard to do, but unless you can, I think you're better off not bringing dev in-house.

Whatever that person's title is, make sure they have some skin in the game. They should be able to understand business goals and recommend technical strategies to meet them.

I suggest finding someone who is at a point in their life and career where they are not using the opportunity to build their resume, but are instead focused on the success of your business.

It takes an experienced leader to resist the pressure from hype marketing and developers to use the new shiny, and instead focus on software that will have a shelf life of 5-10 years.

There are seemingly irrelevant technical choices that you won't understand (like the choice of a UI framework) that can end up costing you millions in "framework churn" (I've directly experienced this several times). This is where it takes a leader that is aligned with business goals rather than interesting or popular tech-of-the-moment to make the tough and unpopular calls.

Technology is the beating heart of your company. Evaluate your technical partner with the same rigour you would use for your cardiologist. You're placing an enormous amount of trust, and I'm not being hyperbolic when I say the wrong decision can cause your company to flatline.

ckrodrigues
0 replies
23h45m

Hey! We also went through the some process, and in the logistics space. We ended up developing a solution in house. Because we fully understood the problem we were able to build the best product for us at the time, but it did took considerable investment from the company (and while the product was great, still questionable if it was the right investment to make). On my side specifically: I ended finding that what we built could be generalized for similar verticals, and now we have a SaaS product based on what we had built internally.

cisrockandroll
0 replies
6h16m

I work in logistics and let me tell you what I think would attract high quality developers.

#1 good benefits. More than 2 weeks pto. A paid sick leave policy. Company paid health care. Paternity leave. Company match on 401k.

#2 Leadership that cares about good engineering over deadlines. Logistics is very fast paced. There is often a lot of pressure to deploy things yesterday. Development takes time, trial, and error. You need to be able to have patience for engineering.

chrysoprace
0 replies
20h45m

When you say provider, I assume you don't own the IP and that you'd be starting from scratch. At my work we owned the IP from software developed by a third-party which we then brought in-house and hired on software developers (myself included). The biggest challenge has been the loss of tribal knowledge of the codebase and the use cases that brought the system to its current state over a decade.

The boring answer is that you'd likely need to put together a business case. What's the benefit you'd get from developing it in-house? Is it worth the projected cost & time-frame (which is likely going to be inaccurate since estimating software is inherently difficult) to fix the painpoints? Would you look to offer the new solution to other potential customers (which may even be competitors to your main business)?

As for attracting talent, I've worked in the tech sector of pharmacy (Australia) for nearly a decade and while the tech sector there is small, the hiring pool is just like any other industry since we don't hire for pharmacy experience.

chrisoconnell
0 replies
2h24m

I actually own a studio that does just this.

I think that for a lot of businesses, they can hire internal developers prematurely before they have a clear vision of the product that they're building or need.

We structured our studio as a group of (very) senior talent, most with over a decade of experience each across Product Design, Software Engineering, and Product Management, where thee entirety of our studio is available on each project.

We focus on documentation, developer experience, and working with companies to get the initial product in a state of both product management and cleanliness to ensure that they're reading to onboard specific team members internally to carry the product forward.

It can be very cost prohibitive to create a new product without having designers, developers, product owners, all that are dedicated to your vision. A developer may miss key user experience interactions, making it difficult to use. A designer may forgot key features from a business perspective. Having access to all of the talent for a new product is hard.

As others have said here, I recommend finding very talented and experienced SENIOR Engineers. If you are intent on them being an internal team, ensure they have excellent project management skills and have built their own side project from scratch, so they know what it takes to build a full product from the ground up.

An engineer that builds their own products has experience that is invaluable when it comes to building functional tools that people want to use.

chris_wot
0 replies
12h57m

Depending on how niche the third party company is, and how large your company is, is it feasible to consider a takeover? You can then get your issues solved without having to prioritize features you don't need, you get to keep the technical staff and don't have to train up a new team in something your business may not have the expertise in.

You also get to keep the same UI, the same business logic and it means less disruption to migrate to new software.

Just a stab in the dark, probably not feasible but you are looking for interesting suggestions...

chfritz
0 replies
2h29m

I hear you loud and clear! In robotics, every company has the same make-vs-buy dilemma with respect to fleet management software (quite comparable to logistics). I've been in your shoes. This is why I believe in third-party solutions that don't try to be one-size-fits-all, but instead enable you to build your own, perfect system yourself, and that's what I'm working on now. I've recently written about it here: https://transitiverobotics.com/blog/make-vs-buy Feel free to find me if you want to chat and compare notes.

chasd00
0 replies
21h10m

One thing to consider with in-house dev is there's no one to yell at except the man in the mirror. Think about this, you need an application as part of your workflow, you're not in the business of selling the software development. What you risk happening is employing a dev team who's job becomes writing code 9-5. Your developers don't have much of an incentive to deliver a v1, they get paid no matter what.

A small, experienced, eat-what-they-kill consultancy may be better. If they don't deliver they don't eat. A firm like that is motivated to get things done on budget and on time. You'll get the application you need to move on with your business rather than having an internal software development firm 100% funded in perpetuity by your real business.

carom
0 replies
20h58m

What industry, what software, and what is your budget? If it is profitable to build and more than one customer, I am sure numerous people here would jump on the idea.

capitanazo77
0 replies
20h23m

Senior programmer here. Yeah. You’re in a spot where you need a senior programmer and a couple of juniors but can’t guarantee steady work for them long term.

Also, in house software needs to retain knowledge, otherwise the knowledge disappears when the senior resigns.

I’ve 20+ years experience with business like yours. Contact me.

https://x.com/eduardoarandah

bruce511
0 replies
2d13h

I've been on both sides of this question so my views are both biased, and experience driven.

In the early 90s we worked as contractors to a company developing (DOS) software for them. They sold and supported it. They got acquired and after another year the new owners decided we were too expensive and took the development in-house (as was their right under the contract.) We moved on to some other things.

Bearing in mind this was simply a continuation of the existing product, not a rewrite. They encountered the following problems;

A) there were no existing senior people on staff with software development skills. So they hired a couple programmers but with no clear vision of architecture and no clear understanding of the implications of short-term decisions.

B) it was already a "big" system, so it took time for new developers to get up to speed. Their developers would get a job offer somewhere else (paying more) so they had to get replacements. (Remember bringing the development in-house was supposed to be a cost-saving exercise, so they didn't overpay.)

C) over the 6 years they stewarded this the product was essentially stagnant, with no major changes or additions made.

3 years after they took it in-house we spoke to them about a Windows product. We would build it (and pay for development) they would sell it (we'd get paid-per-sale). This took 3 years to build, and once that shipped the in-house work was abandoned.

My lessons from this saga were;

Developing in-house is expensive. And forever. Staff posts you add to do this will always be there. Development of big features will end, but maintaince is forever.

Whatever you have budgeted for this, it'll cost 10 times that. And probably 2 to 3 times your (current gustimate) budget for years after that. If you plan to recoup thus investment selling to others (we did) add another 0 on the budget. Going from in-house to "product" is not cheap.

You will need a senior systems architect who stays over the long run to make long-term decisions and to give the project "coherence". Some early decisions can be very important down the road.

Hiring is hard. You want people good enough to do the job, but who are also looking for job stability. Be prepared to look again every few years (unless you get lucky.)

My advice; figure out your budget. Have a sit-down, at very senior level with your supplier. Discuss your long-term relationship. Discuss how much you are willing to spend. Discuss how you might make the deal attractive to both parties. Make yourself important to them.

By FAR this will be the cheapest approach, and the least distracting for you.

If you can't come to a deal, figure out what it will take to transition the existing source code to you. Probably a big pile of money. It'll still be cheaper than writing from scratch.

Ultimately recognise that software development is expensive, and the management of it is hard and distracting. (And in many ways counter-productive). Your best hope is to rekindle your relationship with the provider, which recognizes that you need, and want, to pay a lot more. If there are reasons they can't actually do what you need anymore then figure out the best way forward from that.

brink
0 replies
23h16m

Besides, can we even attract experienced developers to a non-glamorous industry like logistics?

I've been building advanced web apps for 14 years, and I'd happily spear-head something like this, especially for a field as "non-glamorous" as logistics. And I have a feeling there are many developers out there like me.

brianbreslin
0 replies
1d

My team has been building custom software for a large german multinational shipping and freight forwarding company for 18 years now. Happy to chat, my email is in my username @ gmail.

Our client has tried what you're discussing several times. They are a bit bigger (10x) than your org, but never built up the software muscle in house despite hiring and firing entire teams to attempt to build stuff in house. We've handled one corner of their offerings for nearly 2 decades while all their other teams have cycled in and out of internal and external suppliers.

breck
0 replies
17h10m

id be happy to hop on a call and listen and explain what you should do, free of charge. you can take my plan to someone else to implement (im too expensive)

bob1029
0 replies
3h13m

I would prototype this by duplicating a vertical slice of the business that is (presumably) well understood and easy to teach. Don't start with the hardest thing and definitely don't try to plan it all up front. Hire some cheaper contract labor to begin with. If you find you can't even replicate a small part of something you thought you understood, you should probably abandon the overall effort.

The last thing I would do is make some grand decision, locate an 8-figure budget, hire a bunch of people, and then hope for the best. Incrementalism is the key to not blowing this idea up. You already have a ~working system. Leverage the hell out of that. At the end of the day this is probably going to be more of a people problem than a technology problem - managing scope and expectations throughout, etc.

bmitc
0 replies
18h42m

Do you have contact information?

blipvert
0 replies
11h39m

As you mention it explicitly, EDIFACT is a big standard, but the documentation is excellent and machine parsable to generate schema/code.

Years ago I wrote a library to enable an ~80 person record (vinyl/CD) distribution company to use EDI to deal with Amazon/Virgin/HMV/etc.

It’s not that scary - happy to discuss more if it would help.

bionhoward
0 replies
5h53m

Yes. Don’t just bring it in-house, bring it “in-brain,” learn to code yourself and lead by example! Make sure you can write tests (gherkins at a minimum and ideally E2E tests with some browser automation or whatever you need to simulate a user) for your team’s code to know it does exactly what you want and make sure you can run the tests on the dev branch yourself. Then you can trust AND verify!

bhaney
0 replies
20h29m

No. You will almost certainly fuck it up because you're not a software company and very likely don't have a culture conducive to efficiently creating software or identifying and retaining software-related talent. Your costs will balloon and your output will pretty quickly slow to at least as much of a crawl as the vendors you're using, once attrition and tech-debt catch up with you.

If anything, you should contract with a software company that builds custom software solutions for niche businesses. But be very careful when identifying the company to go with, as a lot of them are essentially scams.

bh213
0 replies
9h50m

My team worked remotely from the EU for a similarly sized ($100-$200M) US-based company in the print-on-demand space for over 8 years as an external provider, building much of the core infrastructure and services. We are looking for new projects; contact information is in my profile.

bazaz
0 replies
10h43m

I'd recommend getting a remote, third-party team of contractors, and hiring a fractional CTO to manage that particular team and any related software. Having done that pattern before; it's less liability and cost for you, and easy for you to experiment and get the job done. You can easily end the contract with the team once your software is stable enough.

My only advice would be: don't attach different freelancers to each other and expect the job to get done. That might work in some particular use cases, but most software requires (at least) the engineering team to be in-sync with each other. Freelancers rarely have that skill.

Hiring a full-time tech team in-house is beneficial only when your engineering/software is tightly coupled with the domain. We often overestimate and think that's the case every time -- it really isn't!

Btw if you want to hire such a team, I'm on the engineering end: bazaz@grayhat.com.pk

balls187
0 replies
16h21m

Do you have technical people local to manage your near/off shore resources?

austin-cheney
0 replies
1d2h

So, base your decision only two factors:

1. Budget (perform a thorough cost estimate before making any changes)

2. Quality of service expectations

The risk part of this is that your company has never had a software team before. This means you have nothing to build upon. The level of risk here is tempered by the flexibility within your available budget, which means how much cost are you willing to absorb outside of plan if this goes to shit.

Now, set your expectations right. Software teams never ever make money. They only cost money. Will moving dev in house cost less money than the current solution? No, at least not at first, but you have to build from nothing. Moving dev in house will allow future scale the outside party does not provide.

Secondly, absolutely forget technology. Don't fucking go there and if you do you have already failed. Think only in terms of leadership. What that means for this effort:

1. Hire a leader who can perform risk analysis, measure things, work within a budget, is super assertive, and communicates brilliantly both in person and in writing. The assertive part is important because opinionated technicians/developers will attempt to drive the plan. Don't ever let that happen. A real leader will own this in both failure and reward.

2. Set realistic goals and accomplish those goals. Don't do anything else. Once the first goals are achieved you will have the foundation to do other things. Every distraction wastes more of your budget.

3. Form, in writing, policies that you are willing to fire people for violating. These should enshrine conduct, ethics, and appropriate standards for quality of service.

4. Do not (ABSOLUTELY NOT) think about this in terms of a startup. You are an established company already generating revenue/profit with margins. Proceed with a well planned vision always accounting for risks and make adjustments to the plan very carefully. Distractions and deviations will cost more money.

5. Finally, transition from the current solution to the in house software team carefully and progressively. This will cost more upfront, but dramatically less in the near term due to lower risk.

Good luck.

aswerty
0 replies
2d5h

Sound like you should be doing a proper cost/value/risk analysis of the current solution along with a proposal for change.

Once you do that you will probably have a reasonable understanding of your potential: budget, opportunity cost, RoI, risk, etc. for undertaking some kind of organizational change.

The actual software development side of this seems secondary until the above is done.

asubltmeind
0 replies
3h6m

Besides, can we even attract experienced developers to a non-glamorous industry like logistics?

Yes!!! Nothing a developer loves more is getting into a new market where their work will drive the business and will be seen as valuable instead of a necessity (cost center vs profit center)

What's your core competency? Does it include this software? If yes, then yes you should make this a core competency.

You need to partner with an engineer with a good amount of experience that has worked both in startups and established companies. You need to discuss all the intricacies and then they can tell you what timelines you will be looking at, potential cost, and potential benefit. Do NOT HIRE a CONSULTING company. I worked at one of these and it's a good way to spend $millions without getting much in return.

There are probably providers out there - they probably aren't very good and that's why you're not familiar with them.

arkh
0 replies
11h12m

Currently working for the same kind of company (logistics, niche domain) with a mix of big ERPs (yes, not just one) and in-house software.

If you go with in-house you want to make sure it does not spawn multiple pet projects per need. And you don't want your software to rot. I took my current role to be part of a modernization effort because "it's old software". Well, I did not expect this kind of outdated and things are slow to replace because everything (and many "surprise" scripts and app no one use but in fact someone does) depends on the same badly setup database. But it's a "fun" challenge.

You really want easy to update / rewrite / replace software. Not just a "let's build it one time then consider it good to go for the next couple decades" politics.

Besides, can we even attract experienced developers to a non-glamorous industry like logistics?

Yes, if you can present a good software project. Also pay and perks like WFH will often trump glamour, especially with experienced devs.

architectfwd
0 replies
23h0m

I’ll caveat my response here: this is provided as general guidance and should be seen as such.

1. Have you considered managing your providers performance? What could you do in this area?

2. Have you considered going to market for other providers to start new or to take the solution over? Is that even feasible?

3. Have you considered the long term capability build you need in your company if you decide to bring this in?

angrymouse
0 replies
23h34m

Right in the middle of a retiring of a big external platform and moving it over, slice by slice into separate company owned products and APIs (and a few off the shelf things mixed in too!)

I think there’s plenty of sensible advice about getting a technical person with experience and expertise to help make the right decision. Between doing it yourself, building a platform with various tools stitched together to finding ways of getting what you need from existing suppliers and other tooling.

Something I would also suggest is to be really clear right now on how you currently work, how your existing platform works and the problems it’s causing or at least the opportunities you feel you’re missing out on.

To do this suggest getting a “discovery” team together and doing some service design and analysis to map out your user flows, business and tech. The as-is. and laying against that all the pain points and missed opportunities.

Then using the same team to help you craft how it should work. The to-be vision.

Then using that to-be vision and the insight and expertise you’ve developed to help you decide how best to get to that to-be vision. As cheaply and sustainably as possible.

Part of the organisation I’m helping out. There’s a vast difference between the parts where that discovery work was done (and done with clear purpose) and the bits that haven’t been done. And the endless delay and struggle they’ve had.

andy_ppp
0 replies
5h46m

Every company is a software company, just some haven't realised it yet.

The only thing I would add to the great advice already here is start off very small, and get this tiny feature being used by the company as soon as possible and then iterate. Every two weeks the programmers should be adding value for your staff. Do not try to go with a big bang where you deliver something that does even 10% as much as the probably awful software you are currently using. This is where projects tend to fail.

If you want to filter out quite a few bad programmers I would use Elixir as the people who know about it and like it tend to be people with excellent programming taste in my opinion. Other programming languages are available of course, but using something slightly niche but excellent will attract the right sort of people to a project like this and help retain them.

If you want to chat my email is in my profile! Good luck!

amtamt
0 replies
1h5m

Given the domain is well known and solution is in use already that can be used to model new solution, if I were in your shoe, I would have started with one dba, and a couple of oracle APEX developers. Oracle APEX, with a solid database in background, can get a lot of development done in a short time. In 2-3 months time, a review of development activity would have provided a decent idea if development should be taken inhouse or left in current state.

amelius
0 replies
4h30m

It's not as difficult as you might think, because copying the functionality of an existing system is way more easy than building a system from scratch.

allanren
0 replies
1d1h

Depends on your complexity, if the business is standard logistic process. Then there are plenty of ERP products to choose. Let the ERP company do the work, it won't be cost more than have your own team.

alcaide-mor
0 replies
22h11m

If you have over $200M annual revenue, I can't see how you couldn't afford to build this thing in-house, but then I don't really know what kind of product we're talking about since it's so stealthy.

When it comes to actual suggestions, from a developer's point of view I'd say the following:

1. Migrate slowly. Don't try to build an entire replacement for what you already have at one go. Tackle the low hanging fruits first. Plan the big replacement after the small replacements are already up and running.

2. You'll need at least one person to be the glue between business and tech, and that person must be developer-first, not business-first.

3. Don't overhire. You probably don't need a big team. I'm sure you'd be able to begin with no more than two or three developers.

4. Attracting talent should be easy since the job market has been terrible for developers. You can see job postings with thousands of applications.

5. Hire remote whenever possible. This will increase the talent pool enormously.

6. Always consider the possibility of SAASing whatever you'll build.

Good luck.

alberth
0 replies
22h55m

No advice per se, but questions you'll want to consider as you read others posts:

1. why do you believe you can build it better? (even with the most amazing team)

2a. its easy to over-estimate the gains of a rewrite, and dramatically under-estimate the negatives. how bad could things get, for the business, if you migrated to a worse solution? (lost revenue, lost customers, etc)

2b. after you answer #2a, do the gains (of a rewrite) now really seem so big?

3. if you outsource this rewrite to a 3rd party (freelance, contractor, etc) - how is that any different than today? you're already "outsourcing" this to an existing vendor. How would you maintain code from non-employees?

4. can the business even support the cost (and it's a positive cost/benefit analysis) on hiring full-time employees to rewrite and maintain this code base - forever.

5a. what do your competitors do? (buy the same vendor software or they built their own)

5b. if they use the same 3rd party vendor, is the market big enough for you to turn this into a new revenue generating business (sell this in-house app you'd build)?

alberth
0 replies
3h12m

Also consider you're asking this question to a forum of mostly developers.

And developers love to build things.

So be aware, you might be getting biased responses by people who don't have anything to lose if they are wrong.

acrooks
0 replies
19h47m

Hi, I have a lot of experience in this space - software for logistics, supply chain, shipping.

I have helped companies procure off-the-shelf software, helped them build in-house technology, and have a lot of connections with companies like yours in both sides of the table (from largely in-house all the way to the other side to largely subscriptions), so I’ve seen broad examples of what works and what doesn’t, and how businesses can leverage technology to get a competitive edge.

If you want to chat and learn more, I’m happy to make some time - email address is in my profile.

abakker
0 replies
18h8m

I know it's not popular, but it could also be a place where a 3rd party engineering / development / managed services firm could be useful. Your labor requirements in building and transition may be different than long-term run, and if it's relatively simple, maybe the long-term run/maintain will be different.

disclaimer: I work in the research org as part of a company that specifically advises the contracting and management of outsourcing relationships. This does work, but is not risk-less and effort-free. But, in logistics, you're probably used to managing critical 3rd parties.

aantix
0 replies
1d2h

If you move it in-house, I would recommend changing your application process to include a video portion. Unless they can point to a long track record of open source.

All engineers are utilizing GPT to write their resumes/cover letters.

The written word and keyword references are no longer a signal of ability.

Give them a couple of questions to answer on video.

Record the time when the questions were displayed vs when their video cover letter/resume was submitted to ensure they're organically answering the questions.

Otherwise, be prepared to sift through literally 1,000+ applicants.

Hiring has slowed in the U.S. I wonder if in part it's because everyone now can submit a very qualified resume and it's become increasingly difficult to differentiate good vs bad candidates? Especially given the increase in applicants.

aabaker99
0 replies
15h58m

I'm an engineer in this space and would be interested in learning more about your business and why you feel you are unique and under-served. My contact info is in my profile.

I do find that the biggest challenge as a vendor in logistics is highlighted by, "Our business operates in a specific niche and there are no other providers who cater specifically to our industry." This makes it difficult to make software that works for everyone even if we are all in the same industry.

YZF
0 replies
12h58m

I would first look for someone you can trust who is an experienced software engineer or software engineering manager to take a look at what you're trying to build and give you a gut feel on the scope and schedule. You'll need to factor in some risks on top of that basic gut feel.

I think being in Europe is a plus here in terms of being able to get talent for a reasonable cost. I think you can find good people in any industry but it's never easy. Paying well, benefits/perks and good working conditions are a good start. Count on it taking time and effort. You will need at least 1-3 strong people (one is a bit risky but can also work) and those can help you grow the team and also lead more junior engineers.

What about making some arrangements with your provider with you paying for time/people and them making changes/fixes/custom features for you? Could even be on your premises or some other similar arrangement. That can work if the software has some good bones.

Temporary_31337
0 replies
2h29m

If you’re happy working remotely then you potentially have a much larger pool of talent to choose from.

TYPE_FASTER
0 replies
1d1h

I've worked at a large company that ran internally developed logistics software. It worked for them.

Strategies for attracting and retaining tech talent in a non-tech industry

While you might be in a sector that isn't tech, you have tech. Put yourself in a software engineer's shoes, from a career perspective. We tried to keep up to speed with respect to things like framework/platform version, development practices, etc.

Make it clear and obvious that you will continue to invest in technology. We went to mobile early because it made sense for our business. We continued to invest as mobile changed with the introduction of iOS, and as computer vision got better.

Feel free to reach out if you want to discuss further.

Satam
0 replies
22h46m

Maybe the limitations of the software arise from the fact that it's being sold at a price that's relatively too low? It sounds like it's very niche software with only a handful of users like you at most. With a small number of paying users, even if each one is paying thousands per month, the tool's team might be too underfunded for it to do much more than maintenance.

To do it in-house, you'll probably hire 2-3 engineers. You'll aim to have smart people who can self-manage, design, and who can intuit the business requirements. Your part-time duty will become to be the product's "CEO" of that whole thing.

So you'll end up paying at least €16000/mo (3x€6000) in salaries alone. Data access, storage and infrastructure will probably cost a bit too. How much are you spending now?

RangerScience
0 replies
23h41m

My two cents:

You have a greenfield development project with a very well understood set of business needs and requirements, and you have the budget (I'm guessing) to run some small-scale experiments without the usual sort of time pressures; to a certain kind of developer (hi!) this is super attractive.

I would spend a few weeks getting to know big chunks of the core use cases, and then architect a system designed from the beginning to handle those needs, and the prototype a bunch of that system over a couple of months.

Although these time estimates are totally armchair bullshit, what I'd actually do is timebox both steps to something like "two weeks" and "two months" - that'll help mitigate scope creep that'll come from not having the usual sort of time pressure. It's not about getting it done, it's about finding out what it would take to get it done, and seeing how much can be accomplished in a set amount of time is a good way to do that.

The key bit in all cases is (1) hiring good people (2) getting out of their way except for (3) keeping them on track. (One trick for #3 is to have them propose plans, and then always ask "okay but is there a simpler way to do it?", 2-3 times, kinda like 5-why's).

For #1, I'd look at talks people give at conferences, and then either try to hire those people, or ask those people for referrals.

For #2, that's your executive-level corporate culture. Unfortunately, from what I've seen, you either already have it or you don't, and that's probably not something you can change because if you don't have it, you also don't have the psychological safety necessary to find out that you don't have it - although, you can look for where you've got high employee churn, and that's where your problems are.

For #3, I'd use a combination of what I call the "wine trick" with "ELI5". The "wine trick" is that you don't actually need to know anything about wine to find out if someone else does: just get them talking about the details of their special interest, and if they can, they know a lot about their subject. Combine that with "Explain It Like I'm Five" to find out if they're actually just bullshitting, and because the other way to find out if someone knows a lot about something is if they can teach it. (Plus, they'd need those communication skills during the rest of this process anyway).

RandomThoughts3
0 replies
8h23m

Point to consider: the moment you hire to develop in-house, you are a product company on top of what you were before. Doesn’t matter if you are the sole user of this product and actually not making money with it, you will have to deal with a company in the company.

It could be a very good idea (especially if you can spin it out at some point) - I mean Dassault Systemes started this way and they are a billions dollars company but that came from an engineering company a 100 times larger than your own and for which the investment was pocket change - but it’s going to cost you more than you think, take more time than you think and be more taxing on your time than you think. Also you need to maintain it forever.

If you haven’t done it yet, I would pay for a very serious benchmark of what’s available on the market and open discussion with integrators to see if a custom integration on top of something on the shelf couldn’t be made especially if you have people in house doing low-code thing before pulling the trigger.

PeterStuer
0 replies
23h31m

One thing I did not see discussed here which in my experience as an outside consultant for significant bespoke software developments was important:

Yes, you can attract and retain a good core development team through extrinsic benefits like nice salaries, bonusses, company cars etc. even if your business is not considered intrinsically attractive. However, how will the rest of your employees, both workers but also management cope with people in essentially purely production roles potentially be significantly more compensated than your middle management?

I have seen more than one client that in theory could have benefitted from an inhouse team, but where that was the dealbreaking issue.

PaulRobinson
0 replies
21h33m

One thing to be aware of is your existing supplier might play hardball with your data.

I’ve known companies in this situation try everything from price gouging (“it’ll cost you $10 a record to export your 2 million records”), to just flat out refusing to pick up the phone, answer emails, or reply to legal threats: in principle a court can tell them they need to hand data over, in practice they can drag their feet.

As a former CTO I think you might need help to help you figure out your strategy in more detail and then get it delivered. Plenty of non-tech businesses have dev teams, and it’s becoming more and more frequent in my experience. You can attract a team with flexibility, autonomy, a promise they can learn new things and a great mission. A good CTO with experience in startups can probably help you get that lined up right.

Oras
0 replies
10h38m

I worked in an e-commerce company before and was responsible for the logistics tech.

The first thing to keep in mind, is migration will not be easy, mainly because no one would understand how the current systems work or the decisions behind each function.

You’ll need subject matter experts from your team to guide the new devs during the migration.

Having a CTO to hire the team is two edge sword. If you get it right, you’ll save months down the line getting things right, but if you get it wrong, there is a chance you’ll have to rewrite everything again in a few years.

My suggestion hire a senior full stack developer to do one feature outside the current system but in a way that integrates with the workflow.

This experience will provide lots of learning for your company on how to manage expectations, tech stack required, speed of development, ROI. You’re not going for a large investment either, one developer will not break the bank.

Normal_gaussian
0 replies
6h39m

You would benefit from some more in depth conversations with several strategic technical consultants - essentially a CTO type person - to get some definitive immediate steps and longer term understanding of how you may want to change your business relationship with technology.

Several of the comments here are very good -

- https://news.ycombinator.com/item?id=41195008 - is probably the one I align most with.

- https://news.ycombinator.com/item?id=41193136 - is going to be a common take.

- https://news.ycombinator.com/item?id=41195910 - is an extreme stance that requires and benefits specific sorts of senior leadership.

- https://news.ycombinator.com/item?id=41196183 - is quite scary, but the point is a valid one.

I'd suggest you reach out to a few people who have responded at the strategic level and see where the conversations go; I'd also suggest you reach out to myself (contact in bio / south UK based); and finally tap on your network for others as well. You will end up doing a reasonable amount of internal and external exploration activities before a path is determined - so expectation management is a must.

Best of luck.

Lyngbakr
0 replies
5h5m

    Besides, can we even attract experienced developers to a non-glamorous industry like logistics?
Perhaps it's perceived as non-glamous, but earlier in the week I met with a logistics team in another company who we're working with and the problems they address are absolutely fascinating. The complexity of the domain certainly made it intellectually appealing to me.

Lovesong
0 replies
4h28m

I am in a very similar situation, working for a mid-sized logistics (300 employees with small offices around the globe, 400-500M annual revenue), but with a completely different side, we do practically everything in-house with a very old software that does everything, (Multivalue D3).

My experience on your points:

We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

We also use low-code applications like Talend and TIBCO, to fill some gaps, the older folks that don't want to deal with our ERP prefer using them this way for example.

Have you tried taking a look to https://www.flexport.com/ or https://www.shipbob.com/? Afaik, these are 2 of the most overrall used in the logistics industry.

We are very slowly migrating our system in different departments to more modern solutions, but always keep in mind that as soon as you start migrating, you will need to keep both systems up for a long period of time while this happens, and that means money and workers.

On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.

Europe is slowly moving outside of the EDIFACT standard fortunately and slowly implementing SOAP/XML based systems, you will have a problem here in an in-house solution because Europe systems are usually convoluted and hard to implement from different countries, from a business-side pov exclusively. ( I can tell you from first hand experience ), so indeed, a big problem will arise here. If you also do customs clearance, this will get even harder, as laws vary from place to place in small and big details.

Strategies for attracting and retaining tech talent in a non-tech industry Experiences transitioning...

Finding them is hard, but keeping them is harder, any other logistics company that sees a trained IT specialist with deep business knowledge will try to poach it with a higher wage inmediatly, I had tons of offers from close companies because of my customs knowledge. Pay them well and keep them happy. There is no strategy here, devs move for money like everywhere else, some end up in banks or insurance after some consultancy job with business experience and stick there, you will have to risk training them in house or poaching them from elsewhere.

For an industry as complex and in my opinion, enterprise customizable company, I highly recommend you to try an in-house solution, users sometimes don't need a lot to do their work and the most important thing in logistics is being able to do it quickly and efficiently.

What I can tell you absolutely that it doesn't work is trying to migrate from a big swoop, I saw companies close to us do it and it just didn't work out, their processes slowed down a lot and clients started fleeing to other forwarders because of the time they took to process any shipment. Move slowly in your smallest department ( reefer, customs, import or export, invocing, anything that in your company isn't as importante) and move efficiently, make their work as fast as possible, then grab that feedback and start moving other departments.

KaiserPro
0 replies
22h47m

My advice would be: Specs specs specs.

If you're going in house, or buying in a consultant, you need to be sure about functionality and why you want it. That way you can draw up small, medium and long term goals for what you _need_ and how it affects the business.

The risk with inhouse (or contractors) is that the devs get bogged down in what tool rather than how to solve the business problem.

make sure you have a good idea about the processes the software is supposed to handle, and what data you need for that.

Jefff8
0 replies
20h54m

Firstly, it's important to note that on Hacker News, responders are probably going to be biased towards writing software that solves your problems.

Secondly, it sounds to me as if you are jumping ahead, and favoring one particular solution, rather than looking at this as business problem. If I were tackling it, I'd be making a list of all the possible solutions: - Stay as you are - Stay as you are but make a deal to buy the source code/or perhaps the company that makes the product if that's feasible/or the division - Buy-in an entirely different commercial platform - Build your own as a clone of what you already use, and extend out - Build your own as an entirely new system - something that exactly right for you - Glue systems together to get something that works for you - Probably there are more.

Then I'd list the advantages and disadvantages, the risks, and guesstimates on costs and monetary benefits. This does not need to be a long process - a month and a spreadsheet.

At the end of this process, I'd be thinking about next steps to facilitate the likely candidates. E.g. initial talks to vendors or approaches through an agent about buying the company.

If build-your-own is still on the list, then I'd look at having someone spend a few months documenting and thinking about your existing software, specifically with the aim of mapping out the likely pain-points - e.g. does the system use an interesting scheduling algorithm and if so, what is special, and where does it fail?

This stuff will eventually form the basis of spec for the backbone of a new system. But it's first job is to build some organizational expertise in the software, rather than the use of the software. You want some maps of the territory.

If at the end of this, you have a sense of the pitfalls, then I would think about mapping out what is really needed - interviewing all the levels of your org that have an interest - from the end-users/operators, through to the board. You want to find the stuff that's not documented. You probably don't want to get to a spec, but you do want to have a document that accurately reflects your needs (and also the love-to-haves, and the opportunities to extend)- and it can be used to judge whether a buy-in or a build-your-own can successfully meet your needs.

If you even get this far, this is the point at which you should be deciding between build-your-own and buy-in.

And if it's build-your-own, then this is where you take all the stuff you've learned to spec it.

And if this is the solution, I'd be thinking about what technology will serve you best at least cost, now and ongoing. E.g. should you be building a web app, and if so, what tech could function as the core, so that you don't have to spend money on re-inventing layouts.

Strategies - these are not secret: - Make your business a place that people want to work - that means getting rid of bullies and trouble-makers, and encouraging a supportive environment - Make sure there are challenges, and they are achievable - Offer excellent packages - this can be a mix - work-from-home, healthcare, pay, etc - it's the whole package that matters - Understand that if you don't offer people a pathway to improvement, then you will lose them - Ensure that the actual physical work environment is conducive to concentration - Ensure that the software team are a proper part of the fabric of your company, and not an afterthought.

Transitioning software too, is not rocket-science. You need a solid plan for the transition. You need to train people constantly. You need changes to be small, incremental wherever possible, and clearly communicated ahead of time; you want the people who use the software to feel in control - that this is to help them, rather than to hinder them. And if there are organizational changes as a result, then you need to be sure that you are not shafting staff; you want people on your side, not against you.

Jean-Papoulos
0 replies
11h53m

First try getting into a real talk with your provider where you would get access to the codebase and be able to make changes yourself. Hire a few senior freelancers to assess the project and solve the most urgent things. Form there you'll be able to make informed decisions.

InsideOutSanta
0 replies
6h20m

I guess now is as good a time as any to hire qualified software engineers, because a lot of them are looking for jobs. This is pushing down wages, and making this kind of in-house development more feasible.

The thing is that if you hire the right people, you can probably build something that is better (for your specific use case) than whatever third-party tool you're using now, with a relatively small team and in a relatively small timeframe (by which I mean probably at least a year or two until you have something that you can start to use). You might even end up being able to sell your product to other companies in a similar position, if you want to do that.

But if you hire the wrong people, or you don't have the necessary institutional support, or something else goes wrong, you can throw away millions and end up with nothing.

As for retaining tech talent, give them ownership, acceptable wages, and freedom. And don't hire a scrum master.

HeyLaughingBoy
0 replies
22h39m

There are other options.

I've worked for Engineering Services companies and they excel at this kind of work. We'd interview you to understand your needs, quote a price to provide what you want and a schedule to get it done, along with maintenance as needed.

Yes, I'm vastly oversimplifying to get the point across, but this might be a better model than trying to hire a single dev or create your own internal development team. I could only recommend doing that if you expected that your internal needs would grow continuously and that you could both feed your team enough work to keep them busy (and not wandering off into other jobs) and manage them well. Both of which can be far more difficult than it appears on the surface.

You're not looking for an Accenture or IBM Global Services, but a small company, probably in your local city that provides custom development services. If you're in the US, I'll give Saturn Systems a plug: worked with their team before on a development project and I think this would be right up their alley.

Gettingolderev
0 replies
6h53m

Have you thought about / are you big enough to buy that vendor?

Otherwise: Find a really good HandsOn CTO, give them enough budget to build up a team and have freelancers, build it out.

But before that, have good people analyse the business requirements first.

GarnetFloride
0 replies
17h13m

I would highly recommend first of all reading "Peopleware" and "Mythical Man-month" which are all about making this type of decision. Since this is data exchange, you need to map out the data flows your company does and where things are working and failing currently. At that point you should have enough information to start making decisions.

FuriouslyAdrift
0 replies
48m

The three big logistic systems we looked at where Rex11, Manhattan, and Hopstack. Expensive, but less than the cost of a dev team.

We ended up staying with our ERP as we spend six figures a year on support for that already. We're about the same revenue as you (manufacturing with our own warehousing and trucking company)

Fr3dd1
0 replies
5h50m

As some others suggested I would also recommend to try to make an experiment. Identify one part of your software suite you think you can build, operate and do the maintenance for. Aim to do it as fast as possible. Test if you can resolve the issues, you have with your vendor, if you do it yourself. If that fails, it propbably isnt a good idea to go full scale on it. Again: aim to get some real world experience with your own build software AS FAST (and cheap) as possible. Dont go for a perfect solution.

Fire-Dragon-DoL
0 replies
13h51m

By the way, as a developer, I find logistics interesting, I wouldn't be concerned about the industry. Your problem seems intriguing, I'd work on it.

I don't have experience in this situation, but your assessment sounds very solid,I agree with you.

The main pitfall I keep thinking about is making sure to hire somebody very focused on getting the stuff done specifically for your business. If they go down a path of developing software, it can generate enormous waste. To clarify, they might need to be ready to create scripts to extract data from the existing software and integrate the workflows (kind of doing what you are doing with no code), rather than writing from scratch, because the alternative might have astronomical costs. I would focus on senior devs, pass on juniors for the first hire. Not sure how many people would be necessary.

FLT8
0 replies
22h16m

Reasons not to do this: - you don't really understand the full complexity of the domain or regulatory environment yourself - you don't have the funding available to commit to not only the development team but also the infrastructure to support them (tooling, cloud environments, security team, policies to support this, technical writer, ...) - you're not prepared to pay for top talent (assuming you can even judge it, see the point below). Starting something from scratch successfully requires a really experienced team who understand how to model and build things well. Who know how to build in sucha way that frequently changing things effectively become configuration rather than code etc etc. Most likely this means people who have 10+ years in the industry and preferably people with some product and industry experience. - you expect this will be a one-time cost hit and then effectively free in perpetuity; software is expensive to maintain, requires ongoing security patching, keeping up with library and technology updates, and ongoing commitment even if from a business perspective nothing is charging. - you don't have experts on hand who you can afford to have spending more of their time than you think is reasonable with your development team explaining in detail all of the lessons you've learnt from the current poorly performing software and what they really need. - you're not prepared for it to take at least four times as long and be four times as painful as even your worst-case initial estimates. - you're in an environment that requires eg. purchase of vendor libraries and/or integration to proprietary platforms and this impacts the economics of boutique development - you're highly regulated and software you build/use has additional complications like certification/audit/... requirements - especially if you don't fully understand or can't communicate this effectively to the build team - you don't know how to judge the competence or experience of your founding technical team; this will be critical to your success - more critical than almost anything else. One bad hire can derail your entire effort. - you want an entity that you're bound to contractually and that you can sue for remedy when things go really wrong. And they will go wrong. Of course there are lots of reasons to try to build the software yourself too, but hopefully the above gives a few counter points to think about.

Eric_WVGG
0 replies
1h33m

There’s a lot of advice here regarding the dangers of your plan, and I’ll add a little of my own, but I’d like to offer one note regarding why you are correct for considering this.

What exactly is the nature of this software you’re running on? Is it an aged or decaying platform? Worst case, is this a PHP thing that has to have updates carefully monitored in the event of eventual security breaches and hacks?

And what exactly is the health of the software provider? If they can’t be bothered to respond to you and the sort of budget $300M/year can afford… I’d be sweating bullets for sure. You need to have a plan for them just disappearing one day.

---

That said: I just committed the cardinal sin of helping to buy a company that had a decaying software stack, thinking that we could just straight up replace the whole software stack. Gave ourselves a big fat year of development and a big, experienced team, and still couldn’t pull it off in time. Harrowing experience.

Someone else here suggested getting a small freelance team and "letting them go nuts." I think an approach where a small team was building new, independent microservices that supplemented your main stack, and then gradually replaced features — until finally just a small core was left to be replaced with something modern — would be a feasible approach. This would need to be a very long-term plan with a lot of commitment.

Dennip
0 replies
4h44m

SAP?

An alternative to this strategy might be to have your own software team that builds tools and processes for you to "work with" or "work around" your primary software without fully replacing it.

As others have mentioned, what you want is achievable, if managed the right way, with the migration done in stages.( Trying to replace the whole thing in one jump would be very risky.)

In the real world though its quite easy to miss requirements, some quirk of the existing software nobody really thinks is a feature, except that one person in the office who has gotten used to abusing that quirk to achieve a task.

There is also possibly a lot of domain knowledge that the software team you hire might not be versed in, which can be tricky, although this is partially solved by having a good project lead and strong communication between the teams (software and non-software)

Where is might get more tricky is if you to adhere to certain ISO/etc certifications.

CrimsonRain
0 replies
1d1h

The single most important thing is to hire the right person for leading (technical) this project. Even a tiny (<=3) (but well-paid) team can deliver you results beyond your expectations.

There're interesting things to build in all industry; logistics is not an exception.

I've seen stuff like this before and the most common reason for failure is the "technical" person focusing on entrenching their position instead of focusing on delivery.

CodinM
0 replies
12h26m

As someone that quit a job in this very industry then went back to rebuild when his boss left - people that worked in this domain will always look fondly upon joining such a company.

It's a fascinating domain, and if you're the type of person that can do code but can also see edge cases and understand business logic - you're going to be one of the top paid people around. So, maybe look for people that aren't the usual cut of coders or experts, of course - if your organization allows the "freethinking" type crowd which sometimes might be prone to accepting toxic people (which can and should be filtered out, eventually).

Closi
0 replies
1d2h

I'm a logistics consultant that specialises on the software side of things!

What kind of logistics does your company do? (Transport, Warehousing or both?)

Will depend a lot on your functional requirements, but I would say that unless you are doing something particularly unique, there are probably off-the-shelf products that do what you are looking for, and will probably be cheaper and more stable than a 3+ person dev team in house.

I don't know what your requirements are, but if you are in any way a somewhat normal logistics provider, what you are looking to do will quite closely match an existing software package out there on the market (or more likely, multiple packages). Just because you have package which is a poor functional match at the moment doesn't mean there isn't one that better meets your requirements!

In my experience home-grown systems give you exactly what you want in the short-term, and then come with massive limitations as you try to grow/scale them (i.e. if you are on the 3PL side of things, if you get a new client and have a good WMS you can probably on-board them purely with config without having to write code, despite them having some new/unexpected requirements), and the 'new' home grown system today becomes a legacy nightmare in the future.

Plus home-grown logistics software often misses some critical component that makes warehouses function well (e.g. I have come across many that don't have hard allocation, and then find that they have pickface shortage issues that are hard to resolve!). Unless you are closely copying how other software works in this space, you will probably fall into pitfalls that are already solved.

Assuming it is a WMS and you are a 3PL (my best guess from your description!), personally I think the best thing to do is get a good 'off-the-shelf' WMS and then dedicate your engineering efforts into the more customer facing side of things (e.g. customer portals) where you can actually show differentiation with your competitors. No point reinventing something that everyone else already has!

If you are a 3PL on the transport side, there are also great options that cover 'business as usual' and you can again push some development effort towards the customer side.

For logistics businesses, having software which is industry-standard and has a large support base is a bigger sell to a prospective customer than having your own 'great' homebrew software, but that's just my two cents.

Slightly boring answer.

BirAdam
0 replies
1h28m

I always recommend having in house IT and software development. If you don’t, then you are captive to your vendor.

Arjuna144
0 replies
10h31m

If you should decide to go inhouse, I can warmly recommend checking the *frappe framework*, with which the open-source ERPNext was built. Compared to other such things this is truly open source (not like odoo and others, which really try to catch you in with being "open-source" and then let you pay up for the features you really need).

It is very powerful and comes with so many batteries included and is actually quite fun to develop with.

https://frappeframework.com/

Here is a story of a big financial institution betting on inhouse dev using frappe. (There is a TLDR on the bottom of that page ;) )

https://zerodha.tech/blog/being-future-ready-with-common-sen...

All the best <3

Animats
0 replies
16h1m

A good question is what else does your organization do in-house. You're a logistics company. That probably means you have some trucks around. Who maintains those? And how well?

If the organization can manage its own maintenance operations without crises, it can probably manage software maintenance. The tradeoffs between maintenance expenditures, downtime, and failures on the road will be understood and accounted for properly. If almost all the trucks are out working and the maintenance staff is doing oil changes and replacing worn fan belts, you're good. If you have six trucks out back with parts missing and one being towed in by a wrecker, while the guys in the shop are trying to fix a truck by cannibalizing one of the dead ones, developing software you have to maintain probably won't end well.

AlexMuir
0 replies
21h52m

Feel free to drop me an email - alex.muir@boxmove.com

I wrote the logistics platform for our company - UK-based, £4m revenue. I'll be happy to have an honest chat with you if it would be helpful.

Aerbil313
0 replies
19h54m

As a freelancer myself, I am delighted by the amount of freelancers in the comments. We're very often heavily underrepresented in the wider software world. Guess it has to be that we are still the minority, lol

AAL_throwaway
0 replies
22h42m

I've faced a similar situation as an exec in a different field. Some questions consider:

1. Are you trying to replace the system-of-record? I don't think it changes the technical merits of going in-house, but it does raise the stakes. It becomes more important to engage other stakeholders, and to prepare the business processes/workflow for changes. Secondly, there will be a transitional period where you will need to use both systems, so you will need to have a way to reconcile and merge conflicting records from both systems into a single source-of-truth. Again, these are not deal-breakers, but just things to think through.

2. How many integrations do you have with external parties? You mentioned EDIFACT and government institutions. Integrations are often the dominant source of project delays and complexity.

3. Management structure - you can hire someone to run the program, but like it or not, you are the corporate sponsor. It's success or failure will fall on your head. Whether you hire a "CTO" depends on your technical management ability, but I'd stay pretty close and pretty involved.

4. Attracting talent - as always, it's a question of money and time. You need a healthy budget for a healthy amount of time. A good, experienced senior dev consultant will generally have a lot of contacts, and can pull in others if you provide a solid environment, budget, and roadmap. I wouldn't be worried about not being in a "glamorous" industry - the people you want won't care about that. Some kind of equity or performance-based bonus can really motivate people to deliver value to the business.

5. Roadmap - take a vertical of the business that is more stand-alone and start there. You want to show an end-to-end in-house solution that solves a real problem. It will help you diagnose exactly what kind of challenges, culturally, organizationally, technically, (and even legal/compliance) that you have to deal with. It will be a confidence booster to the rest of the organization that this can work and will be successful. Adjust expectations and timelines as needed.

Would be happy to discuss more, just DM me.

999900000999
0 replies
1d2h

I'd take a middle approach.

Is their an open source solution to your needs? Do you really just need 3 or 4 people ( pay them top of the market, find senior level folks) to slightly tweak it ?

Otherwise you might be looking at a very complicated and expensive development process just to get to V1. Software development for any thing complex takes a lot of time.

On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.

Do you NEED an app. A simple internal website will be infinitely easier to build and maintain.

This is worth hiring a consultant to just talk about what options are available. Preferably someone you know personally, a lot of contractors will try to take you for a ride.

Do you have any programmers on staff right now ? You need someone on your side with a technical background.

Do you understand taking this in house will probably cost and take more time than you expect ?

91bananas
0 replies
23h3m

I work on an internal team like you would be building, I think for a company of your size and probably needs it is very much a needed thing to control the software in-house. Not having people that are dedicated and know your stuff leads to the situation you're in. Just do it. We've outsourced a couple small projects, then re-written them within our team because the quality and lack of specification is just...bad.

My current industry is pumping chemicals, it's non-glamorous but it's a need that must be fed, versus "fancy tech" or whatever. We keep a team of guys employed and happy. Just pay them decently well, don't try to micromanage them, give them good requirements and honest feedback, give them the tools they need.

3D30497420
0 replies
11h41m

One thing that doesn't seem to have been mentioned, if you do go in-house, get a good designer as well. Ideally someone used to working solo, doing deep research, and who understands balancing great UX, technical considerations, and business needs.