标签：#build

Two numbers off my Search Console this morning, same 28 day window, same site. The free landing page roast tool: 42 impressions, average position 38.0. The blog post I wrote to support that tool: 11 impressions, average position 21.1. Six weeks earlier it was the other way round. On July 4 the tool sat at position 7.5 on 18 impressions and the article was at 17.8 on 38. So the tool has more than doubled its reach since then, and its average position has gotten roughly five times worse over the same stretch. Both of those things are true at once, and working out why changed how I plan the next tool. The tool favors.dev/roast takes a URL and gives back a conversion score out of 100. It screenshots your full public page, then grades the copy and the design together across six categories: clarity, value proposition, trust, CTA, visual design and SEO. You get back the specific issues hurting signups with a fix for each, the things the page already does well, and a one line verdict. No signup, no credit card, no email field. Paste a URL, press "Roast it", read the result. It is deliberately small, and the scoping is most of why it shipped. The cut list was: accounts and password resets, saved history, dashboards, billing and usage limits, settings and themes, support for every edge case, and an admin panel for myself. Every one of those is how a weekend build turns into a month. If a free tool needs a billing system, you have started building a second product by accident. What those numbers actually say Here is the honest read, because "my free tool beat 29 of my 32 blog posts" is technically true and a bit misleading. Reading Tool impressions Tool position Article impressions Article position Jul 4 18 7.5 38 17.8 Jul 11 20 7.1 42 16.9 Jul 19 22 10.4 39 19.1 Aug 15 42 38.0 11 21.1 Impressions climbed because the tool started matching a much wider spread of queries. Average position fell for exactly the same reason. It is not ranking better. It is ranking on more things, m

Investors want founders who understand the financial reality of their business. Messy data, misunderstood metrics, or waiting until you’re nearly out of cash to start fundraising can cost founders leverage, valuation, and even a term sheet. In this episode of Build Mode, host Isabelle Johannessen sits down with Sasha Orloff, founder and CEO of Puzzle […]

Build-in-public note, no fireworks. Why bother Search Console in mid-August was blunt: 6 of 1,098 pages indexed, the rest stuck at "Discovered – currently not indexed", and the Links report empty. Zero external backlinks. The site has a thousand free session pages that nobody can find because nothing points at them. Directories are the cheapest way to get the first handful of pointers, and they are also the corpora that AI assistants read when someone asks "what tools show SPX gamma exposure". So the goal was never traffic. It was (a) backlinks and (b) third-party mentions. What went in The same card everywhere: SPX dealer positioning rebuilt from the 0DTE tape; zero-gamma flip, call/put walls, hold band; every finished session free; a backtest Lab; an MCP server; no buy/sell signals. Logo from the favicon, three screenshots (terminal, the measured book, the Lab), category Finance / Investing wherever the menu allowed it. Done and live: Capterra, AlternativeTo, the official MCP registry (and glama.ai, which pulls from it), TradersList, Firsto, TinyLaunch, Startup Fame, Indie Hackers. Submitted and waiting on a human: StartupStash. Product Hunt is scheduled, one shot only. What we skipped, and why — this is the useful part Anything that wants a badge on our homepage for the free tier (Huzzler, Startup Fame's final step). The card is filled and sits unpublished. A measurement terminal with "featured on" stickers on it is a different product. AI-tool directories (Futurepedia, There's An AI For That). $300–$500 for a listing in front of an audience that wants image generators. The MCP server technically qualifies; the economics do not. Hashnode. Published a 1,300-word engineering write-up; AutoMod archived it within the hour as "this type of content" on a free subdomain, with an upsell to Pro. The Markdown is saved; it will go out on dev.to instead. Reddit. Not a channel for this product. Decided, not deferred. Paid "we submit you to 140 directories" packages. Every one

If you have ever tried to win a domain at auction, you probably assumed the game works like eBay: watch the clock, wait for the last eight seconds, fire your bid, walk away with the name. On Namecheap, that does not work. Not "works badly". Does not work. Namecheap's expiring and marketplace auctions close in a daily batch at 11:00 AM ET. Every auction ending that day ends at roughly the same moment, which means there is no quiet corner of the day where you and one other bidder are paying attention. And if a bid lands in the closing window, the auction extends. So the buzzer-beater you were planning gets absorbed and the clock keeps running. The winner is not the fastest click. The winner is whoever set the smartest proxy maximum, on a name they found before anyone else was looking at it. I have been building PounceDomains around that one fact for months, and it is the reason the product looks the way it does. The edge moved from timing to discovery If speed is not the lever, the levers left are: find the good names earlier, and know what they are actually worth before you commit a number. So the engine scans the Namecheap aftermarket around the clock rather than at the bell. You describe the domains you want in plain English, something like "pronounceable 5-letter .com brandables under $50, no numbers or hyphens", and it builds a tuned config you can edit. If your config is too broad, it tells you and tightens it. There are seven scoring lenses you can stack: pronounceable, brandable, exact-match keyword, short premium, dictionary word, two-word combo, and free-text custom criteria. Fast programmatic filters run first, then AI scores what survives, and only domains that clear your threshold become matches. It has graded over 340,000 domains so far. The second lever is the one I care about more. Every match arrives with its receipts The failure mode in domain investing is not missing a name. It is paying $400 for something worth $80 because a free appraisal tool pri

Automating Daily Bluesky Posts with a JSON‑Driven Content Pipeline TL;DR: I added a set of JSON files and a lightweight loader to the content‑automation repo so our CI can generate and publish daily Bluesky posts automatically. The change centralizes multilingual copy, makes the publishing script data‑driven, and removes the manual copy‑paste step that was breaking our release flow. The Problem Our weekly release process includes a short status update on Bluesky. The copy lives in a markdown file that we edit manually, then copy‑paste into the Bluesky CLI. Two issues kept surfacing: Human error – a typo or missing line would cause the post to be rejected by the API ( Error: Invalid payload: missing "text" ). No versioning – we had no way to track which text was used for a given date, making it impossible to audit or rollback a post. The symptom was a failed CI job that stopped the whole pipeline with the error above, and we were forced to roll back the entire release just to fix a missing word. What I Tried First My first attempt was to add a tiny shell script that reads a bluesky.md file and pipes it into the CLI: cat content/2026/08/16/bluesky.md | npx bluesky-cli post That worked locally, but the script crashed in CI because the file path was hard‑coded and the runner didn’t have the bluesky-cli binary installed. I also quickly realized that the same script would need to support English and Spanish versions, so the hard‑coded approach would explode as we added more languages. The Implementation 1. Data‑driven content files Instead of markdown, I switched to a JSON structure that can hold multiple languages and post types (progress, announcement, etc.). Each day gets its own folder under content/YYYY/MM/DD/VS/ . For the 2026‑08‑16 release we added: content/2026/08/16/VS/bluesky_en.json content/2026/08/16/VS/bluesky_es.json content/2026/08/16/VS/metadata.json Example bluesky_en.json [ { "type" : "progress" , "text" : "Finally pushed a real change: coverage for the

The Day I Realized I Wasn't Building Apps For years, I thought I was building apps. That's what I called them anyway. A scheduler. A job bot. A healthcare platform. An AI project. A content tool. A browser automation system. Looking at my GitHub, they seem completely unrelated. Honestly, that's something I've worried about before. I have over a hundred repositories. If someone spends thirty seconds scrolling through them, I can imagine them thinking: "Wow. This person is all over the place." The funny thing is that I eventually realized the opposite was true. My GitHub is here: https://github.com/ashb4 The Scheduler That Wasn't A Scheduler One of my projects started life as a simple scheduler. That was the goal. I hated posting content manually. Open platform. Paste content. Upload image. Repeat. Again. And again. And again. It felt repetitive. It felt annoying. Most of all, it felt like something a computer should be doing instead of me. So I built a scheduler. At least, that's what I thought I was building. Then Things Got Weird The scheduler worked. But now I needed content. Then I needed analytics. Then I needed to know what content was working. Then I needed a way to track winners. Then I needed a way to reuse content. Then I needed platform-specific strategies. At some point I looked up and realized I wasn't building a scheduler anymore. I was building a system. A system for discovering, creating, publishing, measuring, and improving content. The scheduler was just one piece. Then I Started Looking At Everything Else That's when I noticed the same thing happening in almost every project I'd ever built. My job application tools weren't really job application tools. They were systems designed to reduce repetitive effort. My automation projects weren't really automation projects. They were systems designed to reduce repetitive effort. Even my AI projects weren't really about AI. They were systems designed to reduce repetitive effort. Different technologies. Diffe

I recently learned something about building products that I probably should have understood much earlier: People liking your product doesn't necessarily mean they need it. I built a platform called Rizzzler, an open-source profile/link-in-bio platform. The idea was pretty simple. I'd seen people using platforms where they could put a link in their social media bio and create a small personal page. I thought I could build my own version — something simple, fast, customizable, and a little more fun. So I built it. And because I wanted people to be able to trust what they were using, I made the project open source too. I spent a lot of time building the actual product. There are profiles, customization, coins, notifications, milestones, community chat, and other small systems intended to make the platform feel less like a static link page and more like something people could actually interact with. At that point, I thought: "Okay, now I just need people to find it." That turned out to be the easy part. Then I started promoting it. I submitted Rizzzler to places like Product Hunt, SaaSFrame, and other platforms where people discover new products. And for a few days, things actually looked pretty good. I started getting visitors. At one point, the traffic was above the 25th percentile for the category I was looking at in GA4. People were visiting. Some people signed up. And I started getting feedback like: "Good UI." "This is good." "Someone finally made link-in-bio profiles look cool." Those comments felt great. They also gave me a slightly dangerous impression: Maybe I've built something people actually want. Then the traffic stopped. Not gradually. It just became cold again. The initial spike from launching and posting about the product disappeared, and there wasn't enough organic interest to keep bringing people back. That was the part I didn't expect. The product wasn't necessarily bad. This is something I've been thinking about a lot. I don't think the main problem

Building software in 2026 feels surreal. With LLMs handling boilerplate, we ship features in hours that used to take weeks. But fast shipping has a nasty side effect: it breeds overconfidence. A few days ago, we ran an automated check against our own live marketing site ( vergate.dev ). We build security and diagnostic tools for a living, so we expected a clean bill of health. We were wrong. Our scanner flagged 8 real issues in production—including missing security headers that left us exposed to basic cross-site attacks. Dogfooding your own tool isn't a marketing gimmick. Sometimes, it's just plain embarrassing. But it taught us a crucial lesson: you can’t fix what you don't automatically measure. What our scan actually found Here is the exact breakdown of what slipped past us into production (and what probably exists in your current deployment right now): 1. Zero Security Headers Enabled Our hosting provider’s default CDN edge rules didn't set baseline headers. We were shipping without: Content-Security-Policy (CSP): Left us open to inline script injection. Strict-Transport-Security (HSTS): Didn't force browsers to enforce HTTPS strictly. X-Content-Type-Options : Allowed MIME-type sniffing on static assets. X-Frame-Options : Rendered our pages vulnerable to clickjacking IFrames. Why this happens: Framework defaults (like Next.js, Nuxt, or Astro) often expect your proxy or CDN edge (Vercel, Cloudflare, Nginx) to handle headers. If you forget to configure the edge, your app runs bare. 2. Sensitive Meta & Server Leakage Our response headers explicitly broadcast our server stack and proxy details. Attackers use automated scanners like Shodan or Censys to query these specific signatures and exploit target-specific CVEs in seconds. 3. Cookie Missing SameSite & Secure Flags A tracking cookie set on a subroute wasn't explicitly flagged as SameSite=Lax or HttpOnly , leaving a window open for CSRF-style cross-domain requests. How we fixed it (in under 10 minutes) Fixing the

A few days ago I posted here about DevStacker, my app for helping self-taught developers escape tutorial hell and build real projects. We were getting ready to launch it, but then we found some bugs in the login screen. The app itself was working, but the login flow had some issues, and obviously we can't really launch while the first thing users see is broken lol. So we delayed the launch for a bit and we're fixing it now. I'm pretty close to getting everything ready, so hopefully DevStacker will be live very soon. This is also my first app, and honestly I didn't realize how many random things can go wrong until I actually tried to launch one 😭 Anyway, back to fixing login. I'll post again when DevStacker is finally live 🚀

Building voice AI sounds deceptively clean on paper: capture speech, stream it to an STT engine, prompt an LLM, and synthesize audio back in real time. In reality, building a real-time, multilingual voice assistant that handles high-stress banking fraud while running on desktop hardware in 30°C heat with unstable power is a completely different story. As a Class 12 student diving into my first-ever hackathon, I spent the last 10 days of the #VoiceForBharat Challenge building Raksha —an empathetic, multi-agent voice assistant designed to protect Indian citizens from cyber scams, verify official government schemes, and escalate active financial fraud to human coordinators. Here is the honest breakdown of how Raksha evolved from Day 1 to Day 10, the absurd hurdles along the way, and what it actually takes to build reliable voice systems. 1. The Core Problem: Panic & Digital Banking Scams India's digital payments ecosystem is scaling at lightspeed, but so is financial fraud. Every day, people receive panic-inducing SMS messages claiming: "Your bank account is blocked. Update KYC immediately or share OTP." When someone is panicked, reading a 5-page PDF advisory is the last thing they will do. They need immediate, reassuring spoken advice in accessible Hinglish: "Ghabraiye mat. Bank kabhi phone ya message par OTP nahi mangta. Yeh poori tarah fraud hai." Voice is the most natural medium for this. If an AI agent can step in during those critical first 60 seconds, it can prevent immediate financial loss. 2. The 10-Day Journey: Power Cuts, Audio Hacks & Architecture Days 1–3: The Rocky Start & The Audio Hack Day 1 was pure chaos. I was battling 404s and gRPC hanging issues while connecting Gemini and LiveKit. Exactly 16 minutes before the midnight deadline, the power cut out completely. When it returned a minute past midnight, my desktop greeted me with a blue SrtTrail.txt Windows repair screen—and then another storm knocked the grid out again. I thought I was out on Day 1, b

For the last 10 days, I have been building a voice agent called Shiksha as part of the 10 Days of Voice Agents — VoiceForBharat Edition challenge by Murf AI. My original idea was simple: Build a voice agent that can help students learn through natural conversation. Over the challenge, that idea grew into a complete voice-based learning system with memory, tools, human escalation, call analytics, and a specialist agent . What is Shiksha? Shiksha is a voice-based learning partner for students. Instead of typing questions and reading answers, a student can simply talk to Shiksha. A student can: Ask learning questions Take quizzes Continue learning with their saved profile Get help when they are stuck Practice mathematics Get transferred to a Maths Specialist when needed The main goal was to make the experience feel more like a conversation than a traditional chatbot. Tech Stack Component Technology Real-time voice LiveKit Speech-to-Text Deepgram LLM Gemini Text-to-Speech Murf Falcon Backend Python Memory SQLite Call analytics Flask + SQLite External data Open Trivia Database The voice experience is powered by Murf Falcon , which was one of the main parts of the challenge. How Shiksha Works At a high level, the system looks like this: STUDENT │ ▼ LiveKit Real-time Audio │ ▼ Deepgram Speech-to-Text │ ▼ Gemini Agent Reasoning │ ┌────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ Memory Tools Handoff SQLite Quiz API Maths Specialist │ │ │ └────────────┴─────────────┘ │ ▼ Murf Falcon Text-to-Speech │ ▼ STUDENT This was the basic architecture that I built and expanded throughout the challenge. What I Built 1. Student Memory One of the first things I added was a simple memory system using SQLite. Shiksha can store: Student name Current learning level Topics covered Last interaction This means the agent can use information from previous conversations instead of starting from zero every time. 2. Real Tool Calling For quizzes, I didn't want the agent to always generate questions from memor

For the past few months, I've been working on a project that translates online meetings in real time. At first, I thought the problem would mostly be about choosing the right speech recognition model and finding a good translation API. It turned out those were the easy parts. The real challenge was making everything feel instant. People don't wait for subtitles. If the translation appears two or three seconds after someone finishes speaking, the conversation has already moved on. Technically it works, but from a user's perspective, it feels broken. That completely changed how I approached the project. Instead of optimizing only for accuracy, I had to optimize the entire pipeline for latency: Capturing audio continuously Streaming audio to ASR Performing speech recognition incrementally Translating partial sentences Updating subtitles without flickering Handling corrections when the speech recognizer revised previous words Every stage might only take a few hundred milliseconds, but together they determine whether the experience feels "real-time." Another lesson surprised me even more. Translation quality isn't just about picking a better LLM. Spoken language is messy. People interrupt each other, change direction halfway through a sentence, use filler words, and rarely speak in complete grammatical sentences. A model that performs well on benchmarks can still struggle in a live conversation if the input arrives one fragment at a time. That forced me to rethink prompts, buffering strategies, and when to display or revise translated text. Building this project also gave me a new appreciation for streaming systems in general. Real-time applications are fundamentally different from batch processing. Instead of asking, "How accurate is the result?", you're constantly balancing three competing goals: Latency Stability Accuracy Improving one often makes another worse. I'm still learning every day, and there are plenty of problems left to solve. Over the next few weeks, I'd

How long does it take to publish one article? If you run a one-person company, the honest answer isn't "the few hours of writing." It's everything that comes after — moving it into your newsletter, copying it to one dev community, pasting it into another, translating it for an English audience, cutting a short version for X, dropping a note somewhere else. That relay of copy-paste-reformat costs more energy than the writing itself. This week I killed that chore. Now I finish a draft, drop it into a single spreadsheet, run one command, and it fans out to eight platforms on its own. But I don't want to talk about "I built an automation tool." That's the small part. I want to talk about three judgments that are worth far more: where a solo founder's real bottleneck lives, how this machine should actually be built — and how it nearly lied to me. Writing isn't the bottleneck. Distribution is. Most people assume the hardest thing about a one-person company is content output. It isn't. AI has already crushed the marginal cost of writing to the floor. What actually eats your time is the repetitive labor of pushing the same piece across a dozen platforms: log in, paste, fix formatting, upload the cover, edit the tags, publish, log it. Five minutes per platform, eight platforms, forty minutes — every single day. This labor has one especially miserable property: it creates no new value. It's pure hauling of things that already exist from one place to another. And yet you can't skip it — no distribution means even great writing goes unread. So when you work alone, the first thing to industrialize isn't "write faster." It's "hand the entire distribution chore — the certain, repetitive, judgment-free part — over to the machine." A central dispatcher plus plug-in channels I didn't build one giant "fully automatic publisher" for this. Those look great in a demo, but they're a nightmare to change — adding a single platform means touching the whole flow. Instead I split it into two l

There are two ways to work with an AI agent and I had tried both. Write the thing yourself and hand over only the tedious parts. Or hand over the whole task and audit whatever comes back at the end. The first is slow. The second is fast right up until it is wrong, and by then the wrong thing is finished. I expected this series to be about forcing a third option into existence. Nine parts of making an agent follow a workflow it would rather skip. That is not what happened. I never had to enforce it once. The queue that started this had a payload contract nobody had verified, and each phase after that cost me something before it gave anything back. A plan that would not move until the risk register named the provider contract the brief had only guessed at. A build that missed nothing except what my own brief left out. A review that stopped handing back a feeling and started handing back a verdict on every requirement I had already called done. A matrix instead of a trusted green run. A rollback with a name on it before anything got called shipped. And a retrospective that would not let a lesson through until it had checked itself against the trail. Eight parts of that. What I did not expect was which part turned out to be automatic. The Fight I Expected Never Started By the time I finish writing a requirement, I already know roughly what it is going to cost. Most engineers do. You can feel the difference between a one-line fix and something that is going to touch four files and a migration before you have written a single line of it. What I assumed was that the agent could not feel that, and that policing the gap would be my job forever. Reminding it to run the chain. Catching it when it decided a spike was small enough to skip. It has not needed the reminder. Small bugs do not trigger a brief and a plan, and they should not. A standard requirement, a spike, anything long or cross-cutting, runs the full cycle in order. The classification lands where I would have put i

Adding a “Control de Obra” Module to Ventas → Desarrollos (NestJS + Next.js) TL;DR: I built a brand‑new Construction feature (Control de Obra) inside the Ventas → Desarrollos flow, wiring a NestJS controller, a migration for branding_settings , and a Next.js page. While doing that I also fixed the setToken bug that stopped the BrokerDashboard from refreshing its session. The result is a clean, testable API endpoint and a functional UI component that talks to it. The Problem Our product needed a way for sales teams to track the construction status of each development (obra). The UI already had a “Desarrollos” list, but the backend had no endpoint to create, read, update, or delete construction records. At the same time the BrokerDashboard ( apps/web/src/app/portal-broker/page.tsx ) was failing to refresh the user session after a token rotation. The console showed: Error: setToken is not a function at Object.<anonymous> (src/portal-broker/page.tsx:78:15) Both issues were blockers: No API → the UI could only display static data. Stale token handling → users were logged out unexpectedly after a token refresh. What I Tried First I first tried to reuse the existing VentasPropertiesController ( apps/api/src/ventas/ventas-properties.controller.ts ). The controller was already imported in AppModule , but it was dead code (the class had no routes) and its methods lacked the AuthGuard we use across the API. I added a couple of ad‑hoc routes inside that controller, but: The routes conflicted with the existing /ventas namespace. The controller’s @UseGuards(AuthGuard) was missing, causing 401 errors in the browser. The migration for branding_settings was still out of sync, leading to a “column does not exist” error when the new endpoint tried to read branding data. After a few hours of chasing 404s and 401s, I decided the cleanest path was to create a dedicated module for construction and keep migrations in sync. The Implementation 1. Register the new controller in AppModule // a

Automating Multi‑Platform Content Publishing with a Node.js Scheduler TL;DR: I extended the content-automation repo to generate weekly newsletters, Dev.to articles, and platform‑specific markdown in a single CI run. The key was a tiny Node.js scheduler that reads a JSON manifest, writes files, and flips “generated” flags in metadata.json so downstream pipelines know what to publish. The Problem Our content pipeline had three independent manual steps: Write a weekly newsletter markdown file. Draft a Medium article. Publish a Dev.to post. Each step required copying the same body copy into a different folder ( weekly/ , content-automation/medium_* , content-automation/substack_* ) and then manually toggling flags in metadata.json . During a production run on 2026‑08‑08 the CI job failed with a cryptic log line: Error: Conn The truncated message was coming from the Prisma client that our automation script uses to fetch the latest draft from the CMS. Because the script never updated the metadata.json flags after a successful write, the next run tried to re‑process the same draft, hit a stale DB connection, and blew up. In short: the automation was not idempotent , and the state tracking was brittle. What I Tried First My first attempt was to wrap the whole generation flow in a try / catch and, on any error, abort the job without touching the manifest. I added a quick if (fs.existsSync(filePath)) return; guard to each write operation. // naive guard if ( fs . existsSync ( targetPath )) { console . log ( ` ${ targetPath } already exists – skipping` ); return ; } That prevented duplicate files, but it also silently skipped a legitimate update when we intentionally rewrote a newsletter (e.g., after a typo fix). Moreover, the guard didn’t address the stale Prisma connection, so the same Error: Conn kept surfacing in later runs. The Implementation 1. Central Manifest ( metadata.json ) The manifest now lives at content/2026/08/08/content-automation/metadata.json . I added expli

The problem is not a lack of game content Most early game-guide sites begin as broad collections: a release-date post, a few news stories, a list of characters, perhaps a page titled "beginner guide." That structure looks complete in a sitemap but often fails the player who arrives from search with a precise, urgent question. They are not looking for a generic introduction. They are asking: Is the game out in my region? Can I join the playtest safely? Is the PC version confirmed? Does this game actually work like Tarkov, Sekiro, or Stardew Valley? What did the developer confirm, and what is still speculation? I have been building eight small game-guide sites around those moments. The project is an experiment in search-intent publishing : every useful page should answer one query well, show where its information came from, and make its uncertainty visible. The aim is not to create the biggest pre-release wiki. It is to create the most dependable next click. Example of the official-media trail used for Mistfall Hunter coverage. Public media can support a page, but it should never be used to invent mechanics that have not been confirmed. The editorial model: one question, one canonical answer A search-focused guide gets stronger when a reader can tell three things immediately: What the page answers. A release-status page should not compete with a separate news article for the same release-date query. How current the answer is. Status, configuration, test, and platform pages need a visible review date and a concrete update trigger. What is evidence and what is inference. Official store pages, developer announcements, and official videos form the baseline. Public footage is useful but does not prove every system detail. Community testing can be valuable, but it must be labelled and dated. This sounds obvious, but it changes the content plan. I do not add a new URL merely because a keyword has a close variant. I first ask whether a stronger existing page can be updated, l

When people think of Artificial Intelligence, they usually think of chat boxes. You type a prompt, text scrolls across the screen, and you copy-paste it. In the legal world, a chat box isn't enough. A contract on a screen is just a suggestion. A contract in hand—signed, sealed, and cryptographically verified—is a binding asset. As we build Lawyie (Sunverse AI’s intelligent legal infrastructure for Africa), one of our core mandates was moving beyond the chat interface. We needed a Document Factory. Here is the engineering breakdown of how we built an in-memory PDF generation pipeline that creates cryptographically-sealed legal documents in Python. 1. The Problem with Standard File Writing In standard Python web apps, saving a file usually means writing it to the local hard drive and then serving it. In a cloud environment like Streamlit Cloud, doing this at scale causes concurrency issues (multiple users overwriting the same contract.pdf file) and unnecessary disk read/write latency. The Solution: Everything must happen in-memory. 2. The In-Memory Buffer ( io.BytesIO / Byte-Streams) Instead of saving a file to the disk, we use Python’s io module to capture the PDF output directly as a byte-stream and feed it straight into the user's browser download button. Here is how the pipeline works using fpdf2 : from fpdf import FPDF import io def generate_legal_pdf ( contract_text , signature_id ): # 1. Initialize the PDF engine pdf = FPDF () pdf . add_page () pdf . set_font ( " Arial " , size = 11 ) # 2. Clean text (Handling special characters for Latin-1 encoding) clean_text = contract_text . replace ( " ₦ " , " NGN " ). replace ( " — " , " - " ) final_content = f " { clean_text } \n\n SECURE HASH ID: { signature_id } " # 3. Write to the document pdf . multi_cell ( 0 , 10 , txt = final_content ) # 4. Capture the output as bytes (Crucial for fpdf2) pdf_output = pdf . output () pdf_bytes = bytes ( pdf_output ) if isinstance ( pdf_output , bytearray ) else pdf_output return pdf

I’ve always liked the visual language of heraldry: shields, animals, symbols, colors, banners, and mottos that can tell a whole story in a single image. The problem is that creating a good coat of arms from scratch usually takes either design experience or a lot of time. So I built Coat of Arms Maker , an AI-powered tool that turns a plain-language description into an original heraldic design in seconds. 👉 Try it here: https://coatofarmsmaker.org/ What can you create? The tool works well for: Custom family-inspired crests Fantasy houses and kingdoms Tabletop RPG characters and campaigns Gaming clans and guilds Fictional organizations Personal emblems and decorative artwork You describe the symbols, colors, mood, and style you want. The generator interprets the brief as one coherent emblem and produces a polished design without requiring you to learn a complicated graphics editor. For example, you could ask for: A dark medieval shield featuring a silver wolf, a crescent moon, blue accents, and a banner representing courage and loyalty. Why I think it’s useful Most general-purpose image generators can make something vaguely heraldic, but getting the composition to feel like an actual emblem can take repeated prompting. I wanted the experience to be focused: describe the crest, generate it, and get a result designed around the conventions of heraldic artwork. The goal is not to replace official heraldic research or create a legally granted coat of arms. It’s a creative tool for people who want an original visual identity for a story, game, community, project, or family-themed gift. Built for non-designers There are no layers to manage and no complex controls to learn. If you can describe the idea, you can create the emblem. I’m continuing to improve the generator and would genuinely appreciate feedback from designers, fantasy writers, indie developers, and tabletop players. Give it a try and let me know what you create: 🔗 https://coatofarmsmaker.org/ If you have sugges

Inside the NEXUS AI App Builder: an agentic full-stack workspace, not a code generator Published: August 4, 2026 Category: AI Builder Reading time: 11 minutes Author: NEXUS AI Team Most "AI app builders" do one thing well: turn a prompt into a first draft. Ask for a second change, a real database, or a form that actually submits, and the illusion breaks. You are back in a normal editor, debugging code nobody on your team wrote. The NEXUS AI App Builder is built around a different assumption: the first draft is the easy part. The workspace has to survive edit five, edit fifty, a broken build, a schema change, and a handoff to a teammate or another AI agent, without you ever leaving the conversation. This post walks through how the Builder actually works: the agentic edit loop, the two ways to preview a change, visual iteration, sharing and remixing, the MCP handoff that lets coding agents use it directly, and how a Builder project becomes a deployed production app. What most AI builders actually give you Tool type Generates Stops short of One-shot text-to-code A first draft from a single prompt Verifying it runs, fixing its own errors, a second coherent edit Chat-based code snippets Functions and components you copy in Anything outside the snippet: routing, schema, deployment Visual UI builders A styled interface Real backend logic, a database, form submission that persists data NEXUS AI App Builder A real Next.js and Prisma app, verified, previewed, shareable, deployable Nothing on this list. It is the full loop, in one workspace. The pattern in the first three rows is the same: something hands you code, then the responsibility for making it actually work lands back on you. The Builder is built to keep that responsibility on the agent for as long as possible. It edits files and verifies its own work The Builder is not a single prompt-to-code call. It is an agent with bounded file tools that reads and edits your actual project files, the same way a developer would. Y