<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Dallas</title>
    <description>The latest articles on DEV Community by Dallas (@uhdallas).</description>
    <link>https://dev.to/uhdallas</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4061420%2F3e97f4df-78be-4785-a419-89750abd7741.jpg</url>
      <title>DEV Community: Dallas</title>
      <link>https://dev.to/uhdallas</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/uhdallas"/>
    <language>en</language>
    <item>
      <title>A Diet Arena and 105 more pages</title>
      <dc:creator>Dallas</dc:creator>
      <pubDate>Thu, 17 Sep 2026 18:38:51 +0000</pubDate>
      <link>https://dev.to/uhdallas/a-diet-arena-and-105-more-pages-11pi</link>
      <guid>https://dev.to/uhdallas/a-diet-arena-and-105-more-pages-11pi</guid>
      <description>&lt;p&gt;Google Search Console has been telling me something for weeks and I finally got around to actually building for it.&lt;/p&gt;

&lt;p&gt;A while back I noticed one query showing up over and over in my impressions: "flexitarian vs intuitive eating diet." Then "flexitarian vs AIP diet." Then a dozen more variations, all comparing one diet against another. Nawtch had individual pages for a bunch of diets already, but nothing that actually answered a "diet vs diet" question. So I built Diet Arena.&lt;/p&gt;

&lt;h2&gt;
  
  
  What it does
&lt;/h2&gt;

&lt;p&gt;Pick any two diets and get a side by side comparison. Same categories for both, no verdict on which one is better. Typical foods, foods to avoid, eating pattern, macro emphasis, who it's targeted at, how strong the actual evidence is behind it, that kind of thing.&lt;/p&gt;

&lt;h2&gt;
  
  
  The part that took real thinking
&lt;/h2&gt;

&lt;p&gt;With 15 diets, that's 105 possible pairs. I went back and forth on whether every single pair should get its own real page, or whether I should only build out the ones I actually had search data for and let everything else fall back to some generic dynamic view.&lt;/p&gt;

&lt;p&gt;I ended up going all in. Every pair gets a real page, same template, same level of care. Part of that was practical (Astro can generate all 105 from one template and one data file, so it's not actually 105x the work), but part of it was just that the point of this thing was never only "capture search traffic." I also wanted an actual tool people could use to compare any two diets, and a two-tiered system where some comparisons get the full treatment and others get a lesser one didn't sit right with either of those goals.&lt;/p&gt;

&lt;p&gt;To make that work without rewriting the same information 105 times, I had to go back through my diet pages and pull everything into a structured format first. Name, typical foods, eating pattern, evidence strength, all of it, the same shape for every diet. Once that existed, generating every pair was just running a build step, not writing 105 pages by hand.&lt;/p&gt;

&lt;h2&gt;
  
  
  How it's actually doing so far
&lt;/h2&gt;

&lt;p&gt;Honestly mixed, and I think that's worth being upfront about instead of only posting when everything looks good. Out of 105 pairs, about 10 are actually indexed by Google right now. Those are the ones I manually requested indexing on through Search Console, the same shortlist I'd already linked from the "popular comparisons" section on the picker page, since those are the pairs I actually have real search demand for.&lt;/p&gt;

&lt;p&gt;Everything else is sitting in "discovered, not currently indexed," which is Google's way of saying it knows the page exists and just hasn't gotten around to crawling it yet. Manually requesting indexing on 95 more pages isn't really practical either. There's a daily limit on how many you can push through that way, and doing it in bulk for a batch of similar new pages doesn't actually change why Google deprioritized them in the first place.&lt;/p&gt;

&lt;p&gt;That's the real tradeoff of going all in on all 105 instead of a curated dozen. A newer site only has so much crawl attention from Google at any given time, and dumping 105 pages on it at once means most of them are just going to sit in a queue for a while, regardless of what I manually push through. The rest will get crawled eventually on Google's own schedule. I'd rather have a complete, honest tool now and wait on the indexing than fake completeness with a worse version of the feature.&lt;/p&gt;

&lt;h2&gt;
  
  
  If you want to poke at it
&lt;/h2&gt;

&lt;p&gt;&lt;a href="https://nawtch.app/diets/arena" rel="noopener noreferrer"&gt;Nawtch's Diet Arena&lt;/a&gt;, no signup needed. Compare whatever two you're curious about.&lt;/p&gt;

</description>
      <category>seo</category>
      <category>startup</category>
      <category>webdev</category>
    </item>
    <item>
      <title>I Built a Bowl Builder Tool for Nawtch, and the Save Button Was Harder Than It Sounds</title>
      <dc:creator>Dallas</dc:creator>
      <pubDate>Mon, 17 Aug 2026 19:15:33 +0000</pubDate>
      <link>https://dev.to/uhdallas/i-built-a-bowl-builder-tool-for-nawtch-and-the-save-button-was-harder-than-it-sounds-8g4</link>
      <guid>https://dev.to/uhdallas/i-built-a-bowl-builder-tool-for-nawtch-and-the-save-button-was-harder-than-it-sounds-8g4</guid>
      <description>&lt;p&gt;Wanted a tool anyone could use to build a meal-prep style bowl or plate and get real calorie and macro numbers back, with weight adjustments in ounces or grams depending on what you actually use. If you're a Nawtch user, cool, you can add the finished bowl straight into your foods. But if you just landed on the page because you wanted to test out a few combinations, you don't need to be a Nawtch user at all. You can still save bowls locally and come back later to edit them or build more. It's meant to be useful to anybody, not just people already tracking in Nawtch.&lt;/p&gt;

&lt;p&gt;So, I created a Bowl Builder in Nawtch a while back and wanted to write about a decision that took longer to get right than I expected.&lt;/p&gt;

&lt;h2&gt;
  
  
  Two ways to save, and why they had to be different
&lt;/h2&gt;

&lt;p&gt;When you finish a bowl you've got two options. You can hit "Add to Foods," which flattens everything into a single food entry with combined totals, same as any manually added food. Or you can hit "Save Bowl," which keeps every individual component intact so you can come back later and actually edit it.&lt;/p&gt;

&lt;p&gt;At first I figured one save path would cover it. Then I actually thought about what happens if someone builds a bowl, logs it a few times over a couple weeks, then decides they want less rice in it going forward.&lt;/p&gt;

&lt;p&gt;If a saved bowl and a food entry are the same underlying thing, editing the bowl to use less rice would retroactively change every day you already logged that meal. That's wrong. If I logged 520 calories on Tuesday, it needs to still say 520 calories next month even if I change the recipe today.&lt;/p&gt;

&lt;p&gt;So a saved Bowl and a Food entry created from it had to be two genuinely separate things in the data model, not two views of the same object. Once you hit "Add to Foods," that's a permanent snapshot. Editing the original bowl afterward, or resaving it, never touches food entries you already created from it. If you edit a bowl and hit "Add to Foods" again, you get a brand new entry, not an update to the old one.&lt;/p&gt;

&lt;p&gt;This isn't a new idea for the app either. Nawtch already does this same thing with daily calorie targets. If you log a day and hit your range, and then later change your target range in settings, that historical day still shows whether you hit the range that was active back then, not your current one. Bowl Builder just needed the same principle applied to a new feature.&lt;/p&gt;

&lt;h2&gt;
  
  
  Where does this thing even live
&lt;/h2&gt;

&lt;p&gt;Small thing but it took real back and forth to settle. Nawtch has a Tools section and a first draft of the Bowl Builder spec argued it should be its own top level page instead, mostly because it connects back into the food tracking data and the existing Tools page was described as "stuff with no connection to your tracking data."&lt;/p&gt;

&lt;p&gt;I went with Tools anyway. Tools is whatever I decide it means, and "standalone thing you can use on its own, that also happens to plug into the rest of the app if you want it to" is a perfectly fine definition. Scorekeeper (a simple tool for tracking players' scores for most types of games) set the precedent of Tools being a real category, not a junk drawer, and Bowl Builder fits there fine.&lt;/p&gt;

&lt;h2&gt;
  
  
  Keeping it local, same as everything else
&lt;/h2&gt;

&lt;p&gt;Same deal as the rest of Nawtch. No account, nothing sent anywhere. Bowls live in your browser's IndexedDB same as your food logs and weight history. If you clear your browser data it's gone, same tradeoff as everything else in the app.&lt;/p&gt;

&lt;h2&gt;
  
  
  What's next
&lt;/h2&gt;

&lt;p&gt;Probably a similar pattern for a grocery cost planning tool I'm working on now. Different problem (planning what you'll spend on groceries this week versus what you'd spend if you just bought everything fresh), but the same core question of what needs to be a permanent snapshot versus what stays editable.&lt;/p&gt;

&lt;p&gt;If you want to actually mess with it: &lt;a href="https://nawtch.app/tools/bowl-builder/" rel="noopener noreferrer"&gt;Bowl Builder&lt;/a&gt;, no signup needed.&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>architecture</category>
      <category>uxdesign</category>
      <category>uidesign</category>
    </item>
    <item>
      <title>I built a free fitness tracker with no backend and no account — here's what I learned</title>
      <dc:creator>Dallas</dc:creator>
      <pubDate>Mon, 03 Aug 2026 23:17:19 +0000</pubDate>
      <link>https://dev.to/uhdallas/i-built-a-free-fitness-tracker-with-no-backend-and-no-account-heres-what-i-learned-58pb</link>
      <guid>https://dev.to/uhdallas/i-built-a-free-fitness-tracker-with-no-backend-and-no-account-heres-what-i-learned-58pb</guid>
      <description>&lt;p&gt;A few months ago I got tired of every calorie tracker either paywalling basic features or demanding I create an account just to log a banana. So I built Nawtch — a free fitness tracker that runs entirely in your browser, stores everything locally via IndexedDB, and never asks you to sign up.&lt;/p&gt;

&lt;p&gt;Here's the messy, honest version of how it actually came together.&lt;/p&gt;

&lt;p&gt;It didn't start as "Nawtch"&lt;/p&gt;

&lt;p&gt;The app was originally called Foop. I got pretty far into building it before doing a basic search and realizing "Foop" was already in use by a hydroponic gardening app, a B2B SaaS platform, and an AI chatbot app — none of which I wanted to compete with in search results or get confused with.&lt;/p&gt;

&lt;p&gt;So I renamed it. If you're naming a side project: check availability before you fall in love with the name, not after. I went through a whole process of brainstorming invented, slightly-whimsical names before landing on Nawtch (a nod to "gnaw," since you're logging food) — bought the .app and .com, and migrated everything over.&lt;/p&gt;

&lt;p&gt;The bigger rebuild: SPA to real multi-page&lt;/p&gt;

&lt;p&gt;The app started as a single-page app with client-side JS routing — one index.html, everything else swapped in and out via onClick handlers. It worked fine for me as the only user, but it had two real problems once I started thinking about actual growth:&lt;/p&gt;

&lt;p&gt;Zero SEO value. A single URL means Google has exactly one page to index, no matter how many features live inside it.&lt;br&gt;
No individual entry points. Someone searching "free weight tracker no account" had no page to land on specifically — everything was buried behind one homepage.&lt;/p&gt;

&lt;p&gt;So I rebuilt it into real separate pages — index.html, foods/, weight/, programs/, history/ — each independently loadable, each with its own metadata, each usable on its own without needing the others. Someone who only wants to track weight can bookmark /weight/ and never touch anything else.&lt;/p&gt;

&lt;p&gt;The technical gotcha nobody warns you about: IndexedDB is scoped to origin, not to which HTML file loaded it. So splitting into multiple pages was safe — data persists fine across page loads on the same domain — but it did mean auditing every place I'd accidentally relied on in-memory state being passed between "views" that used to be JS state swaps and were now genuinely separate page loads.&lt;/p&gt;

&lt;p&gt;The monetization pivot&lt;/p&gt;

&lt;p&gt;I originally designed a whole three-tier system: free (capped), a one-time Premium unlock, and a Premier subscription for cloud sync — the kind of thing that seemed obviously right on paper. Free tier capped at some number of saved programs/exercises, paid tier unlocks everything.&lt;/p&gt;

&lt;p&gt;Then I actually thought about what I was building this for. The entire pitch of Nawtch is "no friction, no accounts, no paywalls" — and here I was about to build an accounts system whose entire purpose was to gate features behind a paywall. That's exactly the thing I built this app to avoid inflicting on other people.&lt;/p&gt;

&lt;p&gt;So I scrapped the tiers. Nawtch is free forever, every feature unlocked, no account required, ever. Monetization is just non-intrusive banner ads (no popups, no interstitials — I explicitly ruled those out) plus, eventually, maybe a genuinely optional paid tier specifically for cloud sync or AI-assisted logging later — things that have a real recurring server cost, so the pricing model would actually match the cost structure, rather than gating stuff that costs me nothing to provide.&lt;/p&gt;

&lt;p&gt;Building the "boring but trustworthy" content&lt;/p&gt;

&lt;p&gt;Once the core tracker was solid, I added three more pages: Calculators (TDEE, BMR, macros, body fat %, BMI, ideal weight), Diets (a sourced overview of Mediterranean, DASH, keto, and others), and Guides (how-to content for every feature).&lt;/p&gt;

&lt;p&gt;The thing I cared about most here: every number has a cited source. The TDEE calculator names the Mifflin-St Jeor equation and links the original study. The body fat calculator cites the actual 1984 Navy technical report the formula comes from. The diets page doesn't crown a "best" diet — it links real studies for each one, and for Whole30 specifically, it says outright that there's no independent clinical trial behind it, because that's true and I'd rather say that than pretend otherwise.&lt;/p&gt;

&lt;p&gt;This is slower to build than just writing generic blurbs, but it's the kind of thing I think actually earns trust — and maybe backlinks — over time, versus content that reads like it was written to fill space.&lt;/p&gt;

&lt;p&gt;What's actually hard about this path&lt;/p&gt;

&lt;p&gt;No accounts means no user identity, which means no personalization beyond local settings, no cross-device sync (yet), and no easy way to build a community around the product. It also means my only real distribution channels are SEO, word of mouth, and posts like this one — no email list, no push notifications, nothing.&lt;/p&gt;

&lt;p&gt;I don't know yet if "free forever, no account, ad-supported" is a sustainable model at any real scale. But it's the app I actually wanted to use, and it's the app I'm still using every day, months in — which is more than I can say for most of the trackers I tried before building this.&lt;/p&gt;

&lt;p&gt;If you want to poke at it: &lt;a href="https://nawtch.app" rel="noopener noreferrer"&gt;nawtch.app&lt;/a&gt;. No signup, obviously.&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>javascript</category>
      <category>showdev</category>
      <category>ui</category>
    </item>
  </channel>
</rss>
