bwh2

Two good ones: 1) Where Wizards Stay Up Late and 2) How the Internet Happened: From Netscape to the iPhone

The primary cost differences I have experienced come with maintenance and fees, not the initial build.

Maintenance = iOS version updates, dependency upgrades, App Store requirement changes, etc. have been costlier and more out of your control than with web apps. Fees = the App Store's 15-30% fee is more expensive than using a web payment processor.

I highly recommend the book System Design Interview by Alex Xu.

Although you wouldn't expect it, the book Monolith to Microservices presents solid arguments against microservices. The author cautions against using microservices throughout the book due to the additional complexity introduced.

Difficult Conversations. So much stress and anxiety comes from anticipating, avoiding, or not knowing how to have difficult conversations.

It sounds like retention is your problem, less so acquisition. Have you talked with customers to understand why they are leaving your product?

Agreed. That was the point of my comment - there is an abundance of developers who just work in JS/TS/React and have not picked up new technologies. Adding C#, Java, SQL, etc. helps your marketability.

It would help both in demonstration of interest in learning that language further and in being able to pass technical interviews.

As a hiring manager who looks at a lot of resumes, I think your hunch is correct. I see a lot of junior to mid-level developers that primarily work in JS/TS/React. That market is heavily saturated and I regularly read posts on LinkedIn from these people about how difficult it is to find a job.

The candidates that stand out from the pack are those with some tangible production backend experience in languages like C#, Java, etc., combined with SQL experience. Strictly in terms of marketability, I do believe getting real-world backend experience greatly increases your value.

Similar size company and over the past 2y we transitioned from technology based teams to stream-aligned teams that include engineering, product, and design within each team. The book Team Topologies is a good reference for this and fairly quick read.

In my experience, the pros of stream-aligned teams vastly outweigh the cons. The major pros are reduced cross-team dependencies and fewer hand-offs, more ownership over work, focusing people on a narrower set of customer/business problems, and that stream-aligned teams are easier to refactor and decompose as the organization grows.

What I learned along the way is that you will still have some cross-team dependencies based on technical expertise. So you will benefit from your engineering leaders explicitly and regularly discussing these needs, then incorporating some resource sharing into their plans. For instance, you might have an engineer who really knows one area of the product or technology brought into another team's kickoffs and design reviews or even joining the other team temporarily.

Consider focusing on managing the team through this: "there are a lot of skeletons in the code & infra to worry about." Sometimes what happens is you have seniors who know the technology and product inside and out, but don't think in terms of team dynamics and the organization's ability to deliver effectively.

A few books that influenced my product thinking: The Cold Start Problem, Working Backwards, and Strategy Rules.

Most people have not developed the habits and discipline necessary to benefit from a plan.

These are both well written and happen to be about writing: On Writing Well by William Zinsser and On Writing by Stephen King.

The Five Dysfunctions of a Team is similar in style and a good read.