<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Engineering Decisions on Birdor Blog</title>
		<link>https://blog.birdor.com/tags/engineering-decisions/</link>
		<description>Recent content in Engineering Decisions on Birdor Blog</description>
		<generator>Hugo</generator>
		<language>en</language>
		
		
		
		
			<lastBuildDate>Tue, 30 Dec 2025 22:30:00 +0800</lastBuildDate>
		
			<atom:link href="https://blog.birdor.com/tags/engineering-decisions/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>When You Should Not Use Plumego</title>
				<link>https://blog.birdor.com/docs/plumego/reference/when-not-to-use-plumego/</link>
				<pubDate>Sun, 28 Dec 2025 07:30:00 +0800</pubDate>
				<guid>https://blog.birdor.com/docs/plumego/reference/when-not-to-use-plumego/</guid>
				<description>&lt;h2 id=&#34;introduction-a-responsible-framework-must-define-its-non-use-cases&#34;&gt;Introduction: A Responsible Framework Must Define Its “Non-Use Cases”&lt;/h2&gt;&#xA;&lt;p&gt;Any framework that takes engineering quality seriously must be willing to answer one question:&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;“In what situations should you not use me?”&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;If a framework claims that it:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;fits every team,&lt;/li&gt;&#xA;&lt;li&gt;fits every stage,&lt;/li&gt;&#xA;&lt;li&gt;fits every business,&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;then it is almost certainly not credible.&lt;/p&gt;&#xA;&lt;p&gt;Plumego was never designed to be a universal answer.&lt;br&gt;&#xA;It is a choice &lt;strong&gt;explicitly created for a specific class of engineering problems&lt;/strong&gt;.&lt;/p&gt;</description>
			</item>
			<item>
				<title>Choosing Plumego: A Framework Decision Guide for Serious Go Teams</title>
				<link>https://blog.birdor.com/choosing-plumego-framework-decision-guide/</link>
				<pubDate>Tue, 30 Dec 2025 22:30:00 +0800</pubDate>
				<guid>https://blog.birdor.com/choosing-plumego-framework-decision-guide/</guid>
				<description>&lt;h1 id=&#34;choosing-plumego-a-framework-decision-guide-for-serious-go-teams&#34;&gt;Choosing Plumego: A Framework Decision Guide for Serious Go Teams&lt;/h1&gt;&#xA;&lt;h2 id=&#34;introduction-framework-choice-is-a-long-term-commitment&#34;&gt;Introduction: Framework Choice Is a Long-Term Commitment&lt;/h2&gt;&#xA;&lt;p&gt;Choosing a backend framework is rarely a neutral decision. While it is often treated as a matter of developer preference or short-term productivity, in practice it becomes a &lt;strong&gt;long-term architectural commitment&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Once a framework is adopted, it tends to influence:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;How code is structured&lt;/li&gt;&#xA;&lt;li&gt;How teams reason about control flow&lt;/li&gt;&#xA;&lt;li&gt;How errors are handled and observed&lt;/li&gt;&#xA;&lt;li&gt;How new engineers are onboarded&lt;/li&gt;&#xA;&lt;li&gt;How systems evolve under pressure&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Plumego was not created to compete on popularity, ecosystem size, or convenience. It was created to answer a more specific question:&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
