Forem: Jamie Davenport

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.