DEV Community: Timo

I Built a German Decision-Making Tool for My Girlfriend, Then Shared It

Timo — Thu, 30 Jul 2026 07:37:03 +0000

For our anniversary, I wanted to make my girlfriend something personal that would also be genuinely useful in everyday life. Not another item to wrap, but a small digital tool we could use together.

That idea became Entscheidomat, a German-language website that turns small, everyday decisions into quick and playful moments. It is free, requires no sign-up, and works directly in the browser.

The original problem was familiar: What should we eat? Which film should we watch? Who picks first? Sometimes the decision itself is tiny, but the back-and-forth takes far too long. A little randomness is not meant to replace good judgment; it is simply a useful nudge that gets things moving.

What Entscheidomat does

Entscheidomat is built for those low-stakes moments when you want a clear answer without adding friction. The landing page at entscheidomat.com is intentionally straightforward: choose a tool, customize it if needed, and start.

The site is currently in German, because that is the audience and everyday context it was designed for. The tools themselves are universal:

Yes/No generator for quick gut decisions
Coin flip for classic two-option choices
Wheel of fortune for custom options such as dinner ideas, outings, or chores
Dice roller for games and spontaneous choices
Random number generator for any range of numbers
Magic 8-Ball for a playful answer
Name picker for groups, teams, and game nights

The interaction pattern stays consistent: pick a tool, enter your own options where useful, and let the result happen. For example, you can put restaurants or date ideas on the wheel, or add names to the picker. Instead of returning a dry line of text, the result is supported by small animations and optional sound—so the choice feels like a moment rather than a database response.

Four things I learned while building it

1. A personal project still needs a sharp use case

The anniversary was the emotional starting point, but a personal idea only becomes a useful product when it solves a clear problem for other people, too.

For Entscheidomat, that problem is simple: help people make small decisions quickly, without making the experience feel cold or mechanical. This became a useful filter for every feature: does it make the moment faster, clearer, or more enjoyable? If not, it probably does not belong in the first version.

2. The first useful result should happen in seconds

A randomization tool should not need an onboarding flow. The value is in the first click: going from “we cannot decide” to an answer.

That is why the experience is designed to work immediately on phones, tablets, and desktop browsers. The core actions are close to the surface, and customization is available when it helps rather than blocking the start.

3. Motion can make a result feel meaningful

Technically, a random result could be shown as plain text. But a spinning wheel, a rolling die, or a flipping coin makes the process legible and enjoyable. In this context, animation is not just decoration—it communicates that a decision is being made right now.

The app is built with Next.js, React, and TypeScript. For movement and feedback, I use Framer Motion, GSAP, and small sound effects. The most important question was never “which animation library is best?” but “does this feel immediate and understandable?”

4. Privacy can be a product advantage

Not every small web tool needs an account. Entscheidomat keeps settings and custom options in the visitor’s browser, so people can start instantly and stay in control of their data. That approach fits the product: it is meant for spontaneous, lightweight moments.

A small tool can start with a very personal question

Building Entscheidomat reminded me that a meaningful side project does not have to begin with a huge market thesis. Sometimes it starts with a simple question: What could make our everyday life a little easier or more fun?

A website made as an anniversary gift became a German-language tool that other people can use for their own small decisions. If you find yourself stuck between two options, give Entscheidomat a try—maybe a little randomness is the push you need.

What tiny everyday decision would you like a mini-tool to solve?

AI-Ready QR Campaigns: A Developer’s Checklist

Timo — Tue, 21 Jul 2026 12:42:48 +0000

AI-Ready QR Campaigns: A Developer’s Checklist

AI can improve what happens after a scan: personalized landing-page copy, smarter content suggestions, and faster campaign analysis. The QR code itself still needs a dependable delivery layer.

Checklist

use a dynamic redirect rather than encoding a final campaign URL directly
generate a separate identifier for every print asset
keep destinations mobile-first and fast
log only the analytics that are actually needed
update destinations deliberately and test the scan path before printing

QR Master combines branded QR codes, editable destinations, bulk generation, and real-time analytics: https://qrmaster.net

Use AI to improve the experience; use a managed QR workflow to make the connection reliable.

Dynamic QR Codes: The Redirect Layer Behind Editable Campaigns

Timo — Tue, 21 Jul 2026 12:32:33 +0000

Dynamic QR Codes: The Redirect Layer Behind Editable Campaigns

A static QR code contains its final data directly. A dynamic QR code usually contains a short managed URL that redirects to the current destination.

That extra redirect layer is what makes a printed code editable after distribution. It also creates a clean place to collect aggregate scan events, manage destinations, and keep a campaign organized.

A practical implementation checklist

Generate a unique redirect identifier for each asset.
Store destination changes as versioned records.
Return a fast HTTP redirect to the destination.
Keep scan analytics privacy-conscious and aggregated.
Test the code with several phone cameras before printing.

For teams that need branded QR codes, bulk workflows, dynamic destinations, and analytics, QR Master brings these pieces together: https://qrmaster.net

The important design choice is simple: treat a QR code as a durable identifier, not a one-off URL.

Building a QR Code Generator: Dynamic vs Static Architecture

Timo — Thu, 08 Jan 2026 16:46:40 +0000

Content
I recently needed QR codes for a client project and discovered a fundamental architecture decision: static vs dynamic. While they look the same to a user, the engineering behind them is vastly different.

The Architecture of Static QR Codes
Static QR codes are serverless. The data (URL, text, vCard) is directly encoded into the matrix pattern. Once generated, it's immutable.

How it works:
Input: "https://example.com"
Encoding: The string is converted to binary and Reed-Solomon error correction is added.
Rendering: Binary data is drawn as black/white modules.
javascript
// Simple Static Generation (Node.js)
import QRCode from 'qrcode';
const generateStaticQR = async (url) => {
return await QRCode.toDataURL(url);
};
Pros: Zero infrastructure, works offline, free. Cons: Cannot be changed, no analytics.

The Architecture of Dynamic QR Codes
Dynamic QR codes are essentially "short links" printed as graphics. They allow you to track scans and change the destination URL without reprinting the code.

System Components:
Generator Service: Creates a unique short ID (e.g., qrmaster.net/abc1234).
Database (PostgreSQL): Stores the mapping abc1234 -> https://target.com plus metadata (owner, created_at).
Redirect/Edge Server (Node.js/Redis): Handles the incoming request, logs the scan, and issues a 302 Found redirect.
javascript
// Dynamic Redirect Logic (Express + Redis)
app.get('/:shortId', async (req, res) => {
const { shortId } = req.params;

// 1. Check Cache
const cachedUrl = await redis.get(qr:${shortId});
if (cachedUrl) {
// 2. Async Logging (Fire & Forget)
logScanAnalytics(shortId, req);
return res.redirect(cachedUrl);
}

// 3. Database Fallback ...
});
Data Modeling for Analytics
To provide meaningful insights (like "Scans by Device" or "Scans by City"), you need to capture request headers and IP info during the redirect phase.

Conclusion
If you're building a simple contact sharing app, stick to static codes. But for any marketing or enterprise use case where data matters, the dynamic architecture is worth the infrastructure investment.

Building a QR Code Generator: Dynamic vs Static Architecture

Timo — Mon, 05 Jan 2026 20:37:19 +0000

Why I Built a Dynamic QR Code System
I recently needed QR codes for a client project and discovered a fundamental architecture decision: static vs dynamic.

Static QR Codes
The URL is encoded directly in the QR pattern.

javascript
// Static: URL baked into QR
const qr = generateQR("https://example.com/page");
// Can never change after printing!
Problem: Once printed, you can't change the destination.

Dynamic QR Codes
The QR contains a short redirect URL that you control.

javascript
// Dynamic: Redirect through your server
const qr = generateQR("https://qr.io/abc123");
// Server handles redirect + logging
app.get('/abc123', (req, res) => {
logScan(req); // Track analytics
res.redirect(destinationUrl); // Can update anytime!
});
Benefits:

✅ Change destination without reprinting
✅ Track scans (location, device, time)
✅ A/B test landing pages
✅ Smaller QR pattern (shorter URL)
Real-World Use Case
For restaurant menus, you need dynamic codes. Menu changes? Just update the redirect - no reprinting 1000 table tents.

I've been using QR Master for testing this pattern - it's free and has a clean dashboard for generating trackable codes.

Key Takeaway
If your QR code will be printed or permanent, always use dynamic. The 5 minutes extra setup saves hours of reprinting later.

What architecture patterns have you used for QR systems? Drop a comment! 👇