Live data from Hacker News

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

news.ycombinator.com

131–140 of 607 posts

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

#131
post #6

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

Also logistics sort of famously has interesting computer science problems to solve.

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

#132
If you have over $200M annual revenue, I can't see how you couldn't afford to build this thing in-house, but then I don't really know what kind of product we're talking about since it's so stealthy.

When it comes to actual suggestions, from a developer's point of view I'd say the following:

1. Migrate slowly. Don't try to build an entire replacement for what you already have at one go. Tackle the low hanging fruits first. Plan the big replacement after the small replacements are already up and running.

2. You'll need at least one person to be the glue between business and tech, and that person must be developer-first, not business-first.

3. Don't overhire. You probably don't need a big team. I'm sure you'd be able to begin with no more than two or three developers.

4. Attracting talent should be easy since the job market has been terrible for developers. You can see job postings with thousands of applications.

5. Hire remote whenever possible. This will increase the talent pool enormously.

6. Always consider the possibility of SAASing whatever you'll build.

Good luck.

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

#133
I work for a company in the decidedly not-sexy area of pet hospitality. We began building our own software when revenue was under $1M and we're now about 1/4th the size of your company and operate completely on our own software platform. The CEO of my company would convince you to at least try it in a heartbeat. As the original freelance developer and now the CTO, I'll give you the pros and cons from my perspective.

For the first few years as a single shop, they used one then another suite of SaaS designed for the industry. These had some basic public-facing reservations website and a billing system tied to a database of customers, pets, vets, and calendar entries that employees could manage. But the owner was developing his own operational techniques in all areas of the business, with an eye toward building a franchising platform. Operational "secret sauce" he wanted to add in software included: How animals are separated and managed in groups, intelligent maximization of kennel space over time given inter-pet relationships (e.g. family, friend, enemy), tracking pet health and eating habits, matching employee schedules to volume, how reservation slots are filled or saved for most-loyal customers, rewards programs, seasonal rates, franchise-level business variables, getting customer feedback, daily photos and communication with customers, a mobile app for employees to track pets around the facilities in realtime, custom printed collars, projecting volume to fine-tune upcoming sale prices or peak rates, and on and on. It was difficult or impossible to get any features or even bug fixes from the SaaS developers.

He hired me, as a lone freelancer, and paid me half of my estimate up front to spend a year writing him a software platform from scratch. Version 1 did all the basic things he was getting from the SaaS, and then we began iterating on all of the ideas and unique methods. It's been 15 years and one complete rewrite in a more modern language. The company has grown to 8 locations, managing roughly 200 pets per facility at any given time. I have - very rarely - brought on other developers to help, but basically the entire platform is easily manageable by one person and it's not even a full-time job. Our entire operating cost for servers, storage and backup is about $500/mo.

Upsides: They can get pretty much any feature they want, built quickly and cheaply. I understand the business model inside out by now, so I'm able to quickly spot any potential operational or technical pitfalls in new ideas, and work with them to align the software to exactly what their intentions are in new policies, as opposed to just following a feature spec. Just as a small example, when they changed their rules about deposit amounts and cancellation deadlines and fees a couple times over the years, it became much easier to write a subsystem that allowed them to manage those things themselves. Being so tailored, the software prevents employees from making common mistakes. Rollouts are VERY fast, sometimes in the same day as a minor feature is ordered up. We can make new versions available to one facility to test in production and see what bugs crop up, then roll out to the rest. Over time it has been more expensive than any SaaS, but at this point it would be impossible for the company to do what it does without the custom software. Owning the software has itself been a tremendous value addition for both investors and franchisees.

Downsides: As my friends in the tech industry love to point out, all of this constitutes a lot of technical debt. If I die or something, they're gonna be pretty screwed for awhile. As it stands, it would take someone else awhile to come up to speed on the 500k LOC we have across 5 different apps in the suite. The software runs itself, it hasn't gone down in years, and it's recoverable if it does, but as far as bug fixes or new features or dealing with forced upgrades it would take awhile. It didn't have to be this way; they could have hired a team or transitioned to one. Given the CEO's outlook on building things himself, he would have built a team if he felt he needed to. Knowing what I know, they're lucky they chose me as a single point of failure and not someone who might decide to switch careers or retire early. But those are avoidable pitfalls.

Final advice: Take time to choose well-supported technology stacks that will be around a long time. Documenting code. Most importantly, have your coder(s) work directly with the people responsible for writing and developing your operational / business procedures, and have them collaborate on writing the software manual. That way the logic of the business is understood by the coders and the logic of the software is understood by the people responsible for creating and implementing operations.

It doesn't have to cost a fortune to get up and running and it's way, way cheaper than hiring an outside firm. Personally I love working for companies outside the tech industry who need in-house software, it's a much better culture and the results are immediate and tangible.

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

#134

My comment is made from the background of someone who has led the effort of bringing software development in-house, building a 20-odd FTE dev team, and is still leading it 3 years in. I'd not bring everything in-house at once unless you really have to. Your fear that the devil is in the details is very much justified (I have stories, boy, do I have stories ...). However, in your position I would definitively start bu…

Were you at the company before they brought things in-house, or were you brought on for that job explicitly?

I haven't been in this situation before, but I imagine one of the trickier challenges in a role like what OP is describing is that whoever leads this also needs the ability to manage scope for the team, including persuading the existing COO or whatnot that "yes, we _could_ bring this in-house but you really really do not want to."

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

#136
There is a lot to consider given your situation and you have lots of input here already. So, I would only add my 2 cents in the case you finally decide to bring the dev in-house:

1. Start the team from hiring *senior* talent. Prefer *pragmatic*, experienced, and reasonably "passionate" (about technology) people. 2. As soon as the software team starts to grow, hire at least one experienced product design / business analyst.

Initially, someone experienced from the logistics department could work together with few software engineers and explain the business. At this point you need experienced software engineers who would carefully here you out, understand and internalize your needs, and translate this understanding into software. These same engineers would also need to expose you to the *just right* amount of technical details, for you to make the informed decisions about the product. I dare to say that everything else *does not matter* in a sense that you should trust this core team to make the right decisions in the area of software development. Eventually, as the overall complexity grows - product growth, team growth, etc. - you would need dedicated people to fill in this "bridge" role. Initial core team will get tired a bit, will need to focus on other things, so they'd need some help to structure the product. It is not easy, this role exists for a reason. It is overall less efficient this way (as in "output per person"), but necessary for further growth.

---

*Most importantly of all*. Have you considered buying an out-of-the-box solution? Do they really-really not work? Replacing something that already exists... I never saw it go as expected.

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

#137
IMHO I believe nearly every organisation I have worked with at this size always has a management problem.

The reality is if you want your teams to be competitive adding contractors competing with your in-house staff can be a really good thing.

Most in-house teams are jaded with management and having contractors set to do jobs (of course they have to be good) injects some life into the organisation.

If your in-house team is toxic you need to go and be the one to monitor that.

I worked on a team where when the CPO was there it was actually amazing but the moment he left their idiot head of engineering and middle management had a field day doing nothing

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

#138
I worked for a customs-logistics company and did some integrations with european cargo firms. EDI is definitely something a senior developer can figure out and parse/generate. Wiring your system through api/sftp servers won't be that hard.

The main problem will be the UI. Use existing frameworks! Telerik, devex, anything you can get your hands on. Don't let your project become hindered by someone's half-ass attempt at reinventing a data source and pivot grid. It already exists and it is a solved problem.

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

#139
post #93
post #91

Earlier quoted context omitted.

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

Code is often written for an audience: yourself on a year, maybe a younger team member you have In mind. Knowing you won't be around to explain can help drive some decisions and write docs for the audience.

It’s can be less about code and more about supporting the evolution of the business process.

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

#140
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?

Acknowledge and incent the exit plan from the beginning

Incrementally, it might make sense to hire an independent audit on occasion. This might be hiring a senior to jump into the codebase for a week or two to see if they can make sense of it or see any glaring red flags. The important part is them knowing this will take place and them not knowing exactly when or by whom.

Post reply on HN