# Open Standards

{% hint style="info" %}
You can contribute to these open standards by opening a Pull Request to [our repository](https://github.com/goharrier/open-standards).
{% endhint %}

## Welcome to our Open Standards Documentation

This space is dedicated to the development, configuration, deployment, and various opinionated strategies within the **Salesforce ecosystem**. Our goal is to ensure a cohesive approach and a shared understanding among our team members and potentially the entire community.

## Who We Are

Harrier is a specialized Salesforce consultancy focused on delivering enterprise-grade solutions through proven architectural patterns and engineering excellence. We maintain these open standards to ensure consistency, quality, and knowledge sharing across our projects and the broader Salesforce community.

## Our Approach

We believe in:

* **No-nonsense delivery** - Clear, honest communication and practical solutions
* **Engineering excellence** - Following proven patterns and best practices
* **Knowledge sharing** - Building on open-source frameworks and contributing back to the community
* **Avoiding vendor lock-in** - Creating flexible solutions that empower our clients

## What You'll Find Here

This documentation covers:

### Technical Standards

* **Best Practices** - Apex style guides, naming conventions, and development principles
* **Frameworks** - How we leverage fflib, Nebula Logger, and flxbl in our implementations
* **Design Patterns** - Proven architectural patterns for Salesforce development
* **Anti-Patterns** - Common pitfalls and how to avoid them
* **Integration Strategies** - Modern approaches to system integration

### Functional Standards

* **Requirement Definition** - How we shape and document requirements
* **Documentation Approach** - Standards for technical and functional documentation

Each section focuses on practical, implementation-ready guidance based on real-world experience, not theoretical concepts.