<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Case Studies on Bootstrapping.org</title>
    <link>https://bootstrapping.org/tags/case-studies/</link>
    <description>Recent content in Case Studies on Bootstrapping.org</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 19 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://bootstrapping.org/tags/case-studies/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Country and Currency Lists in CSV: Croatia Moves to the Euro Without Touching an Address</title>
      <link>https://bootstrapping.org/country-and-currency-lists-in-csv-croatia-moves-to-the-euro-without-touching-an-address/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bootstrapping.org/country-and-currency-lists-in-csv-croatia-moves-to-the-euro-without-touching-an-address/</guid>
      <description>&lt;p&gt;Country and currency lists look like the most static data an application has. They aren&amp;rsquo;t. Croatia replaced the kuna with the euro on 1 January 2023. Turkey asked to be called Türkiye in 2022. Czechia has been the short name of the Czech Republic since 2016, and plenty of applications still say otherwise. Each of those changes has to reach every database the application runs on, and customers&amp;rsquo; addresses point at those rows.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Email Templates Customers Rewrite: One Conflict Settled Once, and Legal Text the Product Owns</title>
      <link>https://bootstrapping.org/email-templates-customers-rewrite-one-conflict-settled-once-and-legal-text-the-product-owns/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bootstrapping.org/email-templates-customers-rewrite-one-conflict-settled-once-and-legal-text-the-product-owns/</guid>
      <description>&lt;p&gt;Email templates are the reference data customers change most. A self-hosted product ships a welcome email, a password reset and an invoice notice. Each customer&amp;rsquo;s admin rebrands the subject lines, switches off what they don&amp;rsquo;t use and sometimes edits the small print. Then the product team fixes a typo in a subject the admin already rewrote, and updates the legal footer every email must carry.&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://github.com/bootstrapping-engine/bootstrapping/tree/main/examples/templates&#34;&gt;templates example&lt;/a&gt; gives the columns three different owners. The subject and body are merged, so an admin&amp;rsquo;s edit stays unless the seed changes the same value. &lt;code&gt;enabled&lt;/code&gt; is local: on when shipped, the customer&amp;rsquo;s after that. And the footer belongs to the product.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Helpdesk Ticket States: Renaming a State Under Open Tickets Without Moving One</title>
      <link>https://bootstrapping.org/helpdesk-ticket-states-renaming-a-state-under-open-tickets-without-moving-one/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bootstrapping.org/helpdesk-ticket-states-renaming-a-state-under-open-tickets-without-moving-one/</guid>
      <description>&lt;p&gt;Workflow states are reference data with consequences. A helpdesk ships states like new, open, resolved and closed. Every ticket points at one, and each state names the one that usually comes next, so the application can offer a &amp;ldquo;move on&amp;rdquo; button. Renaming a state, or adding one in the middle, is a release-day job that usually ends in a hand-written migration.&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://github.com/bootstrapping-engine/bootstrapping/tree/main/examples/workflow&#34;&gt;workflow example&lt;/a&gt; does it with seed files. The states table refers to itself: &lt;code&gt;next_id&lt;/code&gt; holds the id of the next state, and the seed writes it by code.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SaaS Plan Tiers With Bootstrapping: Install Prices Stay Put and Retired Plans Keep Their Customers</title>
      <link>https://bootstrapping.org/saas-plan-tiers-with-bootstrapping-install-prices-stay-put-and-retired-plans-keep-their-customers/</link>
      <pubDate>Mon, 19 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bootstrapping.org/saas-plan-tiers-with-bootstrapping-install-prices-stay-put-and-retired-plans-keep-their-customers/</guid>
      <description>&lt;p&gt;A product sold as a self-hosted install ships its plan tiers as data: Free, Team, Business, the seat limit of each, and which features each one turns on. The product team owns that list. But once an install is running, its owner sets prices for their own market, renames a tier to fit their sales pitch, and signs customers up to plans the product will later drop. The next release has to change the list without touching any of that.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
