Editorial standards — Uttir
Uttir

Editorial standards

Every post on Uttir is written by a small, named team, reviewed by a subject-matter expert before publication, and updated when the underlying details change. This page documents the process so you can judge the work for yourself.

How we pick topics

Topics come from three places: the contact form, search queries that bring people to Uttir and then bounce, and the underlying tools we have. We do not chase keywords or copy competitor outlines. If a post doesn't connect to a real tool on the site — or to a real question someone has asked — we don't write it.

How a post is written

  • Draft. The author opens the post file in content/posts/, writes a one-paragraph quickAnswer for the top of the page, fills in the metadata, and writes the body. Drafts aim to be useful to a real person, not to hit a word count.
  • First-party data. Any claim that can be measured gets measured. File sizes, timings, output counts, library versions — these are run on the spot and recorded as a "By the numbers" table in the post. We don't paraphrase other sites' benchmarks.
  • Roundup methodology. Posts that compare tools (the "best free X" series) include a "How we picked these" note explaining what we tested, what we dropped, and why. The short version is on the post; the full filter list is in the editorial record.
  • Review. A reviewer from the roster below reads the draft, runs the tools or methods described, and either signs off or sends the post back with notes. The reviewer's name and role appears under the byline.
  • Publish. The post goes live with the reviewer's name, a publish date, and a quickAnswer for the AI-overview snippet.

How we keep posts accurate

Web tools change: libraries deprecate, browser behaviour shifts, paid services acquire each other and the result breaks. We audit the catalogue every quarter and flag any post whose central claim no longer holds. Updates change the updatedAt field; the publish date stays the same. If a tool or service we recommended no longer meets our standards, we say so on the post.

What we don't do

  • We don't use AI to write posts end-to-end. AI may be used for spelling and grammar checks; the substance is human.
  • We don't accept payment for coverage, placement, or ranking. There is no sponsored slot in the post list, and no tool is ranked higher because of a deal.
  • We don't republish press releases or vendor copy as posts. Vendor news is linked from a tool page if it's relevant, not rewritten as editorial.
  • We don't ship a post on a date we didn't actually finish it. The publish date is when the post went live; the updated date is when it last changed.

Reviewers

Each reviewer is named on the posts they review, with their area of expertise. The roster is small on purpose: a real human with a real area of expertise is more useful than a panel of "general editors."

Priya Raman

Privacy and security

Privacy engineer; previously worked on client-side cryptography at a payments company. Reviews every post that touches user data or browser APIs.

Marcus Hale

Developer tools and standards

Web platform developer for 14 years. Reviews every post about web standards, file formats, and developer tooling to make sure the details are correct.

Elena Voss

Design and accessibility

Product designer focused on accessibility. Reviews every post that touches visual design, color, contrast, or UX.

Report an error

Spotted something wrong? A broken claim, an outdated library version, a tool that no longer meets the bar? Use the report a bug page and we'll fix it. Corrections are applied to the post body and the updatedAt field; major corrections are noted in the changelog at the bottom of the post.