381–390 of 607 posts
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 reas…
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…
> 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.
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 whet…
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...)
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 m…
> 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.
Earlier quoted context omitted.
Having had the fun of taking over a project from a bunch of clever contractors I would caution: It may be too clever. There is value in simplicity and a stake in long term ownership. Some article here recently associated technical debt as lost institutional knowledge so handing the most key decisions to contractors has also drawbacks. One needs an integrated approach for design, build, maintenance and operation.
Mixed in with this may also be architectural decisions based from a "let's just spin something up quickly" mentality. Those foundational architectural decisions have a way of becoming set in stone, long after the freelancers have left, dooming the project to scalability and latency problems which seem to linger forever.
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
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 m…
$5M/year? In the US maybe. A team of 5 senior freelancers in Europe will cost about 150-200k per person.
From the inside, I’d recommend that if you bring software dev in house, you bring it entirely in-house. There’s nothing worse (as an in-house developer) than having to work with contractors that have zero skin in the game beyond their paycheck.
What’s the difference between an employee that only cares about their paycheck and a contractor that only cares about their invoice? In my experience you can get burnt by both, and at the end of the day the character of the person matters a lot more than the kind of legal docs they work under.
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.
Earlier quoted context omitted.
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 know…
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…
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.