Before you start writing a plugin, check if you really need one to solve your problem. If your problem does not require meddling with the application's life cycle, it's better to write a library.

While writing/updating a plugin, simultaneously build an example Play application that uses the plugin. This will allow you to check the functionality of it thoroughly with only the additional overheads of publishing the plugin locally for every change made.

If the plugin exposes some services, try to provide a helper object. This makes it easier to maintain the API's consistency and also simplifies the developer experience.

For example, most of the plugins provided by Play (such as akka, jdbc, ws, and so on) provide helper objects through which the API is available. Internal changes to the plugin do not affect the public API exposed through these objects.

If and where possible, try and back up the plugin with sufficient tests.

Document...