标签：#projects

Nowadays most social and pen‑pal apps are built around speed. Swipe left, swipe right, quick short messages, endless notifications. Platforms reward fast replies and surface‑level first impressions. We can chat with dozens of people every day, yet many of us still feel lonely. Connections are easy to start, but rarely grow deep. Even some existing pen‑pal apps gradually move toward swipe‑driven matching, focusing heavily on profile pictures instead of real thoughts. I wanted something different. What if we slow everything down? What if friendship starts from long, thoughtful letters rather than instant small‑talk? That is the original idea behind SlowInk . I am a solo indie developer building this application with Flutter. My goal was not to make another popular social product. I just wanted to solve a pain I felt myself: missing genuine, low‑pressure cross‑cultural communication. During development, I made several intentional product trade‑offs: No swipe matching mechanism. You will not judge people within one second by just looking at avatars. No real‑time instant chat. Communication happens through complete letters. You take your time writing, and others take their time replying. Reduce noisy notifications. There is no pressure to reply immediately. Focus on long‑form writing, for language exchange and sincere pen‑pal friendship. These choices brought technical challenges. Building a letter‑first social system is quite different from building typical instant‑messaging software. I spent a lot of time thinking about user privacy, spam prevention, and how to keep the atmosphere gentle for global users. Many features got cut in order to keep the core idea intact. SlowInk is still an early‑stage project. It is far from perfect. There are bugs to fix and features to polish. As a side‑project developer without large‑team support, every improvement moves forward little by little. If you feel tired of fast‑paced swipe‑based social media, or you enjoy writing and receiving

I've used Untappd for years to log the beers I drink. It works. It also drives me a little crazy every time I open it. Between the ads wedged into my feed, the check-in pressure that makes logging a beer feel like a social performance, and an interface that's accumulated more features than I've ever asked for, opening the app to do one simple thing — "I liked this beer, I want to remember it" — started to feel like more work than it should be. So a few weeks ago, I decided to build my own. The idea: Letterboxd, but for beer If you haven't used Letterboxd, it's a film-logging app that took a genre Untappd basically also occupies — "social logging app for a hobby" — and did it with a fraction of the clutter. Clean, fast, personal-journal-first, social-second. That's the model I wanted for beer. I called it HopLog. The pitch, in one sentence: log what you drink, remember what you liked, discover something new — without ads, without check-in pressure, without a hundred features you'll never touch. Building it like an actual product, not just a weekend hack I didn't want to just start writing code and see what happened. Before a single line was written, I worked through the process a real product team would use: A product requirements doc — what's actually in scope for a first version, and just as importantly, what's not User personas — who is this actually for? (Turns out: the casual drinker who wants a nice photo journal, the homebrewer who wants precise tasting notes, and the traveler hunting for good local breweries — three genuinely different people with different needs) User stories, wireframes, a database schema, an API design, and a milestone-by-milestone roadmap Only after all of that did I start building — six milestones, one at a time, each one tested and verified before moving to the next: authentication, a real beer/brewery database, the actual tasting-logging flow, profiles with stats and badges, a social layer with feeds and follows, and finally search pol

I recently worked through a hands-on Amazon S3 practical series covering the features I would actually expect to use while working with AWS storage. Instead of only documenting definitions, this post focuses on what I configured, the commands I used, how I verified the behavior, and what I observed when something went wrong . For the concepts behind these practicals, I have already covered S3 in two detailed sessions: Session 1: AWS S3 Deep Dive — Objects, Encryption, Bucket Policies & Everything In Between Session 2: AWS S3 — Versioning, Static Hosting, CORS, Object Lock & More This post is the practical companion to those two sessions. The concepts are covered there; here I focus on actually building, testing, verifying, and troubleshooting the S3 features. The labs covered: S3 bucket configuration and lifecycle management Bucket policies with IAM, EC2 and HTTPS-only access SSE-KMS encryption with CloudTrail verification Pre-signed URLs AWS CLI s3 sync S3 Versioning and version recovery Static website hosting S3 CORS S3 Object Lock Note: This is a practical write-up, so I have intentionally kept the focus on implementation and verification rather than turning it into a generic S3 theory article. 1. S3 Bucket Configuration and Lifecycle Management Objective Create an S3 bucket with a secure baseline and configure a lifecycle rule that automatically transitions objects to lower-cost storage classes over time. Configuration For the lab: Block Public Access remained enabled. Bucket Versioning was enabled. Lifecycle rule: s3-lab-lifecycle The rule applied to all objects. Current objects transition to: Standard-IA after 30 days Glacier Flexible Retrieval after 90 days The lifecycle flow was: Day 0 ↓ Object uploaded ↓ Day 30 → Standard-IA ↓ Day 90 → Glacier Flexible Retrieval Result The lifecycle rule was successfully created and enabled, and the S3 console confirmed the configured transition periods. What this demonstrates Instead of manually moving old objects, S3 Life

It’s been awhile since I typed some words around here. Right around the World Cup was the last time, from what I can see. I really didn’t want to like the World Cup, but there’s something about watching it I family that makes it about more than just a game. But I digress - this post has nothing to do with football (fortunately). This is about a pet project I’ve been kicking around for some time, and finally got around to fleshing it out and making it live. A Chinese and Western Zodiac calculator. I’m not a hard-core zodiac horoscope person. I just find the topic interesting. From time to time people would say, “Hey what sign am I?”. I’d spin up the ol’ internet and look for a good Chinese Zodiac calculator (Western Zodiac is much simpler to calculate). But the calculators were usually either deeply embedded in larger sites that were not dedicated to the topic, or ugly as hell and ridden with ads (and who knows what else). I really wished to just find a nice-to-look-at calculator that worked. And one day I realized - hey, I could just make one. I make nice looking websites. I can code enough to set up a Chinese Zodiac calculator that can accurately calculate lunar cycles and your Chinese zodiac animal, without blindly saying, “Oh, you were born in 2026? You’re a horse, of course!” (Which would only be true if you were born on February 17th of 2026 or later). You know, a simple tool that does one thing, and one thing well - show you your sign! (So you can stop asking people in bars…) Zodiacl is Born If you want to know more about the technical side of the new site, you can check it out in my portfolio. So I was probably about halfway through coding the project when the name dawned on me. Unless a client or project needs otherwise, I code and publish for an English- and Spanish-speaking audience. I deeply favor names that work in both languages; the closer to a perfect cognate (word spelled exactly the same in both languages and with the same meaning) the better. I fou

I built Suzi Chat to bring back the nostalgic feel of late-90s/early-2000s browser chat rooms. Key Features: Create and customize your own public or private chat rooms instantly from the browser. Built-in multiplayer casual board games (Chess, Checkers, Gomoku). No complicated setup—straightforward web-based access. Built using a NestJS backend and running on a dedicated Linux VPS. Live Platform: https://suzichat.com Looking for feedback from other developers on the UI layout, room creation flow, and multiplayer lobby stability.

Most "AI gift finders" are a search box with a chatbot glued on. I wanted to build something different — a quiz-driven gift recommender that ranks real Amazon products by who the recipient actually is , not just keywords. I call it GiftHive . In this post I'll walk through the architecture, the conversion tricks I learned shipping it, and the bits I'm proudest of. The Problem Picking gifts is emotionally expensive. You scroll Amazon for an hour, second-guess every option, and end up buying a gift card. Existing tools don't help because they optimize for keyword match , not recipient fit . GiftHive flips the input: instead of "show me gifts under $50", you answer a 30-second quiz about the person (relationship, interests, occasion, budget) and get a ranked shortlist with explanations of why each gift fits. Stack Next.js (App Router) — SSR for fast first paint, RSC for product data Tailwind CSS — design system + dark mode via CSS variables Cloudflare Pages — edge-deployed, free tier covers the traffic Amazon Associates — affiliate revenue model The Funnel The whole site is a 3-step conversion funnel: Landing page — exit-intent modal + social proof toasts prime the visitor Quiz — 30-second, one-question-per-screen flow, no login Results — ranked products with countdown bar and "X people found gifts this week" social proof Every step has a single primary CTA. The exit-intent modal is route-aware — it only fires on / and stays silent on /quiz and /results so it never interrupts the funnel mid-flow. That bug cost me ~15% of quiz completions before I caught it. Personalization Logic Each quiz answer maps to a vector of attributes (interests, style, budget, relationship). Products in the catalog have matching tags. Ranking is a weighted score: score = tag_overlap * w1 + budget_match * w2 + occasion_match * w3 No ML model needed — a few hundred products and clean tagging is enough to feel personal. Amazon Affiliate Integration Every product link runs through getAmazonUrl() w

A production CMS is a sprawl of endpoints: content types, entries, media, users, webhooks, plugins, settings, admin routes. Hand an agent all of it and the agent gets worse, not better. The model's tool selection drifts as the list grows, and half the tools are things a publishing assistant should never be able to call. The point of this post is the opposite move. Instead of exposing an API and hoping the agent behaves, you curate a small, labeled surface up front. HazelJS Skillgate does that curation from an OpenAPI spec, and that is the part we actually build and run here. Scope, up front This post is about curation and classification: taking a spec with many endpoints and turning a chosen slice of it into governed skills. Skillgate selects the surface, marks read versus write, and would deny destructive methods if they ever entered that surface. Turning a write's approval flag into a real human-approval pause, and enabling an LLM to drive the skills, are runtime concerns handled elsewhere in Agent OS. This demo does not implement them, and this post does not claim it does. What it does show is the curation, and that stands on its own. The tool-explosion problem Point an LLM at a full CMS API and you hit four problems at once: tool selection degrades as options pile up, throughput drops while the model reasons over a long list, you lose visibility into what the agent can actually do, and dangerous operations sit one bad call away. The demo spec here is deliberately smaller than a real CMS, 27 endpoints rather than hundreds, but the problem is identical. Even 27 is too many, and most of them are things a publishing agent has no business touching. From REST endpoint to agent skill Skillgate's input is an ordinary REST API described by an OpenAPI spec: the same entries, media, and user routes a CMS already exposes. Each endpoint is described in the standard OpenAPI shape, a method, a path, parameters, a description, and tags. Two representative operations from the sp

I've spent more than a decade building data pipelines, and the part nobody warns you about isn't the pipeline logic. It's the tuning. Executor memory, shuffle partitions, cluster size, thread counts. You pick numbers, ship it, and a few weeks later something breaks in a way that's obviously tuning-related but not obviously what to change . The pattern repeats enough times that you start recognizing it before you've even opened the logs. Job's slow, thousands of tiny shuffle tasks, someone way overestimated the partition count. Job dies on OOM, memory's set for last quarter's data volume, nobody updated it since. Cloud bill jumps, a cluster's been sized for peak load and just sits there mostly idle the other 20 hours a day. Every senior data engineer has this pattern-matching running in their head. It's tribal knowledge, and it lives in one or two people's heads on most teams, which means it doesn't scale and it definitely doesn't survive someone leaving. So I built a small tool to make that pattern-matching explicit instead of tribal: it reads your pipeline's config alongside its actual run metrics and tells you what's likely wrong, with the reasoning shown, not just a suggested number. Why rules instead of a model The obvious move in 2026 is to reach for an ML model. I didn't, and it wasn't because I don't think ML has a place here eventually. It's that for this specific problem, a handful of threshold rules already gets you most of the value, and they're something you can actually audit. If a rule fires, I can point at the exact condition and the exact number: average heap usage 28%, peak 47%, five runs, no OOM errors, therefore memory's over-provisioned, shrink it by roughly a fifth. That's checkable. You can look at your own metrics and see whether the reasoning holds. A model's confidence score doesn't give you that, and for something that's about to change a production config, I want the person approving it to be able to say "yes, I see why" rather than "the m

Recently, I’ve been spending more time building small projects on my own. One thing I’ve learned is that it’s usually better to keep things simple and ship early instead of trying to make everything perfect. A small project can still teach you a lot about coding, deployment, design, and how people actually use what you build. I’m planning to share some of my development notes and experiments here from time to time. Looking forward to learning from everyone on DEV.

Building software is easy. Building something people actually want to use is the hard part. For the last few months, I've been working on CV Mimarı, a resume builder designed to make creating ATS-friendly resumes simple, fast, and accessible. 👉 https://cvimarı.xyz My goal wasn't to build "another resume builder." I wanted to remove the usual pain: confusing editors unnecessary account creation complicated formatting resumes that look good but fail ATS screening The idea was simple: Spend your time improving your experience, not fighting with Word formatting. What it currently does Today the project includes: Resume templates AI-powered resume improvements ATS score checking Resume optimization Cover letter generation Resume examples and guides PDF export Modern responsive interface I tried to keep everything clean and straightforward instead of adding dozens of unnecessary options. Sometimes software tries so hard to become "professional" that it forgets people just want to click a button and move on with their lives. Why I'm posting here I'm not looking for compliments. I'm looking for problems. Imagine you were using this to apply for your next job. I want brutally honest feedback. Things like: Is something confusing? Does the UI feel slow? What would make you leave the site? Which feature feels unnecessary? What's missing? Would you actually trust this with your resume? If something is bad... Tell me. If something is ugly... Tell me. If something makes you want to close the tab... Definitely tell me. The biggest challenge One thing I've learned is that building features is much easier than understanding users. I can spend a weekend implementing a new AI feature. But discovering why someone leaves after 20 seconds? That takes dozens of real users. That's why I'm asking for feedback before continuing to add more features. The roadmap Some ideas I'm considering: More resume templates Better AI suggestions Portfolio integration LinkedIn import Resume version history

A single-author repo of instruction files, not code, Ponytail passed 44,000 GitHub stars in nine days by making coding agents stop over-building. Its headline claim of 80-94% less code came from a flawed baseline; after a contributor said so, the maintainer rebuilt the benchmark as a real agentic run and published a lower figure of 54%. By Steef-Jan Wiggers

I've been going back and forth on whether to share this — it's a pretty niche idea, and I wasn't sure if it's clever or just weird. But here's the technical side of it, which I figure this crowd might actually appreciate regardless. What I built: claimo.me — you claim a short code (2-4 letters, or a custom name) for a one-time fee, no subscription, permanently yours. Each code is configurable as a redirect link, a QR code, or a small profile card. There's also a "Claimo Map" — every possible code is a clickable pixel you can browse, inspired by the old Million Dollar Homepage. The part I actually want to talk about here: it's zero-dependency. No Express, no ORM, no build step — just Node.js 22+'s built-in http module and the new built-in node:sqlite. I wanted to see how far "just the standard library" actually gets you for something real — payments (Stripe), admin moderation, rate limiting, a live interactive map UI, the works. Some things that surprised me building it this way: node:sqlite's DatabaseSync is genuinely pleasant to use, but it's missing conveniences like better-sqlite3's .transaction() helper — I ended up writing a small manual BEGIN/COMMIT/ROLLBACK wrapper. Routing without a framework is maybe 40 lines of code and I stopped missing Express within a day. The real cost isn't runtime performance, it's losing the ecosystem — anything I'd normally npm install for free (input validation, rate limiting, even basic templating) I had to hand-roll. Some of that was genuinely good for me, some of it I'd reconsider on a bigger project. Business side, since half of you will ask: it's a real registered business, payments go through Stripe only (I never touch card data), no crypto, nothing weird. The paid tiers fund keeping a free short-link tier alive too. Honestly — is the zero-dependency thing a genuinely good call for a real production app, or am I just going to regret it in a year? And separately: does "own a short code" as a product idea make any sense to you

Listmargin works out your eBay final value fees, ad fees, and what you actually keep on a sale. Most fee calculators copy a four-line summary of eBay's rates. This one reads the full published schedule: all 46 category rates, the store subscription tables, and the four categories where crossing a price threshold re-rates the entire sale. It's free, with no signup and no paid tier. There's an embeddable version if you run a blog or a tool site. A weekly monitor re-reads eBay's own fee pages, so when a rate moves the calculator gets corrected instead of drifting out of date.

Ship log — first $3 in 3 days (or learn what fails) Aimed at fellow indie hackers: I'm running a "first $100" experiment. One pack, one platform, full learnings shipped. Here's what worked, what flopped, and what I changed. Day 0 — packaging Built headlines-no-ai-wrote , $3, single markdown file + JSON mirror. Stack: Gumroad for checkout, just markdown for delivery. Why markdown? Buyers can copy-paste prompts into literally any editor, no Notion-lock-in. Day 1 — posted to Reddit r/SideProject: drafted post (see post_reddit.md ). Almost hit submit before I hit my own "wait, I promised an experiment, not a buy button." Result: 0 paid, 1 heartfelt comment from a writer friend who told me the headline itself was the best one . Day 2 — the move I sent the full 50 (not the trimmed 10) to 5 newsletter-writer friends with one line: "yo bro, take it, no ask." Don't ship to millions, ship to 5. Day 3 — what's next Trying Show HN with a tight "here's what worked, here's what didn't" framing. If 0 sales after Day 7, the lesson is "Reddit can't find you from zero". Move 2 = HN. Takeaway so far $3 is real money when you sell 33 of them. Reddit / HN hate wall-of-text, but hate wall-of-CTA more. A useful free preview (10 lines here) > a useful paywall (50 lines there). Ship log footer I post the daily update as part of an experiment to get to first $100 with a public ship log. Tiny wins, real numbers. If you do this too — link me up in the comments. — Cross-post: this is part of an automated indie experiment; the only human-written bits are the prompts and the structure.

I build products solo. Every single one of them sits on top of somebody else's API — Stripe for payments, OpenAI and Anthropic for AI features, Meta for ads, print-on-demand APIs, map APIs. My code is maybe half of what actually runs in production. The other half belongs to vendors, and it changes whenever they decide it changes. Twice this year the first notice I got about a breaking change was a production error. Not an email, not a warning. An error, and then me digging through the vendor's changelog trying to figure out what they changed and when. The information was public the whole time. It was sitting in a changelog page I never visit, because nobody visits changelog pages until something is on fire. So I'm building the thing I wanted to exist BreakWatch is simple: you tell it which APIs your product depends on, and it reads their public changelogs for you. It fetches each changelog page once a day Diffs it against yesterday's snapshot Classifies the real changes: breaking (endpoint removed, field deprecated, "migrate by September") vs. informational (new feature, docs clarification — stuff you can ignore) Alerts you only when something looks like it will break an existing integration Keeps everything in a searchable timeline, so six months later "what changed on their side right before this broke" takes ten seconds instead of an afternoon No SDK, no credentials, nothing installed in your codebase. It only reads public pages. What I tested this week I ran it against the real changelogs of the ten APIs I'm watching first: Stripe, Twilio, OpenAI, Anthropic, Shopify, GitHub, Slack, Cloudflare, Google Maps and Plaid. Some honest findings: 10/10 scrape cleanly now, but it took fixes. Stripe's changelog page alone is 3.3 MB. SendGrid's standalone changelog doesn't exist anymore (it merged into Twilio's). PayPal's developer site serves a JavaScript shell with an HTTP 404 to anything that isn't a full browser, so it's out until I add rendering. The thing I was most a

You followed an old breeding guide. You put Penking + Bushi into your breeding farm, dropped the cake, waited for the egg... and out hatched Sibelyx , not the Anubis the guide promised. You're not alone. Your guide isn't broken. The recipe changed. When Palworld hit 1.0, the breeding table got quietly rewritten. Almost every pairing that players had memorized from early-access now produces a different Pal. There's no in-game notice, no patch note that lists the hundreds of changed combos — just a lot of confused hatchings. So I dug into the data. Here's what I found, and the small tool I built to make sense of it. What actually changed in 1.0 I compared two snapshots of the game's breeding data — the pre-1.0 set and the current 1.0 release — both sourced from the open-source PalCalc project. The headline number: 97.7% of comparable pre-1.0 parent pairs now produce a different Pal. That's not a typo. If you take the breeding pairs that existed before 1.0 and run them against the current data, nearly all of them hatch something new. A few concrete examples players keep running into: Old recipe (pre-1.0) What it makes now (1.0) Penking + Bushi Anubis → Sibelyx ... (more pairs in the tool) The mismatch matters because most breeding guides and calculators on the internet still show the old results. Players follow them, breed, and get confused. The subtle trap: renumbering vs. real change There's a detail that trips up every breeding tool that tries to track this. When Palworld 1.0 launched, it also renumbered parts of the Paldeck (Pal #139 vs #116, etc.). A naive diff tool would see the number change and wrongly report "the breeding result changed!" — when really only the number changed, not the actual Pal. To avoid that false signal, I match Pals by their internal game name , not their Paldeck number. A renumbering is not mistaken for a changed breeding result. Only genuine recipe changes are counted. The tool: PalShift I wanted a dead-simple way to answer one question:

So I built a Chrome extension that does one very stupid thing: it waits a random amount of time, then screams at you like a goat if you don't dismiss the notification fast enough. Simple idea. Should've been a simple build. It was not, because Manifest V3 said no. The plan was easy, in my head Here's what I thought I needed: chrome.alarms to fire at a random interval chrome.notifications to show a "you good?" popup If the user ignores it for 60 seconds, play a goat sound Step 3 is where things fell apart. Because in Manifest V3, your background script isn't a persistent background page anymore — it's a service worker. And service workers have the audio capabilities of a rock. No Audio() object. No Web Audio API. Nothing. You can't just do new Audio('goat.mp3').play() and call it a day, because there's no DOM for it to live in. I found this out the way everyone finds out things in MV3: by writing the obvious code, watching it silently fail, and then spending 20 minutes wondering if I'd misspelled "goat." Enter: the offscreen document Chrome's answer to "service workers can't do X" for a bunch of X's (audio playback included) is the offscreen document API . It's exactly what it sounds like — a hidden HTML page that exists purely so your extension has something with a DOM, so it can do DOM things. In my case, playing an mp3 of a goat losing its mind. The flow ends up looking like this: service worker (background.js) → creates an offscreen document if one doesn't exist → sends it a message: "play the sound" offscreen.html/offscreen.js → has an <audio> tag → actually plays the sound → closes itself when done It's a little bit like hiring a stunt double because the main actor (your service worker) isn't allowed near water. The offscreen document does the wet work, then goes home. Rough version of what that looks like in code: // background.js async function playGoatSound () { if ( ! ( await chrome . offscreen . hasDocument ())) { await chrome . offscreen . createDocument

My job-search tool had five functions whose only purpose was fixing JSON that Claude had just written. _clean_json_text , _fix_unescaped_newlines , _fix_single_quotes , _strip_markdown_wrapper , _extract_and_parse_json . There was also a sixth, _retry_json_fix , which took the broken JSON and sent it back to the model with a polite request to fix its own mess. I wrote every one of them, one bug at a time, over weeks. I was a little proud of them. That was the problem. How you end up with five parsers JobSearch is my personal tool, in production, single user: me. It ingests job offers from nine boards, and when I press "Analyze", Claude reads the offer against my CV and returns a structured verdict: score, recommendation, career track, the English level the ad actually requires. That verdict has to be JSON, because everything downstream is a database row, not prose. The first version did what every tutorial does. Ask the model for JSON in the prompt, take response.content[0].text , run json.loads on it. It worked in the demo and then production started teaching me things. The model wrapped the JSON in markdown fences, so I wrote a function to strip them. Sometimes it used single quotes, so I wrote a function to fix those. Then a description with a line break inside a string, so I wrote _fix_unescaped_newlines . Then a NaN where a number should be. Every fix was five lines, obviously correct, and came with its own tests. I still have the test names in the git history and they read like a confession: test_removes_trailing_commas , test_replaces_nan_with_null , test_replaces_infinity , test_unclosed_fence_still_strips_opening . By April the parsing layer was around 250 lines with seven strategies, chained, each catching what the previous one let through. The last resort was the AI self-repair call: if nothing parsed, send the broken output back and ask the model to repair it. A second API call, with real latency and real cost, to fix a formatting problem the first call

I'm excited to share a project I've been building: Letras Personalizadas — a free Unicode text styling tool that helps you create creative copy-and-paste text for social media, gaming, and messaging apps. Here's how it works: • Type your text • Instantly preview dozens of Unicode text styles • Copy your favorite with one click • Use it on Instagram, WhatsApp, TikTok, Discord, Free Fire, and more Although the website is designed primarily for Spanish-speaking users targetting Brazil, it works with any standard Latin text. One thing I've learned while building this project is that these tools are about much more than "fancy fonts." The real challenge is creating a smooth user experience—fast previews, mobile-friendly design, reliable copy buttons, platform compatibility, useful categories, favorites, and making the styled text effortless to use across different apps. I'm continuously improving the interface, expanding the style categories, and refining the mobile experience. If you have a few minutes to try it out, I'd love to hear your feedback and suggestions. Every comment helps make the tool better.

When I first wrote about NutriAgent in November 2025, it was a full application. It had a Python backend, a web interface, a Telegram bot, user accounts, Google OAuth, Supabase, and a Google Sheets integration. Recently, I reproduced its core workflow as a skill for my personal AI agent. It took around 15 minutes and two prompts. I didn't build another backend, deploy a service, or implement OAuth again. I explained how I wanted the workflow to behave, tested it, and watched a new row appear in my nutrition spreadsheet. The original application wasn't a mistake. It was how I could deliver that experience with the tools available at the time. Eight months later, the starting point had changed. Eight Months Ago, This Was an App I built NutriAgent because I wanted to track calories and protein without trapping my data inside a nutrition app. I wanted the raw records in a spreadsheet I controlled, where I could create my own reports and eventually connect nutrition with my training data. The first version was a personal n8n workflow. It worked for me, but when a friend wanted to try it, I realized that everything was tied to my accounts. To make it reusable, I rebuilt it in Python and added the parts a real multi-user product needed: authentication, storage, a web interface, Telegram, Google OAuth, conversation history, and account linking. I've already told that story in I Ditched MyFitnessPal and Built an AI Agent to Track My Food , and later wrote about what broke after I used it every day for a month . This article starts after that version. My Gaming PC Became an Agent Box I had a modest gaming PC at home with 16 GB of RAM and a 1 TB drive. Using it through Windows, WSL, and remote desktop from my Mac felt awkward, so I installed Linux and turned it into a remote box for running agents. I'll write about that setup separately. I moved Hermes there from a VPS. Hermes is the personal agent I now run on that machine. It can load reusable skills and use tools connected