It's a fascinating domain, and if you're the type of person that can do code but can also see edge cases and understand business logic - you're going to be one of the top paid people around. So, maybe look for people that aren't the usual cut of coders or experts, of course - if your organization allows the "freethinking" type crowd which sometimes might be prone to accepting toxic people (which can and should be filtered out, eventually).
Ask HN: Should we bring software dev in-house?
301–310 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#302Earlier quoted context omitted.
> 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.
Fair enough. To clarify, my point was not necessarily “I know better”, but that it is incredibly difficult to get a broad view of the market from a single perspective. This market is by definition a chain of steps with parties that may be antagonistic. It is atypical in that way, and writing software in-house may be more difficult in this sector than in others because of it. While writing software in-house gives you…
No need to apologize, just wanted to make you aware of how it came off to me.
> my point was not necessarily “I know better”, but that it is incredibly difficult to get a broad view of the market from a single perspective. This market is by definition a chain of steps with parties that may be antagonistic. It is atypical in that way
Maybe? That description sounds like it could probably be applied to any highly fragmented vertical though...
> imo the business is intrinsically relatively ill suited for in-house dev considering the high degree of collab with other parties.
I think this hits a reasonable point — if most of the development is related to internal operations, it could be a different calculus than if it is mostly related to interchange with other parties, which implies knowing enough about their business to make sense to them.
Then again, if all you have to interchange with other parties is a choice of third-rate bottom-of-the-barrel software providers anyways, I think it can still be reasonable to switch to in-house dev.
Re: Ask HN: Should we bring software dev in-house?
#303I 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…
Re: Ask HN: Should we bring software dev in-house?
#304I 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…
To me this sounds like an ad.
$5m is a solid number to ballpark any new initiative from scratch.
Re: Ask HN: Should we bring software dev in-house?
#305I 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…
To me this sounds like an ad.
Re: Ask HN: Should we bring software dev in-house?
#306Re: Ask HN: Should we bring software dev in-house?
#307I can share a great deal of input if you would like to chat sometime, message me/I’ll make a point to check tomorrow.
Quick notes * projects that add structure to data, but remain flexible to manual overrides are the most successful + fit logistics.
* full automation is almost never possible. You can automate PIECES of the puzzle, but focus on building software for humans.
* Broadly skilled technical jackrabbits are what you want. Fullstack Developer with great data modeling skills/dangerous with SQL (can DBA, can optimize queries, designing for future analysts)
If you can find a unicorn, that wants to be a #1 and take on the challenge - grab and grow organically. Don’t throw bodies and money at it.
Let them learn the business/bring them to meet everyone and see their processes and - if he’s good - he’ll find small improvements on existing systems/processes that help stabilize the sanity while he continies noodling the big picture.
The big picture will take time / start small and see if you like the results before going two feet in and handing over operations to them.
Attracting talent is easy for #1 show them the size of the company and potential opportunity.
The right person has a long-view in mind and so long as they’re successful, keep them happy and the rest takes care of itself.
Hard to leave an institution like that
Re: Ask HN: Should we bring software dev in-house?
#308https://martinfowler.com/bliki/StranglerFigApplication.html could be a good approach. You first need to hire somebody rather senior to be a "CTO" or "Engineering Manager" who is first of all supposed to help you consider "potential pitfalls" and "alternative solutions." Next I can picture that person putting together a 3-5 person team which could take a big bite out of your problem in the course of a year. Personally…
I think there's a big risk there of hiring a "CTO" who hasn't coded in 10 years and it's just a paper pusher. Ask to see the GitHub.
Re: Ask HN: Should we bring software dev in-house?
#309For us (including the client) the following approach worked great and I'd recommend to give it a try
* hire an agency (or freelancers) to work on (requirements, architecture, design, implementation) your special software - make sure the code is yours legally and you can bring it to another software shop or internal whenever you want * you get bootstrapping important decisions done by someone with experience. because hiring the first employee for that task is hard and risky * you can transition to in house from there, if you're happy with the solution or decide to stay at that agency longer - you're very flexible * Having good and maintained software as a base, start hiring. Build your team and gradually take over development. You don't have to go in-house fully, just so much that it makes sense.
Back then we bootstrapped custom software for that logistics company and gradually migrated it over to their team - even helped them hiring a team in the first place. Over time we lost them as a client (because they happily worked on their software now) but got many more clients since they recommended us highly. So it's a win-win situation.