How We Write
How a blog post or handbook page goes from a draft to something live on usehardal.com.
One person writes the piece. Everyone else reviews it or ships an asset. If a post needs a committee to exist, it is not ready to be a Hardal post.
What to write, and who it is for, lives on Content Strategy. How it should sound lives on Brand Voice. This page is only the path from draft to live.
Before anyone writes
Answer the Content Strategy question in the Linear issue, in writing:
Who is this for, what do they need to know, and why are we the right people to tell them?
If you cannot name one of these readers, stop: a digital marketing manager losing conversion data, a frontend engineer handed server-side tracking, or a data analyst whose GA4 numbers do not match the backend.
Write the useful piece first. SEO comes after, on a finished draft - not as the reason the draft exists. See SEO Approach.
Blog posts
The owner is the writer. AlpAlpGrowth Manager does one SEO pass. Nihal EnginNihal EnginMarketing Designer makes the cover once the title is stable. The owner publishes in Sanity. That is the whole line.
1. Open a Linear issue and write the first draft
If it is not in Linear, it does not exist. Give the issue an owner and a due date. Do not paste the article into the issue and live there.
Create an unpublished draft in Sanity Studio, paste the markdown body, and put the Studio URL on the Linear issue. The issue tracks the work. Studio holds the words.
You do not need permission to start. Share the idea in Slack if you want a sanity check on the topic. Then write.
2. Alp reviews SEO, once
AlpAlpGrowth Manager reviews a readable draft, not an outline. One round. The pass is:
- Title and H1 match the query a real person would type
- Meta description is specific and honest
- H2s help a scanner, not a keyword list
- Internal links to docs, handbook, or related posts
- Turkish posts are written in Turkish, not translated English
Alp leaves "SEO ok" on the Linear issue when the pass is done. Alp is not a co-author. We edit for clarity, not voice.
3. Nihal makes the cover, in parallel
Do not wait for SEO to finish before starting the cover. Start when the title is stable. If the title changes in the SEO pass, the cover is cheap to adjust. Waiting a week is not.
Nihal EnginNihal EnginMarketing Designer uploads the image as the Sanity coverImage, or to Imge so it lives on imge.usehardal.com. We do not park blog art on Imgur. Cloudinary is the asset tool; Sanity is the CMS. See Tools We Use.
4. The owner publishes
The writer sets the publish date, checks slug, language (en or tr), author, description, and cover, then publishes from Sanity Studio. Importing is not a separate job.
After it is live, share it the way Social Media already describes. Beyza AlacalarBeyza AlacalarSocial Media Manager owns the company channels if the writer is not posting it themselves. A post nobody points to is a tree falling in the forest.
Handbook pages
Handbook pages are how we work, not how to set up sGTM. They still have to be specific enough that a new teammate can follow them without a call.
Write the page in content/handbook/ markdown, or edit it in Sanity Studio. Then run yarn handbook:sync so git and Sanity match. A push with drifted handbook markdown will fail yarn handbook:check. Do not treat a handbook page like a blog post: there is no cover-image hop, and you do not paste a one-off import and walk away.
Use a Linear issue when the page is scoped work with an owner and a date. Skip Linear for a typo.
What we do not do
- We do not publish blog posts that only describe our internal process
- We do not run a draft through four people in sequence
- We do not use Imgur for production images
- We do not buy backlinks, gate useful writing, or generate posts at scale with AI
- We do not hold a meeting to "align on the blog post" when a Linear comment would do