It might be worth giving a pointer on setting up your own stackage server. Otherwise, Haskell projects can become an ugly monolith sooner in a company's lifetime than one might expect. It can then become a double-edged sword that you're quite productive in the language.<p>The CI for a medium-sized Haskell-using company should have multiple instances of:<p>Project repo -> CI compilation -> tests -> publish library to company's internal stackage.<p>That way, when someone inevitably publishes something that breaks things, the other teams will have an <i>easy</i> mitigation / known-good-version to fall back on.<p>In other codebases (especially if they use the typical popular dynamic languages), you might start breaking things up into microservices sooner than you would with Haskell. But given that Haskell runs much, much faster than those other languages, and isn't quite the memory hog that the JVM is (when we're comparing to Scala), you might find that it'd help you scale if you broke up the codebase into libraries, rather than breaking it up into microservices. This is especially the case if your company / project is bottlenecked on ops (which many companies are, not just ones using Haskell). Multiple libraries is much easier to manage than microservices and forestalls the point at which you'll need serious dedicated ops.