Writer's guide

What we're looking for

Pieces written by someone who did the work. You built the pipeline, ran the benchmark, read the paper closely, or watched the project fail in production. Readers come here for that first-hand view, not a summary of what everyone else already said.

A strong piece does three things:

• Makes one clear claim. “DuckDB won every query, and the timings were the least interesting part” beats “A comparison of dataframe libraries.”
• Shows the evidence. Numbers, code, outputs and links a reader can check.
• Says what would change its mind. Name the result that would prove you wrong.

Formats we publish

• Tutorial: build something step by step, with code that runs as written.
• Analysis: take a claim, a trend or a number and test it.
• Research brief / arXiv breakdown:explain a new paper: what it found, what it didn't, and what practitioners should do about it.
• Benchmark watch: your own measurements, with the setup to reproduce them.
• Explainer: one idea, explained so a smart newcomer gets it.
• Deep dive, policy brief, careers: longer or more specialised pieces; pitch these first so we can shape them together.

How a piece is put together

Most of our pieces follow a shape like this. Treat it as a starting point, not a form:

1. The opening: a concrete situation or number, and why it matters, in the first few lines.
2. The findings: the substance, in sections with clear headings. Headings become the contents list readers use to jump around.
3. For practitioners: what to actually do differently on Monday.
4. What would make me wrong: the results or conditions that would overturn your conclusion.
5. Key takeaways and sources: a short summary, then every source you relied on.

Length follows the material. Most published pieces take 6 to 12 minutes to read. Cut anything a reader could skip without losing the argument.

Sources and numbers

• Link every claim that isn't yours to the paper, dataset, benchmark or filing behind it. For papers, give the authors, title and arXiv ID or DOI.
• Use exact figures from the source and say where they come from. Don't round a 62.7% into “nearly two thirds” without the original nearby.
• If a number is your own measurement, say how you measured it.

Code and images

• Code should run as written. Readers can copy any code block with one click, so test it before you send it.
• Add a cover image (16:9 works best) and describe charts in the text, so the point lands even without the picture.

House style

• Plain words over jargon. Explain a term the first time you use it.
• No hype: avoid “revolutionary”, “game-changing” and their cousins.
• We don't use em-dashes. Use a full stop, a comma, a colon or brackets instead.
• AI tools are fine for research and checking, but the thinking and the writing must be yours. We don't publish AI-generated filler.

Republishing your own post

Already published it on your blog or Medium? Pick “Republish my post” when you pitch. We add a link that tells search engines your original came first, so it keeps its ranking, and readers see where it first appeared.

A sample pitch

Idea: I re-ran our support-ticket RAG evaluation with three retrievers after a model upgrade. Retrieval quality, not the model, explained most of the difference in answers.

About me: ML engineer at a fintech in Lagos; I own our support assistant and its evaluation suite.

Why it matters: teams blame the model when the retriever is the bottleneck. I can share the harness and anonymised results.

Three short paragraphs like that are plenty.

What happens after you pitch

You get a confirmation email straight away. If it's a fit, you get an author account and an email with next steps. You write in our editor, send it for review when it's ready, and an editor reads and checks it before it goes live under your name.

Pitch an idea or republish a post →