Setting development standards for your technology/team/company is pretty common when writing code to ensure that everyone is following he same practices. However, I believe this is not just something that is applicable when writing code and it can applied to any application development when building on the Salesforce platform.
To start with we can borrow many general practices from coding standards before we get in to Salesforce configuration specifics. Some things I always that you could consider setting standards for are:
Follow a naming convention – prefix the API names of fields etc with an application prefix. (e.g. for an Salesforce app, I might prefix everything with SAL_) the more apps that are added to your org – the more useful this becomes but it is very difficult to do retrospectively.
Field Descriptions – always populate descriptions, this can be your data dictionary right inside Salesforce. Imagine how much easier to understand your org will be for a new joiner if everything has a detailed description.
Declarative Development – Always add detail descriptions e.g. for a process builder. If you are a project/task management tool then consider adding references in the description e.g. a reference to a JIRA ticket which contains all of the designs and details of why this was built. This can be very useful in future when the functionality is changing as you can understand the thinking behind why it was built a certain way before you change it. Is there a particular structure to use for our process builders or flows, do we have one per object with multiple branches or do we create a new one for each use case?
Permissions – How do I assign permissions in my application especially if there are different teams or business unit using the same org. Do I need to create multiple profiles? Can I use Permission Sets and Permission Set group to ensure that each persona only has the access that they need and I am not creating large generic profiles.
Roles – How do we streamline roles in the org. Are avoiding common mistakes like creating the the company org charts in the role hierarchy, there might be times when this is appropriate but generally they are not as people at different levels might have the same data access which could mean that multiple roles are not needed. Less roles will mean less complexity in your org.
Sharing Model – You could add information on the best way to share data for your applications. This is probably specific to your particular applications but you could mention how your data is shared, should we be using roles, sharing rules, groups etc
Mandatory Security Settings – Are there any settings that you not be changed in your org or at least not changed without approval. This could be items like Password Complexity, SSO Setup, Session Settings.
Object Creation – How should we create new objects e.g. do we always enable enable reporting, history tracking or activities?
Integrations – Document objects that are used for integrations so that people will know that changes to these objects need to be carefully managed and tested.
Clicks vs Code – Is there a policy for this on your org. It is jus a case of the best tool for the job or do you want to exhaust declarative app and app exchange options before moving to code?
Your own standards – Anything that would be expected for someone building an application in your org e.g. we always create an External ID field on new object for data loading or any other items that are specific to your org or company.
This is not an exhaustive list and ultimately you need to choose the standards that are right for your org. The important thing is that everyone who is building in your org is following the same guidelines so that your org is easier to understand and it also makes enhancing existing applications or creating new applications in he same org much easier.