Setting up best practises: Our Frontend Playbook is now public

In every development team, especially on frontend projects, the same challenges tend to pop up again and again. Code reviews catching the same issues repeatedly. Developers joining a project and finding patterns completely different from the last one. Arguments about which file some piece of code should live in. Even on the same project, everyone has a slightly different opinion on how to write the most common things.

This lack of consistency in coding practices and project structure can slow down progress and lead to confusion. We felt that frustration too. So we decided to fix it by writing down what we actually agree on. 

That's how the Applifting Frontend Playbook was born.

So, what is the Frontend Playbook? 

It's an opinionated but practical set of guidelines for how we write frontend code at Applifting. 

It’s not just a style guide. We cover everything from project folder structure and naming conventions to programming principles like DRY and AHA, as well as specific patterns we prefer when working with libraries like TanStack Query.

It's a living document maintained by our Frontend Guild. Anyone on the team can propose changes based on their experience—add something we're missing, challenge rules that feel too strict, or update what's no longer relevant.

Why we created the Playbook

We wanted to solve a few recurring problems. New developers joining a project had no clear reference for how things are done. People moving between projects had to relearn patterns every time. Code reviews turned into debates based on personal preference rather than shared principles.

So our frontend team started collecting the bits and pieces we kept discussing: what we argue about, what we consistently agree on, which libraries we enjoy and how we use them. 

After about six months of gathering input, we organised everything into a structured document. Then we sat down as a team, discussed what was missing, and cut what felt like personal preference rather than genuine consensus.

What's inside the Playbook

The playbook is divided into three main areas:

• How we write code – Function and component patterns, TypeScript practices, naming conventions, when to reach for immutability.

• How we structure apps – Feature-Sliced Design, routing patterns, how data fetching and features fit together.

• How we work together – Git workflow, shared UI approach with shadcn/ui and Tailwind, environment variables, API type generation.

We're no longer debating PascalCase vs kebab-case for component files. We've settled on what order code should follow inside a component. These aren't universal truths—they're just what we agreed on as a team so we can move faster with less friction.

Why we made it open source

It started as an internal Markdown file. But especially now in the agentic coding era, passing a giant document as context to AI tools became awkward. You either copy-paste fragments or waste tokens feeding the entire thing.

So we published it as a structured website. It's searchable, organised into categories, and optimised for AI consumption with an llms.txt file that serves as a table of contents. That way, agents can jump directly to the parts they need.

But it's not just about AI. As a software development studio, we often work in hybrid teams with clients. Now it's easy to share how we approach frontend at Applifting without digging through our private GitLab. And for anyone curious about how we work—potential collaborators, future teammates, or just fellow developers—it's all out there.

Explore it yourself

The playbook will keep evolving. What's best practice today might look different in a year; that's just the nature of frontend.

Check it out, and if something resonates or you disagree, we'd love to hear from you.