61–70 of 607 posts
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)
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)
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".
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…
Yes. There's overlap between transit nerds and software devs. I'm one example.
One pitfall to consider: software development is often its own culture, and nourishing and valuing (or merging!) multiple distinct cultures in a company requires real effort from leadership/management/team leads/senior ICs/... I'm sure that e.g. truck drivers and software developers can be made into a strong team, but don't just assume that cross-culture collaboration will work "by accident"/"automatically".
I'm in the software side of logistics, and I can imagine very different things you could be referring to, with different levels of effort and different levels of benefit/risk to you.
If it's just cost-savings, then this product has to be quite expensive to justify your time. If you're hoping that a better version of this product could make your operation more reliable and efficient or unlock new business opportunities, that's a much better proposition, though still hard.
> We'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 sp…
> 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…
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.