Perigon Partners · October 2026 · Live

I don't write our monthly bulletin, but I did build the entire system that ships it

Business in Command goes to CEOs and board members of mid-market businesses on the first of every month. Four issues, none missed, from a small consultancy with no engineer, and nobody starts from a blank page.

Result20 articles in four months, up from 4 in the four before
RoleGrowth and Operations Lead. Built the format, the site, the emails and the sign-up. Emma, Perigon's CEO, writes most of the bulletin, with Nick and Andrew
See it Business in Command, every issueIssue 1, July 2026Subscribe

Business in Command is the new monthly bulletin from Perigon Partners. Before it existed, Emma (our CEO) wrote fairly regular articles on the website, but there was a sense that we could make something more impactful, structured and valuable. While I was building the new Perigon Partners website, I decided to build a whole publishing arm to the website too, and so Business in Command was born.

The consultants write the articles

Perigon is a small strategy consultancy, competing for the attention of boards that also get letters from firms a hundred times our size. A monthly bulletin is the obvious way to stay in front of them, and everyone knows how that usually goes. Issue one is brilliant, issue two is late and issue three never happens.

But we have produced four issues now, all released on time, with genuinely useful articles written by our human consultants. No AI slop in sight. Each month discusses a different theme around corporate strategy and sustainability, and each month has been very well received by our clients and wider contacts.

In those four months, Perigon has released 20 articles. In the preceding four months, Perigon released 4. I would argue that these most recent 20 articles are of the best quality ever. Before BiC there was a will to produce material, but no structure, and I think that’s the key to content.

Now I just want to make this very clear. I am not the person who should be telling a board how to run its strategy. Our CEO and consultants are. My job was to make publishing it cost Perigon as close to nothing as I could, so their time goes on the argument instead of the apparatus.

It’s a format, not a newsletter

Every issue has the same skeleton. One long read, two mid-length pieces, two short ones, a tool to try, a field note and four boardroom questions. Five articles an issue, every issue. The CEO and I spent lots of time figuring out this format. We knew that it would be set in stone and that we would stick to it.

The Business in Command archive: four covers side by side, October back to July, each with a long read on the left and the rest of the issue listed down the right

That structure is the reason a small firm can publish monthly at all. Nobody opens a blank page at the end of the month wondering what to write. They open a slot. It’s also why, four issues in, the thing is recognisable from across a room: the covers are different and the shape is the same.

Seven weeks from nothing to issue one

None of it existed in May. By 1 July there was a content schema with 23 fields behind every issue, so we can publish articles without touching code. Article pages, an archive, a generated share card for each issue, six email templates, a subscribe page, and the plumbing behind it that drops every sign-up straight into the CRM I built for Perigon from scratch.

The website as a whole took 403 commits between 11 May and 7 October, most of them mine, with no software engineer on the payroll. Business in Command is a good chunk of that.

Issue 1 on the web: the long read at the top, two further articles below it, and the tool of the month underneath

The decision that mattered most wasn’t technical. It was publishing on the first of the month, every month, without exception. Four issues, no month missed. That’s the only number in this entry a reader instinctively trusts, because everyone has watched a newsletter quietly die.

Business in Command was generally a straightforward and enjoyable build, but the release on 1 July was hampered by some last minute consent issues. Basically, consent got rebuilt twice. The subscribe form launched with a single mandatory tick box, was reverted the same day, and was rebuilt in June as separate permissions. It’s right now. It should have been designed before launch, because retrofitting consent means changing the form, the database and the emails all at once.

The subscribe page: name, role, company and email, the consent text, and a separate optional tick box for anything beyond the bulletin

Subscribers? Up about a third in four months.

Readership is up by about a third since launch. I’m not going to dress that up as a growth rate, because it isn’t one. It’s small, steady subscriber growth. New readers every month, and no month missed.

Measured against any consumer newsletter, the absolute number would look small. But that’s the wrong comparison. The readers we want are CEOs and board members of mid-market businesses, and the right comparison for that is a room. A room full of exactly the right people is a very good room. Luckily we have more than a room full of readers of Business in Command, and I’m happy with that.

Which leaves the one thing I still can’t see: who opens it. Issue 5 goes out on 1 November, and whether I can tell you who reads it is a plumbing decision I have to make this month. I need to figure out open and click rates. I’ll get back to you.

Under the bonnet

The format is the schema. 23 fields per issue: number, date, cover art, the long read, the two mid-length and two short articles, tool, field note, four boardroom questions, and the bits that hold it together. The CMS form is the editorial brief. If a slot is empty, the issue isn’t finished.

One issue, many outputs. The same record builds the issue page, the archive cover, the share card and the email. Nothing is typed twice.

Subscribe goes through a server-side proxy. The form posts to a Netlify function rather than straight to Zapier, so the webhook address never sits in the page source where anyone could post junk to it.

Consent is stored as separate permissions, not one tick. Each is recorded on its own at sign-up, so the CRM can tell who may be sent what.