Introducing Playbooks
The guides we use to run sprints, deploy agents, build brands, and start companies, published as written. Eight at launch, in four categories.
Today we are publishing Playbooks: the operating guides we use inside Entatan, written the way we actually follow them. There are eight at launch across four categories: engineering, marketing, creative, and ventures.
They are not thought leadership. They are checklists with reasoning. Each one describes a job we do repeatedly, the steps in order, the tools involved, what goes wrong, and what we measure.
What is in the first release
- How we run a two-week build sprint. Scoping, the day-by-day cadence, the demo, and the handover.
- Standing up an AI support agent in a week. Shadow mode, approval mode, the boundary document, and the eval set.
- A performance-marketing stack for a two-person team. Accounts, tracking, creative rotation, and the weekly review.
- Brand system in 72 hours. The compressed identity process, from positioning to tokens to templates.
- From idea to incorporated venture in 30 days. The Vinyatan checklist, from thesis to first customer.
- Agent evals that catch regressions. Building an evaluation set from real cases and running it on every change.
- Landing pages that load in under a second. The stack, the budget, and the checks we run before launch.
- Weekly growth reviews that actually change spend. The agenda, the numbers, and the decisions.
Why publish them
Three reasons. Partners ask how we work, and a document is a better answer than a call. Writing a process down is the only way a small team keeps it when it is busy. And if a playbook is good enough to run your own team on, you should. Some people will read them and hire us. Some will read them and not need to. Both are fine.
Playbooks also replace the help centre. Rather than a knowledge base of short articles, every question a partner has asked more than twice becomes a section in the relevant playbook.
How they are written
Each playbook starts as the internal document we actually use, including the parts that are embarrassing. We remove partner-specific details, keep the numbers, and add the reasoning that lives in people's heads. An agent drafts the first public version from the internal one and the commit history of the last few projects that used it. A person rewrites it. The person's name is on it.
Every playbook has a date and a changelog. When we change how we work, we change the playbook the same week.
What is coming
The next set covers lifecycle email, paid social creative testing, incident response for agents in production, and how we hand a venture over to an operator. We publish when a playbook has been run enough times to trust it, not on a calendar.
Read them
All eight are at /playbooks. If you follow one and something in it is wrong, tell us. That is how they get better.