I’d like to share this example project that I wrote:
The locolamp example is written from a certain perspective – of one who primarily works on a web-application, tending to code in PHP/SQL/JS/etc. That means you’re not responsible for a specific deployment environment (the code may be used in many different deployments). However, you do care about tuning the stack that you work with.
The use-case is roughly comparable to the older-school of PHP dev stacks: “MAMP”, “WAMP”, or “XAMPP”. However, using nixpkgs means that (1) you can reproduce it on different OSX/Linux hosts and (2) it’s possible to fine-tune the environment (adding PECL extensions, changing versions, using bleeding-edge platforms). Additionally, you can (3) make multiple copies of the environment with different options, and (4) track the changes in key configuration elements (default.nix, php.ini, my.cnf, etc).
One might also compare this to a docker-compose project. However, using nixpkgs to get local binaries means (1) simpler networking, (2) simpler IDE integration, and (3) better I/O performance (for grepping/refactoring large codebases or loading large datasets).
I wrote this example several months ago and then sat on it for a while… because I’m pretty sure it breaks some NixOS conventions. As a novice who’s outside the NixOS mainstream, it’s hard to differentiate bad-rule-breaks from the good-rule-breaks. 
I dunno - maybe sharing it will produce some useful lessons or help another newcomer coming from a similar web-dev perspective.