Cantilever Development Ethos

Our customer promise is Digital Hospitality. Nowhere is that more directly felt than in the way we develop our websites. Watch this to understand what we are talking about:

Our prime directive is to meet the needs of the client as best we can. Those needs change project-by-project, but what we pitch and sell are sites that are built to last, with re-usable, flexible components so that our codebases last much longer and can withstand much more change than those of our competitors.

Development Priorities

This is the loose hierarchy of what we try to do with our development work.

  1. Meet or exceed the design and functional requirements
  2. Match or better the budget
  3. Optimize future development, limit technical debt
  4. Learn new technologies and approaches
  5. Generate content for our content channels

Principles

Cantilever development is distinguished by an unusual level of "give-a-crap-itude". We care deeply about the quality and integrity of our work. The greatest badge of honor we can get is when we deliver code for a client’s own team to use, and they can successfully. If we can create systems that last, we are providing value beyond the initial functionality that other firms know how to hack together.

Behaviors

Some distinguishing aspects of our development workflow are:

  • One unified Philosophy, with slight deviations and evolutions per-project which, if successful, get rolled into the methodology. Other styles can be great, but we have decided to sacrifice flexibility to maintain consistency and predictability in our codebases.
  • Accessibility. We should be thinking about accessibility throughout the design and development lifecycle and ensuring that our sites met our standards:
    Accessibility Standards
  • Documentation. Every project should have comprehensive documentation outlining all you need to know about the project and its functionality, plus a README that walks you through local installation.
  • READMEs and Documentation
  • Continual QA. We do not rush to get “ready for QA”, sweeping bugs under the rug. We write features in isolated merge requests and test them individually, so that each step is building on a solid, trusted foundation. Testing duty is spread among the team according to the capabilities of each member.
  • Obsession. For better or worse, we always try to find the optimal solution. We may decide to use a hack or two in the end, adhering to the development priorities, but we like to at least know what the best way forward is before we decide to go a different way.

Frontend Dev Orientation Training With Ty

Done when several new people were coming on to work on our stuff