Answer by Mattias Petter Johansson:
Spotify is internally divided into small (3-12 people) teams called squads. A feature is generally owned by a single squad, and during normal conditions the squad has all it needs to develop and maintain its feature. It's normal for a squad to have iOS, Android, web, and backend developers under its roof. The general idea is that every squad should have the ability to work on its feature pretty much on its own, minimizing the need for the squad to ask other parts of the organization for permission and/or help.
The latest versions of all Spotlets are zipped and bundled with the desktop client binary on every release, assets and all. However, we can also live-deploy new versions of the apps into the running clients of users. This is very useful for emergency releases, but we can also release Spotlets to certain user groups, such as employees or designated testers only. We can even release apps that aren't originally bundled with the client, which is very handy during our, allowing us to quickly get apps into the hands of non-techie decision makers in the company. After demoing your thing, you end off with "and now type this uri into the search field of your desktop client, to try it out with your own account!". This whole system was originally invented as part of the now-defunct Spotify Apps initiative, to support third-party developers adding functionality to the client.
While teams are autonomous, there is functionality that we all would like to share because we explicitly want it to work the exact same way in all apps. For instance, we have a CSS framework called GLUE. It was originally a fork of Twitter Bootstrap, but we've diverged heavily from that over time. Generic functionality such as some list and buttons, we also provide shared components for, but it's very easy for squads to just just templates, or just partially use functionality from the shared frameworks. It's important that squads are able to control their own reality and can pick the best solution for their problem domain, instead of having a company tool forced down their throats just because it's in-house.
We use npm extensively. We have our own internal npm repository where we publish internal modules, and we package the code together using a Browserify-like tool. npm has been magnificent for us. For the browser-specific testing, we use Mocha and PhantomJS.
If you like my writing, don't miss out on more of it –
follow me on Quora and Twitter ( )