Coder Legion - Recent posts tagged sideprojects

Guaranteed JSON from Claude, and the five parsers I deleted to get it.

Mon, 26 Oct 2026 01:28:37 +0000

My job-search tool had five functions whose only purpose was fixing JSON that Claude had just written. _clean_json_text, _fix_unescaped_newlines, _fix_single_quotes, _strip_markdown_wrapper, _extract_and_parse_json. There was also a sixth, _retry_json_fix, which took the broken JSON and sent it back to the model with a polite request to fix its own mess. I wrote every one of them, one bug at a time, over weeks. I was a little proud of them.

That was the problem.

How you end up with five parsers

JobSearch is my personal tool, in production, single user: me. It ingests job offers from nine boards, and when I press "Analyze", Claude reads the offer against my CV and returns a structured verdict: score, recommendation, career track, the English level the ad actually requires. That verdict has to be JSON, because everything downstream is a database row, not prose.

The first version did what every tutorial does. Ask the model for JSON in the prompt, take response.content[0].text, run json.loads on it. It worked in the demo and then production started teaching me things.

The model wrapped the JSON in markdown fences, so I wrote a function to strip them. Sometimes it used single quotes, so I wrote a function to fix those. Then a description with a line break inside a string, so I wrote _fix_unescaped_newlines. Then a NaN where a number should be. Every fix was five lines, obviously correct, and came with its own tests. I still have the test names in the git history and they read like a confession: test_removes_trailing_commas, test_replaces_nan_with_null, test_replaces_infinity, test_unclosed_fence_still_strips_opening.

By April the parsing layer was around 250 lines with seven strategies, chained, each catching what the previous one let through. The last resort was the AI self-repair call: if nothing parsed, send the broken output back and ask the model to repair it. A second API call, with real latency and real cost, to fix a formatting problem the first call should never have had.

I had a test suite asserting that my code could survive output nobody should ever have produced. That is not robustness. That is a bug report addressed to the wrong recipient.

How do you get guaranteed JSON from Claude with tool_choice instead of parsing text?

You define exactly one tool whose input schema is the shape of the answer you want, and you force it with tool_choice. The model cannot answer any other way, and the JSON arrives already parsed and validated against the schema by the API, not by your code.

Anthropic's API has tool use, and you normally reach for it to let the model call your functions. This is the stricter reading: one tool, forced, and the answer comes back as a Python dict on the response object.

I already had a Pydantic model for the analysis, because the DB row needed one. So the schema was free:

def _schema_from_model(model_cls: type[BaseModel]) -> dict[str, Any]:
    """Produce a JSON Schema from a Pydantic model, suitable for input_schema."""
    ...

response = client.messages.create(
    model=model_id,
    system=system,
    messages=[{"role": "user", "content": user}],
    tools=[{
        "name": "submit_analysis",
        "description": "Return the structured job analysis.",
        "input_schema": _schema_from_model(JobAnalysis),
    }],
    tool_choice={"type": "tool", "name": "submit_analysis"},
)
block = next(b for b in response.content if b.type == "tool_use")
data = block.input  # a dict, parsed by the SDK, no text in sight

The refactor landed on April 14 as one commit: every AI call in the codebase migrated, all five parsers deleted, the self-repair fallback deleted, the garbage-JSON test file deleted with them. The commit message says minus 200 lines and it undersells it, because the lines that left were the ones I had to re-read every time something broke.

It was the scary PR of the batch. I shipped it in the middle of an afternoon where Claude and I pushed thirteen PRs to production, and I wrote about that day separately. Twelve of those PRs were routine. This one deleted a safety net and replaced it with a promise from an API, in the same diff.

One thing I kept: the Pydantic validation after the call. The schema guarantees shape, not sense. A score of 950 on a 0-100 field is schema-valid JSON and still garbage, and model output stays untrusted input no matter how it is delivered. The contract moved into the API; the checking stayed on my side of it.

The surprise came after launch

Here is the part I did not expect, and the reason this piece is not just "use tool use, delete your parsers".

With text output, the model treated my prompt rules a bit loosely, and the parsing chaos hid it. With a forced schema, it obeys much more literally. I had a fallback rule for freelance positions: Italian job ads sometimes want a P.IVA, a VAT number, which changes whether the offer makes sense for me at all. The rule said, roughly, "if freelance status is ambiguous, flag it". Under tool use the model started flagging offers that mentioned freelancing in passing, a line about contractors in another team, anything. Ambiguous had quietly meant "mentioned anywhere".

The schema made the model more obedient, and the obedience exposed how sloppy my instructions had been. The fix was not code. It was rewriting the prompt with explicit precedence: the contract type stated in the offer wins, the fallback fires only when the offer itself is about the contract and does not settle it.

So the lesson I actually paid for: when you migrate from text parsing to tool use, your interpretive prompt rules need to be tightened, not loosened. The model stops improvising on format and starts taking your words seriously. If your rules were vague, you find out now.

What I would tell past me

The parsers were never defensive programming. They were a symptom that the contract lived on the wrong side of the API call, and every new repair function was me renegotiating that contract in the worst possible place, after the response, one edge case at a time.

If your pipeline has a function called _fix_single_quotes, you do not need a better parser. Move the shape into input_schema, force the tool, keep your validation, and delete the museum. Then go re-read your prompt, because the model is about to start believing every word of it.

using unity access to create a basic seen. What works and what still needs developing

Thu, 17 Sep 2026 06:11:07 +0000

Since development of unity access has gone so well, I have been able to have most of the basic features built. This means that I was able to begin testing it to see if it would be viable to use in the long run.
I did this by building a basic first person seen.

Building The Scene

I started with a blank unity seen and created a capsule, using the game objects menu in the menu bar.
I then used the accessible hierarchy to find the capsule.

I then renamed it to player.

Next, I added the components to the player object that will be needed for the game.

I then used the same process to add a ground and 2 walls.

overall, I found the new plugin to be much easier than using unity's editor or writing the code to create each object. However, there is still room for improvement.

what to work on next

Now that I have the basic features in place I need to work on a way for the unity access plugin to be integrated into the editor asset system. At the moment I have to move and rename assets in file explorer. This could cause reference errors if I forget to move a .meta file with the asset it is attached to.
I also want to build a material system. The alternative would be to write the code for the objects materials. However, a material system would give me added convenience when adding shaders or effects.
{% card %}
If you want to follow along with the development of Unity Access or check out the code, you can find the repository over on GitHub!
{% endcard %}

join the conversation

what problems have you faced when developing plugins for unity?
Have you done anything around accessibility?

# I Built an AI-Powered Python-to-C++ Transpiler Entirely From My Phone. Here is How (and Why).

Thu, 11 Jun 2026 10:49:30 +0000

Every developer knows the drill: you love Python for its speed of development, but when it comes to raw execution power, heavy data processing, or low-latency systems, C++ is king.

But what if you could write clean, expressive Python code and instantly transform it into highly optimized, production-ready C++? Even better, what if you could orchestrate this entire infrastructure from a device that fits in your pocket?

Meet Astmize ⚡ — an open-source, AI-powered Python-to-C++ transpiler with an active execution sandbox. And yes, I coded the entire ecosystem—both the frontend and backend architecture—directly from a 6.67" mobile phone screen.

Here is a deep engineering breakdown of how it works under the hood.

🛠️ The Architecture: Behind the Scenes of Astmize

Building a complex developer tool on a mobile device requires discarding heavy frameworks and relying on pure, asynchronous engineering. Here is how the orchestration layers interact:

1. Multi-Model AI Fallback Chain

Static AST (Abstract Syntax Tree) parsing can only get you so far with highly dynamic Python code. To ensure flawless code conversion, Astmize utilizes an AI Orchestrator via OpenRouter.

To counter server loads, API limits, or downtime, I built a sequential Fallback Chain:
(Qwen3 Coder -> DeepSeek -> Nemotron -> GPT-OSS ...)

If the primary model hits a rate limit or experiences high latency, the backend seamlessly routes the payload to the next model in the chain asynchronously, ensuring zero interruption for the user.

2. Live Cloud Execution Sandboxing

A transpiler is useless if you can’t verify the output. To solve this, I integrated the Wandbox API. Once the code is compiled into C++, the frontend triggers a remote compilation sequence running native GCC. The user receives real-time console feedback, compilation errors, and program outputs directly inside a dark, responsive cyber UI.

3. Lightweight Mobile-First Stack

Backend: A robust Python/Flask API hosted on a containerized infrastructure, fortified with strict rate-limiting (60 requests/minute) to handle high-traffic spikes securely.
Frontend: A single-file, zero-build vanilla JavaScript frontend designed to render beautifully across desktop and mobile browsers alike, complete with user-customizable editor configurations (font mapping, dynamic scaling, and custom tab sizing).

🚀 Live Demo & Source Code

The entire project is completely free, lightweight, and open-source. You can check it out right now:

🌐 Live Web Application: https://thespacetimedebugger.github.io/Astmize/
📦 GitHub Repository: https://github.com/TheSpacetimeDebugger/Astmize.git

📝 A Personal Note from the Developer (Behind the Glass)

If you’ve made it this far, thank you. I know most readers skip the closing thoughts, but I wanted to share something real with you.

I don't own a computer. Every single line of code in Astmize—from handling the asynchronous orchestration tokens down to wrestling with responsive CSS and debugging raw JSON strings—was typed with my thumbs using tools like Pydroid 3 on a small mobile device.

It was an exhausting, screen-switching nightmare at times, but watching hundreds of developers clone the repo over the last few days has made every thumb cramp worth it.

If this mobile-built project brings a smile to your face, inspires you, or adds any value to your workflow, please consider dropping a ⭐ Star on our GitHub Repository. It takes you exactly two seconds, but for a solo developer fighting limitations from a phone screen, it is the validation and fuel that keeps this project—and my future startup dreams—alive.

Thank you for riding along! ⚡!

How I saved my Python-to-C++ Transpiler from failing by pivoting to Gemini AI (Built 100% on Mobile)

Tue, 09 Jun 2026 09:24:42 +0000

Hey devs!
A while ago, I started building Astmize, a web tool to transpile Python code into optimized C++. In the first version, I tried building a strict AST parser. Long story short: handling type inference across languages entirely from a mobile IDE was an absolute nightmare, and I almost gave up on the project.
Instead of quitting, I decided to pivot. I completely rewrote the backend to leverage Gemini AI as the core translation engine. Now, instead of breaking on complex structures, the AI understands the logic and generates clean, optimized C++ code dynamically.
And yes, the entire stack (Frontend on GitHub Pages, Backend API on Render) was built, debugged, and deployed 100% using my phone.
Version 2.0 is officially LIVE! I'd love for you guys to break it, test it with some complex Python logic, and give me your brutal feedback.
Live Demo: [https://thespacetimedebugger.github.io/Astmize/]
GitHub Repo: [https://github.com/TheSpacetimeDebugger/Astmize.git]
Let's hear your thoughts!

I Built PentestScan: A Simple Web & API Security Scanner for Developers and Small Teams

Wed, 03 Jun 2026 11:06:15 +0000

Building security tools always sounds more impressive than it really is at the beginning.

In my case, PentestScan started as a practical idea:
I wanted to build a simple Web & API security scanner that could help developers, small teams, and DevOps engineers catch common security issues earlier - before an application reaches production.

Not as a replacement for professional penetration testing.
Not as a magic “find everything” scanner.
But it is a practical DevSecOps tool that gives fast, understandable feedback.

The problem I wanted to solve was simple:

A lot of small teams do not have a dedicated AppSec engineer.
Security reviews often happen too late.
Reports from bigger tools can be too complex, too noisy, or too expensive for early-stage projects.
And developers usually need something direct:

What is wrong?
Why does it matter?
How can I fix it?

That is the direction I took with PentestScan.

What PentestScan does

PentestScan is a Web & API security scanner focused on practical checks around common security weaknesses.

The current version is built around:

Web application scanning
API security testing
OWASP Top 10 related checks
Security headers analysis
JWT and session-related checks
Basic exposure detection
Report generation
DevSecOps-friendly workflow

The goal is not to overload the user with hundreds of unclear findings.

The goal is to provide a clean report that helps someone understand the risk and take action.

Tech stack

The project is built with a simple and practical stack:

Python
FastAPI
Docker
Nginx
HTML reporting
API-first backend structure
Security-focused scanning modules

I wanted the architecture to stay modular because security tooling can become messy very quickly if everything is placed into one large script.

So the scanner is organized around separate modules and checks, with the idea that new functionality can be added gradually without breaking the existing structure.

Why I built it

I built PentestScan mainly as a hands-on DevSecOps project.

I wanted to combine several areas that I work with and care about:

application security
backend development
automation
Linux deployment
Docker-based services
CI/CD security thinking
security reporting

One thing I learned while building it is that detection is only one part of the problem.

The harder part is explaining the finding in a useful way.

A security report should not only say:

Missing security header detected.

It should explain:

what was detected,
why it matters,
how it could be abused,
how serious it is,
and what the developer can do next.

That became one of the most important ideas behind the project.

What I am trying to improve

PentestScan is still evolving.

Some of the things I am working on or planning to improve are:

better API scanning
cleaner report structure
more contextual findings
CI/CD integration
better severity scoring
improved attack-path style explanations
more useful remediation guidance
public sample reports

I am also trying to keep the tool realistic.

Security scanners can easily create false confidence.
Just because a scanner does not find something does not mean the application is secure.

So I see PentestScan as a first security layer - something that can help teams catch obvious and common issues earlier, not as a full replacement for manual testing.

Current version

The project is currently available for free here:

https://pentestscan.app/

Before trying the scanner, you can also check a public sample report:

Sample vulnerability report:
https://pentestscan.app/api/v1/public/marketing/vulnerability_report.html

I am sharing PentestScan publicly to get feedback from developers, DevOps engineers, and security people.

I would especially appreciate feedback on:

report structure and clarity,
usefulness of the findings,
scanning flow,
missing checks,
and whether the tool feels useful for small teams or solo developers.

This project is still a work in progress, but it has already been a valuable learning experience in building security tooling that is not only technical but also understandable and useful.

That, for me, is the main point of PentestScan:

help developers see security issues earlier, understand them faster, and fix them with less friction.

Flow of Autonomous Brain and its Engine

Thu, 28 May 2026 07:23:50 +0000

On the last post, I mentioned usuage of multiple github models, but made some more modifications, and now 2 new providers are also added to the boardroom.

STAGE 1 ARCHITECT CONFERENCE

     Architect A (Mixtral/Groq) + Architect B (Llama/Groq) propose plans in parallel
     Judge (GPT-4o) synthesises or proposes a more unpredictable plan

STAGE 2 IMPLEMENT

     Engineer (GPT-4o) writes each file with full sibling context

STAGE 3 QUALITY LOOP (up to 8 rounds)

     Reviewer A (Mixtral/Groq) + Reviewer B (Gemini) in parallel
     Fixer applies merged feedback + Playwright interaction test

STAGE 4 QA REVIEW

     Playwright clicks every button, tests every slider
     QA Tester (GPT-4o) issues verdict: shippable / partially_usable / non_functional

STAGE 5 PUBLISH

     New public GitHub repo created via API
     GitHub Pages enabled -> live URL in under 60 minutes from cold start

STAGE 6 SELF-IMPROVE

     CTO (Gemini) reads last 30 failure logs, proposes a surgical source patch
     Validates Python syntax, commits - next build runs improved code

What have you been working on lately?

Fri, 15 May 2026 12:37:01 +0000

Hi community! Would love to talk and get to know what you are working on right now

Could be:

a startup or a side project
open-source tool
article
random idea that accidentally became serious
or maybe you started new course or learned something new

I’ll go first.

Building an Email System with Aliases, Routing, and AI Assistance (Wizard Mail)

Sun, 10 May 2026 17:42:50 +0000

When I started building Wizard Ecosystem, I didn’t plan to build an email system.

It started as a side idea:

“What if users could have AI-managed email inside the same ecosystem as their assistant, files, and agents?”

That idea turned into Wizard Mail — a full email client with alias support, IMAP integration, and AI-assisted features.

This post is about how it actually works, and what I learned building it.

⚙️ What Wizard Mail is

Wizard Mail is an email module inside Wizard Ecosystem that:

connects to external email providers (IMAP-based)
supports sending and receiving emails
organizes inbox, sent, spam, and folders
adds AI features on top of traditional email

But the most interesting part is not the email client itself.

It’s email aliases and routing.

The idea of email aliases

Instead of just using a normal email like:

user@gmail.com

Wizard Mail introduces:

@wizardecosystem.dpdns.org aliases

These are virtual addresses that:

forward messages to a real inbox
can be created dynamically per user
can be used for separation (projects, signups, services)

Example:

arnav@wizardecosystem.dpdns.org
projects@wizardecosystem.dpdns.org
testing@wizardecosystem.dpdns.org

All of them map back to a real mailbox internally.

⚙️ How alias routing works (simplified)

The system works in layers:

Incoming email hits alias domain

Mail is received for:

alias@wizardecosystem.dpdns.org

Alias resolution layer

Backend checks:

user mapping table
alias → real inbox mapping

Routing engine

The system forwards or stores:

original message metadata
sender + headers
mapped user inbox

Storage layer

Emails are then:

stored in database
categorized into folders
made accessible via API
Why I built it this way

Most email systems are:

provider → inbox → UI

But I wanted:

provider → abstraction layer → AI system → user experience

Because Wizard Ecosystem already has:

memory systems
AI assistants
multi-agent workflows

So email becomes:

not just communication, but structured data inside an AI system

⚠️ Problems I ran into

IMAP inconsistency

Different providers behave differently:

Gmail vs Outlook vs Yahoo
folder structures not standardized
delayed sync behavior

Alias complexity

Aliases sound simple, but:

forwarding loops can happen
mapping conflicts need strict validation
spam handling becomes harder

Email parsing edge cases

Emails are messy:

broken headers
weird encodings
inconsistent formatting

So a lot of time went into:

cleaning and normalizing email data

Where AI actually helps

This is where Wizard Ecosystem becomes interesting.

On top of email, I added AI features:

summarizing long email threads
extracting key actions
categorizing messages automatically
helping draft replies

So instead of:

“read inbox manually”

it becomes:

“AI-assisted inbox processing”

⚙️ Key insight

The most important realization was:

Email is not a messaging problem — it’s a data routing problem.

Once you think of it that way, everything changes:

aliases become routing rules
inbox becomes structured storage
threads become data graphs
What I learned

Building Wizard Mail taught me:

simple features hide complex backend systems
alias systems require careful routing logic
email is much more “messy data” than expected
AI adds value only after structure is clean
abstraction layers matter more than UI
Final thought

Wizard Mail started as a small feature idea.

It became:

a routing + abstraction layer between external communication and internal AI systems

And it changed how I think about system design in general.

I Built a Free Online Charades Game With 500+ Words, a Live Timer, and Team Scoring No App, No Sig

Sat, 25 Apr 2026 14:15:02 +0000

I play charades at family gatherings. Every time, someone spends 10 minutes writing words on paper slips, someone loses the slips, someone argues about the score, and the phone timer app keeps locking the screen mid-countdown.
So I built a browser-based charades game that handles all of it. One link, open it, start playing in 10 seconds.
Here is what it does and how I built it.

What It Is
The Charades Generator is a complete game system that runs entirely in your browser. No download, no account, works on any phone.
Features:

500+ words and phrases across 10 categories
Built-in countdown timer with visual pressure cues
Live team score tracker with round summaries
Difficulty levels: Easy, Medium, Hard
Adult 18+ mode, Christmas pack, Movie charades, Animal charades
Fully customizable: rounds, cards per round, timer length, team names

The Word Bank Architecture
The words are organized into category objects. Each word has three properties: the phrase, a difficulty level, and an optional hint.
javascriptconst categories = {
general: [

{ word: "Skydiving", difficulty: "medium", hint: "extreme sport" },
{ word: "Invisible Man", difficulty: "hard", hint: "classic concept" },

],
movies: [

{ word: "Inception", difficulty: "medium", hint: "dreams" },
{ word: "Titanic", difficulty: "easy", hint: "ship" },

],
animals: [

{ word: "Platypus", difficulty: "hard", hint: "unusual mammal" },
{ word: "Dog", difficulty: "easy", hint: null },

]
};
When the user picks categories and a difficulty level, the system filters across all selected categories and builds a flat deck. The deck gets shuffled with a Fisher-Yates shuffle before the game starts.
javascriptfunction buildDeck(selectedCategories, difficulty) {
let deck = [];
selectedCategories.forEach(cat => {

const words = categories[cat].filter(w =>
  difficulty === "all" || w.difficulty === difficulty
);
deck = deck.concat(words);

});
return shuffleDeck(deck);
}

function shuffleDeck(deck) {
for (let i = deck.length - 1; i > 0; i--) {

const j = Math.floor(Math.random() * (i + 1));
[deck[i], deck[j]] = [deck[j], deck[i]];

}
return deck;
}

The Timer With Visual Pressure
A plain countdown is boring. I wanted players to feel the pressure build as time runs out.
The timer ring changes color based on time remaining. It turns orange at 15 seconds and red at 5. The CSS transition handles the color shift smoothly.
javascriptfunction updateTimerDisplay(secondsLeft, totalSeconds) {
const ring = document.getElementById('timerRing');

if (secondsLeft <= 5) {

ring.style.borderColor = '#ef4444'; // red

} else if (secondsLeft <= 15) {

ring.style.borderColor = '#f97316'; // orange

} else {

ring.style.borderColor = '#8b5cf6'; // default purple

}

document.getElementById('timerDisplay').textContent = secondsLeft;
}
Players notice the color change before they check the number. It creates urgency without them thinking about it.

Score Tracking Across Rounds
Each team has a running total plus a per-round breakdown. At the end of each round, a summary screen shows what each team scored before switching turns.
javascriptconst gameState = {
teams: {

team1: { name: "Team 1", total: 0, rounds: [] },
team2: { name: "Team 2", total: 0, rounds: [] }

},
currentRound: 1,
currentTeam: "team1"
};

function recordScore(teamId, points) {
gameState.teams[teamId].total += points;
gameState.teams[teamId].rounds.push(points);
}
No paper. No arguments. The scoreboard stays visible throughout the entire game.

What Broke During Testing

The Adult 18+ category needed to be completely isolated from family categories. Early builds let filters bleed across category selections when users switched between Quick Bundle presets rapidly.
Fix: reset the entire category selection state whenever a Quick Bundle button is pressed, then apply only that bundle's categories fresh. No carry-over from previous selections.
The second issue was the timer continuing to tick after a player pressed "Got It" or "Skip" on the last card. The interval kept running in the background. Fix was simple: always call clearInterval(timerInterval) before any card transition, not just on timeout.

Why Client-Side Architecture Matters Here

The Charades Generator runs zero server calls during gameplay. The entire word bank loads once with the page. The timer, scoring, and card logic all run in the browser tab.
This is the same approach I use across all tools at stackflowtools.com. The background remover processes images without uploading them. The image compressor runs entirely on-device. The AVIF to JPG converter uses the Canvas API to handle conversion in the browser tab. No file ever leaves the user's device.
For a game tool, the benefit is different. No server means no latency between cards. The game feels instant because it is. There is no network request between pressing "Next Card" and seeing the next word.

By the Numbers
FeatureDetailTotal words500+Categories10Timer options30s, 60s, 90s, 2 minRound options3, 5, 7, 10Cards per round3, 5, 7, 10Server requests during game0Signup requiredNo

Try It
Open stackflowtools.com/charades-generator on your phone, pick your categories, and start playing. Setup takes under 30 seconds.
If you are building other party game tools, the Random Animal Generator on the same site follows a similar word-bank approach and works well as a kids game companion. For game nights that need a name generator, the Free Fire Stylish Name Generator and PUBG Name Generator are also part of the same tool suite at stackflowtools.com.
If you have questions about the deck logic, timer behavior, category isolation, or state management across rounds, drop a comment below.

Sohaib Khan builds free browser-based tools at stackflowtools.com.

The Indie Hacker’s Manifesto: Stop Coding, Start Shipping

Sat, 25 Apr 2026 11:39:31 +0000

I. Strategy: Finding the "Arbitrage of Mediocrity"

1. The Differentiation Framework

The "Goldilocks" Niche: Don’t go so niche that the market doesn’t exist. If there’s zero competition, there’s likely zero money. Aim for "Niche but Scalable."
Dimensional Attacks:
- Attack Open Source: Most OSS tools are powerful but "ugly," hard to configure, and lack support. Your opportunity? Build a Better UI/UX Wrapper that provides a "plug-and-play" experience.
- Unbundle the Giants: SaaS giants (Salesforce, Adobe, Jira) are bloated, expensive, and forced subscriptions. Your opportunity? Build a Lightweight, Privacy-First, One-Time Payment alternative for just one specific feature.
- The 3-Star Arbitrage: Scour Product Hunt or the App Store for famous products with a 3.2-star rating. Read the complaints. Fix that one specific pain point and release it as a standalone micro-tool.

2. Geopolitical Arbitrage

Willingness to Pay (WTP): Target markets with high disposable income and a culture of paying for software (North America, DACH region, UK).
Ignore Low-Value Noise: Don't waste your support time on markets that demand "free" unless you are building a non-profit.

II. Development: Escaping the "Productivity Porn" Trap

3. The "Embarrassment" Principle

Core Logic Only: If a feature doesn't solve the primary pain point, it’s a distraction.
The Reid Hoffman Rule: "If you are not embarrassed by the first version of your product, you’ve launched too late."

4. The Developer’s Comfort Zone

Stop Building Tools for Yourself: Spending three weeks writing a "custom Twitter bot" instead of actually talking to users is just procrastination disguised as work.
The 70/30 Rule: Spend 30% of your time coding and 70% marketing. Great code that nobody finds is just a graveyard of wasted hours.
Code Freeze: Once you launch, stop touching the CSS. Unless it’s a critical bug, put the keyboard away and pick up the megaphone.

III. Marketing: Weaponizing Distribution

5. High-ROI Channels

Channel	Why it Works	The Catch
Reddit	High intent, niche subreddits.	They hate "Salesmen." Must provide value.
X / Twitter	The home of "Building in Public."	Requires consistent personality.
Hacker News	Can trigger massive viral traffic.	Highly critical audience. No marketing fluff allowed.
Product Hunt	The "Grand Opening" of the tech world.	Only lasts 24 hours. Needs a launch strategy.

6. Fighting the Algorithm

Human-to-Human (H2H): Platforms hate "Corporate" ads. Use Storytelling. Talk about your failures, your tech stack, or "The one thing I learned building X."
The Incognito Test: Always check your posts in Incognito/Private mode. If you don't see it, you've been shadowbanned or filtered. Don't wait for stats—verify visibility immediately.

IV. The Moat: Trust & Passive Traffic

7. Trust Engineering

Show, Don't Tell: In an era of AI scams, trust is the only currency. Offer "Local-First" processing, "No-Tracking" guarantees, or high-quality interactive Demos that don't require an email signup.
Zero-Friction Entry: Reduce the "Aha! Moment" time. If I have to confirm my email and set up a profile just to see how your tool works, I'm already gone.

8. AIEO (AI Engine Optimization)

Programmatic SEO: Create landing pages for "Long-tail" keywords (e.g., "Best lightweight Alternative to X for Mac").
The llms.txt Standard: Deploy an llms.txt file in your root directory. This provides a clean, markdown-based summary for LLMs (ChatGPT, Perplexity, Claude) to read. When a user asks an AI for a "tool that does X," you want the AI to recommend you.

V. Post-Launch: Surviving the "Trough of Sorrow"

9. The 72-Hour Rule

After the initial launch buzz, your traffic will drop to near-zero. This is normal. Do not panic. Do not rewrite the codebase. Stick to your marketing plan for at least three days before making a pivot.

10. The Asset Mindset

Everything you build—the domain, the code snippets, the backlinked landing pages—is Digital Real Estate. Even if the product fails to generate revenue today, the "Domain Authority" and the "Skill" you’ve built are assets for your next ship.

The Bottom Line: Be a Marketer who knows how to Code, not a Programmer who "tries" to Market.

author web Organization

BuildInPublic #IndieHackers #Solopreneur

How I Built LoopSignal: Public Feedback Boards, GitHub Sync, and Changelogs for Indie Developers

Mon, 13 Apr 2026 12:47:57 +0000

If you are building a SaaS, user feedback usually ends up everywhere except the one place where it is actually useful.

Some requests arrive through email. Some show up in support chats. A few land in GitHub issues. One power user sends a long DM. Then roadmap time comes around and you realize you are mostly guessing.

That frustration is what led me to build LoopSignal.

LoopSignal is a lightweight feedback platform for indie developers and small teams. It gives every product a public board where users can submit ideas and vote on requests, a public changelog to show what shipped, a widget you can embed inside your app, and a GitHub integration that connects feedback directly to development work.

The goal was simple:

Make feedback easy to collect.
Make prioritization obvious.
Make it easy to show users that their feedback mattered.

That last part is the reason for the name. I did not just want a feature request board. I wanted a tool that closed the loop.

The problem I wanted to solve

Most feedback tools I looked at fell into one of two buckets:

They were powerful, polished, and priced for larger product teams.
They were simple, but too limited or too disconnected from a developer-led workflow.

For indie hackers and small SaaS teams, that leaves an awkward gap.

You do not need an enterprise product suite just to answer questions like:

What are users asking for most often?
Which requests are repeated by multiple customers?
What should I build next?
How do I tell users their request is now shipped?

You need a system that is small, fast, and opinionated in the right ways.

I wanted something that let me:

collect feedback without forcing end users to create accounts
let people vote so demand becomes visible
moderate low-quality or spammy posts
push approved requests into GitHub automatically
publish a changelog from shipped work
drop a widget into any app with one script tag

That became the product spec for LoopSignal.

What LoopSignal does

At a high level, each project in LoopSignal gets its own public feedback workflow.

Here is what that includes today:

Public feedback boards where users can submit feature requests and vote on existing ones
Anonymous participation so end users do not need accounts just to leave feedback
Workflow states like Open, Planned, In Progress, Completed, and Closed
Moderation and spam checks to keep the board usable
GitHub integration that creates issues from approved feedback
GitHub webhook sync so closing an issue can mark the related request as completed
Public changelog pages generated from shipped work
Embeddable widget that works with a single script tag
Email notifications when a request changes status
Team roles for owner, admin, and member access
Analytics and CSV export so teams can understand what is happening on the board
API access for teams that want to script or automate around it

The workflow I cared about most looked like this:

A user submits feedback from a public board or an in-app widget.
Other users vote on it.
The team reviews and approves it.
LoopSignal creates a GitHub issue automatically.
The issue gets worked on in the normal development flow.
When the issue is closed, the feedback item becomes completed and shows up in the public changelog.

That is the whole product in one loop.

Why I built it for developers first

A lot of feedback tools are built like product management software. That makes sense for larger organizations, but it also creates friction for small teams.

Small teams do not want another heavyweight system to maintain. They want something that fits the tools they already use.

That is why LoopSignal is intentionally developer-friendly:

GitHub is a first-class part of the workflow
the widget is just a script tag
the product exposes basic API endpoints
the public board is simple enough that users can start contributing immediately

I wanted the setup to feel closer to "connect repo, share link, start collecting signal" than "spend a week configuring a process."

The stack behind it

I built LoopSignal with a stack that is well suited to founder-led SaaS products:

Next.js 15 for the app, routing, server rendering, and server actions
React 19 for the UI layer
Supabase for Postgres, auth, and database access
Cloudflare Workers for deployment via OpenNext
Paddle for billing
Resend for transactional emails
Tailwind CSS + shadcn/ui for the UI

This stack gave me a nice balance:

fast iteration
a single TypeScript codebase
no separate backend service to maintain
enough structure to support auth, billing, and multi-project access cleanly

How the core product flow works

1. Public submission without account friction

One of the easiest ways to kill feedback volume is to ask users to create an account before they can submit an idea.

LoopSignal avoids that. Users can submit feedback from the public board or embedded widget with an optional email if they want updates later.

The submission flow does a few things before a post is created:

validates the title and description
rate-limits submissions
runs a simple spam scoring pass
stores the post as pending for moderation
auto-subscribes the submitter for future status emails

Here is the heart of that server action:

const spam = checkSpam({ title, description, email, ip });
if (spam.isSpam) {
  await logSpam(ip, "spam_detected", spam.signals, spam.score, {
    title,
    description,
    email,
  });
  return { error: "Your submission was flagged." };
}

const { data: newPost } = await admin
  .from("posts")
  .insert({
    project_id: projectId,
    title,
    description,
    category,
    email: email || user?.email || null,
    ip,
    spam_score: spam.score,
    moderation_status: "pending",
    workflow_status: "open",
  })
  .select("id")
  .single();

It is intentionally simple. The product is optimized for useful signal, not for forcing people through a heavy workflow.

2. Voting as lightweight prioritization

Once a post is approved, it appears on the public board where users can vote on it.

That matters because raw feedback is noisy. Voting turns isolated requests into visible demand. It gives teams a better signal than the loudest customer email.

On the public board, users can:

sort by most voted or newest
filter by status
filter by category
open individual request pages
see admin replies directly under posts

That keeps the board useful as it grows instead of turning into a long unstructured list.

3. GitHub issue creation on approval

The most important product decision I made was to connect approved feedback directly to GitHub.

Once a request is approved, LoopSignal can create a GitHub issue automatically for the selected repository. The issue body includes the feedback description and gets labeled as feedback, plus the category if one exists.

This is the core issue creation logic:

const body = [
  description || "",
  "",
  "---",
  "*Created from LoopSignal feedback*",
].join("\n");

await fetch(`https://api.github.com/repos/${owner}/${repo}/issues`, {
  method: "POST",
  headers: {
    Authorization: `Bearer ${githubToken}`,
    Accept: "application/vnd.github+json",
    "Content-Type": "application/json",
    "User-Agent": "LoopSignal",
  },
  body: JSON.stringify({ title, body, labels }),
});

This sounds small, but it changes the product from "a place where ideas go to sit" into "a place where ideas can enter the actual engineering workflow."

4. Closing the loop with GitHub webhooks

Creating an issue is only half the story.

The more interesting part is the reverse sync. When a GitHub issue is closed, LoopSignal looks up the linked post and updates the workflow status to completed. If the issue is reopened, the post moves back to open.

That logic is intentionally tiny:

if (action === "closed") {
  workflowStatus = "completed";
} else if (action === "reopened") {
  workflowStatus = "open";
}

This is one of my favorite parts of the app because it removes a manual step. Teams do not have to remember to update the feedback board after shipping. Their existing development workflow updates it for them.

5. Public changelog generation

Once a post reaches a shipped state, it can appear on the project's public changelog page.

That matters because collecting feedback is only half the job. Users need to see that something happened because they spoke up.

A good changelog does a few things at once:

shows active development
builds trust with current users
gives potential customers confidence that the product is alive
makes submitters more likely to contribute again

In LoopSignal, the changelog is just another view of the same underlying feedback data. That keeps the system simple and makes the "close the loop" story visible.

I also wanted the product to work inside existing apps without requiring a deep integration.

That led to a simple embed script:

<script
  src="https://loopsignal.dev/embed.js"
  data-slug="your-project"
  defer
></script>

The script renders an iframe-based widget. It can run in a floating mode with a feedback button or in an inline mode inside a chosen container.

The important part is not technical complexity. It is setup speed. If someone can paste one script and start collecting feedback in two minutes, they are much more likely to actually use the feature.

A few implementation details I cared about

Server actions for mutations

I used server actions for most write operations. For a product like this, they are a good fit:

fewer separate mutation endpoints to manage
direct access to auth context and headers
straightforward cache revalidation with revalidatePath

That made actions like submitting feedback, voting, updating statuses, and managing settings feel compact and easy to reason about.

Supabase for auth and data, but with careful access checks

Supabase gave me a lot quickly:

Postgres
auth flows
admin access for privileged operations

But once team-based access enters the picture, things get more complicated. Ownership, admin permissions, member permissions, public access, and API access all intersect in subtle ways.

I ended up centralizing access checks in auth helpers so permission logic was not duplicated all over the app. That was much easier to maintain than sprinkling project ownership checks throughout every action and page.

Simple anti-spam instead of overengineering

For public boards, spam is not optional. If anyone can submit, someone eventually will submit garbage.

Instead of starting with a complicated external moderation service, I began with a simple scoring system:

all-caps titles
too many URLs
repetitive characters
suspicious email patterns
known spam phrases

That is enough to block obvious junk while keeping the product lightweight.

Basic API surface for power users

LoopSignal also exposes a small API:

GET /api/v1/[slug]/posts
POST /api/v1/[slug]/posts
GET /api/v1/[slug]/stats

The write endpoint uses an x-api-key header and is gated to the Pro plan. I wanted the API to be useful for simple automation without expanding the scope into a huge platform surface area too early.

The hardest parts of building it

No SaaS build is complete without a few annoying edges.

Here are the biggest ones I ran into:

1. Deployment on Cloudflare Workers

Running Next.js 15 on Cloudflare Workers is possible, but not frictionless. OpenNext helps a lot, but you still have to think about environment assumptions, missing Node APIs, and deployment quirks.

I like the performance and cost profile, but it definitely required more care than a default Vercel deployment.

2. Permissions get complex fast

The moment a product supports:

project owners
admins
members
public users
API clients

...your permission model gets real very quickly.

What looks simple at the UI level can turn messy in the backend if you do not centralize access control early.

3. Billing logic touches more of the app than you expect

Billing was one of those features that looked isolated at first and then ended up touching a lot of product behavior:

project limits
team member limits
Pro-only analytics
Pro-only API access
expired trial handling

That is a good reminder that billing is rarely "just a checkout page."

What I learned from building LoopSignal

The biggest lesson was that product scope matters more than feature count.

It would have been easy to keep adding "nice to have" ideas:

more integrations
custom branding controls everywhere
more advanced automation
internal product planning features

But the product gets stronger when the core loop stays obvious:

collect feedback -> validate demand -> sync to development -> show what shipped

Everything in LoopSignal is there to support that loop.

The second big lesson is that feedback products live or die on friction.

If users need too many steps to submit feedback, they will not do it.
If teams need too many steps to act on feedback, they will ignore it.
If nobody sees what shipped, the system does not build trust.

Reducing friction at each of those points mattered more than adding complexity.

Who I built it for

LoopSignal is aimed at:

solo founders
indie hackers
small SaaS teams
developer-led products that already live in GitHub

It is not trying to be an all-in-one enterprise product management platform.

It is trying to be the fastest way for a small team to go from scattered user requests to a visible, structured product feedback workflow.

Pricing reflects that:

Starter: $19/month
Pro: $49/month
14-day free trial with full Pro access

The Starter plan covers the public board, changelog, widget, GitHub integration, notifications, and CSV export. Pro adds things like API access and analytics, plus unlimited projects and team members.

Final thoughts

I built LoopSignal because I wanted a feedback tool that fit the way small teams actually work.

Not every product needs a giant roadmap suite. Sometimes you just need one clear place to collect requests, let users vote, connect the important ones to GitHub, and show people that you shipped what mattered.

That is what LoopSignal is for.

If you want to check it out, the product is live at loopsignal.dev. I am also dogfooding it by collecting feedback about LoopSignal on LoopSignal itself, which felt like the right way to launch a product like this.

Building PrudentSpend: Lessons From Shipping a Real-World Personal Finance Web App

Tue, 07 Apr 2026 21:55:40 +0000

Building side projects is easy.
Shipping something people actually use — and maintaining it — is the hard part.

In this article, I want to share the story behind PrudentSpend, a personal finance web application I built to help users track spending, manage budgets, and make better financial decisions. I’ll cover why I built it, the technical choices I made, and the lessons I learned from taking it live.

Why I Built PrudentSpend

Like many people, I struggled to clearly understand where my money was going each month. Existing budgeting tools either felt too complex, too restrictive, or overly automated.

I wanted to build something that:

Was simple and intentional

Focused on clarity over automation

Let users stay in control of their financial data

That idea became PrudentSpend — a lightweight budgeting and expense-tracking platform designed around usability and transparency.

Tech Stack & Architecture

PrudentSpend is a full-stack web application built with scalability and maintainability in mind.

Core technologies include:

Frontend: Modern JavaScript framework with component-based UI

Backend: RESTful API architecture

Authentication: Secure user authentication and session management

Database: Relational data modelling for users, budgets, and transactions

Deployment: Cloud-based hosting with environment separation

From the start, I treated the project like a production system — version control, clear commit history, and structured APIs were non-negotiable.

Key Features

Some of the core features include:

User authentication and protected routes

Expense and income tracking

Budget creation and monitoring

Monthly summaries and usage insights

Responsive UI for desktop and mobile

Each feature was built iteratively, based on real usage and feedback rather than assumptions.

Adoption & Real-World Usage

One of the most rewarding parts of this project has been seeing real user adoption.

Over time:

Monthly active users grew steadily

Users consistently recorded transactions

Engagement remained stable as the user base scaled

This validated an important lesson: a simple product that solves a real problem often outperforms complex solutions.

What I Learned

Shipping beats perfection

Waiting for the “perfect” version delays learning. Releasing early helped me identify what actually mattered to users.

Metrics matter

Tracking adoption and engagement changed how I prioritized features. Data > assumptions.

Maintainability is a feature

Clean code, clear APIs, and documentation saved me time when adding new features later.

Building for users builds better engineers

Working on PrudentSpend sharpened my skills in:

System design

API development

Debugging real-world issues

Communicating technical decisions clearly

What’s Next

PrudentSpend is still evolving. Planned improvements include:

Advanced analytics and insights

Exportable financial reports

Performance optimizations

Accessibility enhancements

You can explore the live app here:
https://prudentspend.com

And I’m always open to feedback from other developers and users.

Final Thoughts

If you’re a developer thinking about building a side project, my advice is simple:

Build something useful. Ship it. Let real users guide you.

That’s where the real learning begins.

I built a free alternative to iLoveIMG — no login, no ads, no paywalls

Tue, 07 Apr 2026 16:18:46 +0000

We've all been there.

You need to quickly compress an image. You Google "free image tool", land on iLoveIMG, upload your file — and boom.

"Sign up to continue."

You just wanted to resize a photo. Not create another account you'll forget about in 3 days.

So after hitting this wall one too many times during a side project, I did what any developer does.

I built my own. ️

Introducing ihateimg.in

ihateimg.in — a completely free image toolkit. No account. No ads. No "upgrade to pro" popup appearing right when you need it most.

Just open the site and get things done.

What it does

Tool	What it's for
️ Crop	Trim your image exactly how you want
Resize	Custom dimensions in pixels or percentage
️ Compress	Reduce file size without killing quality
Watermark	Add text or image watermarks in seconds
Upscale	Increase resolution without heavy blur

The part I'm most proud of — Pipelines ⚡

Most tools make you do this:

Upload → Edit → Download → Re-upload → Edit again → Download → Repeat

With ihateimg.in, you can chain multiple edits into a single pipeline.

Compress + Resize + Watermark — all in one go. Upload once, get your final result. Done.

This alone saves me several minutes every single time I work with images.

How it stacks up against iLoveIMG

Feature	iLoveIMG	ihateimg.in
Login required	✅ Yes	❌ Never
Ads	✅ Yes	❌ Never
Paid plan	$60/year	Free forever
Pipeline / batch edits	Limited	✅ Yes
Compress, Resize, Crop	✅	✅
Watermark	✅	✅
Upscale	✅	✅

iLoveIMG is a solid product — but it's built around converting free users into paying ones. Nothing wrong with that as a business, but it's not what I wanted as a user.

ihateimg.in is built around getting out of your way.

The honest backstory

I needed a quick image tool for a side project. Every popular option either had ads, required signup, or locked the exact feature I needed behind a paywall.

So I spent a weekend building something I actually wanted to use.

It's been live for a while now. I've been quietly adding features and fixing bugs. Today felt like the right time to finally share it with the dev community and get real feedback.

Try it out

ihateimg.in

I'd genuinely love to know:

What's missing?
What would make this a tool you actually reach for?
Any bugs or rough edges you hit?

Drop a comment — I read every single one.

I added a flyable spaceship to my GitHub visualizer | Phase 6 of Stack Universe is live

Sun, 05 Apr 2026 18:43:39 +0000

I made your GitHub profile explorable, you can now fly a spaceship through other developers' universes

Phase 6 of Stack Universe just shipped and it changes what the product fundamentally is. It started as a visualizer. It is now an explorable multiverse.

→ https://stack-universe.vercel.app

Quick context if you are new

Stack Universe turns any GitHub profile into a unique 3D solar system. Your repos are planets sized by star count, orbiting at speeds based on how recently you pushed. Your commit messages float on shooting stars. Your CI/CD runs are space weather, failing builds crack your planets and shatter your deploy streak aura. Every developer gets a permanent URL that is their coordinate in the multiverse.

Previous phases added repo health scores, GitHub Actions weather, OAuth to claim your universe, a README embed widget, and a full AI layer with roast mode, narrator, horoscope, and developer identity panel.

Phase 6 connects every universe together into a living community.

What shipped in Phase 6:

Constellation Multiverse Map

Route: https://stackuniverse.vercel.app/multiverse

Every universe stored in the database now appears as a glowing dot on a top down 2D star map. Position is determined by score — high scoring developers sit near the center, new developers are toward the edges. Constellation lines are drawn between developers who share three or more languages. Named regions appear as faint labels across the map — The JavaScript Nebula, The Rust Cluster, The Python Belt, The TypeScript Corridor.

Hover any dot and it shows the username, score, and distance. Click it and the full cinematic warp entry plays, you fly into that developer's universe from the map. The multiverse is no longer a concept. It is a navigable space.

Universe Discovery Feed

The landing page now has a live ticker powered by Supabase Realtime. Every time someone searches a username it appears in the feed. Two minutes ago someone explored JakeWharton's universe. Just now torvalds was visited. The landing page feels alive instead of static. It is a pure FOMO engine — you see other people exploring and immediately want to explore yours.

Tech Stack Fingerprint

Button in the HUD: MY DNA

Groq and your language data combine to generate a unique radial mandala chart from your exact language percentages. A polyglot developer with eight languages gets a complex multi-pointed flower. A specialist who codes exclusively in one language gets a strong single directional spike. No two fingerprints look the same because no two developers have the same stack.

Downloadable as a PNG. Shareable as your developer DNA. This is the kind of thing developers post on Twitter without being asked to.

Multiplayer Presence

When two or more people view the same universe simultaneously

Button on the landing page: EXPLORE MULTIVERSE

The camera switches to a first person spaceship view. WASD or arrow keys control movement. Mouse controls direction. You fly through infinite space and real developer universes are visible as glowing solar systems in the distance. Fly toward one and it grows larger as you approach. A label appears showing the username, score, and distance. Press E to trigger the full cinematic warp entry and fly inside.

Where the product stands after six phases

Phase 1 gave every developer a beautiful universe. Phase 2 made every planet informative. Phase 3 made it live with CI/CD weather. Phase 4 gave developers ownership. Phase 5 gave it a voice with AI. Phase 6 connected every universe into a community.

The comment that became the product philosophy came from a user early on: same data, but way more engaging when it talks back. That is still the north star. Every phase asks what else this data is trying to say.

Phase 7 is next — a full analytics dashboard with graphs and charts for the professional use case. Same data from the solar system but presented as clean readable charts for teams, managers, and recruiters. After that the combat system — universe battles where your GitHub stats become weapons.

An honest note

I am still learning and improving with every phase I ship. This is a side project and every piece of feedback has directly shaped what gets built next. If you are an experienced developer and see something I should be doing differently in the Three.js architecture, the Supabase Realtime implementation, the Tone.js audio generation, or anything else — I genuinely want to hear it.

Try the spaceship mode. Fly around. Find someone's universe. Drop your universe URL in the comments.

→ https://stackuniverse.vercel.app

What Android OEMs do to background apps, and the 11 layers I built to survive it

Tue, 31 Mar 2026 10:50:49 +0000

I spent over a year building a safety monitoring app that runs 24/7 on elderly parents' phones. If it gets killed, nobody gets alerted when something goes wrong. That constraint forced me into the deepest, most frustrating corners of Android background execution.

This article covers what I learned about how Samsung, Xiaomi, Honor, OPPO, and Vivo actively kill background apps, why the standard Android approach is nowhere near sufficient, and the 11-layer recovery architecture I ended up building. I will also cover two related problems that surprised me: GPS hardware that silently stops working, and accelerometer data that lies about its age.

126,000 lines of Kotlin, 125+ versions, solo developer. The app is called How Are You?! — it learns an elderly person's daily routine over 7 days, then monitors around the clock and emails the family if something seems wrong. But this article is about the engineering, not the product.

The problem: Android wants your app dead

Stock Android already makes continuous background work difficult. Doze mode, App Standby, background execution limits — Google has been tightening the screws since Android 6. A foreground service with REQUEST_IGNORE_BATTERY_OPTIMIZATIONS is the standard answer.

That is necessary. It is nowhere near sufficient.

OEMs add their own proprietary battery management on top of stock Android, and they are far more aggressive. Here is what I encountered on the devices I tested:

Samsung maintains a "Sleeping Apps" list. If your app has no foreground activity for 3 days, Samsung kills it. OTA updates silently reset your battery optimization exemption. The user opted you out of optimization? Samsung un-opted you after the update.

Xiaomi (MIUI/HyperOS) kills background services aggressively and resets autostart permissions after OTA updates. Your app was whitelisted? Not anymore.

Honor and Huawei have PowerGenie, which monitors how often your app wakes the system. Call setAlarmClock() more than about 3 times per day and you get flagged as "frequently wakes your system." They also have HwPFWService, which kills apps holding wakelocks longer than 60 minutes with non-whitelisted tags.

OPPO (ColorOS) has "Sleep standby optimization" that freezes apps during the hours the phone detects the user is sleeping. A safety monitoring app for elderly people needs to run especially during sleep hours — that is when falls and medical events go unnoticed.

Vivo (Funtouch OS) has "AI sleep mode" that does the same thing.

Each manufacturer found a different way to kill you. No single workaround survives all of them.

The answer: 11 layers of recovery

The core insight is that no single mechanism is reliable across all OEMs and all device states. The answer is redundancy — each layer catches the failures of the layers above it.

Layer 1: Foreground service with START_STICKY

The foundation. startForeground() with a persistent notification. The notification channel must use IMPORTANCE_MIN — not IMPORTANCE_DEFAULT or higher. Why? OEMs auto-grant POST_NOTIFICATIONS on higher importance channels, bypassing the user's notification settings and making your persistent notification visible. IMPORTANCE_MIN keeps it silent while startForeground() still gives your process elevated priority.

START_STICKY tells the system to restart the service after a kill. But "restart" can take minutes or never happen on aggressive OEMs.

Layer 2: onDestroy recovery scheduling

When the system kills your service, onDestroy() fires (most of the time). Use this 50ms window to schedule everything that will bring you back:

override fun onDestroy() {
    super.onDestroy()
    ServiceWatchdogReceiver.scheduleWithBackup(this)
    MotionSnapshotReceiver.schedule(this)
}

This fires both the AlarmManager chain and the motion snapshot chain. If onDestroy() does not fire (force-stop, OEM kill without callback), the other layers cover it.

Layer 3: AlarmManager watchdog chain

A self-chaining setExactAndAllowWhileIdle() alarm at 15-minute intervals during active use. When it fires, it checks whether the service is alive and restarts it if not.

The interval adapts to power state: 15 minutes when active, 30 minutes when idle, 60 minutes during deep sleep. This matters for OEM battery scoring — more frequent alarms get flagged.

Important: never use Handler.postDelayed() as a replacement for AlarmManager. Handlers do not fire during CPU deep sleep. I learned this the hard way.

Layer 4: WorkManager periodic watchdog

A PeriodicWorkRequest at 15-minute intervals that does the same thing — checks the service and restarts if needed. WorkManager survives service kills and uses JobScheduler under the hood, which OEMs are more reluctant to interfere with.

But there is a subtle trap: ExistingPeriodicWorkPolicy.KEEP silently discards new requests if a worker is already enqueued, even if the existing one has a stale timer from hours ago. And REPLACE resets the countdown every time you call schedule(). The solution: query getWorkInfosForUniqueWork() first and only schedule when the worker is not already enqueued.

val workInfos = workManager
    .getWorkInfosForUniqueWork(WATCHDOG_WORK_NAME).await()
val isEnqueued = workInfos.any {
    it.state == WorkInfo.State.ENQUEUED || it.state == WorkInfo.State.RUNNING
}
if (!isEnqueued) {
    workManager.enqueueUniquePeriodicWork(
        WATCHDOG_WORK_NAME,
        ExistingPeriodicWorkPolicy.KEEP,
        watchdogRequest
    )
}

Layer 5: Boot recovery

BOOT_COMPLETED, LOCKED_BOOT_COMPLETED, QUICKBOOT_POWERON, and MY_PACKAGE_REPLACED receivers that re-establish the service and all alarm chains after reboot or app update.

Some OEMs reset permissions after OTA updates. OnePlus, Samsung, Xiaomi, Redmi, and POCO all do this. You need to detect the OTA and re-prompt the user for battery optimization exemption.

Layer 6: SyncAdapter for process priority

ContentResolver.addPeriodicSync() gives your process elevated priority through the sync framework. OEMs are reluctant to kill sync adapter processes because the sync framework is a system concept — killing it could break contacts, calendar, and email sync.

This is a ~1-hour periodic callback that checks service health. It will not bring you back fast, but it is extremely hard for OEMs to suppress.

Layer 7: AlarmClock safety net

setAlarmClock() at 8-hour intervals — approximately 3 calls per day. This is the nuclear option. AlarmClock alarms get the highest delivery priority on Android because they are designed to wake users up.

Why 8 hours and not shorter? Honor's PowerGenie specifically tracks AlarmClock frequency. At 15-minute intervals, it flags you as "frequently wakes your system" and kills you. At 8-hour intervals (~3/day), you fly under the radar.

fun scheduleSafetyNet(context: Context) {
    val intent = PendingIntent.getBroadcast(
        context, REQUEST_CODE_ALARMCLOCK, intent,
        PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
    )
    val triggerAt = System.currentTimeMillis() + SAFETY_NET_INTERVAL_MS // 8 hours
    alarmManager.setAlarmClock(
        AlarmManager.AlarmClockInfo(triggerAt, null),
        intent
    )
}

Layer 8: Exact alarm permission recovery

When the user revokes SCHEDULE_EXACT_ALARM, all pending AlarmManager chains die silently. No callback, no exception. Your watchdog, your snapshot receiver, your safety net — all gone.

Listen for ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED and re-establish everything on re-grant:

class ExactAlarmPermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (canScheduleExactAlarms()) {
            ServiceWatchdogReceiver.scheduleWithBackup(context)
            MotionSnapshotReceiver.schedule(context)
        }
    }
}

Layer 9: Batched accelerometer sensing

This is the layer that surprised me most. Keep the accelerometer registered with maxReportLatencyUs during idle and deep sleep. The sensor HAL continuously samples into a hardware FIFO buffer and delivers readings via a sensor interrupt — this is completely invisible to OEM battery managers because it does not use AlarmManager, WorkManager, or any schedulable mechanism.

sensorManager.registerListener(
    batchedMotionListener,
    accelerometer,
    SensorManager.SENSOR_DELAY_NORMAL,
    maxReportLatencyUs  // 10 min in deep sleep
)

The HAL batches readings and delivers them all at once when the buffer fills or the latency expires. You get continuous motion awareness with zero wakes visible to the OEM.

One gotcha: a single SLIGHT_MOVEMENT reading (1.0-3.0 m/s^2) should not exit batched mode. Table vibrations and building micro-movements produce transient spikes. I require 3 consecutive SLIGHT_MOVEMENT readings (~15 seconds) before exiting. Anything above 3.0 m/s^2 (MODERATE_MOVEMENT) exits immediately.

Layer 10: Network restoration and app foreground triggers

CONNECTIVITY_ACTION receiver triggers a service health check when the network comes back. ProcessLifecycleOwner fires when the user opens the app. These are opportunistic — they catch edge cases where the service died during airplane mode or extended offline periods.

Layer 11: User-facing gap detection

When all 10 layers fail (and on some devices, they do), the app detects the gap and shows the user device-specific instructions: "Your [Manufacturer] phone is stopping background apps. Open Settings > Battery > [OEM-specific path] and disable optimization for How Are You?!"

This is the least satisfying layer because it requires user action. But on a few particularly aggressive OEM configurations, it is the only thing that works.

The wakelock tag problem on Honor

HwPFWService on Honor and Huawei devices maintains a whitelist of allowed wakelock tags. If your app holds a wakelock for more than 60 minutes with a tag that is not on the whitelist, HwPFWService kills your app.

The solution is embarrassingly simple: use a whitelisted tag on Honor/Huawei, your real tag everywhere else.

private val WAKELOCK_TAG: String = run {
    val manufacturer = Build.MANUFACTURER?.lowercase().orEmpty()
    if (manufacturer == "huawei" || manufacturer == "honor") {
        "LocationManagerService"  // Whitelisted by HwPFWService
    } else {
        "HowAreYou:PulseBurst"
    }
}

LocationManagerService is whitelisted because it is a system service tag. I am not proud of this, but it works.

getCurrentLocation() hangs forever

Once I had the service staying alive, I discovered a second problem: GPS does not work when you need it.

At approximately 12% battery on my Honor test device, the OEM battery saver silently killed GPS hardware access. No exception, no error callback, no log entry. The foreground service was alive, the accelerometer worked. But getCurrentLocation(PRIORITY_HIGH_ACCURACY) simply never completed. The Task from Play Services hung indefinitely — neither onSuccessListener nor onFailureListener ever fired.

The code fell back to getLastLocation(), which returned a 5-hour-old cached position from a completely different city.

Fix 1: Always timeout

Every getCurrentLocation() call must be wrapped in a coroutine timeout:

suspend fun getLocation(priority: Int): Location? {
    return withTimeoutOrNull(30_000L) {
        suspendCancellableCoroutine { cont ->
            fusedClient.getCurrentLocation(priority, token)
                .addOnSuccessListener { cont.resume(it) }
                .addOnFailureListener { cont.resume(null) }
        }
    }
}

Fix 2: Priority fallback chain

GPS hardware being dead does not mean all location sources are dead. Cell towers and Wi-Fi still work. I built a sequential fallback:

PRIORITY_HIGH_ACCURACY (GPS, ~10m)
    | timeout or null
PRIORITY_BALANCED_POWER_ACCURACY (Wi-Fi + cell, ~40-300m)
    | timeout or null
PRIORITY_LOW_POWER (cell only, ~300m-3km)
    | timeout or null
getLastLocation() (cached, any age)
    | null
TotalFailure

Each step gets its own 30-second timeout. In practice, when GPS is killed, BALANCED_POWER_ACCURACY returns in 2-3 seconds because Wi-Fi scanning still works.

Fix 3: GPS wake probe

Sometimes the GPS hardware is not permanently dead — it has been suspended by the battery manager. A brief requestLocationUpdates call can wake it:

if (hoursSinceLastFreshGps > 4) {
    val probeRequest = LocationRequest.Builder(
        Priority.PRIORITY_HIGH_ACCURACY, 1000L
    )
        .setDurationMillis(5_000L)
        .setMaxUpdates(5)
        .build()

    withTimeoutOrNull(6_000L) {
        fusedClient.requestLocationUpdates(probeRequest, callback, looper)
    }
    fusedClient.removeLocationUpdates(callback)
}

Five seconds, maximum once every 4 hours. On Honor, this recovers the GPS roughly 40% of the time.

Fix 4: Explicit outcome types

The original code returned Location?. The caller had no way to distinguish a fresh 10-meter GPS fix from a 5-hour-old cached position. I changed the return type to make the quality of data explicit:

sealed interface GpsLocationOutcome {
    data class FreshGps(val accuracy: Float) : GpsLocationOutcome
    data class WakeProbeSuccess(val accuracy: Float) : GpsLocationOutcome
    data class CellFallback(val accuracy: Float) : GpsLocationOutcome
    data class StaleLastLocation(val ageMs: Long) : GpsLocationOutcome
    data object TotalFailure : GpsLocationOutcome
}

Now the consumer can make informed decisions. A 3km cell tower reading is low precision, but it answers "is this person in the expected city or 200km away?" For a safety app, that distinction matters.

The sensor HAL lies about timestamps

At 3 AM, your app wakes up to check the accelerometer. You call registerListener(), and the sensor HAL returns data. You check event.timestamp against SystemClock.elapsedRealtimeNanos(). The delta is small. The data looks fresh.

It is not. It is 22-minute-old data sitting in the hardware FIFO buffer since the last time anyone read the sensor.

This is the normal behavior of hardware sensor FIFOs. When the CPU sleeps, the sensor continues sampling into its buffer. When you register a listener after wakeup, the HAL dumps the entire buffer contents at you. The timestamps are real (the readings were taken at those times), but the data is stale — it describes what happened 22 minutes ago, not what is happening now.

On most devices, you can catch this by comparing event.timestamp (CLOCK_BOOTTIME nanoseconds) against SystemClock.elapsedRealtimeNanos(). If the delta is large, the reading is stale.

Honor broke this assumption. On Honor devices, the HAL rebases event.timestamp on FIFO flush, so the delta check shows the data as fresh even when it is not.

The fix: flush, wait for callback, then collect

Do not trust the first readings after registerListener(). Instead:

Call sensorManager.flush(this) to drain the stale FIFO data
Wait for the onFlushCompleted() callback from SensorEventListener2
Only start collecting readings after the flush completes
Set a 1000ms fallback timer in case the HAL never fires the callback

class MotionSnapshotReceiver : BroadcastReceiver(), SensorEventListener2 {
    private var isFlushPhase = true

    override fun onSensorChanged(event: SensorEvent) {
        if (isFlushPhase) return  // Discard stale FIFO data
        collectReading(event)
    }

    override fun onFlushCompleted(sensor: Sensor?) {
        endFlushPhase(byHal = true)
    }

    private fun endFlushPhase(byHal: Boolean) {
        if (!isFlushPhase) return  // Guard against double-trigger
        isFlushPhase = false
        handler.removeCallbacks(flushFallbackRunnable)
        // Now start collecting real readings
    }
}

The fallback timer at 1000ms is important. I originally used 200ms, which was insufficient for Honor devices — their deep FIFO drains at approximately 16Hz, and a full buffer can take over 200ms to flush.

As a secondary safety net, I use dual-clock comparison: both CLOCK_BOOTTIME and CLOCK_MONOTONIC deltas must agree that the reading is fresh. If either delta exceeds 500ms of staleness, the reading is discarded.

A race condition in GPS processing

I had multiple independent trigger paths (stillness detector, smart GPS scheduler, area stability detector) that could request GPS concurrently. Two of them fired within 33 milliseconds of each other. Both read the same getLastLocation(), both passed the stationarity filter, and both inserted a GPS reading.

My code uses a minimum-readings-per-cluster filter to discard drive-through locations — a place needs at least 2 GPS readings to count as a real visit. The duplicate entry from the race condition defeated this filter. A single drive-by at 60km/h became a "cluster of 2."

The fix is a Mutex around the entire location processing path:

private val processLocationMutex = Mutex()

suspend fun processLocation(location: Location) {
    processLocationMutex.withLock {
        val lastLocation = getLastLocation()
        // The second concurrent caller now sees the just-inserted
        // location and correctly skips as duplicate
    }
}

Battery result

After all 11 layers and three tiers of power state, the battery impact is under 1% per day. The key numbers:

Before optimization: ~4,300 AlarmManager wakes per day. Every active-mode pulse (15s/30s) used AlarmManager. Every watchdog check (every 5 minutes) used AlarmManager. Honor flagged the app within hours.
After optimization: ~240 wakes per day. Active-mode pulses use Handler.postDelayed() (zero AlarmManager wakes). Watchdog intervals extended from 5 to 15 minutes. AlarmClock safety net reduced from every 15 minutes to every 8 hours.

That is a 94% reduction in system wakes while maintaining the same monitoring reliability.

The insight: aggressive scheduling wastes more battery than it saves in reliability. A three-tier power state that backs off when the device is still (active at 15-second pulses, idle at 5-minute pulses, deep sleep at 30-minute pulses with batched accelerometer as safety net) achieves both low battery impact and high reliability.

What I would do differently

Build the OEM compatibility layer first. I treated background reliability as something I would fix later. It took 40+ versions across several months to get right. It should have been the architectural foundation from Day 1.

Test on real OEM devices from the start. The Android emulator and Pixel devices tell you nothing about OEM battery management. I did not discover the Honor wakelock whitelist problem, the GPS hardware suspension, or the sensor FIFO timestamp rebasing until I tested on actual devices.

Never trust a single mechanism. Every Android background API has an OEM that breaks it. AlarmManager gets suppressed. WorkManager gets deferred. Foreground services get killed. The only reliable approach is layered redundancy where each mechanism independently tries to recover.

The app is called How Are You?! and is available on Google Play. It is still in early testing — if you have an elderly parent on Android and want to try it, I would appreciate feedback, especially from OEM devices I have not tested yet. Email: developer@howareu.app

I am happy to answer questions about any of these techniques. The OEM compatibility rabbit hole goes much deeper than what I have covered here.

Vector Similarity, Zero Client JS: Decoupled Analytics on a Side Project Budget

Sat, 28 Mar 2026 19:53:21 +0000

A leaderboard for DumbQuestion.ai sounds simple. Track the most asked questions, display them. Done. Except people never ask the same question the same way twice.

I was curious about how creative users of DumbQuestion.ai got with their questions, and I thought others might be as well. So I built a leaderboard of the most frequently asked dumb questions.

The Overqualified persona calls it THE ARCHIVE OF INCOMPETENCE.
The Weary persona calls it THE WALL OF REGRET.
[REDACTED] calls it THE WATCHLIST.
The Compliant calls it THE WALL OF EXCELLENCE (bless its reprogrammed heart).

Building it turned out more interesting than it sounds.

The Product Challenge

People ask the same dumb question in a hundred different ways. "What is 2+2?" and "can you add two plus two for me?" are functionally identical. A simple string counter would give you noise, not signal. I needed semantic matching, not string matching.

This is a solved problem in the ML world, but the typical solutions come with tradeoffs: heavyweight models, expensive APIs, or significant latency added to the critical path. None of those fit a "brutally efficient" side project.

The Solution: Vector Similarity on a Budget

Each question gets run through an embedding model and compared against a Qdrant vector database. Qdrant's free tier is remarkably generous for a side project workload, but self-hosting is trivially easy if you need it.

The matching logic is straightforward:

Generate an embedding for the incoming question
Compare against existing embeddings using cosine similarity
If similarity exceeds a threshold, increment that question's counter
If it's new, add it to the database
The first instance of a question becomes the official display version

The embedding call costs fractions of a cent. The similarity comparison is fast. The result is a leaderboard that actually understands context rather than just matching strings.

The key architectural decision: None of this runs in the main app.

Adding vector similarity matching to every request would add latency, bloat the container, and burn more compute. Anti-pattern to the "brutally efficient" principle I've been following throughout. Instead, every question flows through the console output, gets picked up by a Vector sidecar container, routed through GCP Pub/Sub, and processed asynchronously on my Mac Mini home server (more later).

The Mac Mini handles the Qdrant comparisons and updates a JSON file in Cloudflare R2 storage. When a user hits the leaderboard page it loads directly from R2. No live database queries. No per-request costs. Essentially free page loads at any scale.

What Ended Up on the Leaderboard?

As early users started using the app, the leaderboard filled up with exactly what you'd expect: actual dumb questions, a handful of self-awareness probes, and more than a few prompt injection attempts.

Apparently people read this series and went straight for the easter eggs.

The leaderboard was just one piece of a larger analytics picture. Building it taught me something useful: the most interesting features don't always belong in your main app. That same principle shaped the entire analytics stack.

The Observability Problem

Running a side project means making real product decisions with limited data. Are people actually asking questions or just bouncing off the homepage? Which sites are driving traffic? Are ads being seen, clicked, ignored?

Two constraints shaped the solution: no client-side JavaScript (page bloat is the enemy of brutal efficiency) and no SaaS analytics bill that spikes with usage.

So I built (assembled, really) my own stack from open source tools. On a Mac Mini sitting at home.

The Full Pipeline

Every event in DumbQuestion.ai emits structured telemetry to standard console output:

HTTP requests (method, path, status, duration)
Questions asked (anonymized)
Searches performed
LLM operations (model, token counts, duration, cost)
Prompt injection attempts
Custom product events (Question Asked, Shared, Ad Shown, Ad Clicked)

The Go/GIN framework handles much of the HTTP telemetry automatically. The rest is custom instrumentation added deliberately at key points in the application.

A Vector sidecar container picks up the console output and routes it to GCP Pub/Sub. This is the critical architectural decision: Pub/Sub acts as a resilient buffer between the main app and everything downstream. The Mac Mini can go down, lose power, or restart. Once it comes back up, the stack picks up exactly where it left off. No data loss, no backfill scripts, no drama.

From Pub/Sub, a second Vector instance on the Mac Mini routes to two primary targets:

Plausible handles user behavior and product analytics:

Page views and session depth
UTM tag tracking (know exactly which article drove which visit)
User journey depth (did they just hit the root page or actually ask a question?)
Browser, device type, country of origin
Custom events: Question Asked, Shared, Ad Shown, Ad Clicked

All of this without a single line of client-side JavaScript. No tracking scripts, no page weight, no GDPR cookie banners for analytics. Pure server-side telemetry piped through the same pipeline as everything else.

Parseable handles the operational side:

LLM performance metrics and cost tracking by day
Ad CTR dashboards
Log aggregation for debugging and incident investigation

Think of it as Plausible for the product lens, Parseable for the business and ops lens.

The Resilience Payoff

I've had power outages. Slowdowns. The occasional restart. Every time, the stack catches up from where Pub/Sub left off without any manual intervention.

This isn't accidental. Designing around failure rather than pretending it won't happen is the difference between a toy and a production system. The GCP Pub/Sub buffer was a deliberate choice specifically because I knew the downstream consumers (Mac Mini, Qdrant, Plausible, Parseable) were running on non-guaranteed infrastructure.

Even on a Mac Mini, you can build something production-grade. You just have to design for it.

What I Learned

Two things surprised me building this:

First: How much you can accomplish by treating console output as a first-class telemetry stream. No SDKs, no agents baked into the app, no client-side scripts. Just structured logging and a pipeline that knows what to do with it.

Second: How much the "keep it off the critical path" principle scales. It started as a constraint (keep the main container lean) and became a design philosophy. The leaderboard, the analytics - none of it runs in the main app. All of it works reliably because the main app doesn't have to care about it.

AI helped build all of it. But knowing what to measure, where to put the seams, and how to design for failure? Still the interesting (and super fun) part.

dumbquestion.ai

ShipWithAI #11 — Turn Repetitive Client Work Into a Productized Feature in One Day

Wed, 12 Nov 2025 10:58:35 +0000

Turn your manual consulting tasks into a repeatable, sellable AI-powered workflow. Perfect for indie devs, PMs, and engineers building solo SaaS tools.

Steps:
• Review 5–10 past client jobs and list the inputs, decisions, and outputs.
• Find the 80% of steps that repeat across projects — that’s your core feature.
• Sketch a simple pipeline: Input → Validation → AI Judgment → Output.
• Separate rule-based logic from AI steps, and wrap AI calls with guardrails.
• Expose one clean contract — an API route or upload UI with job tracking.
• Add basic metering and pricing (e.g., per file or per job) to start charging.

Gotchas:
• Don’t chase edge cases — they kill your launch speed.
• Don’t skip validation or monitoring — AI without guardrails breaks trust fast.

Do this today:
• Pick one deliverable you’ve repeated at least twice.
• Write its input → steps → output on a page.
• Draft your first pipeline and test it with one real user.

Full guide →

ShipWithAI #10 — Accept Stripe Payments in 4 Steps (MVP-Ready)

Sat, 08 Nov 2025 09:40:24 +0000

Get subscription payments working in your side project without building custom checkout flows.

Steps:

• Embed Stripe's pricing table component with your user's ID as client_reference_id and their email

• Set up checkout.session.completed webhook to capture subscription_id and link it to your user in your database

• Listen to customer.subscription.created, updated, and deleted webhooks to keep local subscription status in sync

• Add Stripe's customer portal link so users can manage their own subscriptions, upgrades, and cancellations

Gotchas:

• Skipping client_reference_id breaks everything—you won't know which user owns which subscription

• Don't query Stripe's API on every request to check subscription status—maintain a local copy instead

Do this today:

• Copy Stripe's pricing table script into your app and pass user ID + email

• Create one webhook endpoint for checkout.session.completed

• Store subscription_id with your user record when checkout completes

Full guide → https://shipwithai.substack.com/p/add-stripe-payments-in-4-steps-mvp?utm_source=linkedin&utm_medium=legion_newsletter&utm_campaign=20251108

ShipWithAI #8 — Ship a One-Feature MVP in 1 Week

Wed, 24 Sep 2025 17:40:21 +0000

Build and validate a one-feature MVP fast. This is for solo devs using AI to move from idea to proof without overbuilding.

Steps:
• Pick one job story with a clear success metric
• Use AI to draft a one-page spec (journey, UI, API, tests, not-doing list)
• Slice to essentials: one screen, two endpoints, three tests, one metric
• Test with real users or fake doors for quick signal
• Assess the metric: pass → add one adjacent feature; fail → tighten flow and retry
• Run the loop again until you hit the metric

Gotchas:
• Don’t waste time on auth, dashboards, or settings before value is proven
• Don’t validate based on vibes—only on your metric

Do this today:
• Write a job story using the “When / I want to / so I can” format
• Define one numeric success metric
• Run the AI one-pager prompt and trim it to one screen