<p>Most of my posts here explain a concept. This one is different. It is a case study of something I built: <a href="https://www.magicaistory.com/" target="_blank" rel="noopener noreferrer">Magic AI Story</a>, a web app that turns a free-text description into an illustrated story. The hard part was not getting the AI to write a story. The hard part was the constraint nobody warns you about: how do you put a generative-AI service on the public internet, with no sign-up wall, and not wake up to a drained API budget and a pile of content you would not want your name on?<br /><br /> So let's talk about the real work: keeping a public AI service secure, well-behaved, and cheap to run as it grows.<br /><br /> </p><h2>Three Goals That Fight Each Other</h2><p>Here is the tension that shaped every decision. A public AI service pulls in three directions at once, and you cannot fully satisfy all three:</p><ul><li><strong>Open access.</strong> No sign-up, no friction. Land on the page, type an idea, get a story. That is the whole point. The moment you add an account wall, half your visitors leave before they see what it does.</li><li><strong>Cost control.</strong> Every story still costs something, namely three image generations each. Multiply that by 'anyone on the internet, as many times as they like' and even cheap calls add up fast.</li><li><strong>Abuse prevention.</strong> An open box that takes free text and returns AI-generated images is an invitation. Some people will try to make it produce things you do not want your name attached to. Others will just hammer it for fun.</li></ul><br /><p>Pick any two and the third one bites you. Go open and cheap with no abuse controls and you are hosting a content-moderation incident. Keep it open and safe but skip the cost ceiling and you are funding strangers' fan fiction until your card declines. Make it safe and cheap behind a login and nobody uses it. The whole build was really about refusing to fully give up any of the three.<br /><br /> </p><h2>Keeping It Affordable</h2><p>I'll lead with the number I'm proud of. A fully illustrated story (parsed input, a written narrative, and three generated images) costs me about <strong>half a cent</strong> to produce. Fractions of a penny per story, and the whole thing is built so that number stays low as traffic grows. The secret is <em>which models you call and how you call them</em>.<br /><br /> All the language work, meaning parsing the user's input, writing the story, and building the image prompts, runs on <strong>Nemotron via <a href="https://openrouter.ai/" target="_blank" rel="noopener noreferrer">OpenRouter</a></strong>, which happens to be free. For 'write a charming tale about a dragon who's afraid of heights' you do not need a frontier model, and a capable open model that costs nothing does the job well. That single choice removes what would normally be the bulk of the per-story bill.<br /><br /> The only thing I actually pay for is the pictures. Image generation runs on <strong>Flux Dev through <a href="https://runware.ai/" target="_blank" rel="noopener noreferrer">Runware</a></strong>, and each story produces three images. The results are not always perfect, but for the price it is a solid little model. That is the entire variable cost, and it is tiny. Everything else (the database, the rate-limiting, the hosting) adds very little.<br /><br /> I think about it as <em>cost per story</em> rather than a monthly bill because per-story economics is the number that scales with you. A flat monthly figure is meaningless the moment traffic moves. Cost per unit of value tells you whether the thing stays sustainable at ten stories a day or ten thousand. Get that number low and growth becomes a good problem instead of a budget emergency.<br /><br /> But cheap models are only half of it. The other half is <strong>not wasting the calls you do make</strong>:</p><ul><li>One LLM does triple duty (input parsing, narrative generation, and image-prompt crafting) instead of a separate specialised service for each.</li><li>Prompts and generation parameters are tuned to get a usable result on the first try, because every retry is wasted budget.</li><li>The pipeline is built to fail fast. If the input is junk, it gets caught before it ever reaches the image-generation step.</li></ul><br /><h2>Keeping the Budget From Falling Off a Cliff</h2><p>Cheap-per-story is fine right up until someone decides to generate ten thousand of them. With no sign-up, I had no user accounts to attach limits to, so per-account quotas were off the table.<br /><br /> The answer was a <strong>rate-limiting layer keyed on the anonymous visitor</strong>, backed by Redis. Redis fits here because rate-limiting is all short-lived counters with expiry, exactly what an in-memory store with TTLs is built for, and far cheaper and faster than hitting a real database on every request. A visitor gets a sensible allowance, and once they hit it they are asked to come back later. No account required, but also no way for one person to empty the budget. It protects the wallet and keeps the front door open.<br /><br /> </p><h2>Keeping It Secure</h2><p>'Secure' for a public AI service has very little to do with firewalls. What matters are the specific ways an open generative endpoint can be turned against you. I treated it as a list of concrete attacks, each with its own answer:</p><ul><li><strong>Garbage or malicious input.</strong> Free text is the wild west. Everything the user types gets parsed and validated before it can drive a generation, so nonsense gets rejected at the door rather than turned into images.</li><li><strong>Inappropriate content.</strong> This was the one that kept me honest. The same LLM that powers the experience also does a moderation pass, and the prompt design steers generation toward the wholesome and away from the unpleasant. The goal was a real balance: enough creative freedom that the stories are fun and surprising, enough guardrail that the service will not produce something it should not.</li><li><strong>Repeat abusers.</strong> Rate-limiting slows people down, but the determined ones need a harder stop. So there is a <strong>blacklist</strong>, a persistent ban backed by Supabase (Postgres), for cutting off bad actors entirely. Postgres is the right call here precisely because blacklist entries are the opposite of rate-limit counters: they need to be durable and stick around, not expire in an hour.</li><li><strong>Flying blind.</strong> You cannot protect what you cannot see, so analytics are wired in to watch usage patterns, both to spot abuse and to learn what people actually do with the thing.</li></ul><br /><p>Notice the split: <strong>Redis for the short-lived stuff (rate limits), Postgres for the durable stuff (bans).</strong> Same goal of protecting the service, but matching the storage to the lifetime of the data keeps each part simple and cheap.<br /><br /> </p><h2>The Hard Part: Unpredictable Output</h2><p>If I had to point at the single trickiest problem, it had nothing to do with cost or abuse. It was this: <strong>AI output is unpredictable by nature, and the rest of my app is code that expects structure.</strong> I'm asking a creative, free-wheeling model to produce something I then have to parse, validate, slot into a UI, and hand to an image generator. Creativity and reliable structure are not natural friends.<br /><br /> Squaring that came down to three things working together: careful prompt engineering to push the model toward a consistent shape, tuned generation parameters to keep it from wandering too far, and solid error handling for the times it wanders anyway. You treat the model as a component that will occasionally hand you something weird, and you build the surrounding system so that 'weird' degrades cleanly instead of crashing the experience. You are not eliminating the chaos, you are containing it.<br /><br /> </p><h2>What I'd Tell Past Me</h2><p>The thing I underestimated going in was how much of 'building an AI product' is not AI work. The model call is maybe a tenth of the effort. The other nine-tenths is everything around it: a rate limiter so you stay solvent, moderation so the output stays respectable, validation so malformed responses do not break the UI, and a ban list for the inevitable bad actor. The model call gets all the attention, but it is the surrounding engineering that decides whether the thing survives contact with real users.<br /><br /> If you are building something similar, my one piece of advice is to design for the adversarial, broke, worst-case version of your service from day one. Assume someone will abuse it, assume the calls that cost money will get hammered, assume the model will misbehave, and let those assumptions shape the architecture. It is a lot cheaper than retrofitting them after the first nasty surprise.<br /><br /> Want to see the result? <a href="https://www.magicaistory.com/" target="_blank" rel="noopener noreferrer">Give it a go</a>. And if you would rather not deal with all this yourself, get in touch and I might be available to build it for you.</p>

Shipping a Public AI Service Without Going Broke

<p>This is a quick walkthrough of how to run DeepSeek locally using LM Studio, which is free and doesn't require registration. In a few steps you can run a capable model on your own machine, privately and without usage limits.<br /><br /></p><h2>Step 1: Download LM Studio</h2><p>Head over to <a href='https://lmstudio.ai/download' target='_blank' rel='noopener noreferrer'>LM Studio's download page</a>, select your operating system, and click the download button.<br /><br /></p><h2>Step 2: Install LM Studio</h2><p>After downloading, run the installer and follow the on-screen instructions. Once installed, launch LM Studio to begin exploring its features.<br /><br /></p><h2>Step 3: Find a DeepSeek Model</h2><p>Inside LM Studio, find the sidebar on the left and click the <strong>Discover</strong> tab (the purple icon). From there you can search for models that suit your hardware.<br /><br /></p><p>If you're not sure what your computer can handle, start with <em>DeepSeek Qwen 7b</em>. On a modern Mac or a powerful gaming PC, go for <em>DeepSeek Qwen 14b</em> instead.</p><br /><h2>Step 4: Download and Load Your Model</h2><p>Once you've picked a model, click the download button at the bottom right of the window. The download can take a while, since the files range from 4.5GB to 9GB.<br /><br /></p><p>When it finishes, go to the <strong>Chat</strong> tab in the sidebar. At the top you'll see a prompt saying "select a model to load". Choose the model you just downloaded.</p><br /><p>A new window will appear with configuration options. If you're new to this, leave the settings as they are and click <strong>Load Model</strong>.<br /><br /></p><h2>Step 5: Start Chatting</h2><p>Within seconds the model is up and running, and you can chat with DeepSeek the same way you would with ChatGPT, Claude, or the web version of DeepSeek, except it runs locally with no usage limits. These models are not as capable as their full-size commercial counterparts, but they hold up well for most things.</p><br /><p>Conversations are stored only on your computer, so you stay in control. You can delete old chats or start new ones from the sidebar.</p><br /><p>LM Studio can also expose a local API, which is handy if you're a developer and want to build against the models.</p><p>That's it. You now have DeepSeek running on your own hardware.</p>

Running DeepSeek Locally: A Step-by-Step Guide

<p>Hydration is one of those React concepts that sounds more complicated than it is. If you've ever wondered how a static HTML page turns into a fully interactive React app, hydration is the answer.<br /><br />  </p><h2>What Is Hydration?</h2><p>Hydration is the process of taking server-rendered static HTML and attaching React to it so it becomes interactive. The HTML is already there on the page; hydration wires up the event handlers and state so the markup actually does something when you click it.<br /> <br /> </p><h2>Why Do We Need It?</h2><p>With server-side rendering (SSR), your server sends a fully formed HTML page. That's great for first paint and SEO, but on its own it's static. Nothing responds to clicks, nothing updates. Hydration is the step that attaches the event handlers and React state to that markup and makes the page interactive.<br /> <br /> </p><h2>The Hydration Process</h2><p>Here's what actually happens:</p><ul><li>The server sends the initial HTML, which gives you a fast first paint.</li><li>React loads in the browser.</li><li>React reads the existing HTML and matches it against your component tree.</li><li>It attaches the event handlers and sets up state management.<br /> <br /> </li></ul><h2>Common Hydration Problems</h2><p>Hydration is not always smooth. The most common issue is the 'Text content did not match' error, which happens when your server-rendered content doesn't match what React produces on the client during hydration. The two have to line up.<br /> <br /> </p><p>A few things that help keep hydration clean:</p><ul><li>Make sure the server and client render the exact same content.</li><li>Use useEffect for code that should only run on the client.</li><li>Consider partial hydration for better performance.</li><li>Watch for hydration errors in development.</li></ul><br /><h2>Streaming and Selective Hydration</h2><p>Newer versions of React support streaming SSR and selective hydration. Instead of hydrating the whole page at once, React can prioritise and hydrate different parts of the app as needed, which makes large pages feel responsive sooner.</p><p>Hydration is the bridge between static server-rendered content and the interactive app the user ends up with. Understanding how it works makes a lot of SSR behaviour and errors much easier to reason about.</p>

React Hydration: What Is It and How Does It Work?

<p>Whether you're a seasoned developer or just starting out, Git is a tool you'll want set up. Here's how to install and configure it on Linux Mint.</p><br /><h2>Step 1: Update Your System</h2><p>First, make sure your system is up to date. Open your terminal (find it in the menu or hit Ctrl+Alt+T) and run:</p><pre><code>sudo apt update && sudo apt upgrade</code></pre><p>This fetches the latest package info and upgrades your system. It can take a few minutes.</p><br /><h2>Step 2: Install Git</h2><p>With the system up to date, install Git with:</p><pre><code>sudo apt install git</code></pre><p>Your system might ask for your password and confirmation. Type it in and hit 'Y' when prompted. Git is now installed.</p><br /><h2>Step 3: Configure Git</h2><p>Git doesn't know who you are yet, so set your name and email:</p><pre><code>git config --global user.name 'Your Name'</code></pre><pre><code>git config --global user.email 'youremail@example.com'</code></pre><p>Replace 'Your Name' and 'youremail@example.com' with your actual name and email. This info gets attached to your commits, so make sure it's correct.</p><br /><h2>Step 4: Generate an SSH Key</h2><p>To securely interact with GitHub, let's create an SSH key. Run the following command:</p><pre><code>ssh-keygen -t ed25519 -C 'youremail@example.com'</code></pre><p>When prompted, hit Enter to accept the default file location. For added security, you can set a passphrase, but it's optional. This will generate a new SSH key pair (a public and a private key).</p><br /><h2>Step 5: Add Your SSH Key to the SSH Agent</h2><p>Now that you've got your SSH key, let's make sure your SSH agent is running and add your key to it:</p><pre><code>eval "$(ssh-agent -s)"</code></pre><pre><code>ssh-add ~/.ssh/id_ed25519</code></pre><p>These commands will start the SSH agent and add your new key to it.</p><br /><h2>Step 6: Install xclip (Optional)</h2><p>To make copying your SSH key easier, you can install xclip. Run this command:</p><pre><code>sudo apt install xclip</code></pre><p>If you don't want to install xclip, you can manually copy the SSH key by displaying its contents.</p><br /><h2>Step 7: Copy Your SSH Key to GitHub</h2><p>If you installed xclip, copy your public key to the clipboard with:</p><pre><code>cat ~/.ssh/id_ed25519.pub | xclip -selection clipboard</code></pre><p>If you didn't install xclip, you can display the SSH key and manually copy it:</p><pre><code>cat ~/.ssh/id_ed25519.pub</code></pre><p>Then, head over to GitHub, go to 'Settings' > 'SSH and GPG keys' > 'New SSH key', paste your key, give it a name, and hit 'Add SSH key'.</p><br /><h2>Step 8: Check Your Git Version</h2><p>Just to make sure everything is rolling, let's check which version of Git we've got:</p><pre><code>git --version</code></pre><p>This should spit out something like 'git version 2.x.x'. If you see this, congratulations! You've successfully installed Git.</p><br /><h2>Step 9: Create Your First Repository (Optional)</h2>To create your first Git repository, run these commands. They make a new directory, move into it, and initialize it as a Git repository:</p><pre><code>mkdir my_first_repo</code></pre><pre><code>cd my_first_repo</code></pre><pre><code>git init</code></pre><p>That's it. You've installed and configured Git on Linux Mint and set up SSH for GitHub. You're ready to clone, commit, push, and pull.</p><br /><p>Git has a bit of a learning curve, but it doesn't take long before branching and merging feel routine.</p><br />

Installing and Configuring Git on Linux Mint

<article><p>As software engineers, part of the job is making sure our applications stay robust, reliable, and maintainable. We do that with a few different testing strategies, each with its own purpose. Let's look at the three main ones.</p><br /><h2>Unit Testing: The Cornerstone</h2><p>Unit testing is the foundation of any comprehensive testing strategy. It involves testing individual, isolated components or units of a system to ensure they function as expected. These units are typically the smallest testable parts of an application, such as a single function, class, or module.</p><br /><p>The primary focus of unit testing is to verify the correctness of the logic within these individual units, independent of their interactions with other parts of the system.</p><br /><h2>Integration Testing: Bridging the Gap</h2><p>While unit testing ensures the correctness of individual components, integration testing focuses on verifying the interactions and data flow between these components. Integration tests are designed to identify issues that arise when different parts of the system are combined and work together.</p><br /><p>During integration testing, developers create test scenarios that simulate real-world usage of the application, exercising the various interfaces and dependencies between different modules, services, or layers of the system. This helps uncover integration-related bugs, such as incorrect data passing, unexpected behavior due to component interactions, or issues with the overall system architecture.</p><br /><h2>End-to-End (E2E) Testing: The Big Picture</h2><p>End-to-end testing takes a step back and examines the application from the user's perspective. It involves testing the entire application, from start to finish, simulating the user's journey through the system, and verifying that the application functions correctly as a whole.</p><br /><p>E2E tests typically involve automating user interactions, such as navigating through the application, inputting data, and verifying the expected outcomes. These tests ensure that the application's various components, including the user interface, backend services, and databases, work together seamlessly to provide the desired user experience.</p><br /><h2>The Testing Trifecta</h2><p>Each type of testing serves a distinct purpose and provides valuable insights into the quality and reliability of the application. By employing a combination of unit, integration, and end-to-end testing, you can build a comprehensive testing strategy that ensures your application is robust, maintainable, and delivers a seamless user experience.</p><br /><p>Unit tests help you catch and fix issues early, integration tests verify that components work correctly together, and end-to-end tests validate the whole system from the user's perspective. Together they form a solid foundation for the quality and stability of your software.</p></article>

Unit, Integration, and End-to-End: The Testing Trifecta

<article><p>Web Workers and Service Workers sound similar and are easy to mix up, but they solve different problems. Here's what each one does and when to reach for it.</p><br /><h2>Web Workers</h2><p>When a web page tries to handle too many heavy operations at once, the UI freezes because it all runs on a single thread. Web Workers fix that by letting you run scripts in the background, on a separate thread from the main one.</p><br /><p>This means you can do heavy computation without blocking the user interface. The page stays responsive while the work happens off to the side.</p><br /><h2>Service Workers</h2><p>Service Workers act as a proxy between your web application and the network. They can intercept network requests, cache resources, and keep your app working even when the connection drops.</p><br /><h2>So, What's the Difference?</h2><p>Both Web Workers and Service Workers run scripts in the background, but they serve different purposes:</p><ul><li><strong>Web Workers</strong> are all about improving performance by offloading heavy tasks.</li><li><strong>Service Workers</strong> focus on enhancing the offline experience and managing network requests.</li></ul><br /><h2>When to Use Which?</h2><p>Use Web Workers when you need to:</p><ul><li>Perform complex calculations</li><li>Process large amounts of data</li><li>Handle CPU-intensive tasks</li></ul><br /><p>Opt for Service Workers when you want to:</p><ul><li>Create offline-first applications</li><li>Improve loading times with caching strategies</li><li>Implement background sync</li></ul><br /><p>Same background-script idea, two very different jobs. Reach for the one that matches the problem you're solving.</p></article>

Service Workers vs. Web Workers: What's the Difference?

<article><p>Let's look at one of React's most fundamental features: <em>setState</em>. It looks simple on the surface, but a fair amount happens when you call it.</p><br /><h2>The setState Trigger</h2><p>When you call setState, React doesn't update the state immediately. Instead it records a 'pending state update' and schedules the work for later.</p><br /><h2>The Reconciliation Process</h2><p>Once React has collected the pending state updates, it runs a process called reconciliation. It builds a new virtual DOM tree with your updated state, compares it against the current one, and works out the minimal set of changes needed to update the actual DOM.</p><br /><h2>Batching: React's Efficiency Trick</h2><p>Instead of updating the DOM on every setState call, React batches multiple updates together and applies them in one pass.</p><ul><li>This reduces the number of DOM manipulations, which is good for performance.</li><li>It keeps your component from re-rendering more than it needs to.</li></ul><br /><h2>The Lifecycle Order</h2><p>During this process, React calls several lifecycle methods in a specific order:</p><ol><li><strong>getDerivedStateFromProps</strong>: Called after a component is instantiated or when it receives new props.</li><li><strong>shouldComponentUpdate</strong>: Determines if the component should re-render.</li><li><strong>render</strong>: Creates the new Virtual DOM.</li><li><strong>getSnapshotBeforeUpdate</strong>: Captures information from the DOM before changes are made.</li><li><strong>React updates DOM and refs</strong></li><li><strong>componentDidUpdate</strong>: Called after the update is committed to the DOM.</li></ol><br /><p>For functional components using hooks, the process is similar but uses the useEffect hook instead of these lifecycle methods.</p><br /><h2>The Final Update</h2><p>Once React has gone through all these steps:</p><ul><li>It updates the actual DOM in one go.</li><li>It calls the final lifecycle method, componentDidUpdate.</li><li>Finally, it updates the state object of your component.</li></ul><br /><p>After that, your component reflects the new state. That's the full path a setState call takes.</p><br /><h2>Why This Matters</h2><p>Understanding this process helps you:</p><ul><li>Write more efficient React code</li><li>Debug state-related issues more effectively</li><li>Understand why state should be treated as immutable</li><li>Make better use of lifecycle methods</li></ul><br /><p>None of this changes how you call setState day to day, but knowing what happens underneath makes a lot of React's behaviour easier to predict.</p></article>

Insights on Software Engineering and Getting Things Done