The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Most integration documentation is written from interviews. Someone explains how the system is supposed to work, a writer transcribes it, and the doc captures the memory, not the system.
I do it the other way. I read the actual workflow exports, configs, and source, then document how the integration behaves in reality. When the doc and the system disagree, the system wins, because that's what I read.
The difference shows up later. Interview-based docs drift the moment a memory is wrong or a config changed after the conversation. Code-first docs match what's running, and every claim traces back to a specific artifact you can open and check 😍
Four full samples here, built on fictional but realistic scenarios: runbooks, a spec, a two-document package, and an architecture decision record, across n8n, Celigo, Salesforce, Zendesk, HubSpot, and NetSuite.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Your feature sounds impressive... So what?
I think this is one of the most useful questions in copywriting.
It's easy to describe what a product does. The real challenge is explaining why it matters to the person reading your copy.
Let's say you're writing for a SaaS platform:
Feature: “Our platform offers automated reporting.”
So what?
"It reduces the time spent compiling data manually."
So what?
"Your team spends less time building reports and more time making decisions."
Now we're getting somewhere.
This is the “So what?” test: a simple copywriting exercise that helps you move from product features to meaningful customer benefits.
But a feature isn't useless copy. Features can be important, especially in SaaS, where buyers need to understand what a product actually does. But without explaining the value behind them, your messaging may leave readers doing the work of connecting the dots.
Good copywriting makes that connection clear.
Don't just tell people what your product can do. Show them why it matters.
Next time you write a feature statement, ask yourself: “So what?” Would your answer make your audience care?
Writing, data entry, transcription
A client told me everything was wrong
I had just delivered a finished site for a Swedish M&A insurance company. The brief had been vague from the start. He knew roughly what he wanted but couldn't put it into words
Then he said: "This isn't it. You did the wrong thing entirely."
I didn't get defensive and I didn't argue in writing. I proposed a quick call
Five minutes in, he named two things. Only two weren't landing. We fixed them on the call. I polished a few more details afterward. He paid, left happy, and later came back with more projects
Design is a matter of taste. When a client says everything is wrong, it rarely means you missed. It means you haven't heard their taste in their own words yet, and a call gets you there fastest
When a client says everything is wrong, how do you find out what they actually mean?
A quick call helps so much.