Here's the tension I find with projects like these: App developer knowledge seems to end with a helm chart. Anything more complex than that, they won't be able to deliver themselves. For platform/k8s admins, these tools are more cumbersome than just writing a dedicated operator in go.
What advantages does this offer over rolling my own CRD and operator? Assume it takes me 4 hours to write an operator end to end.
You should write your operator. You are correct: it is quite straightforward and you'll have solid understanding of what is happening and how it works.
That is how this project started. We wrote custom operators for the various platform components; that worked outstandingly well. Shockingly well to be honest.
This system evolved from that approach because we needed a way to rapidly customize our application models. If you don't need to support varied use cases _and_ have standardization writing your own is the way to go.
Where Koreo excels is when your developer knowledge ends with a Dockerfile and your platform team is able to abstract service deployment away from them. Many organizations use a "god chart" to do such a thing but those will become cumbersome over time. Koreo's value prop also is greatly enhanced when paired with ACK or Config Connector as you have an organization specific DSL that will integrate your container runtime with your cloud resources. E.g. mount your rds address on your pod in one workflow.
What advantages does this offer over rolling my own CRD and operator? Assume it takes me 4 hours to write an operator end to end.