Introduction

Welcome to the Applifting Frontend Playbook — a collection of patterns, conventions, and recommendations we’ve gathered through years of building frontend applications across many projects.

What is this?

This is not just a style guide. Many formatting and linting rules are already enforced automatically via tools like ESLint, Prettier, or Biome. What you’ll find here goes beyond that — it’s a handbook of battle-tested patterns and approaches that we’ve found helpful, practical, and worth sharing.

Think of it as a playbook that captures how we think about frontend development: how we name things, where we put them, which libraries we prefer, and why.

Why does it exist?

Frontend development offers endless ways to solve the same problem. Without shared conventions, codebases diverge, onboarding slows down, and code reviews turn into debates about personal preferences.

This playbook exists to give us a common ground — a reference point we can rely on when making decisions. It helps us:

• Move faster by not reinventing the wheel on every project
• Onboard new developers with clear expectations and patterns
• Keep codebases consistent so switching between projects feels familiar

How we use it

At Applifting, this playbook serves as our anchor when in doubt. Unsure how to name a function? Check the playbook. Wondering where to place a new component? Check the playbook. Having a disagreement in code review? Check whether the playbook has an opinion on it.

It’s not about enforcing rigid rules — it’s about having a shared vocabulary and a starting point for discussions.

A living document

This playbook is a living organism. We constantly revisit, update, and improve it based on our evolving needs, new tools, and lessons learned. If something feels outdated or you have a better idea, contributions are welcome.

When a new project is started, it should follow the current version of the playbook at that time.

This document follows Semantic Versioning and all changes are recorded in a Changelog.