References

Das Körper-Labor connects Human Design with concrete experiments in four areas of life: food, sleep, movement and environment. Every participant gets a personal reading written for her chart and tests the impulses on her own body. The group is small, the start individual.

The website has to explain this calmly and credibly, move interested people onto a waitlist and, after the invitation, lead them into a protected area that delivers what the course promises.

A participant’s chart is calculated from her birth data, with the time zone and historical daylight saving at the place of birth. An own library does this, and also supplies the Dream Rave and the bodygraph geometry. So there is no dependency on a third-party service, and the result can be traced.

The weekly texts do not have to be written from scratch every time: the Brain holds the course owner’s texts for every feature and makes them available in the reading, in the agent and through an MCP server. More in the “Human Design Brain” reference.

• Next.js 15 (App Router), React 18 and TypeScript; Tailwind for the design system.
• PostgreSQL for contacts, weeks, notes, audit and Brain; Resend for all mails.
• Server-generated PDFs for reading, bodygraph and invoice; Tiptap as the editor for the weekly texts.
• Vercel AI SDK for the agent in the account, a self-built MCP server for the weekly texts.
• Own library for chart and Dream Rave; Vercel for hosting and schedules.
• Light and dark theme and a cookie dialog.

• The same knowledge is written again and again: a profile 4/1 or channel 20/34 appears for many participants, and adapting the same text every time costs hours.
• The knowledge is scattered: in old readings, in about 190 transcribed course videos with roughly 440,000 words, and some only in her head.
• An AI assistant without a foundation invents things. Claiming things in the course owner’s name that she would never say is a risk on health topics.
• Participants need the text at the right time: someone in week 1 should not read all the gates yet.

A chart has a finite, known set of features: type, authority, profile, definition, centres, circuits, channels, gates, crosses. Each gets exactly one entry with a speaking key like kanal-20-34 or tor-29. From the birth data comes the list of a chart’s keys, and every entry that matches is ready. That is deterministic, explainable and cheap. A vector search was deliberately not built.

The text holds a placeholder for the first name, replaced when an entry is taken over: written once, still personal. An entry can also apply to several features, such as a homework for all Generators.

Every change to an entry is logged with date, author (editor, import, AI agent, system) and version including a diff against the previous one, by a database trigger, so also for direct changes. Sources and references live in their own columns, not in the text. The dashboard shows key figures, coverage per feature group and the 64 gates on the bodygraph, green where an entry exists. The graph shows all entries and links as a network.

• 783 entries and 2,717 links
• 190 course transcripts with about 442,000 words, plus 12 analyses
• 64 gates with 384 lines, 36 channels, 12 profiles, 192 incarnation crosses
• All feature groups fully covered

Wording over summary: the AI structures, it does not rewrite. The agent is grounded: it answers from the Brain and says so when there is nothing on a topic. No names in the text, because entries are copied into other weeks.

Honest about the limits: there is no semantic search and no versioning of meaning, only the history per entry. There is one shared admin login, so no distinction of people in the history. The transcription needs ffmpeg and runs locally. Some texts still have to be checked against specialist sources. The Brain does not replace advice, it speeds up the course owner’s work.

• Next.js 15, React 18, TypeScript; PostgreSQL with tables for entries, history and categories.
• A PL/pgSQL trigger for the history, with the author as a session variable.
• Vercel AI SDK through the AI Gateway for import, agent and specialists, with a fallback model.
• A self-built MCP server with ten tools; a second one for the weekly texts.
• An own force simulation in SVG for the graph, Mermaid for the guide in the admin.

The demo above runs only on invented sample data (208 entries, 220 links). The figures in the text are the real system’s; real entries, participant data and transcripts are not part of the page.

At fairs and summits, companies should be able to design a drink with their own logo and slogan and take it home as a gift. The label is not a mockup but the real, printable label of the bottle: same dimensions, same layout, same certification marks.

The visitor stands at the booth, the light is bright, time is short. So the flow has to be fast, tappable and clear at a glance. In the end sales needs three things: a finished design, usable contact details and a printed label.

The key principle: what the visitor sees is what gets printed. The preview and the PDF use the same coordinates, and the label is generated in the browser with canvas and jsPDF as a print-ready PDF at 51 × 120 mm. Every layout change was checked against both, not just the screen.

Visitors rarely have their logo as a file, but they know their company name. So the app searches: from a company name or address it gathers candidates from several sources (a logo service, Wikipedia in several languages, the favicon and a server-side read of the website with a headless browser). The visitor taps the right suggestion. A list of invited customers and a file upload complete it.

The first version was made for DigitalX. The next fair follows in November and the app will be adapted for it. That is what trade-fair mode is for: switched on before a fair, all requests land in their own tab, apart from real web requests, and can be reviewed or deleted in bulk afterwards. It changes nothing about the design or the print. The team switches slogans, texts and times itself; new material such as invited customers’ logos or product motifs is added per fair.

• React 18, TypeScript and Vite, with React Router and Framer Motion; icons by Lucide.
• Vercel Functions for the API: requests, settings, sign-in, logo search, uploads.
• Neon Postgres for requests, history and settings; Vercel Blob for logos, PDFs and thumbnails.
• Resend and React Email for customer and admin mails in the client’s look; no mails when the client’s own staff use the app; duplicate submissions are detected.
• Print PDF in the browser with canvas and jsPDF, congruent with the SVG template of the real bottle.
• Admin sign-in with signed sessions (JWT), cookie dialog, light and dark theme.
• Square shapes, corporate colours and the client’s house font as a binding design system.

In development since early May 2026, with about 195 commits. Over the summer a front-end prototype became a production-ready app with admin area, database, e-mail delivery and iPad optimisation. Trade-fair mode was added in September.

The demo above shows the real design (bottle, label, fonts, product sheet). The flow is an own re-implementation; the requests and the company logos in the picker are invented, and nothing is stored.

An organic beverage producer offers private label and creator brands: strategy, recipe, packaging and production planning from one source. That used to mean media breaks, follow-up questions and requests that only became reliable after several rounds.

So the configurator is a qualification tool, not just a form. The measure of success is a qualified request that already thinks taste, recipe, container, label and quantity together, and the buyer gets feedback immediately instead of waiting for an answer.

The same physical bottle can be run as returnable at home and as single-use for export. A switch appears only when the category has at least one template with an export entry; the chosen market goes into the request. Carbonation is data-driven too: allowed when the chosen template provides for it.

Shotty consists of two cooperating agents, both working only from the certified ingredient grid of 138 organic ingredients. The rule “no hallucinating, no guessing” is not a wish in the prompt but is enforced technically.

Six dimensions from 0 to 100: sweetness, bitterness, acidity, spiciness, fruitiness, carbonation. Every category has its own starting profile, its own order and its own ingredient list; carbonation only appears for refreshing drinks and kombucha, kefir. The named starting points (“Ginger lemon”, “Elderflower fizz”) are computed from real products with the same algorithm as the matching.

The engine follows flavour-wheel theory: sweetness balances bitterness and acidity, spiciness needs sweetness as a carrier, acidity lifts fruitiness, carbonation sharpens acidity. On top there are hard rules where the slider moved last wins, so nothing jumps under the finger.

• Hard rules: sweetness plus bitterness at most 100, sweetness plus acidity at most 110, spiciness at most twice the sweetness, the fruitiness ceiling drops with bitterness.
• Six warnings, such as “spiciness needs sweetness” or “flat profile”, and a balance score from 0 to 100.
• Auto-balance: iterative, six passes at most, alternately raising the balancers and lowering the aggressors.
• Core ingredients: one to six out of 57 canonical raw materials with a taste vector; the profile is predicted from them, recommendations come from proximity to the target profile.

Every real product of the producer is mapped to canonical ingredients through its ingredient list and gets a derived taste profile. The match is 40 percent taste similarity, 35 percent shared ingredients and 25 percent balance compatibility; the top five are de-duplicated by product name.

The result goes into the request: “The desired recipe is 87 percent product X.” For sales that is a solid signal of how close the wish is to the existing range.

The interface runs in German and English, with a switch in the header and a central dictionary. The data is bilingual too: ingredient labels, starting points, category names and descriptions, the product catalogue, the Shotty chat with its synonym parser and the AI answers. E-mails to team and customer arrive in the language of the request.

• Next.js 16 (App Router), React and TypeScript, Tailwind with shadcn and Radix, Framer Motion and Lenis.
• Claude through the Anthropic SDK, structured JSON answers, validated on the server; model and prompts live in the code.
• Requests and logos in private Vercel Blob, images delivered through a proxy.
• Supabase Auth with Azure AD OAuth for the admin area.
• Resend for bilingual HTML e-mails to the team and, optionally, customers.
• Hosting and analytics on Vercel; SEO with sitemap, JSON-LD and llms.txt.

The demo above runs the real code of the balance engine and the product matching, so sliders, warnings, score and matches react live. Shotty answers here from the engine’s rules instead of a model; the start page, container templates and the label step match the product; ingredient catalogue, products and requests are invented, and nothing is stored.

A beverage producer plans revenue per sales channel and per customer. The data lives in an internal SQL Server system; field sales work on the road on tablets without a VPN. That used to mean spreadsheets by mail, follow-up questions, and a state that was already stale when it was merged.

The goal was one place where forecasts and terms are made, versioned, with the management view against the channel targets and an approval wherever terms differ from the standard.

The field devices cannot reach the internal system. So a nightly job writes customers and yearly, monthly and product revenue into a cloud database. The job runs in one transaction: an interrupted run leaves no half state.

The app only reads that cache and writes its own data next to it: the current forecast per customer and, on every save, a row in the history. From that it can answer which term applied on a given invoice date.

• Next.js 16 (App Router, route handlers), React 19, TypeScript, Tailwind CSS 4
• Neon (serverless PostgreSQL) with Drizzle ORM; cache tables read-only, inputs and history separate
• NextAuth with roles (field sales, inside sales, manager), route protection by proxy, role check in every API route
• Nightly Node sync from SQL Server to Postgres, atomic via a WebSocket transaction
• Recharts for Pareto and trends, pdfmake for the customer report
• Vercel hosting with a preview per branch; reachable on tablets without a VPN

The demo uses the real forecast model and views, with invented customers, people and numbers from a JSON file that mirrors the structure of the real database. A forecast you save appears in the team dashboard and the manager view; nothing leaves the browser.

A beverage producer fills several hundred articles in many container types and sizes, for its own brand and for private labels. The planners used to look at a workbook that merged open orders, sales forecast and current stock, with pivot slicers and conditional formatting. It was powerful, but tied to one person and one machine.

The goal was to take over the workbook’s logic one to one, check the results against the Excel values, and turn it into a web application that gets fresh data every night and shows every planner the same.

The data comes from two views of the merchandise system on a SQL Server: the production proposals and the actual production planning. A script queries them at night and writes a JSON file; the app’s API routes serve that file and fall back to the live query only without a cache.

The same routes feed a separate management dashboard, which is why the planning app owns this interface. The formulas live in one place and are checked against the Excel values.

• Next.js 16 (App Router, Route Handlers), React 19, TypeScript, Tailwind CSS 4, shadcn/ui
• Recharts for the charts, light/dark mode, slicers and an editable table without a table library
• SQL Server through mssql with a shared connection pool; nightly JSON cache by cron, written atomically
• Calculation logic in one place, checked against the Excel test values
• Self-hosted behind a reverse proxy; separate apps share one domain

The demo uses the real formulas and views, with invented articles, brands and quantities from a JSON file that mirrors the structure and the spread of the real data. A fill plan quantity you change flows through to the coverage and the container view; nothing leaves the browser.

A beverage producer analyses volume and revenue by customer, article, brand and sales channel. That used to mean Excel exports and Power BI reports without real-time interaction, and anomalies at article level often stayed hidden until the month-end close.

The goal was a tool for operational sales users: current numbers, freely filterable, with prior-year comparison and forecast, in the browser, nothing to install.

The numbers come from a SQL Server reporting system with well over a million rows. So the server aggregates in SQL instead of sending a sample to the browser: totals and rankings are right even for rare filter combinations. Expensive queries sit in a cache with staggered lifetimes, warmed after every deployment.

The agent is not a chatbot with knowledge in its prompt. It gets the app’s endpoints as tools and queries the current data for every question; the result is as current and as filtered as the dashboard itself.

• Next.js 16 (App Router, route handlers), React 19, TypeScript, Tailwind CSS 4
• SQL Server via mssql with a connection pool, server-side aggregation, TTL cache and warm-up
• Claude with tool use: own endpoints as tools, up to six rounds, streamed Markdown answers
• PDF export in the browser (pdfmake), answer ratings stored outside the release directory
• Standalone build behind nginx as a systemd service, atomic directory swap with health check and rollback
• Tests for the sales scope and the filter builder against an in-memory database

The demo uses the real aggregation, forecast and planner logic with invented customers, brands, articles and figures from a JSON file. The internal views (table catalogue, schema, refresh status) come from that file too, with invented names. The agent answers with stored replies and shows the flow; the model is not connected. Nothing leaves the browser.

The quality team of a beverage producer keeps complaints in a quality-management system. For analysis there was an export that became pivot tables: a new work step per question, and patterns across years were hard to see.

The goal was a tool for the quality team: numbers and trends immediately, every case readable with all its fields, questions in natural language, and for each new complaint a hint whether there is a precedent.

The data comes live from the reporting system, with a static export as a fallback if the database is unreachable. The analysis runs in the browser over the loaded set, so filters react without waiting.

The language model never sees the whole set. The query view lets it build a filter that the browser executes; the assistant gets key figures and a sample; the case analysis gets the most similar cases. The precedent agent needs no model at all: it computes by rules and is therefore traceable.

• Next.js 16 (App Router, route handlers), React 19, TypeScript, Tailwind CSS 4, Recharts
• SQL Server via mssql with a connection pool, static export as fallback on outage
• Claude for query translation, assistant and case analysis, streamed Markdown answers
• Rule-based precedent matching: batch comparison, archetype, Jaccard text similarity, time weighting
• Voice input through the Web Speech API, deep links for every filter state
• Standalone build behind nginx on the company network

The demo uses the real filter, aggregation and matching logic with invented complaints, suppliers, articles and batches from a JSON file. The query view and the assistant answer with stored results and show the flow; the model is not connected. The precedent agent really computes in the browser. Nothing leaves the browser.

The bee is a glTF 3D file that I modelled in three dimensions. It is the little helper of my nomonkey mascot on the new nomonkey.work (version 2.0, in preparation) and at the same time proof that 3D on the web can be light and still beautiful.

• A five-point Catmull-Rom curve sets the route; the bee leans into the turn and lands softly on a flower.
• The wings are a separate animation clip whose speed runs down to zero as it lands.
• A soft contact shadow is drawn locally and never embedded in the model.
• Lighting from a room environment instead of heavy textures; reduced motion pauses the wings.

The original study does more: the flight follows the page scroll, you can draw your own path, drop flowers the bee flies to, and inspect the model from every side. Here a compact version runs with flight, draw path, flowers and 3D view; only the scroll-driven flight stays in the study.