How do you write a post that's still useful in a year?
Five rules. They exist because operators arrive here mid-problem, usually from a search result, and they need the answer before they need the story. Follow them and your post gets read, replied to, and found again months later. This page follows its own rules. That's the test.
Can someone get the answer without scrolling?
Open with 40–60 words that answer the question in your title. Not context, not "we've been thinking about this a lot". The answer. If someone reads only your first paragraph they should be able to act, and if they keep reading it's because they want the how, not because you withheld the what.
This is also what search engines and answer engines quote. A buried conclusion gets summarised badly or not at all. Put the finding up top, then earn the rest of the scroll.
"So we've been running HubSpot since 2023 and honestly the data has always been a bit of a mess. Last quarter our VP asked me to look into it…"
"We deduped 41,000 HubSpot contacts in a 40-minute supervised agent run. Match on normalised email domain plus company, never on name similarity. That one rule removed 94% of false positives."
Are your headings the questions people actually type?
Write every section heading as the question that section answers, in the words an operator would use. "Setup" tells nobody anything. "What permissions does the MCP server actually need?" tells a reader whether to stop scrolling, and it matches how people search.
Keep each section to roughly 140–170 words — one question, one answer, then move on. If a section runs past that, it's usually two questions wearing one heading. Split it.
Where are the numbers?
"Much faster" is not a result. Give the before, the after, and the unit: records touched, minutes saved per week, error rate, seats affected, dollars if you can share them. A number is what makes your post worth more than the same claim on a vendor blog.
You don't need clean numbers. Approximate is fine, ranges are fine, "we stopped measuring after week three" is fine. Say so. What isn't fine is an adjective standing in for a measurement you never took.
Can a reader check your claim themselves?
Every factual claim that isn't your own experience gets a link to the primary source: the vendor's API docs, the changelog entry, the rate-limit page. Not a listicle, not a screenshot of a listicle. If the only source is your own run, say "in our instance" and let the reader weigh it.
Limits and pricing change constantly. Dating the claim ("as of August 2026") costs you six words and saves the next reader an hour of confusion.
"HubSpot's batch upsert caps at 100 objects per request (developers.hubspot.com, checked 14 Aug 2026), so the agent chunks the merge list before it calls anything."
What broke, and what did it cost you?
Every real build has a failure in it. Name yours: the run you had to roll back, the field you overwrote, the week adoption collapsed. That paragraph is the most valuable thing in your post, because it's the part nobody else publishes.
It also sets the tone here. Replies tear the workflow apart, never the person. If you're on the replying side: add a number, a source, or a counter-example, or don't post the reply.
The one-line version: answer first, question headings, real numbers, checkable sources, and the failure included. Everything else is style.