Forem: Hauke J.

Add a Feedback Widget to Your Next.js App in 5 Minutes

Hauke J. — Tue, 28 Apr 2026 10:14:38 +0000

You shipped a Next.js app. Users are visiting. When something breaks, they just leave. No email, no bug report, no context about what they were doing when it broke.

This guide adds a floating feedback button to every page. Users can screenshot, annotate, and submit without leaving the page. One script tag, no npm packages, App Router and Pages Router both supported.

What you're adding

SeggWat is a feedback widget your users can:

Click on any page (it's a floating button)
Use to capture their viewport, then annotate with arrows, rectangles, text, and a blackout tool for sensitive bits
Use to file bug reports, feature requests, or general praise (each gets categorized)
Pin to a specific release via version tracking
Trigger without dropping a single cookie. GDPR-friendly, EU-hosted.

Submissions land in a dashboard with Kanban triage, analytics, and an Ideas Portal where users can vote on features.

Prerequisites

A Next.js project (App Router or Pages Router, both work)
A free SeggWat account (14-day trial, no credit card)
Your project key from the SeggWat dashboard

Option 1: App Router (Next.js 13+)

The cleanest place for the script is your root layout. That puts the button on every page without duplication.

Step 1: Add the script to your root layout

Open app/layout.tsx and load SeggWat through Next.js's built-in <Script> component:

// app/layout.tsx
import Script from 'next/script';

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html lang="en">
      <body>
        {children}

        <Script
          src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
          data-project-key="YOUR_PROJECT_KEY"
          data-enable-screenshots="true"
          data-button-position="bottom-right"
          data-button-color="#6366f1"
          strategy="afterInteractive"
        />
      </body>
    </html>
  );
}

That's it. Every page in your app now has a feedback button.

Step 2: Tag feedback with your app version (optional)

If you want to know which release a bug was reported against, set data-version. Read it from package.json or an environment variable:

<Script
  src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-enable-screenshots="true"
  data-version={process.env.NEXT_PUBLIC_APP_VERSION || "0.1.0"}
  strategy="afterInteractive"
/>

Every submission is now tagged with the running release.

Step 3: Identify logged-in users (optional)

If your users are authenticated, link feedback to their identity with setUser(). Drop this in a client component:

// components/SeggWatUser.tsx
'use client';

import { useEffect } from 'react';
import { useSession } from 'next-auth/react'; // or your auth provider

export function SeggWatUser() {
  const { data: session } = useSession();

  useEffect(() => {
    if (session?.user && window.SeggwatFeedback) {
      window.SeggwatFeedback.setUser(session.user.id);
    }
  }, [session]);

  return null;
}

Render <SeggWatUser /> in your layout next to the script.

Option 2: Pages Router

Pages Router users add the script to _app.tsx:

// pages/_app.tsx
import type { AppProps } from 'next/app';
import Script from 'next/script';

export default function App({ Component, pageProps }: AppProps) {
  return (
    <>
      <Component {...pageProps} />

      <Script
        src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
        data-project-key="YOUR_PROJECT_KEY"
        data-enable-screenshots="true"
        data-button-position="bottom-right"
        data-button-color="#6366f1"
        strategy="afterInteractive"
      />
    </>
  );
}

Same result, same one tag.

Adding more widgets

SeggWat ships several widget types. Here are the others worth knowing about.

Helpful rating (great for docs)

If you have a /docs section, drop a "Was this page helpful?" prompt at the bottom:

// Only on docs pages
<Script
  src="https://seggwat.com/static/widgets/v1/seggwat-helpful.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-container="#helpful-container"
  strategy="afterInteractive"
/>

// In your docs component:
<div id="helpful-container" />

Star rating (product pages, features)

<Script
  src="https://seggwat.com/static/widgets/v1/seggwat-rating.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-container="#rating-container"
  data-style="stars"
  data-max-stars="5"
  strategy="afterInteractive"
/>

The same widget supports a smiley variant via data-style="smiley" if stars aren't your aesthetic.

NPS survey

<Script
  src="https://seggwat.com/static/widgets/v1/seggwat-nps.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-mode="banner"
  strategy="afterInteractive"
/>

NPS only fires when its triggers match (URL pattern, custom event, or time-on-page), and respects per-visitor cooldown so you don't hammer the same person twice.

Customization cheat sheet

Everything is configured through data- attributes. No CSS overrides.

Attribute	Values	Default
`data-button-position`	`bottom-right`, `right-side`, `icon-only`	`bottom-right`
`data-button-color`	Any hex color	`#2563eb`
`data-enable-screenshots`	`true` / `false`	`false`
`data-version`	Any string	(none)
`data-language`	`en`, `de`, `sv`	Auto-detect
`data-show-powered-by`	`true` / `false`	`true`

Dark mode

The widget watches prefers-color-scheme and matches the user's system preference. No setting required.

Why this works well in Next.js

A few things worth flagging:

strategy="afterInteractive" defers loading until after hydration, so the widget doesn't drag down your Lighthouse score.
The widget is a vanilla script, not a React component, so it sidesteps server components and streaming SSR entirely. No hydration mismatches.
Static export (output: 'export') works fine. The script loads from a CDN at runtime.
Edge Runtime is fine for the same reason. Everything happens client-side.

What you get in the dashboard

Once submissions roll in:

A live feed that updates as feedback arrives
A Kanban board for triage: New, Active, Assigned, Resolved, Closed
Trend charts by type and over time
An Ideas Portal where users upvote feature requests (auto-populated from feedback)
GitHub integration: turn an idea into an issue, status syncs both ways

Quick comparison

Feature	SeggWat	Hotjar	Canny	Google Forms
In-page widget	✅	✅	❌	❌
Screenshot annotation	✅	❌	❌	❌
Idea voting portal	✅	❌	✅	❌
GDPR / EU-hosted	✅	❌ (US)	❌ (US)	❌ (US)
No cookies	✅	❌	✅	❌
MCP server (AI-native)	✅	❌	❌	❌
Starting price	$6/mo	$32/mo	$79/mo	Free

Wrapping up

You've got a feedback widget on every page of your Next.js app. Users can screenshot bugs, request features, and rate pages without leaving their session.

About five minutes of work, ten lines of code, zero npm dependencies.

Next steps:

The full Next.js example is on GitHub
Sign up for SeggWat (14-day free trial)
Not on Next.js? See the React guide
For programmatic access, the REST API is documented too

SeggWat is an EU-hosted, GDPR-compliant feedback tool built in Rust. No cookies, no tracking scripts, no data sold elsewhere. Try it free.

Building dioxus-docs-kit

Hauke J. — Wed, 22 Apr 2026 09:44:24 +0000

After moving my docs into my Dioxus app, the next question was pretty obvious.

What does a reusable docs setup for Dioxus actually need?

I did not want a giant CMS.
I did not want runtime content fetching.
I definitely did not want a fragile pile of custom glue code that works once and then becomes a weird private framework I regret later.

I wanted something boring, solid, and reusable.

That is basically how dioxus-docs-kit happened.

What the kit includes

Right now, the core pieces are:

MDX content rendering
sidebar navigation from _nav.json
compile-time embedded content
full-text search
page navigation
optional OpenAPI reference pages
theme switching

Which is a fairly unsexy list, honestly.

That is a compliment.

These are exactly the boring pieces I kept wanting whenever I looked at docs setups for real app projects.

Why compile-time embedding matters

One of my favorite parts of the setup is that docs content is embedded at compile time.

The build helper reads _nav.json, finds the referenced .mdx files, and generates include_str!() calls for them.

So the result is simple:

content ships with the app binary
there is no separate content service
there is no runtime file discovery mess
deployment stays straightforward

For self-hosted apps, this is great.

The docs are just there. No second system pretending it is not a second system.

Navigation stays explicit

Navigation is driven by a _nav.json file.

I like that because it keeps the structure intentional.

I do not want a docs system making clever guesses about what my sidebar should look like based on whatever folder scanning logic happened to be easy to implement.

I would rather define the structure once and keep it explicit.

Boring wins again.

MDX without turning everything into a circus

I wanted Markdown-style authoring with enough room for richer content when needed.

That is where MDX helps.

Plain Markdown is great right up until it is not. Then suddenly you want richer callouts, custom components, or tighter control over how a page is rendered.

The goal here was not to make content authoring infinitely flexible.

The goal was to make it flexible enough without turning the docs pipeline into a cursed build experiment.

Search is not optional anymore

Docs without search feel fake surprisingly fast.

Once a project grows beyond a handful of pages, nobody wants to browse around politely. They want the answer.

So full-text search is built in.

That sounds obvious, but it is one of the first things that makes a docs system feel real instead of homemade.

OpenAPI pages are a big quality-of-life win

A lot of app docs eventually need API reference pages.

That is usually where people give up and bolt on yet another separate tool.

I did not want that.

So the kit supports optional OpenAPI integration.

Same shell. Same navigation. Same deployment. No weird handoff into a different docs universe.

Why this matters for real projects

This is not a crate for demo screenshots.

It is useful when a Dioxus product has real docs pressure.

A few obvious examples from my own stuff:

SeggWat could use it for setup docs, widget docs, API references, and educational docs around feedback workflows
infra.page could use it for integration setup guides, self-hosting docs, and example dashboard templates
StepShots could use it for feature docs, workflow guides, and onboarding content that should be searchable instead of buried

That is the kind of product context I built it around.

Theme switching and app-native integration

Because this lives inside a Dioxus app, the docs can use the same broader UI approach as the rest of the product.

That sounds small until you live with a split setup for a while.

Theme switching feels more natural. Routing feels more natural. The whole thing stops feeling like a branded iframe with better typography.

One small but very real integration footgun

There is also one annoying practical detail the repo handles explicitly.

If dioxus-docs-kit is pulled from crates.io, Tailwind CSS 4 cannot scan ~/.cargo paths for class usage.

So the repo ships a safelist file you can copy into your project and reference from your Tailwind setup.

Not glamorous. Still the kind of thing that absolutely matters in a real integration.

The actual goal

The goal was never "let me build a docs framework because frameworks are fun."

The goal was simpler.

Make it easy to ship real docs with a Dioxus app, keep the content in the repo, and avoid turning documentation into another hosted system that slowly drifts away from the product.

That is the whole idea.

Repo: https://github.com/hauju/dioxus-docs-kit

I Replaced Mintlify With Docs Inside My Dioxus App

Hauke J. — Tue, 21 Apr 2026 12:36:33 +0000

A lot of docs tools feel great right up until you want them to stop being "the docs tool" and start being part of your actual product.

That was the point where Mintlify started annoying me.

To be fair, Mintlify was not pulling my docs out of the repo. The content was still there. So this is not a "hosted docs bad" rant.

The real friction was simpler:

the docs still felt like a separate hosted surface
I wanted tighter integration with the app itself
I wanted full control over routing, rendering, and layout
I wanted better control over URLs, metadata, internal linking, and the broader SEO shape
and yes, downtime on the hosted side is still downtime for your docs

Mintlify can be totally fine. It just stopped fitting what I wanted.

So I switched.

I now self-host my docs inside my Dioxus app, keep the docs in the repo, and use my own docs kit instead of outsourcing the whole thing.

TL;DR: If you are already building in Dioxus, self-hosting docs inside the app gives you simpler deployment, tighter ownership, and better control over the full docs plus SEO setup than a separate hosted docs surface.

Why I wanted docs inside the app

Mostly because I got tired of the split.

If the docs are part of the product, I want them to live like part of the product.

That means:

same repo
same deployment
same routing model
same design system
same ownership

I did not want the docs to feel like a polished annex attached to the real app.

I wanted them to feel native.

For a solo builder, every extra moving part becomes maintenance tax eventually. You might not notice it on day one. You definitely notice it later.

What was wrong with the hosted-docs setup

The problem was not that Mintlify was bad at docs.

The problem was that I no longer wanted docs-as-a-service.

Hosted docs tools optimize for convenience first. That is fair. That is the whole pitch.

But once you care about deeper integration, the tradeoff changes.

I wanted:

docs that feel like part of the app, not adjacent to it
content stored right next to the code it documents
a path to publish blog-style pages without bolting on another system
full control over rendering and shipping
tighter control over URLs, metadata, internal linking, and how docs pages support the rest of the site

At that point I was not really asking for a hosted docs product anymore. I was asking for docs that behave like application pages.

What I built instead

I built dioxus-docs-kit, a reusable docs framework for Dioxus 0.7.

It gives me:

MDX-based docs pages
sidebar navigation from _nav.json
full-text search
page navigation
optional OpenAPI reference pages
theme switching
compile-time embedded content

That feature list is nice.

But the bigger win is that it lives inside the app.

The docs are not a separate product anymore. They are just part of the product.

That sounds obvious, but it changes a lot.

Real examples from my own projects

This only gets interesting when you think about real products, not toy repos.

That is why I keep looking at it through projects like:

SeggWat, where docs, setup guides, widget install docs, and educational content should stay close to the product
infra.page, where self-hosting docs, integration setup guides, public dashboard templates, and config references all want to live near the app
StepShots, where onboarding docs, workflow guides, and search-friendly content are part of the product experience, not an afterthought

In all three cases, I would rather have docs live with the app than rent them as a separate surface.

Why this is better for a solo builder

1. One deployment

I deploy the app and the docs together.

No extra hosted docs service. No separate deployment flow just to update documentation. Fewer places for things to drift or break.

2. Docs stay closer to reality

When the docs live in the repo, right next to the code, it is harder to forget them.

Not impossible, sadly. But harder.

And harder is already a real improvement.

3. I own the UX

If I want the docs to match the app, they can.

If I want custom routing, layout tweaks, embedded product-specific components, or search behavior that fits the app, I can do that without fighting the boundaries of a hosted platform.

4. I get better SEO control

This part matters more than people admit.

I do not just want docs pages to exist. I want control over:

URL structure
page metadata
canonical rules
internal linking
how docs connect to blog content
how blog content connects back to product pages

That is much easier when the docs are part of the same system instead of a separate hosted surface with its own defaults.

The tradeoff

Obviously this is not the right choice for everyone.

If your goal is to ship decent docs this afternoon with almost no engineering effort, a hosted docs tool is still a pretty reasonable choice.

But if you are already building in Dioxus, and you want docs to feel native, self-hosting starts looking a lot better.

Especially if you are a solo builder and you care about long-term leverage more than short-term convenience.

Why I turned it into a reusable kit

At first this was just me scratching my own itch.

Then it became pretty obvious that other Dioxus apps would want the same thing.

So I pulled it into a reusable package instead of hiding the setup inside one project.

That is what dioxus-docs-kit is for.

A docs site framework for Dioxus apps that keeps content local, ships with the app, and still gives you the important docs features people expect.

What comes next

In the next post, I will break down what is actually inside dioxus-docs-kit, including MDX support, compile-time content embedding, search, OpenAPI pages, and theming.

Repo: https://github.com/hauju/dioxus-docs-kit
Crate: https://crates.io/crates/dioxus-docs-kit

In-App Feedback for SaaS: Why Widgets Beat Forms in 2026

Hauke J. — Thu, 16 Apr 2026 08:29:56 +0000

In-app feedback is one of those things teams usually ignore until they realize their current setup sucks.

A user hits a bug. They open support chat, send a vague email, or quietly disappear. If you are lucky, they fill out a form. If you are not, you get silence.

That is why in-app feedback matters. Instead of asking users to leave your product and explain everything from memory, you let them send feedback right where the problem happened.

For SaaS teams, that usually means better bug reports, more product ideas, and fewer useless back-and-forth messages.

What is in-app feedback?

In-app feedback is feedback collected directly inside your product.

Usually that means a small feedback button or widget that lets users:

report bugs
suggest features
rate a page or flow
leave contextual comments
attach a screenshot of what they are seeing

The important part is not the UI chrome. It is the context.

If feedback happens on the page where the issue appears, you get a lot more signal. You know what the user was looking at, what page they were on, and often which browser, viewport, or app version was involved.

That is a completely different quality level than a generic contact form.

Why forms are bad at product feedback

Forms are fine for lead capture, surveys, and support intake.

They are usually bad at product feedback.

Here is the problem:

the user has to leave the current flow
they have to describe the issue from memory
you have to reconstruct what actually happened

That is a stupid amount of friction for something that should take 20 seconds.

A generic form also misses the details product teams actually need:

page URL
screenshot context
browser and viewport
release version
category of feedback
relationship to a specific feature or workflow

So the report you receive is often some variation of:

"The button does not work"

Cool. Which button? On which page? On mobile? After which step? Was it a bug, confusion, or just bad copy?

Now somebody on the team has to play detective.

Why in-app feedback works better

In-app feedback works because it catches the moment while it is still fresh.

The user does not need to remember what happened. They are already there.

That changes a few things immediately.

1. You get more submissions

Every extra step kills response rate.

If the feedback button is already inside the product, users are much more likely to send a quick report or idea.

2. The feedback is more specific

When users can annotate a screenshot or submit feedback from the current page, the report stops being abstract.

Instead of "search is weird," you get "search results overlap the filter drawer on iPhone width."

That is useful.

3. Product and engineering can act faster

Context cuts down the follow-up loop.

If the report already includes the page, screenshot, and version, triage gets much easier. The team can spend less time clarifying and more time fixing.

4. Feedback becomes part of the product, not an external chore

This is the bigger shift.

A feedback form feels like an extra task. A widget feels like part of the app.

That sounds minor, but it changes behavior. Users are more willing to report friction when the reporting path is right there.

What good in-app feedback should include

Not every feedback widget is worth using. Some are just forms stuffed into a modal.

A solid setup should cover at least these basics.

In-app feedback essentials for SaaS teams

Feedback button or embedded entry point

Users need an obvious way to send feedback without hunting for it.

Screenshot capture and annotation

This is huge for bug reports and UI issues. A screenshot saves an absurd amount of clarification work.

Categories or feedback types

Bug report, idea, rating, and general feedback should not all land in one giant pile.

Metadata capture

At minimum: page, timestamp, and some basic environment details. Version tracking is even better.

Triage workflow

If feedback lands in email or a raw spreadsheet, you are back in chaos. It should go into a dashboard where you can sort, review, and act on it.

Privacy-friendly implementation

A lot of teams do not want extra cookie banners or surveillance-heavy scripts just to collect product feedback. Fair enough.

Where SeggWat fits

SeggWat is built for this exact use case.

Instead of sending users to a generic form, you add a lightweight feedback widget directly to your site or app. Users can submit bug reports, feature ideas, ratings, or comments without leaving the page.

A few details make it especially useful for small SaaS teams:

screenshot annotation for visual bug reports
rating widgets including NPS, star, and helpful ratings
ideas portal if you want voting and roadmap-style feedback
developer-friendly integration instead of a giant install project
privacy-first setup with EU hosting and no cookie-heavy nonsense

It is a better fit for builders who want product feedback infrastructure without buying an enterprise suite.

When in-app feedback is worth adding

If your product has any of these problems, you probably need it now, not later:

users report bugs with no context
feature requests are scattered across email, chat, and notes
support keeps forwarding vague product complaints
you are shipping fast and need tighter feedback loops
you keep saying "we should probably add a feedback widget"

That last one is usually the giveaway.

Early-stage SaaS teams often think they are too small for a proper feedback system. I think the opposite is true.

When you only have a small number of active users, each signal matters more. Losing context at that stage is expensive.

When a simple form is still enough

To be fair, sometimes a plain form is fine.

If you just need a basic survey or a one-off contact page, do not overcomplicate it.

But if your goal is ongoing product feedback inside a web app, forms hit their limit fast.

They are detached from the product, bad at visual context, and annoying for users at exactly the moment you want the least friction.

The practical takeaway

If you want better product decisions, you need better raw input.

For SaaS teams, in-app feedback is usually the simplest way to get that. It keeps feedback close to the experience, improves report quality, and makes it much easier to close the loop.

A generic form can collect words.

An in-app feedback widget can collect usable product signals.

That difference is the whole game.

If you want to try it without bolting on enterprise nonsense, SeggWat is a straightforward place to start.

Why I Picked Rust for a Production-Ready Micro SaaS

Hauke J. — Wed, 15 Apr 2026 08:11:24 +0000

A lot of people hear "micro SaaS" and immediately reach for the usual stack.

Use JavaScript. Ship fast. Fix the weird production issues later. Maybe never.

That works, sometimes. But if you are building a product you actually want to run for years, the stack decision is not just about how fast you can get v1 online. It is about how much nonsense you are signing up to maintain.

I built SeggWat in Rust because I wanted a product that feels boring in production, cheap to run, and pleasant to extend. For a small SaaS, that matters more than trendy takes about founder speed.

TL;DR: Rust is a strong choice for a micro SaaS if you care about reliability, low memory usage, predictable performance, and long-term maintainability. It is a worse choice if your main goal is hacking together a throwaway MVP in a weekend.

The usual argument against Rust

The common pushback is easy to summarize:

Rust is slower to write
The ecosystem is "harder"
Hiring is tougher
You do not need that much performance for a small SaaS

Fair enough. If your product is a landing page, a Stripe webhook, and three cron jobs, Rust might indeed be overkill.

But that is not most SaaS products for very long.

Once you have real users, state, authentication, background jobs, integrations, analytics, dashboards, and support edge cases, production complexity shows up fast. At that point, the question changes from "what helps me ship fastest this weekend?" to "what will break least often six months from now?"

That is where Rust starts looking much better.

What I actually wanted from the stack

When building SeggWat, I did not optimize for resume points or language fashion. I optimized for a few practical things:

Low operational overhead
Good performance on modest infrastructure
Confidence when refactoring
Strong support for concurrent workloads
A product that would not slowly turn into a haunted house

SeggWat handles feedback widgets, screenshot-related flows, ratings, idea tracking, dashboard features, and integrations. It is not Google-scale, but it is also not a toy script. I wanted the backend to stay lean and predictable as features accumulated.

Rust fit that goal better than the usual dynamic-language default.

Reliability matters more than raw speed

People often frame Rust as a performance language. That is true, but for SaaS the bigger win is reliability.

Memory safety without garbage-collector pauses is nice. The real prize is catching entire categories of bugs before deployment:

use-after-free bugs
accidental shared mutable state
sloppy null-ish handling
a bunch of async mistakes that become production incidents elsewhere

That does not make bugs disappear. Sadly, no compiler has reached wizard status yet.

But Rust does force you to be explicit in ways that pay off once the codebase grows. I trust refactors more in Rust than I do in looser stacks, especially when async code, background jobs, and state transitions are involved.

For a solo founder, that trust is huge. You do not have a QA department. Future-you is the QA department.

Small servers, real product

One of the underrated advantages of Rust is how much work you can get done on small machines.

For a micro SaaS, infrastructure costs are not just a line item. They directly affect your margin and your stress level.

A backend that starts fast, uses little memory, and handles concurrency efficiently lets you stay on simpler infrastructure longer. That buys you time. And time is basically runway with better branding.

SeggWat is not trying to impress people with giant infra. Quite the opposite. I want the product to be affordable, privacy-friendly, and efficient. Rust supports that philosophy well.

Rust changes how you design software

This is the part people miss.

Rust is not just a faster runtime. It nudges you toward better system design.

Because ownership, types, and error handling are stricter, you end up thinking more clearly about:

what state exists
who owns it
what can fail
what should be async
where boundaries between modules should live

That extra friction can feel annoying early on. Then, later, it feels like a gift.

In many fast-moving SaaS codebases, complexity gets hidden until it bites you. In Rust, complexity tends to show up earlier, while it is still cheap to fix.

I will take earlier discomfort over late-night production archaeology every time.

The tradeoff is real, not imaginary

I am not going to do the weird marketing thing where Rust magically has no downside.

It does.

Rust is slower for rough prototypes

If you are validating whether anyone wants the product at all, a higher-level stack may let you test ideas faster.

Some libraries are less polished than the mainstream equivalents

The web ecosystem is good now, much better than it used to be, but you still hit rough edges.

Compile times can be annoying

Not catastrophic. Still annoying.

You need to enjoy explicitness at least a little

If you hate types, ownership, and reading compiler messages, Rust will feel like punishment instead of leverage.

So yes, there is a cost. The point is that the cost buys something real.

Why Rust still made sense for SeggWat

SeggWat is a feedback product for SaaS teams. It needs to be trustworthy.

That means:

widgets should stay lightweight
the backend should be stable
privacy-sensitive data should be handled carefully
the product should not need bloated infrastructure to stay responsive
new features should not make the system feel shakier every month

Rust maps well to that.

It also matches the audience. A lot of SeggWat users are technical founders and developer-led teams. "Built in Rust" is not the whole value proposition, but it does signal a certain engineering mindset: practical, efficient, and not interested in enterprise fluff.

Would I recommend Rust for every micro SaaS?

No.

I would recommend Rust when most of these are true:

you plan to run the product for years, not months
you care about low infra costs
reliability matters a lot
the product has meaningful backend logic
you are comfortable trading some early velocity for long-term calm
you actually like working in Rust

I would not recommend Rust if you are optimizing for the fastest possible no-code-to-v1 sprint, or if the backend is so thin that the language choice barely matters.

Use the boring tool that matches the real shape of the product.

For SeggWat, that boring tool turned out to be Rust. Which is a very Rust sentence.

The bigger lesson

The stack question is usually framed too narrowly.

People ask, "What helps me ship fastest?"

A better question is, "What helps me keep shipping without hating my life?"

For me, Rust wins that second question by a lot.

It makes some early steps slower. Then it pays back through stability, performance, and confidence. For a production-minded micro SaaS, that is a trade I am very happy to make.

If you are building a SaaS and want a feedback system that reflects those same priorities, take a look at SeggWat. It is built for small teams that want useful feedback without enterprise bloat, privacy headaches, or a giant integration project.

What stack did you choose for your SaaS, and would you make the same call again?

How to Add a Feedback Widget to Your Astro Site in 5 Minutes

Hauke J. — Tue, 14 Apr 2026 12:11:23 +0000

TL;DR: Drop a single <script> tag into your Astro layout. No npm install, no adapter config, no island architecture gymnastics. Works with static output, SSR, and hybrid rendering.

The Problem

You shipped your Astro site. Lighthouse score is pristine. But you have no idea what your users actually think.

Contact forms collect dust. Email links get ignored. And the one bug report you did get said "it's broken" with no context — no browser, no viewport, no screenshot.

You need a feedback channel that's right there when users hit a problem.

What You're Adding

SeggWat is an embeddable feedback widget that gives your users:

A floating feedback button (bug reports, feature requests, general feedback)
Built-in screenshot annotation (arrows, rectangles, blackout sensitive areas)
Optional star ratings, helpful ratings, and contact forms

All feedback lands in a dashboard with Kanban triage, analytics, and a public ideas portal.

No cookies. No tracking scripts. GDPR compliant by default, EU-hosted.

Prerequisites

An Astro project (v2+, any rendering mode)
A SeggWat account (14-day free trial)
Your project key from the SeggWat dashboard

Step 1: Add the Script to Your Base Layout

Astro's layout components are the perfect place for global scripts. Open your base layout (usually src/layouts/Layout.astro or src/layouts/BaseLayout.astro) and add the widget script before the closing </body> tag:

---
// src/layouts/Layout.astro
interface Props {
  title: string;
}

const { title } = Astro.props;
---

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <title>{title}</title>
  </head>
  <body>
    <slot />

    <!-- SeggWat Feedback Widget -->
    <script
      is:inline
      defer
      src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
      data-project-key="YOUR_PROJECT_KEY"
      data-enable-screenshots="true"
    ></script>
  </body>
</html>

Replace YOUR_PROJECT_KEY with the key from your SeggWat dashboard → Project Settings → Widgets.

That's it. Build, deploy, done.

Step 2: Customize the Widget

SeggWat uses data- attributes for configuration — no JavaScript API calls needed for basic setup. Here are the most useful options:

<script
  is:inline
  defer
  src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-enable-screenshots="true"
  data-button-color="#6366f1"
  data-button-position="bottom-right"
  data-version={import.meta.env.PUBLIC_APP_VERSION ?? "dev"}
></script>

Attribute	Default	Options
`data-button-color`	`#2563eb`	Any hex color
`data-button-position`	`bottom-right`	`bottom-right`, `right-side`, `icon-only`
`data-enable-screenshots`	`false`	`true`, `false`
`data-version`	—	Any string (e.g., `"1.2.0"`)
`data-language`	Auto-detect	`en`, `de`, `sv`
`data-show-powered-by`	`true`	`true`, `false`

Version Tracking Tip

Notice the data-version attribute above? It pulls from an environment variable. Set PUBLIC_APP_VERSION in your .env file:

PUBLIC_APP_VERSION=0.3.1

Every feedback submission gets tagged with the version, so you know exactly which release triggered a bug report.

Step 3: Add Per-Page Widgets (Optional)

Want a "Was this helpful?" widget on your docs pages? Add the helpful rating widget to specific layouts or pages:

---
// src/layouts/DocsLayout.astro
import Layout from './Layout.astro';

const { title } = Astro.props;
---

<Layout title={title}>
  <article>
    <slot />
  </article>

  <div class="feedback-section">
    <p>Was this page helpful?</p>
    <div id="helpful-widget"></div>
  </div>

  <script
    is:inline
    defer
    src="https://seggwat.com/static/widgets/v1/seggwat-helpful.js"
    data-project-key="YOUR_PROJECT_KEY"
    data-container="#helpful-widget"
  ></script>
</Layout>

This renders an inline thumbs-up/thumbs-down widget right below your content. No floating button — it sits in the page flow.

Step 4: Track Logged-In Users (Optional)

If your Astro site has authentication (via middleware, cookies, or an auth adapter), you can associate feedback with specific users:

<script
  is:inline
  defer
  src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-enable-screenshots="true"
></script>

<script>
  // After widget loads, identify the user
  document.addEventListener('DOMContentLoaded', () => {
    if (window.SeggwatFeedback) {
      window.SeggwatFeedback.setUser('user-123');
    }
  });
</script>

Now feedback submissions are tied to that user ID in your dashboard.

Works With Every Astro Rendering Mode

Mode	Works?	Notes
Static (`output: 'static'`)	✅	Script loads client-side, no adapter needed
SSR (`output: 'server'`)	✅	Same — widget is purely client-side
Hybrid (`output: 'hybrid'`)	✅	Same behavior

The widget is a client-side script — it doesn't depend on how the HTML was generated.

Works With Starlight Too

Building docs with Starlight? Override the layout to inject the widget:

---
// src/components/StarlightFeedback.astro
---

<script
  is:inline
  defer
  src="https://seggwat.com/static/widgets/v1/seggwat-feedback.js"
  data-project-key="YOUR_PROJECT_KEY"
  data-enable-screenshots="true"
  data-button-position="bottom-left"
></script>

Then add it to your Starlight config's custom components. Now your docs site has a feedback button, and users can screenshot exactly which section confused them.

What Happens Next

Once deployed, feedback starts flowing into your SeggWat dashboard:

Triage — New feedback lands in a Kanban board. Drag from New → Active → Resolved.
Screenshots — Users' annotated screenshots show exactly what they see. No more "can you send a screenshot?"
Analytics — Track feedback trends, satisfaction scores, team response times.
Ideas Portal — Promote feature requests to a public portal where users can vote.
GitHub Integration — Create GitHub issues from ideas, with automatic status sync.

Quick Comparison

Feature	SeggWat	Contact form	Google Form	Hotjar
In-page feedback	✅	❌	❌	✅
Screenshot annotation	✅	❌	❌	❌
No cookies	✅	✅	❌	❌
Setup time	60 seconds	Varies	5+ min	10+ min
GDPR (EU-hosted)	✅	Depends	❌	❌
Starts at	$6/mo	Free	Free	$32/mo

Wrapping Up

One script tag. Real feedback with context.

Check out the full Astro example on GitHub for a working integration with dynamic controls.

→ Start your 14-day free trial

Built with Rust. Hosted in the EU. No cookies. Learn more about SeggWat.

Writing a Rust Driver for the Sensirion SEN5x Air Quality Sensor

Hauke J. — Tue, 14 Apr 2026 06:26:17 +0000

If you have ever tried to integrate an environmental sensor into a Rust embedded project, you know the drill: vendor SDKs are C-only, community crates may not exist for your specific sensor, and the datasheet is your best friend. I recently went through this with the Sensirion SEN5x module and want to share what I learned building a no_std Rust driver from scratch.

The SEN5x is a multi-sensor module from Sensirion that measures particulate matter (PM1.0, PM2.5, PM4.0, PM10), volatile organic compounds (VOC index), nitrogen oxide (NOx index), temperature, and humidity, all over a single I2C bus. That is a lot of environmental data from one package.

Here is how to build a driver for it in Rust.

What You Need

A microcontroller with I2C support (I used an RP2040, but any target with embedded-hal I2C traits works)
The SEN5x module (SEN50, SEN54, or SEN55 -- the communication protocol is identical)
A Rust toolchain with your target configured (thumbv6m-none-eabi for RP2040, thumbv7em-none-eabihf for STM32, etc.)

Your Cargo.toml dependencies will look something like this:

[dependencies]
embedded-hal = "1.0"

We are intentionally keeping dependencies minimal. The driver itself only needs embedded-hal traits.

Understanding the SEN5x I2C Protocol

The SEN5x uses Sensirion's standard I2C protocol, which has a few quirks compared to a typical I2C device:

Commands are 16-bit. You send two bytes for each command, MSB first.
Every data word is 3 bytes. Two bytes of data followed by a CRC-8 checksum.
Timing matters. Some commands need execution delays before you can read the response.

This means a typical exchange looks like:

Write: [cmd_msb, cmd_lsb]
Wait: execution time
Read:  [data_hi, data_lo, crc, data_hi, data_lo, crc, ...]

The CRC-8 Implementation

Sensirion uses CRC-8 with polynomial 0x31 and initial value 0xFF. This is the first thing to implement because every data word needs CRC validation:

fn crc8(data: &[u8]) -> u8 {
    let mut crc: u8 = 0xFF;
    for &byte in data {
        crc ^= byte;
        for _ in 0..8 {
            if crc & 0x80 != 0 {
                crc = (crc << 1) ^ 0x31;
            } else {
                crc <<= 1;
            }
        }
    }
    crc
}

This runs on any no_std target with no allocations. Fast and predictable.

Structuring the Driver

I like to structure embedded drivers around the embedded-hal traits so they work on any platform. The core struct is generic over the I2C implementation and a delay provider:

use embedded_hal::i2c::I2c;
use embedded_hal::delay::DelayNs;

const SEN5X_ADDR: u8 = 0x69;

pub struct Sen5x<I2C, D> {
    i2c: I2C,
    delay: D,
}

impl<I2C, D> Sen5x<I2C, D>
where
    I2C: I2c,
    D: DelayNs,
{
    pub fn new(i2c: I2C, delay: D) -> Self {
        Self { i2c, delay }
    }
}

The default I2C address for SEN5x is 0x69. It is not configurable -- every SEN5x module uses this address.

Sending Commands

Every command follows the same pattern: write two bytes, optionally wait, optionally read back data. Let us build a helper:

impl<I2C, D> Sen5x<I2C, D>
where
    I2C: I2c,
    D: DelayNs,
{
    fn write_command(&mut self, command: u16) -> Result<(), I2C::Error> {
        let bytes = command.to_be_bytes();
        self.i2c.write(SEN5X_ADDR, &bytes)
    }

    fn read_words_no_alloc(
        &mut self,
        command: u16,
        delay_us: u32,
        buf: &mut [u16],
    ) -> Result<(), Error<I2C::Error>> {
        self.write_command(command)
            .map_err(Error::I2c)?;

        self.delay.delay_us(delay_us);

        let num_words = buf.len();
        let mut raw = [0u8; 24];
        let read_len = num_words * 3;
        self.i2c
            .read(SEN5X_ADDR, &mut raw[..read_len])
            .map_err(Error::I2c)?;

        for (i, chunk) in raw[..read_len].chunks(3).enumerate() {
            let crc = crc8(&chunk[..2]);
            if crc != chunk[2] {
                return Err(Error::Crc);
            }
            buf[i] = u16::from_be_bytes([chunk[0], chunk[1]]);
        }

        Ok(())
    }
}

This no_std-friendly version uses a fixed-size stack buffer. No heap allocations, no alloc crate needed.

Error Handling

A proper driver needs a clear error type:

#[derive(Debug)]
pub enum Error<E> {
    /// I2C bus error
    I2c(E),
    /// CRC checksum mismatch
    Crc,
    /// Command not allowed in current state
    NotAllowed,
    /// Sensor reported internal error
    Internal,
}

The error is generic over the I2C error type so you get the platform's original error information propagated through. NotAllowed catches invalid command sequences (for example, reading measurements before starting them), and Internal surfaces faults reported by the sensor itself. Enable the thiserror feature for std::error::Error integration, or defmt for embedded-friendly formatting.

Reading Measurements

The SEN5x measurement flow is: start measurement, wait for data-ready, read the values. Here are the key commands:

Command	Code	Description
Start Measurement	`0x0021`	Begin continuous measurement
Stop Measurement	`0x0104`	Stop measurement mode
Data Ready	`0x0202`	Check if new data is available
Read Measured Values	`0x03C4`	Read all sensor values

Putting it together:

pub struct SensorData {
    pub mass_concentration_pm1p0: f32,
    pub mass_concentration_pm2p5: f32,
    pub mass_concentration_pm4p0: f32,
    pub mass_concentration_pm10p0: f32,
    pub ambient_humidity: f32,
    pub ambient_temperature: f32,
    pub voc_index: f32,
    pub nox_index: f32,
}

impl<I2C, D> Sen5x<I2C, D>
where
    I2C: I2c,
    D: DelayNs,
{
    pub fn start_measurement(&mut self) -> Result<(), Error<I2C::Error>> {
        self.write_command(0x0021).map_err(Error::I2c)?;
        self.delay.delay_ms(50);
        Ok(())
    }

    pub fn data_ready(&mut self) -> Result<bool, Error<I2C::Error>> {
        let mut buf = [0u16; 1];
        self.read_words_no_alloc(0x0202, 20_000, &mut buf)?;
        Ok(buf[0] & 0x01 != 0)
    }

    pub fn measurement(&mut self) -> Result<SensorData, Error<I2C::Error>> {
        let mut words = [0u16; 8];
        self.read_words_no_alloc(0x03C4, 20_000, &mut words)?;

        Ok(SensorData {
            mass_concentration_pm1p0: words[0] as f32 / 10.0,
            mass_concentration_pm2p5: words[1] as f32 / 10.0,
            mass_concentration_pm4p0: words[2] as f32 / 10.0,
            mass_concentration_pm10p0: words[3] as f32 / 10.0,
            ambient_humidity: words[4] as i16 as f32 / 100.0,
            ambient_temperature: words[5] as i16 as f32 / 200.0,
            voc_index: words[6] as f32 / 10.0,
            nox_index: words[7] as f32 / 10.0,
        })
    }
}

A few things to note about the value scaling:

mass_concentration_pm* values are unsigned 16-bit divided by 10 (unit: ug/m3)
ambient_temperature is signed 16-bit divided by 200 (unit: degrees Celsius)
ambient_humidity is signed 16-bit divided by 100 (unit: %RH)
voc_index and nox_index are unsigned 16-bit divided by 10 (dimensionless index)

The signed/unsigned distinction is important. Casting a u16 to i16 before converting to f32 handles the two's complement correctly for temperature and humidity values.

Using the Driver

Here is what the application code looks like on an RP2040:

#![no_std]
#![no_main]

use rp2040_hal as hal;
use hal::i2c::I2C;
use hal::Timer;
use defmt_rtt as _;
use panic_probe as _;

#[hal::entry]
fn main() -> ! {
    let mut pac = hal::pac::Peripherals::take().unwrap();
    let sio = hal::Sio::new(pac.SIO);
    let pins = hal::gpio::Pins::new(
        pac.IO_BANK0,
        pac.PADS_BANK0,
        sio.gpio_bank0,
        &mut pac.RESETS,
    );

    let i2c = I2C::i2c0(
        pac.I2C0,
        pins.gpio4.into_function(),  // SDA
        pins.gpio5.into_function(),  // SCL
        400.kHz(),
        &mut pac.RESETS,
        125.MHz(),
    );

    let timer = Timer::new(pac.TIMER, &mut pac.RESETS);
    let mut sensor = Sen5x::new(i2c, timer);

    sensor.start_measurement().unwrap();

    loop {
        if sensor.data_ready().unwrap() {
            let m = sensor.measurement().unwrap();
            defmt::info!(
                "PM2.5: {} ug/m3, Temp: {} C, Humidity: {} %RH, VOC: {}",
                m.mass_concentration_pm2p5, m.ambient_temperature, m.ambient_humidity, m.voc_index
            );
        }
        // SEN5x updates roughly every 1 second
        timer.delay_ms(1000);
    }
}

Clean, readable, and fully type-safe. No unsafe blocks, no C FFI, no raw pointer arithmetic.

Testing with Mock I2C

The embedded-hal-mock crate lets you write unit tests for your driver on your development machine. You define expected I2C transactions and the mock verifies them:

#[cfg(test)]
mod tests {
    use super::*;
    use embedded_hal_mock::eh1::i2c::{Mock as I2cMock, Transaction as I2cTransaction};
    use embedded_hal_mock::eh1::delay::NoopDelay;

    #[test]
    fn test_crc8() {
        assert_eq!(crc8(&[0xBE, 0xEF]), 0x92);
        assert_eq!(crc8(&[0x00, 0x00]), 0x81);
    }

    #[test]
    fn test_data_ready() {
        let expectations = vec![
            I2cTransaction::write(SEN5X_ADDR, vec![0x02, 0x02]),
            I2cTransaction::read(SEN5X_ADDR, vec![0x00, 0x01, crc8(&[0x00, 0x01])]),
        ];
        let i2c = I2cMock::new(&expectations);
        let delay = NoopDelay::new();
        let mut sensor = Sen5x::new(i2c, delay);

        assert!(sensor.data_ready().unwrap());
    }
}

This catches protocol bugs before you flash hardware. Highly recommended.

Lessons Learned

1. Always validate CRC. I2C buses in real hardware are noisy. I initially skipped CRC checks during development and got intermittent garbage readings that were hard to debug. CRC validation catches these immediately.

2. Respect the timing. The SEN5x datasheet specifies minimum delays between sending a command and reading the response. Skipping these delays causes NACK responses. The delays are not optional.

3. The embedded-hal 1.0 migration was worth it. If you are still on embedded-hal 0.2, the I2c trait in 1.0 is cleaner and combines read/write/write-read into a single trait. The migration is straightforward and the result is more ergonomic.

4. Test with mock I2C. You can write and validate your entire driver logic without touching hardware. This speeds up development significantly.

What About Existing Crates?

You might find existing SEN5x crates on crates.io. Before reaching for one, consider whether it targets embedded-hal 1.0 (released stable in early 2024). Many embedded sensor crates still target 0.2, and mixing HAL versions in one project creates compatibility headaches. Building your own driver is also an excellent way to understand the sensor's protocol deeply, which helps when debugging real hardware issues.

Wrapping Up

The Sensirion SEN5x is a capable module that packs a lot of environmental sensing into a single I2C device. Rust's embedded-hal ecosystem makes it straightforward to write a portable driver that works across microcontroller families.

The combination of strong typing, zero-cost abstractions, and no_std support makes Rust genuinely productive for embedded sensor work. No runtime overhead, no hidden allocations, and the compiler catches protocol mistakes at build time instead of at 3 AM when your sensor readings go wrong.

If you are working on IoT or environmental monitoring projects in Rust, I would love to hear about your setup. Drop a comment or find me on GitHub.

Follow me for more embedded Rust content and practical driver guides. You can also check out oxidt.com for more articles on Rust development.