process
The Evidence Thesis, And Why BorderKit Is MDX-First
Why the public web ships as founder-authored editorial first, not a community feed.
By Jak · Published
type: blog-post title: 'The Evidence Thesis, And Why BorderKit Is MDX-First' slug: the-evidence-thesis-and-why-borderkit-is-mdx-first published: '2026-05-10' updated: null author: name: Jak role: founder topic: process dek: 'Why the public web ships as founder-authored editorial first, not a community feed.' seo: description: 'BorderKit''s public web ships as founder-authored editorial in MDX. Here is the evidence thesis behind that choice.' og_image: null canonical_url: 'https://borderkit.app/blog/the-evidence-thesis-and-why-borderkit-is-mdx-first'
There are two shapes a gear-and-event product can take. The first is a content mill: roundups, listicles, affiliate-stuffed buyer's guides, and a community feed where the loudest voice and the freshest post win. The second is a slower thing: setup knowledge written by people who actually used the kit, in conditions they actually faced, with the failure modes named honestly. We are building the second one. This post explains what that means in practice, and why the first surface BorderKit ships is editorial MDX rather than a community feed.
The thesis in one paragraph
Field-tested setup knowledge beats listicles. A real review of a real kit used during a real event — with the setup context, the conditions, the requirements that drove gear choice, the outcome, and the refinements you'd make next time — is worth more than a hundred "best ten" articles assembled from product copy. The reader gets something they can act on. The author has to commit to honesty, because the artefact is checkable against the real world. That two-way contract is the product. Everything else is content noise.
Why MDX first, and not a community surface
There is a tempting shortcut where you ship a community feed early, let users post reviews, and call the volume of posts a marketing surface. We are deliberately not doing that. Three reasons.
First, the editorial floor has to be established before the community is invited in. If the first public reviews on BorderKit are thin, speculative, or padded with affiliate links, every later review inherits that baseline. Setting a high bar with founder-authored content gives community contributors something concrete to model against. A community surface without an evidence discipline is just a forum.
Second, the public web surface and the workspace product have a hard
boundary. The workspace holds private data — exact storage locations, medical
context, schedule patterns, vulnerability indicators. None of that belongs on
the public web. The Spec 1 foundation deliberately gives the public-web
service account no Firestore access at all. That boundary is much easier to
hold when the public surface ships as compiled MDX files in the repo,
reviewed by hand before publish, rather than a runtime write path from
authenticated users into a /public collection.
Third, there is a future shape we want to be ready for. The PRD's v1.5 release introduces Published Setup Snapshots — a forward-compatible artefact where workspace setup data can be published in a redacted, versioned form. The founder reviews we publish now in MDX are deliberately a rehearsal of that shape. The frontmatter schema mirrors the Snapshot fields. When v1.5 ships, the existing reviews migrate forward without losing their slugs, provenance, lifecycle state, or revision history. We are writing durable artefacts before the storage substrate exists.
What "evidence-backed" actually looks like
Concretely, a founder review on BorderKit has four things that a listicle does not.
A setup context that names the intended use, the environment (redacted to region or biome, not exact location), the conditions (weather, duration, load), and the constraints (weight, regulatory, medical, time). This frames what the kit was solving, so the reader can judge whether the review applies to them.
A requirement-first frame: what the kit had to do, stated before any gear is named. This is the same primitive the workspace product uses internally. It forces the author to start from the problem, not from the shiny object.
A resolved-gear list that names what was actually used, in the role of "this thing resolved that requirement". Owned items, descriptive labels — no SKU-level lock-in. Affiliate disclosure where merchant offers appear, in the schema rather than in inline prose.
A review outcome and refinements block: did it work, partially work, or fail; and what concrete changes are going back into the next kit. The refinements are corrective actions, not aspirations.
That structure is the floor. The schema is enforced at build time, so we cannot accidentally ship a thin review.
What this commits us to
Two things, mostly.
A real cadence floor: one founder review per month, one blog post per month, with explicit permission to skip a month rather than publish filler. The skip rule is the honest part. A content mill cannot skip a month; it publishes whatever it has. A founder-authored editorial surface can, and should, when nothing real is ready to say.
A redaction discipline that runs before every publish. Storage locations, sensitive personal context, private notes, medical or contact data, vulnerability indicators (home absence, dependants, schedule), and raw private review notes are excluded by default. Affiliate disclosure is required where merchant offers appear. The checklist lives in the repo next to the content so it travels with every author's work.
What this is not
This surface is not a community claim. There are no user reviews from non-founder authors, no follows, no comments, no feed. There are no claims about user data, because there is no public user data here. There is no implication of launch dates we have not committed. The CTA is a single primary affordance, no modal pop-ups, no exit-intent overlays. The brand voice is the absence of those.
Everything in the privacy notice and the cookies notice reflects that posture: no cross-site trackers, no analytics that touch device storage, no consent banner needed because there is nothing to consent to beyond the strictly-necessary runtime. If that posture ever changes — if a vendor needs device storage, or a trackable embed lands — the addendum gets revised and a proper consent management surface ships first. The cleanest privacy posture is the absence of the problem.
That is the thesis, and it is the brief for everything we publish here from now on.