Agreed. I think with the pace of change happening more frequently it might require more disciplined focus on training, constraining systems, and number of products.

Seems like a narrow view of developer tools. Isn't this the bread and butter of GitLab/Microsoft and others? I work in a dull industry and the perception isn't we need new tools to understand our abstractions. The main challenges I run into are that we need more staff to run and maintain new ways to work with our APIs. How do we keep track and find our APIs? Who owns the database? Am I allowed to connect to this database? My main job is to figure out how to make an on-rails experience so that when a developer leaves after two years new ones aren't relearning the flavor of the month pattern or tech someone wanted to try. It's a broad enough problem I'm sure it can be productized if you keep it general enough.

It is a microservice chassis https://microservices.io/patterns/microservice-chassis.html At scale you have lots of teams writing their own boiler plate and getting it right or wrong. This solves that at the application level. Steel toe is another option by pivotal. You can see an example of how cross cutting concerns can be solved in this mindmap https://www.alanmbarr.com/blog/images/cross_cutting_concerns...

There's some level of friction in working with databases. Not insurmountable but painful.

I loved the ML based emphasis. I'm a big fan of f# unfortunately as the article details .net has a shadow of the libraries that Java has. Clojure and Scala have much broader access to popular libraries. I've found most developers are ok with the hum drum c based languages thus c#, java, golang are good enough for most people with no interest to jump the chasm to an ML inspired language.

While it is true that .NET has less libraries than the JVM ecosystem, I'm not sure it remains sensible to still call it "a shadow of". In certain domains the .NET ecosystem is better. Either way, if a team was almost able to put up with the OCaml ecosystem, I believe the .NET ecosystem would be no problem at all.

Any plans on open sourcing this or making the code available?

Do you support on-premises kubernetes?

I'm still building so I currently don't. Kubernetes is just a tool I use to deploy my customers sites on, it's not the selling point.

I do however have plans of supporting enterprise by packaging a version of the app into an on-prem deployment system so you can just deploy your own kubernetes cluster and install the app and have your own enterprise version of Primcloud.

yes good product management is key even though your customers may not have a choice

Yup, for sure. Having PMs who understand infrastructure and distributed systems can be a secret weapon for high-scale businesses, especially in enterprise SaaS where competition is more directly head-to-head.

There's a good blog on scaling a platform team and how to keep up with growth. https://medium.com/adobetech/why-do-organizations-need-a-pla...

Great book highly recommended