241–250 of 607 posts
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.
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 ISO643…
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.
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…
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.
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 ha…
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.
I do find that the biggest challenge as a vendor in logistics is highlighted by, "Our business operates in a specific niche and there are no other providers who cater specifically to our industry." This makes it difficult to make software that works for everyone even if we are all in the same industry.
If you 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.
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…
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.
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.)