telemeter.ai
Preview
Join the waitlist
Menu

Telemeter3 min read

What this blog is, and is not

Evidence-backed implementation notes and architecture decisions — not manufactured benchmarks, customer stories, or trend commentary.

This is the first post on the telemeter.ai blog, and its only job is to state the standard the rest of this blog is held to before a second post exists to test it against.

What this is#

The plan is for this space to carry implementation notes and architecture decisions from building telemeter.ai: what a design doc committed to, why a particular tradeoff was made, what changed after it met a real constraint. When a post makes a technical claim, it should be checkable — against the code, against a cited source, or against a decision record in the repository — rather than asserted on the strength of the byline alone.

Telemeter is a pre-MVP, solo-founder build. Most of what eventually gets written here will describe a system still being built in public, including the parts that are designed but not yet live. A post that describes planned behavior will say "planned," the same way the rest of this site does.

What this isn't#

Three things this blog will not do, on purpose:

  • No manufactured benchmarks. A performance number needs a real measurement behind it, with the method disclosed, or it does not appear.
  • No invented customer stories. telemeter.ai is pre-launch. A blog post is not the place to imply a customer, a case study, or a quote that does not exist yet.
  • No trend commentary for its own sake. A post exists to document a decision this project actually made, not to comment on the industry in general to fill a publishing schedule.

Honesty as a build constraint, not a tone#

This isn't a style preference — it's the same rule the rest of the site holds itself to (see ADR 0016): a specific, falsifiable claim, or an explicit "planned" / "designed, not yet built" label. A blog is an easy place for that discipline to slip, because a narrative reads better with a few invented specifics in it. The standard here is that it shouldn't.

How a post gets published#

Every post in this blog is an MDX file with a small set of required frontmatter fields, validated against a schema at build time. An invalid or incomplete post fails the build rather than publishing quietly wrong:

title: "Post title"
subtitle: "One or two sentences — the deck and the card excerpt."
author: "Byline"
date: "2026-07-19" # ISO date, drives ordering
tags: ["topic-one", "topic-two"]
category: "engineering" # engineering | architecture | notes

A post can also be marked draft: true while it's being reviewed — a draft is excluded from the index and the sitemap (and, once it ships, the RSS feed), and its own page declines to render, until it's ready.

Reading this blog#

If a future post here ever states something that turns out not to hold up — a number that was wrong, a decision that got reversed without saying so — that's a bug in this blog, evaluable against the standard set out above, not a reason to read everything on it a little more skeptically. Report it to founder@telemeter.ai.

Related