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

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.

Hello,

I've only done B2B transformations (revisiting all software systems and realigning/reimplementing them in parallel) like this in multiple verticals, both physical and digital, for the past 20 years as a Fractional CTO for companies in your revenue range and larger.

As needed I can traverse the entire pyramid from top to bottom from business strategy, finding partners and vendors, and informing everything down to the nuts and bolts alone for maximum alignment, and ensure it's learned alongside team members in the organization.

I often help with the budgeting and estimating process and find customers save significant time and money with the right strategy, approach and oversight.

Here's my take:

1. ATTRACTING TECH TALENT:

- Consider a contract-to-employment model. I've built teams where contractors who prefer employee life can switch over. There's other options too depending on your current mix and structure.

- Emphasize training at all steps. I guarantee clients a trained and productive resource, regardless of employee or contractor status.

2. THIRD-PARTY TO IN-HOUSE TRANSITION:

- Success: Helped clients reduce days-to-cash by 50% with custom solutions, projects relatively on time, and staff that remained able to work in the new system.

- Caution: Seen projects stall due to underestimated complexity, or avoiding realities (ie., data may not be as good as they thought)

- Run fast from anyone who wants to build only code from scratch from the outset. Also run from buying an all-in-one system until you know what your critical path is. I have worked around and through both, including from the start, and rescuing projects.

3. POTENTIAL PITFALLS:

- Underestimating current system complexity.

- Cloud lock-in: It's the new software/vendor lock-in, just sneakier. There are ways to have your cloud cake and eat it too while maintaining options.

- Over-engineering: Build software has become horribly overcomplicated. It's hard to keep things simple and flexible, easy to make it complicated. Helping everyone understand the data and process together sheds a major light on the path ahead and create a better sense of ownership.

4. ALTERNATIVE SOLUTIONS:

- Hybrid approach: Develop core competencies in-house while using strategic third-party solutions.

- Agency acquisition: I've facilitated M&A deals where companies purchase agencies.

- Vendor-as-internal-department: Set up external vendors with internal SLAs.

KEY CONSIDERATIONS:

- I would start with an honest assessment of where your organization truly is and where it wants to be. Beyond advisory or building, learning where your business needs to head and measurable ways to get there is critical.

- In-house dependency is important, but there may be better external options too that can be much more stable than an agency with interests with multiple clients.

- Any culture change and planning for it is critical.

- Industry standards (SOC, HIPAA, etc.) and architecture will ultimately decide the fate in 5-10 years.

- I keep software sales promises honest and accurate to the company, ensuring clarity on current state and future direction. Includes negotiating contracts that work for the business, not the vendor alone.

I have a lot of conviction about what I do because I've done it and still do it, keeping up with where things are headed to provide input on where things could be. I train to process, and so the process is central.

If you'd like to chat more, I'm happy to offer an hour of my time.

I'm genuinely curious to see how much actual valuable information and insight I can provide to help you think through your situation. Firehose, or key points. My email is in my profile or reachj45@gmail.com

My goal is to give you as much food for thought as you like, knowledge as possible, regardless of any direction you ultimately take. My email is in my profile if you're interested in a no-strings-attached discussion, except I'd like you to bring the most painful issues.

The world is an odd place where people who don't understand software sell it to people who don't always know how to buy it, let alone roll it out. Navigating this can be an outlier for impact. I'm here to help change that where it crosses my path and get technology working for people instead of the other way around.

Note: Edited from a laptop instead of written from a phone. :)

In case anyone's thinking of reaching out, offer is open to anyone relative to my availability.

I was wondering if a starting a new company was a better way.

It has one customer (initially).

If it doesn’t pan out you can drop that shitty vendor.

> It depends. In the end EDIFACT is just a protocol. If you go the Java route Smooks, for example, has pretty decent support to read/write EDIFACT messages.

You can also do shim servers to translate between protocols - a long time ago, I had to interface with a Rails app (by another team, so I couldn't modify it) with an Emerson (the industrial giant) SOAP API, and what turned out to be effective was a Sinatra shim server that only converted JSON to SOAP. Now I could plug the two together without worry.

So - I'm guessing you could have a Java Smooks applet that translates from a JSON API to the EDIFACT protocol, and then you can write your main app in anything you want.

PS - Seconding the "don't go microservices", even though I'm advocating for one here - IMO, you only want microservices if they can be fully defined, independent products; a JSON/EDIFACT translation service would probably qualify.

+1 to this take. I think hiring a CTO at the start might lead to its own distinct challenges, especially if that's not something familiar. Hiring a small excellent team of builders could be an effective solution, especially folks with sufficient experience and very strong communication skills.