标签：#indie

I've shipped 4 Chrome extensions and 2 VS Code extensions. The advice that always sounds smart — "find a popular extension the dev abandoned, rebuild it better" — is miserable in practice. You open the Web Store, see 100k users and a 4.4 rating, think you found gold, then burn a weekend reading reviews only to realize half the complaints are unfixable traps (sync died, login broke, backend gone). So I built a small pipeline to do the boring part automatically. The method Scrape public Chrome Web Store metadata — users, rating, last-updated date. Filter: 20k–300k users, 18+ months without an update, rating 3.3–4.4 (good enough to prove demand, bad enough to prove pain). Pull up to 50 recent reviews per candidate via public CWS data. Score each one: score = log10(users)10 + months_stale0.5 + feature_request_count2 - trap_count1.5 The key part is trap_count — I subtract points for complaints about sync/login/server issues, because those are unfixable without inheriting someone else's dead backend. High "demand" with high trap count is a mirage. One example Extension Manager — 100k users, 4.4★, last updated ~25 months ago. Looks healthy until you read the 1–2★ reviews: "The site-specific rules feature simply does not work… the core feature advertised is broken." "It won't save any changes made… extensions are re-enabled automatically." A user even posted an RCE report: the dev parses JSON with a Function(str)() fallback — executing arbitrary code from untrusted input. That's not "build a clone." That's "fix the rules engine, kill the eval, add local backup, ship something 100k people already want." The counterintuitive part The highest-scoring extension in my list (200k users, abandoned ~4 years) is actually the worst business opportunity — it's a simple toggle utility whose users will never pay, and the original asks for camera/mic permissions (adware-grade). Raw download counts would put it at the top of your build list. Revenue potential buries it. That gap between "

I take a lot of screenshots. The article I'll read later. The recipe I'll cook on Sunday. The movie name from someone's Instagram story. A job post, a product, a tender. Most of them die in my camera roll. So I built Chista — an iOS app that auto-imports every screenshot, classifies it with AI (Article, Product, Event, Reference, Media), and surfaces a one-tap action: Buy on Amazon , Add to Calendar , Reserve on OpenTable , etc. It shipped on the App Store thirty days after I started, for about $300 in total cost. The interesting part wasn't the app. It was what the build revealed. What I built Chista is a native iOS app + Python backend. iOS reads new screenshots in the background via PHPhotoLibraryChangeObserver , scoped to PHAssetMediaSubtype.photoScreenshot (so it literally can't see your other photos). Each new screenshot gets OCR'd on-device with Apple Vision , then the image + OCR text get POSTed to the backend. Backend sends the pair to OpenAI GPT-4o with a structured prompt that returns a CategorizationResult JSON: category, subtype, title, suggested action, extracted data (price, deadline, URL, etc.). Result gets persisted and pushed back to the inbox via Supabase real-time. That's the whole thing. The "magic moment" is just: you screenshot something, switch to Chista a few seconds later, it's already sorted with a contextual action button. Stack Layer Tool Why iOS app Swift 5.10, SwiftUI, StoreKit 2 iOS 17+, modern surface Backend FastAPI on Railway One-file ergonomics, fast cold starts Database + Auth Supabase Postgres + JWT auth out of the box AI OpenAI GPT-4o (Pro), gpt-4o-mini (Free) Tier-routed at categorization time Push APNs via aioapns Direct, no Firebase middleman Subscriptions StoreKit 2 + app-store-server-library Server-side JWS verification Affiliate routing Custom matrix in Supabase tables Amazon Associates wired, more pending Hosting (web) Cloudflare Pages Free, fast, never goes down No frameworks I wouldn't reach for again. What it cost Lin

The thing I'm building, App Store Analyzer, is a website that does one thing: it reads an iOS niche and writes a deep market analysis for indie devs. For a long time that analysis had one brain — and it spoke German. That made sense at the start. German is my home market and my own language, so I built the analysis logic in German first. I could actually feel whether the output was good or garbage, section by section, because I was reading it in the language I think in. It got deep. Reliable. I trusted it. Then it started to hurt. Every time I wanted the analysis in another language, I was basically running the whole expensive thinking step again from scratch. German code, German slugs, German routes, German everything — and a goal of serving 14 languages. The whole thing fought itself. So I rebuilt the brain in English. Not "translated the code" — rebuilt the canonical brain so English is the one source of truth. Now the engine thinks once in native English, and that single analysis gets translated and cached into 13 other languages . Generate once, translate many. It was not a clean ride. The lows. A refactor left a pile of undefined names and quietly 500'd my detail pages — live, in production, while I thought everything was fine. I misread a normal cache warm-up window as a dead backend more than once and "fixed" things that were never broken. I spent an embarrassing stretch hammering an endpoint with a wrong key, watching 403 scroll by, before realizing my terminal had eaten the line that set the key. Small things. Hours each. The highs. Two of them I didn't expect: It got cheaper , not just cleaner. I'm not paying for a full deep analysis per language anymore — one real generation, then lightweight translations. For a solo dev watching every API cent, that's the whole game. And the English brain was actually sharper . I ran the old German output against the new English one side by side, fully expecting English to be the weaker copy. It wasn't. In a few section

You’ve spent weeks, maybe months, tracking down bugs, optimizing your user interface, and wrestling with backend security rules. You compile your native release build or run your final production compilations, thinking the hardest part of the journey is officially behind you. Then you open the Google Play Console, and you’re hit with the ultimate indie developer roadblock: the mandatory 12-tester and 14-day closed testing requirement . Many independent creators view this process as a simple download checklist. You might think, "I'll just find 12 people to download the app, leave it on their phones for two weeks, and wait it out." However, treating the testing phase as a static metric is the fastest way to get rejected during the final production access review. So, what is Google actually tracking in the background during these two weeks? Let’s take a deep dive into the core algorithmic requirement that determines your success: Continuous Engagement . 🔄 Decoding "Continuous Engagement" Google Play policies are not designed as a simple box-checking exercise. The underlying goal of the algorithm is to verify if your application is genuinely functional, stable, and being tested by an organic user base before it reaches millions of production users. To enforce this, Google's advanced systems actively monitor the devices connected to your closed test track over the 14-day timeline: Background Device Pings: Google Play Services regularly collects background automated signals (ping logs) from the devices where your test build is active. Real User Interaction: Leaving an app to rot in an application drawer without ever opening it is instantly flagged by the algorithm. Google measures whether the app is actively opened daily and tracks active interaction metrics within the build. Feedback Loops: The system monitors whether your test community is utilizing the internal testing channel on the Play Store to send private developer feedback and crash reports. 📉 The Illusion of "Ju

I run a couple of small niche sites — a pet-health tool and a travel-info site. The thing that actually moves the needle for both isn't clever copywriting. It's having a lot of pages that each answer one specific, low-competition question. "Puppy vaccine schedule by breed." "Is [neighborhood] worth visiting." That kind of thing. This approach has a name: programmatic SEO . You take a data set (one row = one page), pour it into a template, and generate pages at scale. Done well, it's how directories, comparison sites, and tool sites quietly rank for thousands of long-tail terms. Done badly, it's a spam farm that Google buries. More on that later, because it matters. The problem: the tooling is either expensive or a Rube Goldberg machine When I went looking for a way to do this without hand-coding every page, I found two camps: Agency-grade SaaS — powerful, but priced at $99–$299/month . That's a lot of money to spit out HTML when you're a solo operator running sites that make beer money. No-code stacks — wire a spreadsheet to a CMS to a static-site generator with a couple of automation tools in between. It works, but now you maintain a fragile chain of four services, and your pages live inside someone else's platform. Neither felt right. I just wanted: spreadsheet in, clean HTML out, files I own. What I actually built (for myself, first) So I wrote a generator for my own sites. Every morning it reads a CSV, applies a template, and produces a folder of static HTML pages — each with valid JSON-LD, proper meta tags, an internal-link hub, and a sitemap. I deploy the folder. Done. After running it daily for months on my own properties, I cleaned it up and turned it into a product: PageForge . The core idea is deliberately boring: CSV + template → a ZIP of clean static HTML pages you own. No dashboard you have to log into forever. No lock-in. The output is just files. If you stop using PageForge tomorrow, your pages keep working because they're plain HTML sitting in your r

I just launched Kotobato on Google Play after about two and a half years of solo development. It's a word puzzle RPG — you swipe connected letters on a board to form words, and those words become attacks. Longer words deal more damage. Rarer words hit harder. I want to share what I built, why I built it this way, and what surprised me most during development. The core mechanic The board is a grid of letters. You swipe a path through connected letters to form a word. When you submit the word, it becomes an attack against the enemy. The twist: word length isn't the only thing that matters . The game has six elemental types — Animal, Nature, Knowledge, Food, Life, and Fantasy — and each word is categorized into one of these elements. Enemies have elemental weaknesses, so the right word beats a long word if you're hitting a weakness. This created an interesting design problem. In most word games, you're just maximizing point value. In Kotobato, you're making tactical choices: do I use a short word that hits a weakness, or a long word that deals raw damage? Why hiragana and English both work The game runs in both Japanese (hiragana) and English. This wasn't a late addition — it was part of the original design. Japanese hiragana is a syllabic script with 46 base characters. Because each character represents a whole syllable rather than a single phoneme, even short hiragana words feel phonetically "weighty." A 4-character hiragana word might correspond to an 8-letter English word in spoken syllables. This means the game feels different in each language — not just translated, but genuinely different. Japanese mode rewards knowledge of vocabulary that uses phonetically distinctive combinations. English mode rewards knowledge of unusual high-value words (think quixotic , ephemeral ). What I actually built 100-floor tower with escalating bosses, including historical Japanese figures like Oda Nobunaga and Toyotomi Hideyoshi Gacha character system — collectible characters with d

The most expensive mistake of my career wasn't a line of code; it was a 'yes'. That 'yes' not only cost me money but also severely damaged my reputation, which I had built over years. This was a turning point I experienced when my personal project, which I proudly worked on and named "BurnCPU," reached its first 100 users. Today, with 20 years of system architecture and operations experience, I can clearly see the decisions I made back then and the lessons I've learned since. This post is not just a technical error analysis; it's also an intention to share a pragmatic decision-making process, trade-offs, and the courageous stance of an expert. My goal is to spark discussion, encourage thought, and perhaps help you avoid similar mistakes. When Did That 'Yes' Come? BurnCPU was initially a tool I developed for my own needs, aimed at optimizing server resources. The goal was to reduce costs by efficiently utilizing idle CPU time. The development process was enjoyable and, over time, exceeded expectations. When the first beta users started giving positive feedback, my excitement was at its peak. And then the moment arrived; an investor, during this period when my project reached its first 100 users, offered financial support for a major scaling and marketing push. The offer was tempting. It presented an opportunity to reach wider audiences, add more features, and perhaps even commercialize the project. The person opposite me was introduced as a recognized and successful name in the industry. Without delving too deeply into the details of the offer, I said "yes." This simple word marked the beginning of the most expensive mistake of my career. ⚠️ A Risky 'Yes' When making this decision, I did not sufficiently analyze the technical maturity of the project or whether my infrastructure could handle such a load. I overlooked the chasm between the marketing power promised by the investor and my technical infrastructure. After the First 100 Users: Unexpected Problems When we re

Hey. No new feature this time - just a pass through the corners before the next one. We had a list of nine bugs we'd written down and kept walking past. Most were small. One wasn't, and it was hiding behind a button. When you import a file the studio already has - same bytes - we ask whether to share the existing file or make an independent copy you can edit on its own. Pick "independent copy" and you expect exactly that: your own file, safe to change or delete without touching anything else. It mostly worked. But the new copy's internal name was built from how many copies already existed - copy 2, copy 3, and so on. The problem shows up after a delete. Say you had three, removed the middle one, then made another. The new one counted "two exist, so I'm number three" - but number three was already taken. The studio saw the clash, quietly kept the old file, and pointed your new scene at it. You thought you'd made a clean copy; you were sharing the original, and the real copy you just made was orphaned on disk with nothing pointing at it. Edit "your" copy later and you'd be editing the original too. Nothing crashed. Nothing warned you. That's the worst kind. The fix: stop counting, and instead look at which names are actually taken and pick the first free one - so a copy made after a delete always gets its own identity. We also made the studio shout in the logs if two files ever collide again, instead of silently dropping one. Better a loud bug than a quiet one. The rest were smaller. A menu element could jump for a single frame when you grabbed it (the drag started from where the element was saved , not where it was shown ). A countdown number sat blank for one frame before popping in. And the end screen had a leftover timing delay we fixed - which you'll never see, because that screen is solid black either way. Real bug, just invisible. The one we'd marked most important? We went to fix it and found a rebuild from two weeks ago had already solved it. We checked three

Six months into running my SaaS, my "feedback system" was three browser tabs, a starred Gmail folder, and a sticky note on my monitor that said "check Discord." That was the whole system. It held together until the day I found a three-paragraph email from a paying user — a genuinely detailed feature request with a real use case — sitting unread for 24 days. His last line was: "Happy to pay more if you can support this." I replied the same afternoon I found it. His reply: "Switched last week, thanks anyway." That was the moment I stopped treating feedback management as a nice-to-have. Why the usual fixes didn't fix anything I tried the obvious things first. I want to document them because I see a lot of people cycling through the same failed solutions. Notion database 🪦 Built a beautiful one. Color-coded tags, priority columns, status tracking. It lasted 11 days before nobody — including me — was maintaining it. The friction of "open Notion, find the right database, fill in six fields" is invisible when you're designing the system and fatal when you're in the middle of a support conversation. Airtable form 🪦 Better entry point, still disconnected from where users actually were when they had feedback. Nobody bookmarks your Airtable form. They DM you on Discord and you think "I'll add that later" and you don't. Canny — this one actually worked, for a while I genuinely liked Canny. Clean interface, users could upvote requests, I could see what was popular. It felt like a real system. Then our user count grew and the pricing tier jumped. I was looking at $99/month for a feedback board for a product still finding its footing. That's not a moral judgment on Canny — it's a fair product — but for a bootstrapped indie dev, it started feeling like a tax on momentum. The deeper problem with all three solutions was the same: they were inboxes, not loops. User submits → enters the void → user never knows if anyone saw it → user assumes nobody did → trust erodes → churn. I had bui

Every "what should I build" thread on here is full of AI wrappers fighting over the same five SaaS founders. Meanwhile there's a guy sitting at a loading dock right now, doing arithmetic in his head, who is about to undercharge his broker by a few hundred bucks because nobody built him a 30-second tool. I built that tool. It's a free detention-pay calculator for truck drivers. This is the build log — the niche-selection, the single-file stack, and two decisions (an SVG gauge and a no-mail-service auth scheme) that were more interesting than the app deserves. I'm not a trucker. I build small free web tools for industries other may find unglamourous or not enticing enough. That honesty matters later. The problem (worth $2–6k/yr to one user) Truckers get a "free time" window at a dock — usually 2 hours. Past that, the broker owes detention pay (~$50–100/hr). Drivers leave an estimated $2,000–6,000/year of it unclaimed, mostly because the math + the paperwork is annoying enough to skip. So the spec wrote itself: In/out times + free hours + rate → dollars owed. Export a dispute-ready PDF they can email the broker. Work on a phone, no login, instant. Validating before writing a line The mistake I almost made: assume the niche is empty because I'd never heard of it. I checked. It is not empty — DockClaim ($49/mo, GPS tracking), Detention Buddy, a couple of $9.99/mo App Store apps, even a free email-gated web calculator or two. That killed my first instinct ("be the only one") but clarified the real wedge: everything is a paid app download or email-gated. The opening was a genuinely free, no-signup, instant web version that also generates the claim PDF. Not "the only detention tool" — the one with the least friction. I'll say more on why I'm careful about that claim at the end. Lesson: validate to find your angle , not just a go/no-go. "Crowded but all friction-heavy" is a fine market. The stack: one HTML file No framework. The whole app is a single self-contained .html — m

Started propfirmpinescripts.com a while back selling pine script strategies for futures prop firm traders. Figured I would share some of what worked and what has not. The problem I was solving I was actually trading on Apex myself and kept running into the same thing. Every pine script strategy I found online was not built for prop firm rules. Daily loss limits not enforced in code. No end of day flatten. Blew an evaluation partly because of it. Figured other traders had the same problem. Coded the rules myself, then decided to sell the scripts. What I built Pre-built pine scripts for 4 instruments: GC (gold futures), MES (micro S&P), MNQ (micro Nasdaq), CL (crude oil). Each one has daily loss lock, EOD flatten, win lock coded in. You can configure the limits for different firms without touching the core logic. Priced at $50 for a single script or $150 for all 4. What actually moved conversions Adding real payout screenshots. Like actual Apex payout certificates from traders who passed using the strategies. Before I did that — traffic but weak conversions. After — noticeably better. Prop firm traders do not trust backtest results at all anymore. Too many people have gamed them. A real funded account payout is the only thing that actually means something to them. Where things are at Still early. Revenue is real but small. Building more SEO content, getting into prop firm communities, and eventually a subscription tier for updates when firms change their rules. If you are a dev with trading knowledge this space is underbuilt.

Most indie hackers I know spend an embarrassing amount of time on the naming part. We argue with ourselves over the perfect .com, eventually settle for some janky combo of words with random consonants ripped out, and ship a domain we secretly don't love. There's a quieter option a lot of builders haven't seriously considered: .Vegas. It's a geographic TLD, but it does NOT require you to be in Las Vegas or build anything Vegas-related. What it does give you is a TLD that sounds bigger than it costs, reads as memorable, and is still wide open in 2026. I went down a small rabbit hole this week looking at side-project ideas that would have an almost unfair head start on .Vegas. Here are five. 1. A weekend trip planner Domain: weekend.vegas or trip.vegas This is the lowest-hanging fruit and I'm honestly surprised nobody's built it yet. A tiny webapp that takes a Friday-to-Sunday window and spits back a fully booked itinerary: flight, hotel, two restaurant reservations, one show, one activity. Three clicks, done. Why it works on .Vegas: the domain is the elevator pitch. Nobody needs to read your tagline. The URL bar tells you what the product does. That's worth more than most landing-page copy will ever earn. 2. A bachelor/bachelorette party coordinator Domain: bach.vegas , party.vegas , last.vegas Group-trip coordination is genuinely awful. Splitwise + a group chat + a shared Notion doc + that one friend who keeps forgetting to Venmo back. There's room for a niche product here that handles the deposit splits, the "who's in for the cabana" upsells, and the inevitable last-minute flight changes. Why it works on .Vegas: the URL doubles as a tagline. You don't have to explain what kind of trip it's for. 3. A booking aggregator for shows and residencies Domain: shows.vegas , tonight.vegas Caesars, MGM, Live Nation, AXS, Vivid Seats, the venue's own ticketing system — finding a good show on a specific Tuesday night is a pain. A scraper-backed booking aggregator that's honest a

Every week another "AI agent for X" launches. Email triage. Calendar coordination. Sales follow-up. PR reviewer. Slack monitor. Meeting summarizer. I've installed enough of them to see the pattern. Here's the dirty secret nobody mentions in the launch posts: These tools don't reduce your work. They multiply your notifications. Each AI tool is configured to be helpful by default. "Helpful" means: "I noticed this thing — here's a notification." Stack a dozen of those, and instead of one inbox to ignore you have twelve. The signal-to-noise ratio gets worse every time you add an AI to your workflow. The mainstream answer is "just configure each one." Sure. Spend four hours tuning notification settings every time you add a tool, and another four hours when one of them ships a "smarter notifications" update. That's not productivity. That's notification janitorial work disguised as setup. This is a structural problem. Not a configuration problem. The wrong question Every AI tool asks the same thing: "Is this important?" Wrong question. There is no objective "important." Importance depends on you, right now. A Stripe webhook is important when you're debugging a checkout flow. The same webhook is pure noise during a deep work block. A Slack message from your cofounder is critical at 11am Tuesday and irrelevant at 11pm Friday. The right question is: Is this urgent enough to interrupt me, right now, given what I'm doing? That's not a question any individual AI agent can answer. It's a layer above all your AI agents. None of them have the context. None of them know what the others are doing. None of them know how you're spending the next hour. So they all default to "I'll just send you a notification, you decide." Which is exactly the experience you have right now: drowning. What an AI firewall actually looks like I'm building that layer. It's called Klorn . Here's how it works in practice. Every signal — email, calendar invite, agent action, webhook, push from another tool — g

When Mozilla shut down Pocket in July 2025, I lost my favorite tool. Worse, none of the English alternatives (Instapaper, Readwise, Matter, Raindrop) had Japanese UI, and their article extraction was mediocre on Japanese pages. So I built one. It's called Readbox — Japanese-first, English-too, read-later as a PWA. Here's what I learned shipping it. The stack Next.js 15 App Router + TypeScript strict (no any ) Supabase (Postgres + Auth + RLS) Stripe (JPY + USD prices, locale-routed) Tailwind CSS Service Worker for PWA install + offline read Three things that bit me 1. Article extraction on Vercel serverless First attempt: Mozilla Readability + jsdom. Doesn't bundle on Vercel because of ESM compatibility issues and the 50MB serverless function size limit. I tried 6 approaches — Webpack externals, dynamic imports, edge runtime — none worked cleanly. Ended up using Jina Reader , which returns clean Markdown/HTML from any URL. Trade-off: third-party dependency, rate limits at scale. But it works today, and it's free. 2. Storing article body on-device I didn't want to host millions of articles' worth of HTML on Supabase (cost + privacy). Solution: extracted HTML lives in the browser's IndexedDB only (via Dexie); only metadata (URL, title, tags, read status) syncs to the server. Trade-off: cross-device sync of body content doesn't work seamlessly. Acceptable for a "read it later" workflow where you usually read on the device you saved on. 3. i18n routing — the silent sitemap killer For Japanese + English from one codebase: app/[locale]/ segment with /en prefix for English (default Japanese has no prefix, to preserve old URLs). Middleware detects cookie / Accept-Language and redirects accordingly. The gotcha (cost me a launch-day hour): middleware matcher excludes _next , api , image extensions — but if you forget .xml/.txt/.webmanifest , sitemap.xml and robots.txt get rewritten to /ja/sitemap.xml (which doesn't exist as a route → 404). Fix: export const config = { matcher