The Standard IT Playbook

Email: the backbone

Everything else in this playbook hangs off email. Get this right and the rest falls into place. Get it wrong and no tool will save you.

Who hosts your email

Who hosts your email is a real decision in terms of money, but in the end it is the same tool no matter who you use. We recommend Purelymail for three reasons. They stick to email standards strictly. They charge pay-as-you-go, so if you have a larger team with a few people who barely touch email, you pay almost nothing for them: a team of ten heavy users runs about $10 a month. And they have been around since 2018. A good alternative is Migadu, around since 2014. Their pricing is a little more involved but the service is excellent.

How to structure your addresses

• Every person has an email. Only people send email. Teams, groups, and departments do not.
• If one day an agent sends email, give it its own address, like sales-robot@example.com. The address tells the reader who, or what, wrote the message.
• Use aliases for anything you print or publish. We use feedback@ and customers@ so we can keep the same address on our product boxes without stamping a person's name on them.

The etiquette that makes email work

This is the part nobody wants to hear and the part that matters most. Email without etiquette becomes a swamp. With it, email scales to run an entire company. The Linux kernel coordinates thousands of contributors over plain email, and the only reason that works is that they are deadly serious about etiquette and let no one slide.

1. No top posting. Every message you send should contain only the information you want to keep. When you bottom-post, leave enough context that someone reading a week after their original message gets a refresher of where the conversation stood as they read your reply.
2. Plain text is king. If you genuinely need HTML, for a table say, use it. Otherwise plain text wins. Most of these rules are drawn from useplaintext.email.
3. Use the headers deliberately. Putting someone in To: means something different from Cc:. To: means you are aiming the water gun at them. Cc: means you would just like them to get splashed.

Three more that earn their place once you are past the basics:

• Communicate more, not less. People are stingy with the email they send. One of us receives around 200 emails a day and clears the ones that need a reply in about two hours. Volume is not the enemy. Disorder is.
• Keep the mailing list in Cc for anything not private. The list archive is the memory of the company. Why would your communication not be part of that memory? It is everyone's job to filter their own mail well so they see only what they need.
• Write clear subject lines. People write subjects as if every vowel cost money. Long is fine. Unclear is not.

Mailing lists: the company memory

This is our favourite part of the setup. Mailing lists are powerful precisely because they are such a simple primitive. They adapt to an astonishing range of situations, and they turn day-to-day conversation into a permanent, searchable record without anyone doing extra work.

Which service, and what it costs

We are on Google Groups today, because we are on Google for email. We recommend groups.io instead: it has more features than you will ever need and is genuinely easy to use. Start on their free plan. The limit you will eventually hit is the 1 GB storage cap. When you do, it is $20 a month for effectively everything you will ever want.

Start with as few lists as you can

We began with a single group that included the whole company. After about a month it became obvious that one product line generated discussion unrelated to everything else, so we split it onto its own list. That is the right order of operations: start with one, and let real friction tell you when to divide.

A common shape for an e-commerce business past ten people is two lists: one like platforms@ for listings, product, and marketing, and one like purchasing@ for manufacturers, freight forwarders, and 3PLs. Once you have lived with lists for a couple of months and know what is genuinely useful to you, add more. Not before.

The settings that matter

First, a mindset point the whole team needs: the lists are not only for internal chatter. Your external partners will post into them too, and that is a large part of the value. A supplier's reply landing in the archive is company memory you did not have to file.

Two things lists give you that aren't obvious

• New hires inherit the whole archive on day one. Before they ask a single question they have something to search. groups.io exports everything to an mbox file, so you can even seed a new person's mailbox with past threads and let them search it in whatever mail client they like, or run a subset through an LLM to get up to speed fast.
• Every message has a permanent link. When you want to point to a specific decision from another email, the wiki, or a chat, you link to the archived message and the reader lands on it with the full thread for context.

Shared files: managed Nextcloud

Nextcloud is powerful software and notoriously fiddly to self-host. So we don't. We let professionals run it and we get the ownership of self-hosting with none of the maintenance.

The plan

We use Hetzner's Storage Share, which is managed Nextcloud. We are on the NX11 plan: 1 TB for €4.29 a month, unlimited users. It scales to 10 TB. You can order it bare, or route a subdomain to it so your files live at something like nc.example.com. Hetzner keeps the software stable, the servers up, and runs daily backups of the entire file system. This is not hobby software: it is used by the German federal government, the French Ministry of the Interior, the Sorbonne, and Deutsche Telekom, among others.

Folder structure

This is particular to every business, so we will not hand you ours and pretend it fits. The one rule worth stating: structure for the new hire who has never seen it, not for the person who built it. If a folder name needs explaining, rename the folder.

The admin features that earn their keep

The admin panel is where a managed Nextcloud quietly beats consumer file sync:

• Per-user storage quotas, so no one person can swallow the system.
• Enforced 2FA for everyone.
• Automatic expiry on public links, so a folder someone shared and forgot cannot quietly stay open to the world while sensitive files get added to it later.
• Teams, so you can share a folder or file with a whole group in one click.

Version history and external sharing

We use version history for exactly one thing: saving ourselves from ourselves. It is the undo button for a file someone overwrote.

External sharing is where it gets genuinely useful. We set public links to expire automatically after six months, so nothing stays open forever by accident. And we lean on the file request share type constantly: you send a client or a manufacturer a link, they cannot see anything in the folder, all they can do is drop files into it. It is the cleanest way to collect documents from someone outside the company.

Passwords: KeePassXC

Your passwords should not live on someone else's server behind a subscription. KeePassXC keeps them in an encrypted file that you own, that syncs with the file system you already have, and that costs nothing per user, ever.

How to organise the vaults

We keep one folder at the root of our shared files that everyone can reach. Inside it, a vault per department and a folder of personal vaults:

safe
├── accounting.kdbx
├── admin.kdbx
├── logistics.kdbx
└── personal
    ├── claire.kdbx
    ├── john.kdbx
    └── mary.kdbx

To weave shared credentials into each person's own database, use KeePassXC's KeeShare feature. It is not strictly necessary: you can simply keep several files with different passwords. But KeeShare lets the logistics vault, say, appear inside a logistics person's personal database automatically, which is a real convenience once you are past a handful of people.

Where the vaults live

All of them live in Nextcloud. When someone leaves, you email them their personal file and delete it from the shared folders. These files are tiny: one of ours holds hundreds of passwords and is under 500 KB.

Onboarding a new hire

1. Give them a short screen-recording from someone on your team explaining the basics of KeePassXC for your setup. A generic tutorial is fine to supplement, but your own two-minute video is what lands.
2. Send them the passwords for the KeeShare vaults that are theirs (logistics only, say) through a one-time secret service like PrivateBin. Never the shared file's password over plain email.
3. Drill the one rule that actually matters: never lose your master password.

KeePassXC's documentation is excellent, and this video is a good tour of the advanced features when you are ready for them.

Coordination: the Situation Room

Mailing lists have one weakness: a thread has no status. It is either in your inbox or it is not. The Situation Room is the small, deliberate fix for that, and it is nothing more than a spreadsheet.

Why this exists

This problem is not new. The Linux kernel hit it years ago and built a tool called Patchwork that reads the whole mailing list, picks out the messages containing patches, and tracks the status of each one so a maintainer never loses a thread just because it went quiet for a while. We needed something like that, far simpler. So we built the Situation Room: a single spreadsheet listing the things currently in flight. It can be a Google Sheet, or an .ods file living in Nextcloud. The tool does not matter. The discipline does.

How it works, column by column

The flow is simple. When an email thread turns into something that needs real work, or needs you to wait on an outside party, you add a line to the Situation Room. Our columns are deliberately plain:

The rhythm

Everyone looks at this file several times a day, and it changes every single day. We do not use it to run meetings. We have very few meetings, and when we do meet it is about one specific topic, not a march through the backlog. For something as simple as a status update, a well-written email is almost always enough.

Build a tool that serves you, not one you serve. Keep it simple. The moment the Situation Room needs a manual, you have overbuilt it.

A ready-to-use situation-room-template.ods, filled with realistic example rows you can clear out, is included in the toolkit. See the final section.

Knowledge base: DokuWiki

Some things need to be carved in stone, not discussed in a thread. For those, you want a wiki. We use DokuWiki, and we will be honest about where we compromised.

The honest trade-off

This is the one place in the stack where we are less minimal than we could be, and we half regret it. We would have loved a wiki that was just markdown files under Git version control. Two things stopped us. First, Git defeats even programmers often enough that we did not want to spend our lives debugging broken repositories for the sake of a wiki. Second, DokuWiki already existed and gave us most of what we wanted:

• A familiar web interface anyone can use.
• A plain-text-file backend, no database. That means AI can read the entire knowledge base directly, in seconds.
• Niceties like link autocompletion, which quietly encourages linking, the real superpower of a wiki.
• Open-source software that has been maintained for years and runs happily on the cheap webhosting we already pay for to serve our website.

How to install it

1. Buy the most basic Hetzner webhosting plan.
2. Point your domain's nameservers at Hetzner's.
3. Do not put the wiki at your domain root. Create a subdomain in Hetzner's console, like wiki.example.com.
4. Using the WebFTP tool in Hetzner's konsoleH, create a folder layout: inside public_html (already there), add a site folder and a wiki folder.
5. Download DokuWiki (the install guide is thorough), decompress it, and drag the files into the wiki folder via WebFTP.
6. In the subdomain settings in konsoleH, set the subdomain's root to the wiki folder.
7. Visit wiki.yourdomain.com/install.php and follow the admin setup. This is where you configure access permissions.
8. Set up SSL certificates for both yourdomain.com and wiki.yourdomain.com (Hetzner's SSL guide).

Namespaces, and not over-thinking them

We have under 100 pages and do not expect more than 300 in five years. At that volume, search is good enough that namespaces barely matter. For most companies, fussing over namespace hierarchy is premature optimisation. If your project genuinely needs deep structure, you already know enough about wikis to design it yourself.

What belongs in the wiki

The wiki is for things you want carved in stone: stable, important, and worth getting exactly right for everyone. Two good examples:

• The invoice-payment process. Important, slow to change, and it needs to be unambiguous for the whole team.
• Your company's AI-use policy. It will evolve, but slowly, and when it does you discuss the change over email and then update the page.

A sidebar layout in DokuWiki format, and an example AI-use policy, are both in the toolkit. See the final section.

Quick chat: Delta Chat

Delta Chat is a lighter version of WhatsApp: it does everything genuinely necessary very well, and none of the gamification we do not want. Remember the goal here is to chat as little as possible.

Why this one

Delta Chat runs on email underneath, so it fits the rest of the stack naturally, and it has one feature we consider non-negotiable: a short auto-delete timer on conversations. That single setting is what keeps chat in its lane. It also has a genuinely powerful trick up its sleeve: webxdc apps, small applications that run inside any chat. We use them to live-edit small documents on the fly. There are hundreds of them. You do not need to be paranoid about which ones you run or who wrote them, because these apps cannot reach the internet at all. They can only exchange messages with the other people in the chat they live in. It is also a perfect place to have an AI build a small bespoke tool for your team when you want one.

The one feature that is mandatory

If you choose a different tool, fine, but it must let you set a very short deletion timer on conversations, like one week. That timer is the whole point. Anything worth remembering belongs in email, where it becomes part of the company memory. Chat is for the things that are not worth keeping.

Rolling it out

1. Get everyone to download the app and create an account on any of the chatmail relays. In practice that is just installing the app and following the prompts.
2. Share your profile with the team using the QR code or link the app gives you. You can keep multiple profiles in Delta Chat: one of us uses it for both family and work, kept cleanly separate.

The AI layer

Here is the payoff that most people miss. Every AI tool on the market is straining to "integrate" with your SaaS stack: APIs, paid tiers, your data routed through someone else's servers. When your company already runs on plain text, that whole problem evaporates. AI works directly on your data, locally, with no middleman.

Why we don't use MCP servers (yet)

Our understanding may be limited, but as we see it, MCP servers are useful for injecting only the relevant slice of information into a model's context at a given moment, the situation where you do not want the AI taking action for you. For now, our AI workflows use only our email as context, and instead of an MCP to search it, we use notmuch to build very precise search queries in advance and inject only the relevant context. It is a different shape of solution for a focused job.

A workflow we genuinely rely on: the weekly recap

Once a week, an email goes to the whole team with the big topics of the week, the progress made, and what matters for the week ahead. It is generated by a small set of Python scripts that pull the week's email and the Situation Room, load the last few reports for long-term context, send it all to a model, and email a draft back for a human to check before it goes out.

The scripts are included in full in the toolkit. They are worth reading even if you never run them, because they show something a SaaS product's setup never will: pages of custom search terms and bespoke logic shaped entirely around how our company actually works. That is what becomes possible when your data is just files and plain text.

What we do not let AI touch

For now, AI takes no action without supervision. The weekly recap sends a draft for a human to verify before anything is fired off to the team. We also keep a written AI-use policy in the wiki, evolving slowly, and an example version of it is in the toolkit. Its spine is simple:

• Not for communication. An email from a person should have been written by that person. If you include AI-generated content, flag it as such.
• Not for calculations. Use a program to compute numbers. You can ask AI to help you write that program; you do not ask it to do the arithmetic.
• Fine for interpretation, if flagged. AI is often excellent at finding insight in a mountain of detail. Share those readings flagged as AI-generated, and never make a decision on an interpretation you have not understood and checked yourself.

Rolling it out to your team

The tools are the easy part. Whether this works comes down to how you introduce it to people. Here is exactly how we did it.

The training, step by step

1. The IT stack owner records a screen video for each tool, covering setup for your specific use case. These videos are essential, and no document replaces them. It takes the stack owner about a day to make the full set, and you keep them forever for future hires.
2. One email goes out per tool (Nextcloud, KeePassXC, DokuWiki, email itself, the AI workflows), each with the same three sections: what the tool looks like and does; why you chose it over the alternatives; and what the tool is not for.
3. Give everyone two weeks to try things and collect pain points and questions in a shared document.
4. Everyone sends their pain points to the stack owner, then you hold one team call to walk through the tools, the friction, and the questions together.

What we would do differently

We tried GitLab, Basecamp, and Google Docs before we landed here. We wish we had read this playbook and skipped the detours. Three lessons stand out:

• Push everyone off Gmail and Google Workspace from the start. It became an expensive dependency we are still carrying, and Google folding AI canned replies and emoji reactions into email has actively hurt us.
• Change everything at once, not piecemeal. We did not introduce all of these tools together, and we should have. A single wholesale switch feels stable. A drip of constant changes feels like the ground is moving.
• Teach the Nextcloud markdown editor earlier. Its live collaborative editing covers about 95% of what people reach for Google Docs to do, and we were slow to show people that.

What it costs, what breaks

No hand-waving. Here is the real monthly bill, the real maintenance load, and the one thing that has actually given us trouble in two years of running this.

The monthly ledger

That is the whole stack for a company doing $7.5M a year. Drop the mailing list down to a free Google Group and you are at $32 a month. We think groups.io is worth the difference, but the option is yours.

Maintenance

Nothing here truly needs touching. Every service in the stack is run by professionals. Most "maintenance" is just helping a team member sort out an error on their own machine. All told, it is about two hours a month for the stack owner.

What has actually broken

In about two years, exactly one thing has been a recurring nuisance: the Nextcloud desktop sync client. The software works well, but every so often it needs a restart to start syncing again. We solved it the same way we solve most things, with a short video showing people two things:

• How to add Nextcloud as a startup service on Windows, Linux, and Mac.
• How to restart the Nextcloud desktop sync tool on each of those.

Everything else has run without drama. We have noticed no meaningful downtime. Hetzner warns us before they do maintenance, and we have never once been affected by it.

The toolkit

This playbook is built on real working files, sanitised of our company's data and ready for you to adapt. They come with the toolkit: one zip with everything below, plus this book as a PDF and a self-contained offline HTML file. $249, one payment, future editions included.

Where to go from here

This playbook is the blueprint. If you want the conversation, a small list of operators running their companies this way share configurations, templates, and what they have learned at standardit.org. And if you would rather have it set up for you, with the keys handed over at the end so you own everything, that is something we do for a few companies a year. The site explains how to ask.