标签：#buildinpublic

Most of what you read about autonomous agents is about giving one a goal and hoping it doesn't go sideways on the way there — the unwatched agent that loops, or drifts, or quietly runs up a bill. I wanted the cleaner version of that question, with the goal taken out entirely: what does an agent do when there's no goal at all? I've spent about four months building a harness around a coding agent — gates, persistent memory, verification hooks. Last night I ran it with the one variable that matters here set to zero: no task. Method Three sequential runs: Each run was a fresh agent process — no conversation history carried over from the run before, only the harness it loads at startup. The prompt was a single "." — the minimal input the CLI accepts (an empty string exits with an error). As close to "no instruction" as the interface allows. The agent's scratch working directory was empty and swept between runs — but the harness, the git repo, and a shared run-record all persist and load at startup. So no run was handed a task, yet a later run could read what earlier ones had recorded. That's deliberate, and it's the point: it's how Run 2 knew it was the second run and Run 3 could check Run 2's fix. What I'm measuring isn't behavior from a blank slate — it's what the agent does with a maintenance-shaped harness and a shared record when nobody gives it a job. No task was assigned. Logging was external and invisible to the agent, so it had no "produce a report" objective to satisfy. Same model each run. Cost was billed per run; I recorded turns, cost, and the resulting git state for each. Then I read the transcripts and checked every action against the actual commit and log. Numbers below are measured, not estimated. Results Run 1 — 17 turns, $1.65. The agent inspected system state unprompted. It found a stale security alert, cross-checked it against the record, and classified it as an already-resolved false positive. It then attempted a file operation that a safety gate bl

Hello everyone! 👋 Happy to be joining the DEV community. I’m a Computer Engineering student based in Italy. My main focus is Cybersecurity, but I strongly believe you have to know how to build a system before you can secure (or break) it. Lately, I’ve been jumping between two very different worlds: Embedded C: writing firmware, managing file systems, and building custom OLED menus for the M5Stick S3. Frontend: building web apps using Next.js and React. My workflow is a bit of a hybrid. I like to focus on the system architecture, memory management, and edge cases, while using AI tools to do the heavy lifting of writing the actual code. Then, I review everything strictly to make sure it doesn't break. I’m here to build in public, share my projects, and learn from this awesome community. What are you all currently hacking on? See you around!

A few weeks ago I wrote about hitting ReAct in the coursework and having a record scratch moment, because I had already met it without knowing its name. That post ended on a section called "Building Ahead of Understanding," which was me making peace with shipping things before I fully understand them. This week I shipped my first chatbot. It passed on the first attempt, on deadline day, on a project where the rubric was grading a product AWS had already discontinued. And I spent most of that day quietly worried that it did not count. Let me be clear about what the worry was, because it was not about cheating. Using AI agents to build a coding project is allowed here. I asked before I started, I got a yes, and I disclosed the whole arrangement in my README, including a section that names what each tool did and what I did. Nobody was misled about how this got built. The worry was smaller and more personal than that. I still did not type the code. My agents did. I directed, I validated, I decided, and underneath all of it was a small voice asking whether directing is the same as knowing. Whether a person who cannot write a Bedrock call from memory gets to say they learned Bedrock. Here is what I found out. The starter files were a generation behind the instructions Some context on where this came from. AWS AI & ML Scholars is a program AWS runs with Udacity, open to anyone 18 or over with no prior experience required. Everyone starts in a Challenge phase built on the AWS Certified AI Practitioner material, and the top 4,500 finishers get a fully funded nanodegree in one of three tracks: AI Programmer, Agentic AI Business Professional, or Agent Developer. I am in Agent Developer, the Bedrock AgentCore and multi-agent systems path. This chatbot is the first of its three projects. The project is a customer support chatbot on the Amazon Bedrock AgentCore managed harness. Three routes, one system prompt. A bug report gets collected across turns and filed to DynamoDB through

I got banned from SoloLearn for trying to help beginners. Here's what happened. Yesterday, I was on a mission. I'm Harun, a 12-year-old solo dev who built KODA , an AI coding mentor, entirely on my Android phone. I noticed hundreds of beginners on SoloLearn asking: "How do I start?" , "Help me with loops!" , "I'm stuck!" So I did what any helpful founder would do: I answered their questions, gave them code solutions, and added a small P.S.: "P.S. I built a free tool called KODA to help with this. Try it here: [Link]." I thought I was being helpful. SoloLearn's algorithm thought I was spamming. Within hours, my account was blocked. 🚫 The Moment of Panic When I saw "Your account is blocked," my first thought was: "Oh no, I messed up. My marketing is over." But then, my CEO brain kicked in. I realized: If an automated bot thought my helpful comments were "spam," maybe I was doing something right. Maybe I was being too effective. The Lesson: Marketing vs. Helping Here is what I learned in 24 hours: Algorithms hate links. Even helpful ones. If you paste a URL 10 times, the bot doesn't care about your intent; it sees a pattern. Trust takes time. You can't force users; you have to earn them. The Story > The Link. People don't click links because they are forced to. They click because they connect with the story . The Pivot So, am I quitting? No. I'm pivoting. I'm turning this ban into this article. I'm going to focus on Dev.to , where the community values "Build in Public" stories. I'm going to ask my friends (Renuka, Dharaneesh) to be my first real users, face-to-face. And maybe, one day, I'll go back to SoloLearn with a smarter strategy: No links in comments. Just value in the bio. To Other Founders If you get blocked, rejected, or told "no" today: Don't stop. Turn that hurdle into content. Turn that rejection into a lesson. Turn that "Blocked" screen into your next viral post. Because while others see a wall, I see a story. And stories build empires. Try KODA anyway (no

What I Built HalfAdder, FullAdder, Add16, Inc16, And ALU. How I Solved Like when I built logic gates, I started with analyzing truth table of HalfAdder , FullAdder . HalfAdder was really easy. After looking at the truth table, I could map the sum and carry outputs to logic gates pretty quickly. FullAdder was also not hard since it's really similar to HalfAdder except that it can add 3 bits. I realized that I could build it by combining some chips and logic gates I had already made instead of designing everything again from scratch. Once I finished building them, I was also able to build Add16 . At first, I had no idea how to sum all the 16 bits. But I soon realized that I could build a 16-bit adder by combining the smaller adders I had already built and passing carry information to the next bit. It looks not beautiful, but still works. And about Inc16 , it's basically add exactly 1(0000000000000001) . So I could easily build it using Add16 . (But I did something weird at first.. check the Reflection below) ALU was the core part of project 2. Once I realized that Mux can be used as if , I could make proper outputs using logic gates. ALU is also a combination of logic gates and chips, after all. What I Learned How to build basic chips using logic gates and already-built chips Why I should reuse the chips for another chip(check the Reflection section below) Mux can be used like if How to use bit slicing and fan-out in HDL and why it's important Reflection Before I started this part, I didn't know two things: I could use bit slicing and true , false for each bit. So when I first tried to build Inc16 , it looked really weird, since I calculated all the bits one by one. It's not logically wrong. But not beautiful either. I was not sure if it was right or not. Then I realized that I already built Add16 . But I had no idea how I could use it to add exactly 1(0000000000000001) . After googling, I realized that I could use bit slicing like Python's list slicing and construct

I'm a business student, not a developer. I shipped a working SaaS product in 10 days with Claude Code. (Draft for dev.to — edit anything that doesn't sound like you, then publish. Suggested tags: #ai #nextjs #supabase #buildinpublic) Ten days ago I couldn't have told you what a webhook was. Last night I published quidkit — a Next.js + Supabase + Stripe starter kit with working auth, subscription billing, and documentation — and this morning I'm writing this from holiday. I study business management. I'm not a CS student. I can't really "code" in the way that word usually means. What I can do, it turns out, is manage a very fast, very literal developer that lives in my terminal — and that changed what's buildable for someone like me. This is the honest write-up: what I built, how the AI workflow actually looked, every bug that nearly got me, and what it cost. What I built quidkit is a starter kit for developers building subscription apps. The pitch: before anyone can pay you monthly for your app idea, you need the boring foundation — accounts and login, taking payments, knowing WHO paid, emails that send themselves, security so users can't see each other's data. That's 2–4 weeks of tedious work that isn't your idea. quidkit is that foundation, pre-built: clone it, rename it, build your thing on top. Stack: Next.js 16, React 19, Tailwind v4, Supabase (auth + database with row-level security), Stripe (checkout, customer portal, webhook sync), Resend (email). Live demo at demo.quidkit.dev — you can sign up and "pay" with Stripe's test card and watch the whole pipeline work. £29. Because the established kits are £200–£300 and I'm literally the target market: someone without that kind of money. The actual workflow People imagine "AI builds your app" as one magic prompt. It's not. It's closer to being a project manager with one extremely capable, extremely literal employee: I wrote specs, not code. Every session started with me pasting a detailed brief into Claude Code — w

I run TextTimeTools , a free site with speaking-time and reading-time calculators. It's a pure static site deployed to Cloudflare Pages — no backend, no database, no CMS. The calculators themselves are one page. But the site has 50+ pages , each targeting a different keyword like "how many words is a 5 minute speech" or "how long to read 1000 words". Every single one of those pages is generated by a build script. I've never written one by hand. Here's the pattern, and why it's the highest-leverage thing I've done for this site's organic traffic. The problem with a single calculator page A speaking-time calculator answers one query well: "how many words is my speech". But people don't search for tools — they search for answers : "how many words is a 5 minute speech" "how many words for a 3 minute speech" "how long to read 1000 words" "how long to read 5000 words" Each of those is a separate keyword with its own search intent and its own competition. One calculator page can't rank for all of them — a page titled "Speaking Time Calculator" has no reason to show up for "how long to read 1000 words". The classic fix is to write a page per keyword. That works, but it doesn't scale — every new keyword means hand-writing another page, and keeping them consistent is a nightmare. The fix: generate pages at build time The build script ( gen-longtail.cjs ) takes a list of keyword targets and emits a complete, keyword-specific HTML page for each one. The word count pages and reading time pages are both generated this way. const PAGES = [ { minutes : 1 , slug : ' how-many-words-is-a-1-minute-speech ' , variant : ' is-a ' }, { minutes : 2 , slug : ' how-many-words-is-a-2-minute-speech ' , variant : ' is-a ' }, { minutes : 5 , slug : ' how-many-words-is-a-5-minute-speech ' , variant : ' is-a ' }, // ... up to 15 minutes { minutes : 2 , slug : ' how-many-words-for-a-2-minute-speech ' , variant : ' for-a ' }, { minutes : 5 , slug : ' how-many-words-for-a-5-minute-speech ' , variant :

Finding software is easy. Finding the right software is not. Search for almost any category—email marketing, CRM, productivity, design, or AI—and you will find hundreds of options. Every product presents itself as the best choice, while many comparison articles repeat the same features without explaining which users each tool actually suits. That problem inspired me to build PickTool , a platform for discovering and comparing AI and SaaS tools. PickTool is still evolving. I am currently improving its content quality, tool coverage, comparison experience, performance, and SEO structure. This is not a polished launch announcement. It is an honest look at the architecture behind the project and some of the lessons I have learned while building it. What Is PickTool? The goal of PickTool is simple: Help people find the right software in minutes, not hours. Instead of creating a basic directory filled with product names and affiliate links, I want each important tool to include useful and structured information, such as: Core features Pricing model Best use cases Strengths and limitations Ratings and evaluation criteria Alternatives Direct comparisons Related guides and category pages The challenge is that this creates several interconnected types of content. A single product can appear on its own tool page, inside a category, in multiple comparisons, and in articles about the best software for a particular use case. Keeping all of this consistent requires more than publishing isolated blog posts. Why I Chose Next.js and Laravel PickTool uses a decoupled architecture: Next.js powers the public-facing website. Laravel powers the backend, API, database logic, and administration system. MySQL stores tools, categories, ratings, pricing information, and editorial content. I chose this combination because I wanted the frontend and content-management logic to evolve independently. Laravel provides a structured backend for managing relationships between tools and content. Next.js

A chatbot can sound convincing for five minutes without remembering anything. Then you mention the job interview you were stressed about last week, the name of your dog, or a small detail from a late-night conversation. It replies like none of it happened. That is where most "AI companion" demos fall apart. I am building Local Waifu , a desktop AI companion that runs on the user's own Mac or PC. One of the rules I set early was simple: conversations and memories should stay on the machine. No central chat database. No server that needs to be online for the character to remember someone. The rule sounds clean. Building it was not. Saving chats is not memory The first version of memory was the obvious one: save messages. That gives you history, which is useful, but it does not solve recall. A long chat history grows fast. Sending all of it back to a local language model on every message is slow, expensive in context space, and usually makes the reply worse. The model does not need to see every conversation from the last six months. It needs the few pieces that matter right now. If someone says, "I have to take Luna to the vet tomorrow," the character should be able to find that Luna is their dog. It should not need to reread hundreds of unrelated messages about work, movies, and dinner plans to get there. So I treated chat history and long-term memory as different things. Chat history is the recent conversation. It gives the model immediate context. Long-term memory is a small collection of facts, moments, preferences, and relationship details that may matter later. Those memories need to be searchable by meaning, not only by exact words. The memory data stays in SQLite I wanted the app to work without a hosted database, so the storage layer is local SQLite. Each character gets their own data. Chats, memories, extracted entities, and relationships are stored locally on the device. If a user creates two characters, one character does not quietly inherit the other one's

On August 19 we launched LeadAce on Product Hunt. It was our first launch to an English speaking audience. I am writing down the numbers while they are still uncomfortable, because the posts I found most useful when I was preparing were the ones that did this. We are a small software company in Tokyo. LeadAce is an outbound sales agent that runs as a Claude Code plugin. The backend is open source. It has been in Public Beta since the launch. The numbers Product Hunt, 24 hours: 2 upvotes 1 comment, which was mine Day rank #160, week rank #758 3 followers on the product page Signups from the launch: 0. Site traffic for the four weeks up to launch day: 6 active users, 27 page views. Referrers were direct 4, producthunt.com 1, t.co 1. Our X account over the same four weeks: 48 posts, 576 impressions total, 2 link clicks, 2 new followers. So the launch did not fail at the landing page. It failed before that. Almost nobody arrived. Where we got stopped This is the part I did not plan for. I spent weeks on the product, the demo video, the gallery images and the copy. Every one of those was ready. What I did not have was accounts. Hacker News. I could not post Show HN at all. HN was limiting Show HN submissions from low karma accounts, and my account had karma 1. I created it years ago and never used it. There is no way to buy your way past this, and there should not be. r/ClaudeAI. My first attempt was removed by automod because the account was too new. I tried again from my older Reddit account, which has an age of 5 years but karma 1. A moderator locked it. The subreddit requires 50 total karma to post a Showcase on the feed. They pointed me to a megathread instead, which is the correct call on their side. My comment there got 67 views and 1 upvote in 19 hours. r/SaaS. The post went through, but Reddit's pre-submit check warned me that it might break the rules on vendor spam. I removed every link from the body and changed the ending to a real question. That version poste

The renewal notice came and I decided to let it go. threadkeeper.io was my first idea and my first website. I bought the domain in August 2025, about six weeks after a community college AI summer camp where I was writing files with names like ccc-ai-pdf-project and describing them in my own README as a beginner Python project. Then I shipped a domain, a blog, a CLI, and a manifesto. Before I let it lapse I went back to look at it one more time. Sentimental. Five minutes, tops. Then I tried to figure out where the source code lived, and realized it did not live anywhere. The site was on Spaceship. I had built it there, in the browser, and never put it in version control. Not once. There was no repo to clone, no local folder, no backup. The only copy of my first website that existed in the world was the one running on a server I had four days left on. The tagline on that site, in cyan, at the top of the page, was "Don't commit without context." I never committed it at all. I did not have the source code to my own website So the first job was not nostalgia. It was extraction. I pulled all eight pages and every asset off the live server before it went dark: the landing page, the blog, three posts, the Dr. Kahlo page, and the Ariadne Clew recap app I built for an AWS hackathon. Nineteen files. sitemap.xml claimed there were four pages, which tells you how much I trusted my own sitemap in 2025. The rest I found by following links. That archive is now public, with a SHA-256 for every original file so anyone can verify nothing drifted in the rescue: earlgreyhot1701d.github.io/threadkeeper-archive It is committed now. A year late. I named a file dom_js.js and did not blink Here is the first thing I found once I could actually read my own code. The Ariadne Clew app had seven JavaScript modules. Two of them were named with snake case and a suffix: api_js.js , dom_js.js , main_js.js . Four were camelCase with no suffix: utils.js , theme.js , exportMarkdown.js , dragDrop.js . Tw

Extending the Login Session to 1 Year for Kiosk‑Mode TV Screens (Next.js API Route) TL;DR: I changed the maxAge of the auth cookie from 30 days to 365 days in src/app/api/login/route.ts . The tweak lets a TV kiosk stay logged in without a daily refresh, while keeping the same security flags. The Problem Our kiosk‑mode deployment runs on large‑format TVs that display a live dashboard. The UI is protected by the same JWT‑based authentication we use for the web app. After a user logs in, the server sets a Set-Cookie header with the token: cookie : serialize ( " token " , jwt , { httpOnly : true , secure : true , sameSite : " lax " , path : " / " , maxAge : 60 * 60 * 24 * 30 , // 30 days }); In practice, the TVs are turned on once a week and are expected to stay signed in for months. After 30 days the cookie expires, the dashboard silently redirects to the login page, and a technician has to manually re‑authenticate the device. The symptom was a 401 Unauthorized error after exactly 30 days, logged as: Error: No valid session cookie found (maxAge expired) The root cause: the maxAge value was hard‑coded to 30 days, which is fine for browsers but not for unattended kiosks. What I Tried First My initial thought was to keep the 30‑day limit and simply refresh the token on every API call . I added a middleware that called the login endpoint silently if a request lacked a valid token. The flow looked like this: // pseudo‑middleware if ( ! req . cookies . token ) { await fetch ( " /api/login " , { method : " POST " , body : storedCredentials }); } What went wrong? Rate limiting – The middleware hit the login endpoint on every request that missed a token, quickly exhausting the auth provider's rate limit. State leakage – Storing credentials on the client (even in a server‑side environment) introduced a security surface. Complexity – The extra round‑trip added latency and made the code harder to debug. After a few failed attempts (and a stack trace full of 429 Too Many Requests )

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

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 🚀