Skip to content
Flagon

The Book of Flagon

How we work, in the open.

This is the real thing, not a polished excerpt. How Flagon, Inc. operates, what we value, how we pay people, how we decide. If something here reads badly, that’s a bug; tell us and we’ll fix it. It’s all versioned in git, so you can watch it change.

Chapters

  1. Why Flagon exists01The reason we started, and the one bet the whole company runs on.
  2. How we got here02Flagon's scrappy origins, and the companies we openly learned from.
  3. How we get users03Distribution by being genuinely useful and building in the open, not by buying attention or gating the door.
  4. Who we build for04The teams Flagon is for, the person who feels the problem first, and who we're honestly not for.
  5. How we make users happy05Happy users are the whole growth strategy, so making them happy is the actual job.
  6. How we make money06The actual business model: a genuinely free, self-hostable core, and paid plans for the people who'd rather we run it for them.
  7. Priced below cost, on purpose07We charge less than we could, sometimes less than a thing costs us to run, because the cheapest fair option in a category is the one people stay with and tell a friend about.
  8. Which products to build08How we decide what to build, starting from the foundation and building up, never sideways into a worse version of five other tools.
  9. Small by design09How Flagon is organized around small, autonomous teams, and why we intend to stay that way as we grow.
  10. Building a team worth being on10Why the bar stays high and we hire slowly, and how a great small team beats a big average one.
  11. Our values11The four things we actually mean, what they look like, and what they don't.
  12. Operating principles12Our values, decomposed into short named rules you can actually use on a Tuesday.
  13. Have a point of view13Generic is the real risk. We would rather make deliberate, opinionated choices than blend in safely.
  14. A world-class place to build14What makes Flagon a genuinely great place to be an engineer: autonomy, real ownership, and time to do it right.
  15. Staying alive15Financial discipline and honesty, and why staying independent is what lets us keep our promises.
  16. Where we're going16Our direction and what winning looks like, without a dated roadmap.
  17. How you can help17The last page of the book. Concrete ways to help us build the company these pages describe.

Working here

How we work

  1. How we workThe operating rhythm: small batches, shipped when good, written down, open by default.
  2. How our teams workThe company Flagon is built to be, told through the teams that run it.
  3. How we communicateAsync-first, writing over meetings, kind and direct, public by default.
  4. How decisions get madeWho decides what, disagree and commit, one-way vs two-way doors, and being wrong gracefully.
  5. Meetings and toolsHow we run the few meetings we keep, why we default to async, and the tools we reach for.
  6. Giving and getting feedbackHow we give feedback that helps, how we take it well, and why it's part of working in the open.
  7. Working asyncNon-linear workdays, written-first by default, and why async is what makes remote humane.
  8. What we keep privateWe're public by default, but a few specific things aren't, and each exception has to earn its place.
  9. How we planSmall batches, short cycles, and plans that survive contact with reality: cadence without ceremony.
  10. How we writeWriting to think, documents over decks, short proposals before big changes: how an open company stays legible.
  11. How we set goalsA few real goals over a long list: outcomes over output, revisited often, kept lightweight on purpose.
  12. Getting togetherRemote-first means being in one room is deliberate, not default: what we get together for, and what we don't.
  13. How this handbook worksThe handbook is the company: it lives in git, anyone can change it with a pull request, and every page is a draft.
  14. How to be useful hereA short mutual contract on how we show up for each other and get things done.

Tools & processes

  1. Spending moneyHow we handle company spending: trust-based, with judgment and documentation instead of an approval gauntlet.
  2. Team changesHow people move between teams and change what they own here: low ceremony, in the open, and without drama.
  3. Working in GitHubGitHub is where the work actually lives: the code, the handbook, the roadmap, and most of the decisions. Here's how we use it.
  4. Adding toolsHow we decide what software the company runs on: prefer few, boring, and owned over a sprawl of half-used subscriptions.
  5. Staying secureSecurity is everyone's job, not just engineering's. The basic habits we all keep so one careless moment doesn't become a breach.

People ops

  1. Working hereWhat it's actually like to work at Flagon, who thrives, and who won't.
  2. OnboardingGetting a new person productive is our job, not theirs. What we owe someone in their first weeks, and how we know it worked.
  3. Your first weekWhat to expect on day one and through week one, and why the goal is momentum.
  4. 1:1s and growing hereYour agenda, not your manager's. What 1:1s are for, and a lightweight picture of growth.
  5. Staying human at a distanceRemote kills the hallway, so we rebuild connection on purpose, without forcing fun.
  6. How we manage (and don't)What the management job is here, what it isn't, and why it's not a promotion.
  7. How we part waysHow we handle people leaving, by choice or not, with honesty and respect.
  8. When we disagreeA lightweight path for working through conflict and disagreement on a small team.
  9. Diversity and belongingWhy a mix of people makes the work better, and the daily habits that make a small company somewhere you actually want to be.
  10. Side gigsOur stance on side projects, moonlighting, and who owns what you build on your own time.
  11. Growing hereHow you develop and progress at Flagon: by scope, not tenure, and without being forced into management.
  12. Learning out loudWe fund curiosity generously and share what we learn openly, because knowledge kept in one head helps one person and knowledge shared compounds.

Pay & perks

  1. How we pay peopleThe philosophy, the formula, and the levels behind every number we pay.
  2. Share optionsEveryone here gets equity. This is how our option grants work: the terms, the vesting, and the plain-English answers to the questions everyone has.
  3. Benefits and perksWhat we offer beyond salary, and the philosophy behind what we do and don't.
  4. Time off and hoursOutcomes over hours, real rest, and playing the long game with your energy.

Hiring

  1. How we hireWhat we look for, how the process runs, and how offers and rejections work.
  2. The hiring processThe exact stages from first contact to offer, what each one is for, and how long it takes.
  3. How we interviewFor anyone running an interview here: how to get a real signal, stay fair, and treat the candidate the way we'd want to be treated.

Resources

Brand

  1. OverviewWhat brand means at Flagon, why we treat it as a growth engine rather than a coat of paint, and where to find the rest of it.
  2. FoundationsWhat the brand is built out of: taste over polish, the personality we aim for, and who we are actually talking to.
  3. VoiceHow Flagon sounds in writing: the register we use, the words we avoid, and the rules that keep it consistent across everyone who writes.
  4. Visual identityThe Flagon mark, the palette, and the type, with the rules for using them. One vessel, one accent, one typeface family.
  5. AssetsWhere the logo lives, the treatments to reach for, and the clear-space and sizing rules for using the mark cleanly anywhere.
  6. In practiceHow the brand shows up on real surfaces: the site, docs, release notes, support, social, and swag. The same instincts, applied everywhere.

Engineering

  1. How we buildThe engineering habits we actually keep: ship small, stay releasable, and prefer boring tech that works.
  2. Tech stackWhat Flagon is built with, and why: two small, independently deployed services, boring proven tools, and a hard rule that the API is the only thing that owns data.
  3. Developing locallyPostgres in Docker, then the API and the app however you like: both in containers, or natively so you can keep next dev up while you restart Go. Running in minutes, not days.
  4. Project structureA map of the Flagon monorepo, so you can find the thing you need to change without reading everything first.
  5. How to do product as an engineerHere you don't get handed a spec. You own a problem, talk to the people who have it, and ship the smallest thing that helps. This is what that looks like day to day.
  6. Ship the smallest useful changeWhy we split big work into small useful pieces, ship them, and iterate in the open.
  7. How we review codeKind and rigorous, fast on small changes, and aimed at the person who reads this code a year from now.
  8. How we review PRsThe mechanical checklist for getting a pull request reviewed and merged here. The why behind it lives in how we review code; this is the how.
  9. Shipping and releasingHow a change actually gets to production here: small pull requests, a trunk that's always releasable, and deploys boring enough to do on a Friday.
  10. How we testTests that earn their keep, catch real regressions, and give you the confidence to ship without slowing everyone down.
  11. Bug prioritizationHow we decide which bugs get fixed when. A simple four-level scheme, honestly applied, so the important things get fixed fast and nothing rots silently in a backlog.
  12. Feature ownershipYou build it, you own it, from the first commit through it running in production. What that means, and what it doesn't.
  13. When things breakBlameless, stabilize first, tell the truth, and turn a bad day into a better system. No heroes required.
  14. Security and trustHow we think about security, privacy, and earning the trust people place in us.
  15. Open source and building in publicWhy we default to open, what that means for the roadmap and the mistakes, and why it's an advantage rather than a giveaway.
  16. How we designDesign is the whole shape of the thing, not a coat of paint at the end. This is how we think about craft.
  17. Visiting customers as an engineerSome things never show up on a call. Sitting next to someone while they use what you built is one of the highest-leverage things an engineer here can do.
  18. Customer comms as an engineerWhen you ship something that changes what customers experience, they should hear it from us first, clearly, and before it bites them. How to do that well.
  19. Support and customer careSupport is craft, not a cost center. Here's how we treat the people who use what we make.
  20. Writing docs as an engineerDocs are part of the product, not a chore that comes after it. Stripe is our north star.
  21. Writing blogs as an engineerYou just solved something hard and interesting. Writing it up is worth more than you think, both to the people who'll read it and to you. Here's how.

Product

  1. OverviewWhat product means at Flagon: not a department that decides what everyone else builds, but the people who keep us close to users and honest about how we're doing.
  2. What product managers doThe PM role in full: the three things a product manager owns for their team, and the things they deliberately don't.
  3. Product metricsAlways knowing how a product is performing, in usage and in revenue, and treating a number moving the wrong way as the start of a question, not the end of one.
  4. Listening to usersThe systems that keep the whole team, not just the PM, in regular contact with the people we build for, and what we do with what we hear.
  5. Deciding what to buildHow priorities actually get set here: not by a PM ranking a backlog, but by a team that understands its users deciding together, including for products that are already mature.
  6. Releasing products and featuresHow something new reaches users here: gradually, watched closely, and treated as the start of the work rather than the finish line.