DEV Community: Jamie Davenport

Why we're building a Github alternative

Jamie Davenport — Fri, 29 May 2026 17:24:04 +0000

Something is shifting. Over the last year, projects I respect have packed up and left GitHub, not quietly, and not without explaining why.

Ghostty announced it was leaving. Zig migrated to Codeberg. Plenty of individual developers have written their own version of the same story. These aren't fringe holdouts; they're some of the most thoughtful people building software today, and they've decided the place we've all called home for nearly two decades is no longer where they want to do serious work.

I think they're right. And I think the reasons they left point at something bigger than GitHub: a gap that none of the obvious replacements are filling. So we're building Plain to fill it.

The exodus is already happening

You don't have to take my word that something's wrong. The people leaving have been specific.

Mitchell Hashimoto kept a journal of GitHub outages for a month while working on Ghostty. His conclusion was blunt:

This is no longer a place for serious work if it just blocks you out for hours per day, every day.

On a single bad day he noted: "I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage." Almost every day in the journal had an X next to it.

The Zig team, moving to Codeberg, described a platform that had lost its edge:

the engineering excellence that created GitHub's success is no longer driving it

They pointed at GitHub Actions specifically: "inexcusable bugs" in a system that felt "completely neglected," to the point where it "started 'vibe-scheduling'; choosing jobs to run seemingly at random."

And in one developer's account of moving to a self-hosted Forgejo, the real reason wasn't even the downtime:

This decision wasn't primarily driven by GitHub's outages, but rather by the deeper implications of ownership and control over my work.

Why people are leaving

Read enough of these and three themes separate out.

Reliability. GitHub now logs hundreds of incidents a year. Its own SLA commits to 99.9% uptime on paid tiers, which sounds great until you do the maths and realise that's nearly nine hours of allowed downtime a year, and that's the promise, not the record. When the tool that gates every merge and every deploy is down for two hours in the middle of your day, "99.9%" stops being an abstraction.

Ownership. GitHub is now part of Microsoft's CoreAI division. Its CEO stepped down. For a lot of people, the question stopped being "is it up?" and became "whose priorities does this serve, and what happens to my work if they change?"

Stalled innovation. This is the quietest complaint but maybe the most damning. The product that felt magical in 2012 feels, as the Zig team put it, "sluggish and often entirely broken." It hasn't meaningfully reimagined how we build software in years. It's just gotten bigger.

Everyone's "alternative" is just GitHub again

So people leave. Where do they go? GitLab, Bitbucket, SourceHut, Gitea, Codeberg, Forgejo, Radicle.

Some of these are genuinely good, and the self-hostable open-source ones solve the ownership problem cleanly. That's a real achievement and not one to wave away.

But look at what you actually get. Every one of them is, fundamentally, a faithful reconstruction of GitHub. Repos, issues, pull requests, a CI bolt-on. They answer "what if GitHub, but you owned it?" or "what if GitHub, but open source?", and those are good questions.

They just aren't the interesting question. None of them ask what a forge should look like if you designed it in 2026 instead of porting the 2012 design. None of them ship what we now take for granted everywhere else: instant, sub-50ms interactions, offline-first sync, and AI woven into the work rather than stapled to the side.

We've been so busy escaping GitHub that nobody stopped to build something better than it.

The real problem: everything lives in a different tool

Here's the thing the GitHub-clones miss entirely.

Building a product doesn't just mean writing code. It means code and the issues that describe what to build, and the docs that explain how it works, and the CI that proves it works, and the artifacts you ship at the end. Five surfaces, minimum.

Today those live in five different tools. Code in GitHub, issues in Linear, docs in Notion, CI in some YAML you'd rather not look at, artifacts in yet another registry. We spend an absurd amount of effort wiring these together with integrations and webhooks and bots, and the wiring is exactly where the friction lives. Context falls into the gaps between tools. The issue doesn't know about the commit. The doc doesn't know about the release. Nothing knows about anything else without a plugin.

Y Combinator recently put out a request for startups describing this exact disease at the company level: knowledge "scattered across emails, Slack, tickets, and databases," keeping organisations in "open loops." Their framing is sharp: fragmentation makes a company illegible to AI. You can't automate across tools that don't share a model of the world.

Plain is the developer-tooling version of that idea. Put the five surfaces in one system, with one model underneath, and integration stops being something you build. It's just how the thing works.

Why now: AI changes what a forge can be

There's a reason this is worth building now and wasn't five years ago.

AI agents have finally gotten good enough to be a first-class primitive: not a chatbot bolted onto a sidebar, but something that can actually act across your code, your issues, your docs, your builds. A forge designed around that capability is a genuinely different shape of product. It couldn't have existed in 2015 because the agents didn't.

But "AI-first" has earned a bad name, and the migration stories show why. One of the things that pushed the Zig project out was AI being forced on them: Copilot promotion that repeatedly ran over their explicit no-LLM policy. That's not AI as a tool. That's AI as something done to your repo without consent.

Plain's bet is the exact opposite. AI you direct, not AI done to you:

Agents are explicitly triggered, by an event, a schedule, or a chat. They don't act unless you wire them to.
Every run has a full audit trail and a rollback. You can see exactly what an agent did and undo it.
They're a primitive you compose, the same way you compose a CI pipeline, not a feature switched on in your settings by someone else.

The Zig story isn't an argument against AI in a forge. It's an argument for building the kind that respects the person using it. That's the kind we're building.

What Plain actually is

Plain puts all five surfaces in one integrated platform:

Git: a host that keeps up with you, with globally mirrored conflict-free replication, stacked diffs and inline review, signed commits and protected branches by default.
Issues: sub-50ms, fully keyboard-driven, offline-first with seamless reconnect, and auto-linked to the commits and PRs that resolve them.
Docs: a block editor that lives next to the code, versioned alongside every release, backlinked to issues, code, and builds.
CI: zero cold-start, always-warm runners, an org-wide shared build cache, pipelines defined as composable code.
Artifacts: content-addressed, deduplicated storage, edge-cached installs worldwide, signed provenance on everything you ship.

And tying them together: Agents, the first-class primitive from the section above, acting across all five surfaces with that audit trail and rollback.

The point isn't the feature list. The point is the line connecting it all. Because the issue, the commit, the doc, and the build live in one system, they actually know about each other, and the automations you can build on top are more powerful than anything you can duct-tape across five tools' APIs. That's also what makes the agents useful: they can finally see the whole picture.

And we're holding ourselves to a real reliability bar: 99.99% uptime, about 52 minutes of downtime a year, an order of magnitude tighter than GitHub's 99.9% promise. If the whole pitch is "this is where you do serious work," it had better be up.

That's the whole idea, and it's why the tagline on the site is the honest summary: the developer platform that finally feels whole.

The bet, and we might be wrong

I'll be straight about the obvious objection, because you're already thinking it.

GitHub is entrenched. Network effects are real: your open-source contributors, your CI integrations, your muscle memory all live there. Integrated all-in-one suites have been tried before and mostly didn't dislodge it. By the base rates, a new forge is a long shot.

We might be wrong. This is a bet, not a sure thing, and I'd rather say that plainly than pretend otherwise.

But here's why I think the bet is good. Every previous challenger competed on GitHub's own terms: same product, cheaper, or open source, or self-hosted. We're not doing that. The cracks the migrations exposed are real, the fragmentation tax is paid by every team every day, and AI agents have just made a genuinely new product shape possible for the first time. When the incumbent is faltering and the ground rules have changed, the maths on a long shot gets a lot more interesting.

That's the bet. We think it's worth making.

Where this goes

The five surfaces are where we're starting, not where we're stopping.

Think about what happens after you've built the thing. You deploy it onto compute. You wire up networking. You provision a database, point DNS at it, and watch it with telemetry. Today every one of those is, again, a separate tool with a separate model and another integration to maintain. It's the exact same fragmentation, just one layer down the stack.

The logic that makes Plain work for code, issues, docs, CI, and artifacts doesn't stop at the artifact. If your build, your release, and your runtime all share one model, then the thing you build in becomes the thing you run on. Compute, networking, databases, DNS, and telemetry are simply the next surfaces, and an agent that can already see your code and your CI can reach all the way through to what's actually running in production and act on it.

That's a long road, and I'm not going to pretend the first release covers it. But it's the direction, and it's why "an integrated forge" undersells what we think this becomes: one coherent platform for building and running software, instead of a dozen tools you glue together and hope stay in sync.

Come build with us

Plain launches in June 2026, and it isn't just a prototype: teams are already building on it, including PolicyStack and Auvia. We're building it in the open and we want the people who've felt this pain most to shape it.

Reserve your place in the first wave →

If you've got opinions about what a forge should be in 2026, especially if you've recently rage-quit one, I want to hear them.

What if your CI was just code? Workflows, a typed platform, and a model one function away

Jamie Davenport — Thu, 28 May 2026 14:38:51 +0000

Originally published at plain.jxd.dev/blog/ci.
Cross-posted here for the dev.to community — the canonical version (and any future updates) lives on the original.

Most CI is YAML: a config language pretending to be a programming language, with string interpolation standing in for control flow and a feedback loop that runs only after you push. You write a block, push, wait, watch it go red on a typo, fix the typo, push again. The language can't help you, because there is no language: just a document that a runner interprets somewhere else, later.

It works. Half the software in the world ships through it. But nobody likes the part where a ${{ }} is subtly wrong, or where the answer to "how do I reuse this across three jobs" is "copy the block." We took CI as a given for so long that we stopped noticing how much of it is friction we'd never accept anywhere else in our stack.

Plain takes a different path. CI is built into the platform, analogous to GitHub Actions, but with a few differences that change how it feels to use. None of them are individually radical. Together they add up to something that feels less like configuring a runner and more like writing the rest of your software.

Workflows are real code

A Plain workflow is a source file you author in a real language (TypeScript, Python, or Go), not a YAML document. Here's the CI that builds this very repo:

// workflows/ci.ts
import { defineWorkflow, on, pm, sh } from "@plain/ci";

defineWorkflow("ci", {
  on: [on.push({ branches: ["main"] })],
  run: async () => {
    await pm.install(); // auto-detects pnpm/npm/yarn/bun from the lockfile
    await sh("pnpm run build");
  },
});

Triggers, steps, and shell calls are ordinary expressions. You get autocomplete, refactoring, jump-to-definition, and the option to factor common logic into functions instead of copy-pasting blocks between jobs. A matrix isn't a special YAML construct; it's a for loop. A conditional step isn't if: with a string expression; it's an if. The patterns you already know carry over, because it's the same language you write everything else in.

Because the workflow is just code, it's type-checked by the same toolchain as the rest of the project. A typo in a trigger or a bad argument to a step is an error you see in your editor, not a red build you discover ten minutes after pushing. And when you do want to run it, you don't have to push to find out what happens:

plain ci run <workflow>

That command runs the workflow locally, against your working tree, the same way it'll run on the server. The feedback loop collapses from "push and wait" to "save and run." It's the difference between debugging by deployment and debugging by execution: the thing every other part of your toolchain figured out years ago, finally applied to CI.

Compose like the rest of your code

The first thing you reach for in any language is "extract the repeated part into a function." YAML can't, really (anchors and reusable-workflow indirection are a pale imitation), so CI pipelines drift into copy-paste. When the workflow is code, the repeated part is just a function in a file you import:

// workflows/lib.ts
import { pm, sh } from "@plain/ci";

export async function buildAndTest() {
  await pm.install();
  await sh("pnpm run build");
  await sh("pnpm test");
}

// workflows/ci.ts
import { defineWorkflow, on } from "@plain/ci";
import { buildAndTest } from "./lib";

defineWorkflow("ci", {
  on: [on.push({ branches: ["main"] }), on.pr.opened()],
  run: () => buildAndTest(),
});

Steps run in sequence because await runs in sequence. Want two builds at once? That's not a strategy.matrix block; it's Promise.all over an array, the way you'd parallelize anything else:

await Promise.all(
  [1, 2, 3, 4].map((shard) => sh(`pnpm test --shard=${shard}/4`)),
);

There's no second mental model for "how CI does loops" or "how CI does shared logic." It's the model you already have.

The platform is the standard library

This is the part that doesn't map onto GitHub Actions. Your run function is handed a ctx, the context for the event that triggered it, and through it, the whole platform. No marketplace action, no GITHUB_TOKEN, no REST calls assembled by hand. ctx carries the trigger (ctx.pr, ctx.commit, ctx.git.branch, ctx.trigger) alongside typed methods to act on it.

Think about what a triage automation looks like on a conventional CI: a third-party action you found in a marketplace, pinned to a SHA you hope is safe, fed a personal access token through a secret, talking to a REST API whose response shape you're guessing at. Here it's a few method calls on an object your editor can describe to you:

// workflows/triage.ts
import { defineWorkflow, on } from "@plain/ci";

defineWorkflow("triage", {
  on: [on.issue.labelled("bug")],
  run: async ({ ctx }) => {
    if (!ctx.issue) return;

    // Open a tracking doc and link it to the issue.
    await ctx.docs.create({
      title: `Investigation: issue #${ctx.issue.number}`,
      body: "## Repro\n\n## Root cause\n\n## Fix",
    });

    await ctx.comments.create({
      parentKind: "issue",
      parentId: ctx.issue.id,
      body: "Triage doc created, picking this up.",
    });
  },
});

The same client exposes ctx.issues.create, ctx.labels.add, and ctx.relations.add, so a workflow can comment, file follow-ups, label, and wire up relationships across the platform, all from one place, with one set of credentials. There are no tokens to mint and no scopes to get wrong, because the workflow is already running inside the platform it's acting on. Permissions come from the workflow's identity, not from a secret you copied into a settings page and now have to remember to rotate.

That's the quiet payoff of CI living in the platform rather than next to it: the integration surface that usually eats the first day of any automation project simply isn't there.

Calling a model is one function

AI models aren't a bolt-on action you find in a marketplace and feed an API key. They're part of the SDK. The whole surface you need is one call:

import { ai } from "@plain/ci";

const summary = await ai.chat("Summarize this build failure:\n\n" + log);

ai.chat runs against models hosted by the platform, so there's no key to manage and nothing to provision. That makes it cheap (in effort, not just money) to drop a model into the middle of an otherwise ordinary pipeline step. Summarize a flaky test log before posting it. Draft a changelog entry from a diff. Turn a stack trace into a plain-English first guess at the cause and leave it as a comment. None of these are worth standing up an API integration for. All of them are worth one function call.

Free text is fine for a comment, but pipelines usually want a decision. So when you need structured output, hand ai.extract a schema and you get back a typed value, validated, no parsing:

import { ai } from "@plain/ci";
import { z } from "zod";

const triage = await ai.extract(log, {
  schema: z.object({
    category: z.enum(["flaky", "real-failure", "infra"]),
    summary: z.string(),
    suspectFiles: z.array(z.string()),
  }),
});

if (triage.category === "flaky") await sh("pnpm test --retry 2");

triage is typed exactly as the schema says, so the if below it is something the compiler checks, not something you hope the model formatted right. The model's output becomes an ordinary value your control flow can branch on.

And when a task is open-ended enough that you'd rather describe the goal than script the steps, ai.agent gives the model the platform itself as tools. You pass it the slice of ctx it's allowed to use, and it decides which calls to make:

import { defineWorkflow, on, ai } from "@plain/ci";

defineWorkflow("autolink", {
  on: [on.pr.opened()],
  run: ({ ctx }) =>
    ai.agent({
      goal: "Find the issue this PR closes, label it 'fixed', and link it to the PR.",
      tools: [ctx.issues, ctx.labels, ctx.relations],
    }),
});

Same credentials, same typed surface as the rest of ctx; the model just calls the functions instead of you. The point isn't that AI belongs in every pipeline. It's that the cost of trying it should be a single line, so the decision is always "is this useful here?" and never "is this worth the setup?"

Example: a reviewer that leaves inline comments

Here's where the three ideas (code, ctx, and ai) start compounding. A pull-request reviewer reads the diff, asks a model for findings in a fixed shape, and posts each one as an inline comment on the exact line:

// workflows/review.ts
import { defineWorkflow, on, ai } from "@plain/ci";
import { z } from "zod";

defineWorkflow("review", {
  on: [on.pr.opened(), on.pr.synchronized()],
  run: async ({ ctx }) => {
    const diff = await ctx.pr.diff();

    const findings = await ai.extract(
      "Review this diff. Flag real bugs, missing error handling, and " +
        "anything that looks unintentional. Skip style nits:\n\n" + diff,
      {
        schema: z.array(
          z.object({
            file: z.string(),
            line: z.number(),
            severity: z.enum(["blocker", "warning", "note"]),
            comment: z.string(),
          }),
        ),
      },
    );

    // Post each finding as an inline comment on the PR.
    for (const f of findings) {
      await ctx.pr.comment({ path: f.file, line: f.line, body: f.comment });
    }

    // Block the merge only if the model found something serious.
    if (findings.some((f) => f.severity === "blocker")) {
      await ctx.pr.requestChanges(`${findings.length} issue(s) found.`);
    }
  },
});

No webhook to register, no diff to fetch over HTTP, no comment API to authenticate against, no JSON to coax out of the model by hand. ctx.pr.diff() and ctx.pr.comment() are the platform; ai.extract is the model; the for loop and the if are just the language. The whole reviewer is the thing it does, with nothing in between.

Example: bump and publish

Put those pieces together (platform access through ctx, a model through ai, and the feedback loop of running locally first) and a release pipeline gets short. This workflow bumps the version, asks a model to write the release notes from the commit log, publishes the package to Plain's own registry, and records the release as a doc, all in one file:

// workflows/release.ts
import { defineWorkflow, on, sh, pm, ai } from "@plain/ci";

defineWorkflow("release", {
  on: [on.manual()],
  run: async ({ ctx }) => {
    // Bump the patch version (writes package.json, makes a commit + tag).
    await sh("npm version patch -m 'release: %s'");
    const { stdout: version } = await sh(
      "node -p \"require('./package.json').version\"",
    );

    // Summarize everything since the previous tag with a model.
    const { stdout: log } = await sh(
      "git log --oneline $(git describe --tags --abbrev=0 HEAD^)..HEAD^",
    );
    const notes = await ai.chat(
      "Write release notes from these commits, grouped into " +
        "Features / Fixes / Internal:\n\n" + log,
    );

    // Build, then publish the package to Plain's registry. No registry
    // URL, no auth token: on-platform credentials are implicit.
    await pm.install();
    await sh("pnpm run build");
    await ctx.artifacts.publish({
      name: "@plain/ci",
      version: version.trim(),
      dir: "dist",
    });

    // Record the release as a doc on the platform.
    await ctx.docs.create({
      title: `Release v${version.trim()}`,
      body: notes,
    });
  },
});

Look at what isn't there. No separate release config to keep in sync with the workflow. No action versions to pin and later upgrade. No registry credentials threaded through a secret. No second file describing how to post the release notes somewhere people will see them. The shell results you destructure, the model call, the artifact payload, and the doc body are all type-checked together, in one place, by the same compiler that checks the package you're releasing.

And because it's just code, the whole thing runs locally with plain ci run release before it touches the real registry. You can watch it bump the version, generate the notes, and tell you exactly what it would publish: the rehearsal and the performance are the same script, which is the only way you ever fully trust a release pipeline.

A smaller attack surface

The supply-chain incidents of the last couple of years have mostly rhymed. A popular third-party action gets compromised, and because uses: some-org/some-action@v3 pulls code that runs inside your job with your credentials, the blast radius is every pipeline that depended on it. Secrets land in logs; tokens get exfiltrated; the mutable tag you trusted points somewhere new overnight. The standard advice, pin every action to a full commit SHA, is sound, and almost nobody follows it consistently.

The marketplace is the vector, and Plain doesn't have one. When the platform is the standard library, the things a workflow calls (ctx.docs.create, ai.chat, pm.install) are first-party surface, versioned with the SDK, not arbitrary code you pulled from a stranger and handed your token to. There's nothing to pin, because there's no @v3 to repoint.

Credentials follow the same line. There's no long-lived access token sitting in a secrets page waiting to leak: a workflow acts as itself, with permissions scoped to what it's for and expiring with the run. The thing an attacker most wants out of CI, a durable credential, mostly isn't there to take.

None of this makes your own dependency tree safe. pm.install() still pulls whatever your lockfile points at, and that's a supply chain like any other. What goes away is the CI-specific layer: the third-party action running beside your code with your keys. That's the part that's been burning people lately, and it's the part the model removes by construction.

For everything still on the inside, the run is sandboxed deny-by-default. A workflow starts with no network egress, no filesystem outside its own workspace, and no credentials it wasn't explicitly handed; anything beyond that is something you opt into in the workflow, in code, where a reviewer can see it. So when a dependency does turn out to be hostile, a postinstall script that tries to phone home or read a token finds the doors already locked. You can't drive supply-chain risk to zero, but you can make a compromised package's default capabilities close to nothing.

When the runner goes down

The day before this post went up, GitHub Actions was down for the better part of an hour. If you've lived on shared CI for any length of time, you know the shape of it: nothing you can do, no commit that fixes it, just a status page and a queue that isn't moving. CI sits on the critical path between writing code and shipping it, so when it stops, so do you.

We won't pretend a young platform has a longer uptime record than the incumbents; it doesn't, and anyone who claims otherwise on day one is selling something. What we can do is build for reliability from the start rather than bolt it on later, and the code-not-config model helps more than it looks. Because a workflow is an ordinary program, the exact same run happens on your machine:

plain ci run release

An outage of the hosted runner is a degraded state, not a wall. The pipeline you'd normally hand to the server is a script you can also run yourself, so "CI is down" stops meaning "we can't ship" and starts meaning "we ship the manual way for an hour." Reliability isn't only about how rarely the service falls over. It's also about how much you're stuck when it does.

The shape of the bet

Each of these on its own is a small thing. Code instead of YAML. A context object instead of a marketplace. One function instead of an integration. A local run instead of a push. But the YAML era trained us to expect friction at every one of those seams, and to build elaborate habits around routing past it.

The bet is that when CI is real code, with the platform as its standard library and a model one function away, all of that friction was incidental: not the cost of doing CI, just the cost of doing it in a config file bolted onto a service that didn't know about the rest of your work. Take those away and the release pipeline you'd dread writing in YAML becomes one short file you'd actually enjoy.

This is an early take, and the design is still moving. Plain is in early access — if you'd like to be one of the first teams to try it, join the waitlist.

OpenTelemetry in TanStack Start with Better Stack

Jamie Davenport — Tue, 21 Oct 2025 10:16:27 +0000

View the original post here

Modern web apps are distributed systems, even when they look simple on the surface. When a single user action fans out into server functions, database calls, and third‑party APIs, you need end‑to‑end visibility to understand where time is spent and why errors occur. That's exactly what tracing provides.

In this post we'll add tracing to a TanStack Start application using OpenTelemetry and export those traces to Better Stack via OTLP. We'll keep the scope intentionally tight: this guide focuses only on tracing. No metrics, no logs—just high‑signal spans that tell the story of each request from start to finish.

Instrumentation

We first need to install the OpenTelemetry dependencies.

bun add @opentelemetry/sdk-node @opentelemetry/api @opentelemetry/sdk-trace-node

Next, create an instrumentation.ts file where we'll configure the OpenTelemetry SDK. To begin with we'll use the ConsoleSpanExporter. The ConsoleSpanExporter outputs trace data to the console, allowing you to verify that tracing is working correctly before configuring the OTLP exporter that will send the spans to Better Stack.

// src/instrumentation.ts

import { NodeSDK } from "@opentelemetry/sdk-node";
import { ConsoleSpanExporter } from "@opentelemetry/sdk-trace-node";

const sdk = new NodeSDK({
    serviceName: "example",
    traceExporter: new ConsoleSpanExporter(), // Temporary
});

sdk.start();

With the SDK ready, ensure it runs before any application code that you care to trace. Import instrumentation.ts at the very top of your TanStack Start server entry so the tracer is active before routes and server functions load.

// src/server.ts

import handler from "@tanstack/react-start/server-entry";

import "./instrumentation";

export default {
    fetch(request: Request) {
        return handler.fetch(request);
    },
};

Finally, we can add spans to our server functions. Later on we'll configure global middleware to automatically instrument requests and server functions.

// src/routes/example.tsx

import { trace } from "@opentelemetry/api";
import { createFileRoute } from "@tanstack/react-router";
import { createServerFn } from "@tanstack/react-start";

const tracer = trace.getTracer("example");

const testFn = createServerFn({ method: "GET" }).handler(() => {
    return tracer.startActiveSpan("testFn", async (span) => {
        try {
            return "Hello World";
        } catch (error) {
            span.recordException(error);
            throw error;
        } finally {
            span.end();
        }
    });
});

export const Route = createFileRoute("/example")({
    component: RouteComponent,
    loader: () => ({
        data: testFn(),
    }),
});

function RouteComponent() {
    const { data } = Route.useLoaderData();

    return <div>{data}</div>;
}

Better Stack

In Better Stack, navigate to the 'Sources' section and connect a new traces source for your application. Ensure that you select the 'OpenTelemetry' platform as the source type, as this will allow you to send trace data using the OTLP protocol.

Next, install @opentelemetry/exporter-trace-otlp-proto and replace the ConsoleSpanExporter with the OTLPTraceExporter in our instrumentation.ts file.

import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-proto";
import { NodeSDK } from "@opentelemetry/sdk-node";
import { env } from "./env";

const sdk = new NodeSDK({
    serviceName: "example",
    traceExporter: new OTLPTraceExporter({
        url: env.BETTERSTACK_TRACE_URL, // https://<ingesting-host>/v1/traces
        headers: {
            Authorization: `Bearer ${env.BETTERSTACK_SOURCE_TOKEN}`, // <source-token>
        },
    }),
});

sdk.start();

Now you should be able to run your application and see traces populated from the Better Stack dashboard.

Global Middleware

We can configure global middleware to automatically instrument requests and server functions. To do so we need to update the start.ts file like so:

// src/start.ts
import { SpanStatusCode, trace } from "@opentelemetry/api";
import { createMiddleware, createStart } from "@tanstack/react-start";

const tracer = trace.getTracer("example");

const tracing = createMiddleware().server(async ({ next, request }) => {
    return tracer.startActiveSpan(
        `${request.method} ${url.pathname}`,
        async (span) => {
            span.setAttributes({
                "http.method": request.method,
                "http.route": url.pathname,
            });

            try {
                const response = await next();
                span.setStatus({ code: SpanStatusCode.OK });
                return response;
            } catch (error) {
                span.recordException(error);
                span.setStatus({
                    code: SpanStatusCode.ERROR,
                    message: error.message,
                });
                throw error;
            } finally {
                span.end();
            }
        },
    );
});

export const startInstance = createStart(() => {
    return {
        requestMiddleware: [tracing],
        functionMiddleware: [tracing],
    };
});

Server Function Names

In production TanStack Start uses a hash as the server function name. This can make it difficult to identify the function in the Better Stack UI.

By default, IDs are SHA256 hashes of the same seed to keep bundles compact and avoid leaking file paths.

We can configure TanStack to produce more descriptive function names. Be careful as this API is still experimental.

// vite.config.ts
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import viteReact from "@vitejs/plugin-react";
import { defineConfig } from "vite";
import tsConfigPaths from "vite-tsconfig-paths";

export default defineConfig({
    server: {
        port: 3000,
    },
    plugins: [
        tsConfigPaths(),
        tanstackStart({
            serverFns: {
                generateFunctionId: ({ functionName }) => {
                    // Configure the function IDs to be something more descriptive
                    return `${functionName}`;
                },
            },
        }),
        viteReact(),
    ],
});

Next Steps

This guide has shown you how to add tracing to a TanStack Start application using OpenTelemetry and export those traces to Better Stack. We've also configured global middleware to automatically instrument requests and server functions.

The implementation is very minimal and you'll likely want to add more spans and attributes to your server functions. You can also add metrics and logs to your application to get a more complete picture of your application's performance.

Story of Vox

Jamie Davenport — Sun, 19 Oct 2025 12:26:19 +0000

Read the original post here

Over the years, I've used countless tools to collect user feedback—Canny, UserJot, and more. I even built a simple open-source feedback widget for Linear earlier this year, which is now used by a few larger companies. And yet, I was never fully satisfied. These tools always felt heavier than they needed to be, requiring too much configuration and offering too little flexibility.

That's why I built Vox — a simple, lightweight customer feedback tool designed specifically for solo founders, indie hackers, and small teams. Here's a look at what drove me to build it and what makes it different.

Simplified Configuration

Most feedback tools require a lot of manual setup:

Open a dashboard
Click “New Project”
Type a name
Copy a snippet of code into your app

This might not sound like much, but for someone who launches multiple products, it quickly becomes tedious.

With Vox, you only need an API key. Everything else happens in code. You can add tags to filter feedback in the dashboard, so the same snippet of code works for multiple apps—just update the app tag and you're collecting feedback in minutes. No dashboard juggling, no repetitive setup.

Headless Styling

Most feedback widgets come with their own styling baked in. That's limiting if you want your widget to fit seamlessly into your app. Vox is headless, giving you full control over how it looks. You can design it yourself—or let an AI agent do it for you. Being headless also makes Vox framework-agnostic, so it works anywhere.

Full Control

I also wanted full control over the feedback process. My apps already handle authentication and user data, and I wanted to leverage that when collecting feedback. Vox makes it easy to attach user information and metadata, giving you richer insights without forcing your users to fill out redundant forms.

Example

Adding Vox to a Next.js app is simple and gives you full control over tags. On the backend, set up a feedback route with your API key and any tags you want—like app or user—so you can filter and categorise feedback easily.

import { createFeedbackHandler } from "voxjs/server";
import { NextRequest } from "next/server";
import { getAuth } from "@/auth";

export async function POST(request: NextRequest) {
    const auth = await getAuth(); // Your custom auth logic.

    if (!auth) {
        return Response.json({ error: "Unauthorized" }, { status: 401 });
    }

    return createFeedbackHandler({
        tags: {
            app: "my-app", // Your app name.
            user: auth.user.email,
        },
    })(request);
}

On the frontend, just call:

import { feedback } from 'voxjs/client';

await feedback('This is great!');

This approach keeps setup minimal, works with any framework, and ensures feedback is always tagged the way you want.

What's Next

I already use Vox in all my projects, but my next step is to commercialise it. My focus will be on marketing and partnering with founders and indie hackers to help them collect better feedback, faster.

Vox isn't about reinventing the wheel—it's about making feedback simple, lightweight, and under your control. For small teams and solo founders who want to move fast without sacrificing insight, that's a big deal.

If you're interested in integrating Vox for your customer feedback needs, you can sign up here.

My Tech Changes in 2025

Jamie Davenport — Sat, 18 Oct 2025 14:14:16 +0000

Read the original post here

This year, I've been on a mission: use fewer tools, but make each one count. If it doesn't speed up development, simplify my workflow, or just make coding more enjoyable, it doesn't make the cut. Here's what's made the list in 2025.

TanStack Start

The biggest change for me this year? Moving from Next.js to TanStack Start. I've built a bunch of apps—personal and professional—and this framework quickly became my go-to. The developer experience is incredible, type safety is rock-solid, and building apps feels… well, fun again. Honestly, it's hard not to gush about it.

Biome

I used to juggle ESLint and Prettier. Now, Biome does it all. One tool, less config, fewer headaches. Sometimes, the simplest upgrades are the most satisfying.

Bun

PNPM was great, but Bun has taken over as my default package manager. I'm also using Bun build for bundling before publishing to NPM. The speed is ridiculous, and it fits perfectly with my "fewer, bigger impact tools" philosophy.

Better Auth

With Lucia now deprecated, I needed a replacement. Better Auth turned out to be just as easy to use, with a strong ecosystem and no extra friction. Authentication should be simple—and now it is.

Polar

Stripe is powerful, but sometimes you just want something that works without extra hassle. Polar does that. Easy integration, less headache, more time to focus on what actually matters: building features.

The Takeaway

2025 has been all about refining my workflow. Fewer tools, but each one a game-changer. These five—TanStack Start, Biome, Bun, Better Auth, and Polar—have sped up my development, reduced friction, and reminded me why I love coding in the first place.

What I Learned From Shutting Down My VC-Backed Startup

Jamie Davenport — Fri, 17 Oct 2025 12:59:52 +0000

Read the original post here

Two years ago, I was running Docbot, a knowledge-sharing platform for tech teams. As a solo founder, I'd managed to raise £580k in venture capital funding to build what I believed would transform how engineering teams documented and shared information. Today, Docbot is shut down.

After multiple pivots and countless attempts to find product-market fit, I made the difficult decision to close the company. It wasn't the outcome I'd hoped for when I started this journey, but the lessons I learned along the way have fundamentally shaped how I think about building businesses. Here's what went wrong, and what I'd do differently.

Being Afraid to Burn Cash

When the investment hit our bank account, I remember staring at the balance in disbelief. It was more money than I'd ever seen in my life, and that realisation terrified me. I became obsessed with preserving runway, convinced that frugality was the path to success.

This fear led me to deprioritise expenses that could have accelerated our growth. Ad spend sat in the "maybe later" column. Marketing initiatives were shelved. Customer acquisition strategies were postponed. Instead, the money went almost exclusively toward salaries—building the team and the product.

Looking back, this was a critical mistake. By being too conservative with our burn rate, we actually slowed our path to finding product-market fit. We could have learned much faster whether our assumptions were correct by investing in growth experiments. We might have discovered the need to pivot earlier, or found the right positioning sooner. Instead, we moved cautiously, and that caution cost us time we couldn't afford to lose.

Hiring the Wrong Team Composition

As a software engineer, I did what felt natural: I focused obsessively on building a great product. And I believe we succeeded on that front. The engineering, product design, and user experience were all top-notch. But a great product alone doesn't make a successful company.

I hired people like me—engineers, product managers, designers. We built beautiful features and solved complex technical problems. What we didn't build was a sales pipeline or a marketing engine.

I had absolutely no idea how to manage a B2B sales cycle. Lead generation was a mystery. Positioning? I was making it up as I went along. I should have hired someone with real experience in sales and marketing from a startup or scaleup environment—someone who had been through the zero-to-one journey before and knew how to build demand from scratch.

Instead, we had an incredible product that not enough people knew about, and even fewer understood how to buy.

Overlooking Security From Day One

Docbot's value proposition required customers to trust us with their internal documentation and knowledge. That meant storing sensitive data, intellectual property, and confidential information. Security should have been a cornerstone of our offering from the beginning, but I treated it as something to address "eventually."

One of the quickest wins we could have pursued was starting SOC2 or ISO27001 certification early in the company's life. Or we could have hired a DevSecOps engineer to help architect the product with security built in from the ground up. With the right security posture, we could have even explored on-premise deployment options or other enterprise-friendly approaches that would have opened doors with larger customers.

Security certifications and robust architecture aren't just checkboxes—they're sales enablers, especially in the B2B space. Without them, we faced an uphill battle convincing enterprises to trust us with their data.

What Comes Next

Being 25 years old and running a venture-backed company was an incredible experience. The pressure, the responsibility, the constant problem-solving—it shaped me in ways I couldn't have anticipated. But over time, I've come to understand what truly matters to me.

It's not building a unicorn valued at $1 billion. It's not the headlines or the validation that comes with massive scale. What I care about is freedom—the freedom to work on what I want, when I want. The ability to build something sustainable that both my users and I genuinely love.

Now, I'm focused on building as a solopreneur. My goal is simple: grow monthly recurring revenue to a level that lets me live comfortably while creating products that solve real problems. No investors to report to, no pressure to chase hypergrowth, no need to compromise on vision for the sake of scale.

Docbot didn't work out the way I planned, but it taught me what success actually looks like—at least for me. And that lesson alone made the journey worthwhile.

Setup User Feedback Collection in Minutes

Jamie Davenport — Thu, 16 Oct 2025 13:31:26 +0000

Setup User Feedback Collection in Minutes with @jxdltd/feedback

Collecting user feedback shouldn't be complicated. @jxdltd/feedback is a headless feedback platform that gets you up and running in just a few minutes with a simple, type-safe SDK.

Why @jxdltd/feedback?

Headless architecture - Bring your own UI, no bloated widgets
Type-safe - Built with TypeScript for a great developer experience
Automatic tagging - Organize feedback by app, environment, or custom tags
Centralized management - All feedback in one place across multiple apps
Framework agnostic - Works with Next.js, Express, or any web framework

Getting Started

1. Install the package

bun add @jxdltd/feedback

2. Create a server handler

Set up a feedback endpoint that forwards submissions to the centralized service:

import { createFeedbackHandler } from "@jxdltd/feedback/server";

// Create the handler with your API key and tags
const handler = createFeedbackHandler({
  apiKey: process.env.FEEDBACK_API_KEY,
  tags: {
    app: "my-app",
    environment: "production",
  },
});

// Example: Next.js API route
export async function POST(request: Request) {
  return handler(request);
}

3. Submit feedback from the client

import { feedback } from "@jxdltd/feedback/client";

// That's it! 
await feedback("This is great!");

Real-World Example

Here is the code from one of my products Big Journal.

// routes/api.feedback.ts

import { createFeedbackHandler } from "@jxdltd/feedback/server";
import { createFileRoute } from "@tanstack/react-router";
import { json } from "@tanstack/react-start";
import { getAuth } from "@/auth/functions";
import { env } from "@/env";

export const Route = createFileRoute("/api/feedback")({
    server: {
        handlers: {
            POST: async ({ request }) => {
                const auth = await getAuth();

                if (!auth) {
                    return json({ error: "Unauthorized" }, { status: 401 });
                }

                return createFeedbackHandler({
                    apiKey: env.FEEDBACK_KEY,
                    tags: {
                        app: "big-journal",
                        user: auth.user.email,
                    },
                })(request);
            },
        },
    },
});

All feedback automatically includes your tags, making it easy to filter and analyze by app, environment, version, or any custom dimension you need.

The Headless Advantage

Unlike traditional feedback widgets that force a specific UI, @jxdltd/feedback gives you complete control over the user experience. Build a feedback form that matches your design system, integrate it into your existing modals, or create a simple button - it's entirely up to you.

Get Started

Check out the GitHub repository to get started. With just three steps and a few lines of code, you'll have production-ready feedback collection running across all your applications.

Perfect for indie hackers, startups, and teams who want powerful feedback management without the complexity.