I'm assuming you're asking what's important in writing "production" Haskell rather than "toy example" Haskell.

Ixiaus's point about mechanics more than theory certainly rings true, though we did think a lot about whether to use GADTs for the Dimension type. Overall I see this as similar to writing "production" code in other languages, going through a couple feedback loops using real use-cases. Profiling to find the bottlenecks, observing how APIs are used in practice compared to intent, and reaching the service to a stable equilibrium.

Not the op nor on their project but I do work at a company using Haskell to solve interesting theoretical problems and for mundane software like cli tools and grpc services and web services.

Most people have an assumption that production Haskell involves a lot of theory when that's actually more the exception I think. My day to day use of Haskell (with the exception of a few projects) is as a strongly typed imperative language. In order to use it in production in that capacity you should have an intermediate level understanding of the type system so that you can wire library apis up and use them.

The productivity gains from Haskell's type system are quite large and they compound, particularly when you have multiple people massaging the​ code base.