Live data from Hacker News

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

news.ycombinator.com

151–160 of 607 posts

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

#151
post #55

Earlier quoted context omitted.

> 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…

+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.

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.

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

#152
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.

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

#153
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).

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

#154
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.

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

#156

Earlier quoted context omitted.

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.

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.

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

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

#157
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

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

#158
post #91
post #62

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…

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

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.

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

#159
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.

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

#160

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…

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.

Post reply on HN