321–330 of 607 posts
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.
Earlier quoted context omitted.
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 an…
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…
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.
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.
That said, my feeling is the guy doesn’t have a prebuilt fit for his company / he’s already shopped extensively.
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'…
Great approach advice IMO.
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'…
Great advice IMO.
Earlier quoted context omitted.
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.
> 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.
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.
> 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…
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.
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.
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.