<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>staudt::it — Notes</title><description>Short pieces on things that come up in the work — tool choices, architecture trade-offs, lessons from client projects.</description><link>https://staudt-it-dienstleistungen.de/</link><language>en-US</language><item><title>Building n8n workflows with Claude and MCP — instead of clicking them together</title><link>https://staudt-it-dienstleistungen.de/en/notes/n8n-mcp-claude-workflows/</link><guid isPermaLink="true">https://staudt-it-dienstleistungen.de/en/notes/n8n-mcp-claude-workflows/</guid><description>n8n has been the pragmatic self-hosted Zapier for years. With the official n8n MCP server and Claude in the IDE, production-grade workflows now grow out of a plain-prose description — validated, version-controlled, deployable. Notes from a few recent SME projects.</description><pubDate>Fri, 15 May 2026 00:00:00 GMT</pubDate><category>n8n</category><category>mcp</category><category>claude</category><category>automation</category><category>sme</category></item><item><title>Why I bill by the hour, even on fixed-scope projects</title><link>https://staudt-it-dienstleistungen.de/en/notes/hourly-billing-fixed-scope/</link><guid isPermaLink="true">https://staudt-it-dienstleistungen.de/en/notes/hourly-billing-fixed-scope/</guid><description>Fixed-price contracts feel safer to the client. In practice they hide risk in padding, misalign incentives, and reward whichever side is better at scope-policing. A short defense of hourly billing with a hard cap.</description><pubDate>Wed, 29 Apr 2026 00:00:00 GMT</pubDate><category>consulting</category><category>business</category></item><item><title>Astro, Next.js, or Angular in 2026 — a decision tree that actually works</title><link>https://staudt-it-dienstleistungen.de/en/notes/astro-next-angular-2026/</link><guid isPermaLink="true">https://staudt-it-dienstleistungen.de/en/notes/astro-next-angular-2026/</guid><description>The frontend framework question still lands in almost every project. The honest answer is not about benchmarks or developer experience; it is about which problem class fits which tool. Here is the tree I use.</description><pubDate>Wed, 15 Apr 2026 00:00:00 GMT</pubDate><category>frontend</category><category>architecture</category><category>stack</category></item><item><title>MQTT topic design: rules that survive contact with a real fleet</title><link>https://staudt-it-dienstleistungen.de/en/notes/mqtt-topic-design-rules/</link><guid isPermaLink="true">https://staudt-it-dienstleistungen.de/en/notes/mqtt-topic-design-rules/</guid><description>Topic structures look tidy on a whiteboard and embarrassing six months into production. A short list of design rules I keep coming back to, after running several MQTT backends in the wild.</description><pubDate>Wed, 04 Mar 2026 00:00:00 GMT</pubDate><category>mqtt</category><category>iot</category><category>architecture</category></item></channel></rss>