A native macOS screen recording app that handles recording, editing, and sharing in one place. Record your screen, camera, and audio as independent tracks, polish with professional effects, and share with a link — no Electron, no cloud dependency, no bloat.

🌐 shipclip.app

The Problems

1. Bloated tools: Most screen recording apps are Electron wrappers or cloud-first SaaS products that feel sluggish and phone home constantly.

2. Post-production pain: Getting polished results (zoom-to-click, camera PiP, click indicators) usually means bouncing between multiple apps.

3. Privacy concerns: Many recording tools upload your content by default or require accounts just to record.

The Solution

ShipClip handles the full workflow natively on macOS — capture, edit, and export without leaving the app.

Recording — Full screen or single window at 60 FPS. Screen, system audio, microphone, and camera are captured as completely independent stems for full control during editing.

Timeline editing — Non-destructive split, delete, mute, and solo operations with waveform visualization. Per-track volume control and audio mute regions. Draggable playhead and automatic time ruler scaling.

Visual effects — Zoom-to-click with configurable zoom level (1x–3x) and smooth cubic easing. Click indicators with color-coded pulses (left/right click), optional click sounds, and cursor pulse animation. Custom cursor rendering with type detection (arrow, I-beam, pointer, resize).

Camera PiP — Draggable picture-in-picture overlay recorded at 1080p. Background effects including Gaussian blur, person segmentation via Vision framework, solid color replacement, and full background removal. Keyframe-based positioning over time. Configurable size, corner radius, and frame styling.

Screen styling — Canvas padding, rounded corners, and backgrounds (solid color, linear gradient with angle control, or custom image).

Export — MP4 (H.264 + AAC) at native resolution and 60 FPS by default, with configurable resolution and frame rate for smaller file sizes and better web performance.

Sharing — One-click upload to shipclip.app with shareable links and a web player. Local export to ~/Movies/ShipClip/ always available.

Technical Stack

• App: Swift, SwiftUI, ScreenCaptureKit, AVFoundation, Metal for GPU-accelerated compositing, Vision framework for person segmentation

• Backend: .NET 9 Web API with PostgreSQL, Stripe billing, S3/R2 storage

• Frontend: Next.js + shadcn/ui for the landing page, account management, and web player

• Infrastructure: Docker on Kubernetes (k3s), CI/CD via GitHub Actions

• Updates: Sparkle auto-update framework with EdDSA-signed, notarized DMGs

Architecture

ShipClip uses a stem-based architecture where each input (screen, system audio, mic, camera) is recorded independently and composed at playback and export time. A custom AVVideoCompositing implementation handles real-time effects rendering — the same Metal compositor powers both the timeline preview and the final export, so what you see is exactly what you get.

Sessions are stored as discrete stems (screen.mov, system_audio.m4a, mic.m4a, camera.mov) with a session.json manifest and auto-saved edits.json for non-destructive editing state.

Not to cheat. To learn. Voice control seemed like a way to explore what the plugin API actually exposes without crossing ethical lines. I'd build something that required a human in the loop, and in the process, I'd see exactly what an automation developer sees.

What I found: botting isn't a detection problem. It's a client control problem. And it won't be solved until Jagex ships an official plugin API.

Video version: [VIDEO_LINK_HERE]

TL;DR: RuneLite isn't bad, Jagex isn't lazy, and "detect better" isn't the answer. This is the cost of the community picking RuneLite over the official client.

Live stats: Tracking RuneLite adoption after the Java client shutdown

What I Built

I created a new ironman account, voicescaper, and set out to play the game by voice.

The tool has two pieces. A RuneLite plugin reads game state: where NPCs are, what's in my inventory, which tiles are walkable. An external application listens for speech, transcribes it locally, and translates commands into mouse clicks. Everything runs on my machine. No cloud services, no data leaving my computer.

Playing as voicescaper was humbling. I chopped trees, mined ore, talked to NPCs, attacked cows. The kinds of things you do in the first hour of any account. It worked, mostly. But voice recognition is unforgiving. "Attack cow" sometimes became "a tank cow." Pathfinding meant saying "move five tiles north" and hoping I'd counted right.

After an hour, I was exhausted from talking and went back to clicking.

The Moment It Clicked

But then I started thinking about what I'd actually built.

The plugin has access to complete game state. The external application can click anywhere on screen. The only thing making this a voice control tool instead of a bot is that a human provides the intent.

I didn't build autonomous automation. But the architecture would trivially support it. Swap out voice recognition for a decision loop, and you have a bot. The structural pieces are identical.

This is the core insight: the plugin API that enables quest helpers and ground markers also exposes everything automation needs. The hard part of botting, understanding what's happening in the game, is already solved by the same infrastructure that makes RuneLite useful.

Why This Matters

When people talk about botting, the instinct is "detect better" or "ban harder." But detection has structural limits.

Jagex can only see what reaches their servers: clicks arriving at plausible speeds. They can't see what's running on your machine, what plugins are loaded, or whether a human decided to click or a script did. From their side, a bot with full game state access looks identical to a player.

That's the problem. It's not that Jagex isn't trying. It's that the information they'd need to distinguish automation from legitimate play doesn't exist at the server level.

The Automation Landscape

There are several ways people automate OSRS. Understanding them helps clarify where Jagex has leverage and where they don't.

Network bots talk directly to Jagex's servers. No client, just raw packets. In theory, Jagex could change the protocol anytime. In practice, breaking RuneLite (which reverse-engineers the same protocol) creates friction.

Memory bots attach to the running client and read game state from RAM. The standard defense is kernel-level anti-cheat like Vanguard or EasyAntiCheat. But that's invasive software, and you can't mandate it for a third-party client you don't control.

Auto-clickers are simple input macros. These are actually detectable. Clicking the same pixel every 1.8 seconds for five hours is statistically obvious. But the moment automation has access to game state, it can vary timing and position to look human.

Client plugins are where I operated, and where Jagex has the least leverage. The RuneLite API exposes complete game state. Anyone can fork the client, write unreviewed plugins, or bridge data to external programs. Jagex can't see what plugins you're running. They can't verify your client is legitimate.

Everything I built used public APIs. I didn't reverse-engineer anything. I used the same tools as tile markers and quest helpers.

What OSRS Can Learn from WoW

World of Warcraft has supported add-ons for over twenty years. Thousands of developers. Deeply customizable UI. A massive plugin ecosystem.

And yet, WoW's add-on system doesn't meaningfully lower the barrier to automation. Not because Blizzard detects better, but because the API is intentionally constrained.

Like RuneLite, WoW add-ons can't generate input. No fake clicks or keypresses. The difference is everything around that constraint.

WoW add-ons run in a sandbox. They can display information and help you make decisions, but they can't hand that information to external programs. There's no bridge. If you want to build a WoW bot, you have to leave the add-on system entirely: memory reading, injection, OS-level input spoofing. Techniques that are harder to build and easier to detect.

RuneLite is different. Plugins run in a full JVM with access to complete game state. A plugin can trivially act as an oracle, packaging up coordinates, NPC positions, and interface state for whatever external tool wants to consume it. The plugin doesn't click. But it makes clicking programmatically easy.

Imagine if RuneLite's entity highlighter could show you where the fishing spot is, but couldn't tell an external program its exact screen coordinates. That's roughly what WoW enforces.

WoW has quest helpers too. Questie, RestedXP. But notice how they work: targeting icons, minimap markers, on-screen directions. Not direct entity outlines with pixel-perfect coordinates exposed to the API. Different levels of access. And critically, the data can't be bridged out.

Jagex needs an official client with a plugin API designed like WoW's. One that lets you build helpful tools without also enabling automation.

The Accessibility Angle

Somewhere along the way I realized what I'd built had legitimate uses beyond my experiment. OSRS requires thousands of clicks per hour. That's fine if you have full use of your hands. It's a barrier if you don't.

Voice control isn't a competitive advantage. It's slower and less precise than a mouse. The human is still playing, still making decisions. The interface just changes how input is provided, not who provides it.

The uncomfortable part is that the same infrastructure supports both. An accessibility tool and a bot differ only in what drives decisions. Distinguishing between them technically is extremely difficult.

Why Jagex Is Stuck

Jagex isn't lazy. They tried.

In May 2018, Jagex told RuneLite to shut down. Not "remove these features." Shut down entirely. When Adam, the developer, asked what specifically violated their terms so he could fix it, Jagex wouldn't say. The demand was: close by the end of the week.

The community erupted. RuneLite had already become essential. Jagex backed down.

That moment forced a choice: client control or player retention. They chose openness. Botting became harder to fight as a direct result.

In June 2022, Jagex formalized the compromise with an approved client list. Only RuneLite and HDOS are permitted. Everything else gets you banned.

But an approved list doesn't give Jagex technical leverage. They still can't see what plugins are running. They still can't verify inputs came from legitimate play. They just narrowed the field of clients they're not actively fighting.

Update (January 28, 2026): The legacy Java client had been deprecated for years. Jagex's reasoning for finally retiring it: "the vast majority of users are botting." When the switch flipped, tens of thousands of accounts vanished from the player count overnight. This proves Jagex can still act decisively—but notice what they could act on: a client they control. RuneLite and HDOS remain untouched. I'm tracking RuneLite adoption to see if those bots migrate.

The Roadmap

RS3 is getting an official plugin API in 2026. Jagex announced a dedicated team building it.

Old School started down the same path. In July 2024, they announced a plugin API in development, built in collaboration with established plugin developers.

Then they paused it to prioritize HD rendering and mobile improvements.

I get it. HD and mobile are visible features. A plugin API is infrastructure. Hard to put in a trailer.

And to be fair, finishing the new renderer lets them retire legacy code. That cleanup positions them to build the API properly.

But infrastructure is how you solve this long-term. The anti-bot leverage that comes from client control doesn't exist until the API ships.

RS3 is getting this in 2026. Old School should too.

The Uncomfortable Reality

There are three paths forward.

Ban third-party clients. Close the vulnerability, lose a huge chunk of players. RuneLite isn't optional for most of the community anymore.

Keep the status quo. Third-party clients stay legal. Botting stays viable. The cat-and-mouse continues indefinitely.

Reclaim the client with a constrained plugin API. This is the only sustainable option. But it requires Jagex to control the runtime and define the extension boundaries. Copying RuneLite's features isn't enough. The API itself needs different constraints.

With client control, Jagex can ask "did this come from software we trust?" instead of "does this look human?" That's a different question. Bots are much worse at answering it.

There's a world where plugins exist and botting becomes meaningfully harder. It just can't be built on third-party clients.

Why I'm Writing This

Some people will read this and think I'm enabling botters. I'm not.

The dynamics I'm describing are already well understood by people who build bots. I'm explaining them to everyone else: players frustrated by gold farmers, community members who think Jagex isn't trying hard enough.

You get a remarkable plugin ecosystem and major quality-of-life improvements. You also get an automation surface that can't be fully closed. These aren't separate issues. They're the same architectural choice, viewed from different angles.

A Note on Implementation

I'm deliberately not providing technical specs or library names beyond what's necessary to make the argument.

The goal is to explain why the botting problem is structural, not to hand out a reference implementation. Anyone determined to build automation doesn't need my help.

The tool runs entirely locally. No cloud services, no data collection.

What I'd Like to See

Unpause the plugin API. HD is great. Mobile matters. But the API is how you get long-term leverage. It should be a priority.

Design it with WoW's lessons in mind. Intentional limits. A sandbox that exposes information without exposing control. Protected functions that can't be called programmatically.

Work with RuneLite. The RuneLite team built something remarkable. They understand what plugins need. Collaborate on what a healthy API looks like.

If anyone at Jagex wants to talk about client architecture or plugin tradeoffs, I'm available. I'm not interested in enabling gold farmers. I love this game and want it to be around for a long time.

Also, if you're hiring for the bot-busting team, I'd love to help.

References

• RuneLite threatened to shutdown (May 2018)

• Reddit thread on shutdown threat

• "Why Jagex Tried To Sue RuneLite. The True Story" by ColonelloRS

• "How Cheaters Defeated RuneScape's Best Bot Detection" by ColonelloRS

• "I Interviewed Adam the Founder of RuneLite" by Crumb

• "this trend in gaming makes me very concerned." by LowLevelTV

• "i was right (again)." by LowLevelTV

• WoW Secure Execution and Tainting (Wowpedia)

• WoW AddOn Security Discussion (WoWInterface)

• Jagex third-party clients update (June 2022)

• New official client announcement (July 2023)

• Official client update, plugin API announced (July 2024)

• RS3 2026 roadmap, plugin API confirmed

• OSRS Winter Summit 2026, HD prioritized, plugin API paused

• Java Client discontinued, "vast majority of users are botting" (January 2026)

• Java Client history (OSRS Wiki)

• Reddit: "Bot Nuke 2026" - 55,000 players vanished overnight

I set out to understand why OSRS has a botting problem. I ended up learning it's architectural, not a detection problem. And it won't change until Jagex controls the client.

Last week, I handed in my notice and walked away from my golden handcuffs. I'm leaving $200k in unvested stock left on the table.

Is that wise? Depends on what you value.

I wasn't seeing my wife or toddler, I wasn't building anything for myself anymore, and I was watching my goals evaporate in a cloud of Slack pings and badge swipes.

So I made the call. I'm going back to a remote job, and setting a five year goal to earn $200k from side projects instead.

What Happened

I was hired as a hybrid 2 days a week in office role. Then the stock price shot up. Then came the RTO (return to office), the reorgs, the demands, the culture. You know the story.

At first, I thought I could power through. I'd just keep stacking cash, ride the vesting curve, buy time later. And I did hit the vesting cliff. I've got some equity in my pocket. But the rest? The real upside? That's more time, more sacrifice, more office.

Meanwhile...

Side projects? Dead.

Weeknights? Gone.

Weekends? Recovery mode.

Family time? Maybe two hours a day, and I wasn't even present for half of it.

At some point, I realized I was working for a version of me that doesn't exist anymore.

The Tradeoff

$200k is a lot of money. It's painful to walk away from. But stock isn't just money. It's a bet. And in my case, it was a bet that required me to burn out slowly over the next few years.

Meanwhile, my kid is growing up now. My wife and I are trying to build a life with margin, not just money. I've spent 15 years learning how to build. It's time to apply it to something that's mine.

So here's the new goal:

Make $200k from side projects by 2030.

Not overnight. Not with a viral launch or SaaS rocketship.

Slow. Intentional. Profitable from the start. Built to last.

Side Contracts

In addition to building product, I'm also leaning on my freelance brand, Ligma Digital, to bring in revenue from consulting and dev work. I've already built a lead gen bot. So far, I've got a few warm leads and potential contracts in the $10k+ range.

And now that I'm going remote again, I get back about three hours a day on weekdays that used to vanish into commuting and office overhead. That's over 750 hours a year.

Even if I bill just a portion of that time, I should exceed the $200k target by a wide margin. And the rest of the hours? I get to spend them with my family or invest in building something real.

First Project: Andon Lamp

You know how you're constantly alt-tabbing to check if your AI tool is done thinking?

Andon Lamp fixes that. It's a desk device that glows based on your AI assistant's status. You can stay in flow, keep your hands on the keyboard, and stop babysitting the process.

I built it with a Rust CLI, a Raspberry Pi Pico, and a string of RGBW LEDs.

It's vibey. It's functional. It's already saving me context switches.

🎥 Watch the demo →

Pre-order at getandon.com →

Who This Is For

This mission isn't just about me. It's for:

• Developers who want out of the full time trap

• Parents who don't want to miss the good stuff

• Builders who've flopped a few projects but still have the itch

If that's you: hey. Let's build in public together.

Follow Along

I'll be sharing everything here:

• Revenue numbers

• Project breakdowns

• Monthly updates

• What works (and what definitely doesn't)

📬 Join the email list below →

📺 Subscribe on YouTube →

0 / 200k. One step at a time.

The evolution of DeskThang - a comprehensive LED status indicator system built for Raspberry Pi Pico, designed to provide visual feedback for AI agent states and general status monitoring.

🌐 Visit getandon.com for the complete experience.

The Evolution

Andon builds upon the foundation established by DeskThang, pivoting from a complex LCD-based system to a focused, reliable LED status indicator. While DeskThang explored many concepts, Andon represents a refined vision with clear purpose and production-ready implementation.

Key Features

• RGBW LED Strip: 38 SK6812 LEDs with individual control

• Status Indicators: OK (green), Warning (yellow), Error (red), Info (blue)

• Desk Lamp Mode: White balance control for ambient lighting

• AI Integration: MCP server for direct Claude and AI system integration

• Patterns: Rainbow, chase, fade, pulse, and custom effects

Technical Stack

• Firmware: C code running on Raspberry Pi Pico with modular architecture

• Host Application: Rust CLI for cross-platform USB communication

• MCP Server: Node.js server for AI system integration

• Hardware: RP2040 microcontroller, SK6812 RGBW LED strip, USB connection

Design Philosophy

1. Focused Purpose: Clear visual status indication without complexity

2. Modular Architecture: Clean separation of concerns and maintainable code

3. AI-First: Built specifically for AI agent workflow integration

4. Production Ready: Reliable hardware and robust software

Command Interface

# Status control
andon-cli status ok          # Green pulsing
andon-cli status warning     # Yellow pulsing
andon-cli status error       # Red pulsing
andon-cli status clear       # Clear status

# Desk lamp mode
andon-cli lamp on            # Ambient lighting
andon-cli white 200          # White balance control

Current Status

Andon is actively developed with stable firmware, cross-platform host application, and comprehensive AI integration through MCP.

Visit getandon.com to get started, or check out the DeskThang project to see where it all began.

Professional freelance software development and technical consulting services, delivering custom solutions for modern web applications, embedded systems, and AI integrations.

🌐 Visit ligma.digital for services and portfolio.

Services Offered

Web Development

• Full-stack applications using modern frameworks (Next.js, Vue.js, React)

• Backend APIs and microservices (.NET, Node.js, Python)

• Database design and optimization (PostgreSQL, MongoDB)

• Cloud deployment and DevOps (AWS, Docker, CI/CD)

Embedded Systems

• Firmware development for microcontrollers (RP2040, ESP32)

• Hardware prototyping and PCB design

• IoT solutions and sensor integration

• Real-time systems and communication protocols

AI Integration

• Custom AI tool development and automation

• Model Context Protocol (MCP) server implementation

• Workflow optimization and intelligent systems

• AI-powered application features

Technical Expertise

• Languages: Rust, C, JavaScript/TypeScript, Python, C#, Zig

• Frameworks: Next.js, Vue.js/Nuxt, .NET, Express.js

• Databases: PostgreSQL, MongoDB, Redis, SQLite

• Cloud: AWS, Docker, Kubernetes, CI/CD pipelines

• Hardware: Raspberry Pi Pico, Arduino, PCB design, 3D printing

Project Approach

1. Discovery: Understanding requirements and technical constraints

2. Architecture: Designing scalable, maintainable solutions

3. Development: Iterative development with regular client feedback

4. Deployment: Production-ready deployment with documentation

5. Support: Ongoing maintenance and feature development

Recent Work

• AI-Powered Applications: Custom MCP servers and intelligent automation tools

• Embedded LED Systems: Hardware and firmware for status indication devices

• Web Platforms: Community-driven applications with modern tech stacks

• Hardware Prototypes: Custom PCB design and embedded system development

Current Availability

Accepting new projects with focus on:

• AI integration and automation solutions

• Embedded systems and hardware projects

• Modern web application development

• Technical consulting and architecture review

Contact ligma.digital to discuss your project requirements and get a custom proposal.

The Work Dilemma

In enterprise software, the pressure is always the same: deliver more, deliver faster. But at the same time, the systems you rely on are off-limits. You're not allowed to poke around in the guts, even if those guts are on fire. Priorities are set by the product team, and internal tooling always comes last, if it's ever considered at all.

Tech debt? We'll talk about that later, but later never comes. The opportunity cost of fixing what's broken is always weighed against shipping new features. "We can't spend two sprints refactoring when we could be building the new analytics dashboard!" Never mind that the current dashboard is held together with duct tape and prayers. The pressure to never look back, to never clean up what you've built, turns your codebase into a game of Jenga that nobody wants to touch.

You're expected to run a race, but you're not allowed to lace your own shoes. Or check if they're on the right feet. Or if you're even wearing shoes.

The Epiphany: Build Your Own Tools

The epiphany didn't come from writing code, it came from woodworking.

In the shop, it's completely normal to spend hours building templates or jigs before making a single real cut. A botched cut on a $300 slab can blow the whole project (and your weekend). So you invest in the things that reduce risk and make future work easier, even if that means stopping to build the tools first.

That same mindset clicked for me at work. If I'm tripping over the same problem more than once, that's a sign: build the tool. Make the jig. Automate the annoying part. Future You will say thanks. Present You will at least grumble less.

It's not rebellion, it's just how you get things done when the system around you won't help.

DeskThang: A Case Study

I've been working on a little project called DeskThang, a physical device that lives on your desk and quietly tells you what you care about.

• CI pipeline failed? Red flashing

• Stripe sale? Purple pulse

• Cursor's agent mode is waiting for you? Blue glow

• Want something else? Fully scriptable from bash:
  
  

  deskthang led 00ff00    # Set LED to green
  deskthang image test.png # Display an image
  

  
  

It's scriptable, open-source, works over USB, and doesn't spy on you. Designed for people like me, devs who want ambient context without Slack pings, browser tabs, or pulling out a phone to get sucked into the void. (deskthang.com)

I started with a 3D-printed enclosure, which works well to show off the concept. But I want more. I want something beautiful, a device I'll be proud to leave on my desk. Something with wood, weight, and actual presence.

So I set out to build a wooden version.

That meant learning how to kerf-bend 1/8" Baltic birch plywood. Mine is made up of three layers. The trick is to cut just deep enough, through about 1.75 layers, so the outer veneer stays intact and bends without snapping. We're talking about a margin of error of 0.2mm-cut 1.8mm when you need 1.6mm and it snaps. Go too shallow at 1.4mm and it won't bend at all. Every cut has to be that precise, dozens of times across the piece.

Then comes the steaming. You've got to soften the wood before shaping it into curves. Only after it cools and dries do you get to see if your spacing and depth were consistent enough to hold a clean bend.

It's taken a lot of trial and error, but each iteration got better as I improved my process. Without the sleds, the jigs, the templates, and without CAD and Blender for modeling and fit checks, it wouldn't be possible. It's the same mindset as building software tools: remove the friction, one annoying detail at a time.

Same lesson: when the process sucks, pause and build the thing that makes it suck less.

Bonus: now I get to pretend I'm an old-world craftsman and ship functional hardware.

Next post: we'll get into epoxy resin art and building custom light pipes for the wooden version. I've got some glow experiments queued up.

Why This Matters

At work, no one's going to hand you the time or space to fix broken workflows. But you can sneak efficiency in through the side door. A script here. A CLI tool there. A bit of automation no one asked for, but everyone mysteriously starts using.

At home, you can go even further. You can build for joy. You can experiment. You can turn a bad cut into a better jig.

Tools aren't just about speed, they're about predictability. Predictable means repeatable, repeatable means reliable, and reliable means fast.

Every tool you build removes guesswork, smooths friction, and transforms uncertainty into clarity. And clarity is always quicker.

Closing Thought

If something keeps slowing you down, stop. Step back. Ask yourself: could I build something that fixes this?

Whether you're coding, crafting, cooking, or managing a team, the principle stays the same: when friction slows you down, build the tool that speeds you up. The solution might be a script, a jig, a checklist, or a new process-but the mindset of building your own tools applies everywhere.

More often than not, the answer is yes, and no one else is going to do it for you.

TTRPG List is a web platform dedicated to helping tabletop role-playing game (TTRPG) creators share their work and players discover new adventures, free from the shadow of mainstream titles.

The Problems

1. Overshadowed Creativity: Countless innovative TTRPGs struggle to find an audience because they're buried under popular, big-budget games.

2. Disconnected Communities: During times of isolation, like the COVID-19 pandemic, finding meaningful ways to connect through games was a challenge.

3. Corporate Influence: Large platforms often prioritize profit over passion, leaving indie creators without a voice.

The Solution

TTRPG List is a simple, community-focused site that:

• Allows creators to submit and feature their games

• Provides a searchable database of TTRPGs with tags and systems

• Encourages discovery through a clean, user-friendly interface

• Fosters a space for players and creators to connect over unique, imaginative games

Technical Stack

• Frontend: Vue.js with Nuxt for a fast, server-rendered, and responsive user interface

• Backend: .NET API for robust server-side logic and user management

• Database: PostgreSQL for reliable storage of game data, tags, and systems

• Storage: Amazon S3 for hosting game images and assets

• Email: SendGrid for sending registration, notification, and update emails

Design Philosophy

1. Community First: A platform built for and by the TTRPG community, not corporate interests.

2. Transparency: Open about the solo development process and how featured content supports the site.

3. Simplicity: Easy navigation and submission process to encourage participation.

4. Imagination Unleashed: A focus on games that push boundaries and explore new ideas.

Features

TTRPG List offers:

• Game Submission: Creators can add their games with details, tags, and links.

• Search and Filter: Players can browse by tags (e.g., "fantasy," "sci-fi") or systems (e.g., "D20," "PbtA").

• Featured Games: Optional promotion for creators to boost visibility.

• User Accounts: Basic login/register system for submitting and managing content.

Example usage:

• A player searches for "solo TTRPGs" and finds a hidden gem.

• A creator submits their game with tags like "horror" and "narrative," reaching new fans.

Current Status

This project is a solo labor of love, actively maintained with plans for growth:

• Enhancing search functionality with advanced filters

• Exploring community forums for discussion and feedback

• Adding tools to assist creators in game development

• Keeping the site sustainable through optional featured content

Follow my journey on Bluesky (bsky.app/profile/nemo.foo) or reach out at nemo@ttrpglist.com to share ideas and feedback!

I'm 4 days into an afternoon project. I was so sure I'd crush this one. I had a good plan and the stoke was high. Let me introduce Deskthang. It's a thang for your desk. When I work, I want to put my phone in the other room, and only get the important notifications (thangs) in a different way. If my deployment pipeline fails, I want a globe on my desk to turn red and show me a gitlab logo. I do not want to check my phone or email or anywhere a distraction might find me.

Quick backstory: I work full time++ doing boring enterprise software dev and rarely get to flex my engineering skills. While my title says engineer, I'd disagree.

The Problem I'm Trying to Solve

I always try to align multiple interests for a side project. I wanted to pull my electronics hardware box out of storage, I wanted to solve the notifications and focus issue for myself, and I wanted to see how scared I should be about AI taking my job. As they say, I was trying to get a few birds stoned at once.

1. I miss working with hardware.

During COVID lock-downs I landed an R&D contract for a IoT Prototype. That R&D job was the most fulfilling work of my career. I worked with a small, scrappy team with some of my best friends. I was 3D printing models, soldering components, writing embedded C, and field-testing with mechanical engineers... Real engineers. We worked hard, often late into the night, and the collaboration felt more like playing StarCraft with the boiz than a 9-to-5. I've missed that deeply ever since. Recently, I've been inspired recently by @_MaxBlade and DeskHub and wanted to brush the dust off my electronics skills.

2. I hate the UX of MFA (Multi Factor Authentication).

I use GitLab heavily for CI/CD with my personal Kubernetes projects. Knowing the status of my pipelines is crucial... broken builds could disrupt all 7 of my users! Logging into GitLab feels like getting stabbed in the spleen. Every time I log in (multiple times a day), I face captchas, authenticator apps, or waiting for email codes, followed by yet another captcha. I've tried pipeline notifications through Slack, Discord, and Telegram, but those apps are like productivity black holes. I don't want my phone near me while working, or to open chat apps that derail my focus. Removing these distractions keeps me locked in.

3. I want to see how good these AI tools are.

I want to figure out if AI is going to take my job. I'm skeptical it can replace what I do, but I like testing my assumptions. Sometimes AI surprises me; other times, it's just a rabbit hole of wasted hours when I avoid doing real thinking.

Recently, I used Claude Sonnet 3.5 to brute-force hundreds of React compile errors while upgrading a project from React 15 to 18. I threw package.json updates, deleted node_modules, and burned through a small fortune in AI tokens. To my surprise, we had a passing build by the end of the day. Work has been encouraging us to adopt an AI-first workflow and giving us unlimited tokens. It's a wild experiment.

This happened on a Friday. I wiped the sweat off my brow after a hard day's prompting, and headed home early to start on my side project...

The Plan

Unlike me, my wife likes to leave the house and do things. I've spent a few years turning my garage into my favorite place to be. My wife and I have a deal where 1 day a month, She takes the kiddo and I am absolved of all responsibilities. I get a full day to lock in and build projects. From her perspective, I order doordash and turn into a degen who is unfit to father. From my perspective, I get to enjoy my favorite place and just tinker or play games or do whatever. These are the days I get to play mad scientist and feel most like myself. I look forward to it every month. My plan was to learn zig, brush off my hardware skills, build this project, write a blog post and make a video about it. Totally achievable.

I wanted to wire up a Raspberry Pi Pico, a small 240x240 LCD display and some RGB LEDs. I was going to learn Zig and use it to send image data over USB to the pico which will put an image on the screen and change the LED color. I would set up webhooks from GitLab to call an API in my Kube cluster and setup my host Zig app to poll that same API for changes and send updates to the Pico. I really wanted to transmit the data over USB because I've never done that before. I've already used Bluetooth, LTE and Wifi and just wanted to do something new.

The wiring is simple. Common patterns I was familiar with like SPI (Serial Peripheral Interface) for the display + some RGB leds. The TTY (TeleTYpewriter) serial data port on Linux /dev/ttyACM0 for USB communication with the Pico felt familiar because of how I had setup debug logging in the past. It looked like I had enough example repos collected that I could stitch a solution together. I did a little research each day and felt a little more sure each time. I've been using ChatGPT and Claude more and more to do initial research. I was at an AI hype peak and was bold enough to trust it...

Since I do full stack web stuff on the daily, the api, webhooks and postgres are out of scope for the degen day. I was scoping the day's work to Zig -> Pico image transfer.

1. Setup Pico

• Organize the workspace

• Find a micro usb cable that supports data and not just charging... really why are they all power only?!

• Wire up a breadboard with Pico & display and LED

• Setup the C SDK for the raspi pico and a repo gitlab, gihub-mirror

• Push a build and see logs on cat /dev/ttyACM0

2. Setup Pico Display

• Put something on the screen during the boot loop.

youtube link (12 sec)

3. Setup Host Zig Project

• Setup a host directory in repo

• Init zig project

• Send a message and see something on the screen

youtube link (9 sec)

4. Image Transfer

• Yeet the raw rgb image data over USB

• It's bidirectional safe right

• USB CDC is bidirectional safe
  • TTY interface is built on top of USB CDC
    • TTY is bidirectional safe because CDC is (no it's not... thanks gpt)

In the above image you can see the outright lie that broke me... USB CDC has separate TX (Transmit) and RX (Receive) buffers so it's bidirectional safe. The same is not true for TTY which is bidirectional but less safe with a single buffer for TX and RX data.

Timeline of Actuality (AI Woes)

After a dozen duds, I found a data capable usb micro cable and everything went smoothly until the image transfer. I used Claude, Cline, and ChatGPT to AI-max my way to a buggy but working implementation. I sent commands from my terminal with Zig over USB to the Pico which read them and changed the screen. This only took a few hours and I was excited that the AI assisted dream was real. It's not complex but I think it was faster than I could have done alone. I have no experience with zig besides hearing ThePrimeagen yap about it. I haven't even read the docs.

Multiple times, I found myself stopping Cline from starting completely new implementations of already solved issues. I didn't catch everything though. When Cline blew through my API limits, I added Claude to my harem and ran both in parallel when possible.

As I look through the code now, I realize that I'm lousy at multitasking and was gaslighting myself.

The Image Transfer Disaster

This is where my hubris came into play. In my mind, I pictured sending all the image data in one go, like an S3 upload. I imagined clean, raw data streaming over /dev/ttyACM0. It wasn't clean. It wasn't raw. It was chaos.

I expected to see:

pico - heartbeat
zig - start image transfer
zig - [240x240 COLOR PIXELS]
zig - end image transfer
pico - heartbeat

What I actually saw looked like this, but worse:

pico - heartbeat
zig - start ima%
pico - heage transfert
pico - heartbeat
zig - [240x240 COL
pico - heartbea
OR PIXELtS]
pico - heartbeat
zig - end image transfer
pico - heartbeat

It's just like that interrupting cow knock knock joke. Completely unfunny and day ruining.

Key Problems:

1. Buffer Conflicts: /dev/ttyACM0 was the battlefield. The same buffer was used for both logging and image transfer. If a log slipped in during the data stream... well good luck figuring out what the hell just happened.

2. Noise: Some weird corruption was happening. Maybe I wasn't clearing buffers properly. Maybe the gods of USB communication just hate me.

The bottom line? Neither the Pico nor my laptop could trust the data. Each system needed to learn to yield, and I needed to build the round-a-bout to force them to be polite and wait their turn.

Packets, Protocols & State Machines, Oh my...

I needed to get serious. So, naturally, I let Claude write some docs:

• Detailed a packet shape.

• Documented a checksum verification plan.

• Described data format for transfer.

• Denoted how to chunk and rebuild the image.

• Depicted the state machine transitions.

• Demonstrated command system.

• Designed a logging system that doesn't break incoming commands.

After delving down dem docs, I let AI run with the actual implementations. At this point, my "degen hat" came off, and I resumed my dad duties while letting Cursor and Cline play StarCraft with my codebase. This is the dream use case for AI, right? Just let it rip and come back to a perfectly functioning system. Let's see just how close we get to the sun.

Reality Check: AI tools are like interns who know how to Google really fast but don't understand context. Cursor started changing core implementations for unrelated edits. Cline would randomly rewrite half the system without asking. By the time I noticed, my codebase looked like the aftermath of a spaghetti fight at a junior developer convention. Most of the codebase was actually unreachable.

What did I learn?

Like Icarus, my codebase is irrecoverable. A tangled heap of wing fragments and melted wax, dripping with half-baked ideas and unsupervised AI chaos. My grand vision of outsourcing grunt work to AI had sent me soaring, but the sun of reality burned away any hope of landing gracefully. Here's what I'm taking away from this flaming descent.

1. AI is a tool, not a co-pilot

AI is great for generating ideas or drafting code, but it doesn't understand. It's like giving a junior developer a chainsaw instead of a scalpel—it might finish the job, but you'll spend twice as long cleaning up the mess. I learned that I need to stay firmly in the driver's seat when tackling new tech.

2. Friction forces focus

Having AI directly in my editor felt like playing with infinite cheat codes. It was too easy to let it run wild and harder to maintain control. Moving forward, I'm introducing deliberate friction. I will be using AI only in web interfaces or as a brainstorming tool. If I have to paste its suggestions into my code manually, I'll be more mindful of the process and less likely to reach for it.

3. Mistakes teach better than shortcuts

When I make mistakes, I learn. Debugging my own failures has always been one of the best ways to understand a new language or concept. Relying on AI to "fix" things for me short-circuited that learning process. As a result, I'm left with no deeper understanding of Zig than when I started.

4. Patience beats hubris

Building something new, with unfamiliar tools takes time. The idea that I could fully implement my vision in a single "degen day" was overly optimistic, bordering on foolish. Sometimes, you have to respect the complexity of what you're trying to achieve.

Moving Forward

Deskthang has grown from a casual afternoon project into a saga of overconfidence, AI misadventures, and lessons learned the hard way. For now, I'm shelving the AI driven shortcuts and committing to a rewrite on my next no-responsibilities day.

I've picked up a pen and started writing docs by hand like it's the stone age. I plan to work through some Advent of Code problems in Zig to actually learn the language before taking another crack at this project.

Want to see if Deskthang ever works, or just enjoy the chaos as I fail forward? Subscribe below for a monthly email drop of my latest misadventures and skill issues. Together, we'll learn how to coexist with AI, relearn the lessons I forget, and hopefully build something worthwhile in the process.

LFG 🚀

A USB-connected desk companion that helps maintain focus by bringing important notifications directly to your workspace, without the distractions of phones or chat apps.

The Problems

1. Notification Overload: Modern devices bombard us with notifications everywhere, making it difficult to maintain focus and separate work from personal life.

2. Authentication Friction: Tools like GitLab's MFA, while necessary, create constant workflow interruptions.

3. IoT Security Concerns: Traditional IoT devices with WiFi chips introduce unnecessary security risks and complexity.

The Solution

DeskThang is a USB-connected device that:

• Features a 240x240 pixel circular LCD screen and programmable RGB LEDs

• Connects via USB-C with no wireless components

• Is completely scriptable through bash commands

• Provides visual feedback for:
  • CI/CD pipeline status

  • Payment notifications

  • System status indicators

  • Custom notifications

  • And more through simple scripting

Technical Stack

• Host Driver: Written in Zig for efficient USB communication

• Firmware: C code running on the RP2040 (Raspberry Pi Pico)

• Scripting: Python for easy customization and integration

• Hardware:
  • RP2040 microcontroller

  • 240x240 circular LCD display

  • RGB LEDs

  • USB-C connection

Design Philosophy

1. Location-Based Computing: Notifications appear only where they're relevant - work notifications stay in the office.

2. Security First: No wireless connectivity means fewer attack vectors and security concerns.

3. Open Hardware: Complete documentation for firmware updates and hardware hacking included.

4. Ultimate Scriptability: Simple bash commands enable endless customization possibilities.

Command Interface

DeskThang provides a straightforward command-line interface:

# Basic Commands
deskthang ping              # Send ping command (expects pong response)
deskthang test <1-4>       # Run test pattern 1-4
deskthang led      # Set LED color (hex format)
deskthang image path/to.png # Display image (240x240 png)

These simple commands can be combined with other tools to create powerful automations. For example:

# Turn LED red on failed GitLab pipeline
gitlab-ci-notifier on:failed "deskthang led FF0000"

# Display team logo during standups
at 9:00 "deskthang image ~/team-logo.png"

Project Status: Abandoned

This project has evolved into Andon Lamp.

DeskThang served as the foundation for what became Andon Lamp - a refined, production-ready evolution of the original concept. While DeskThang focused on the core hardware and basic functionality, Andon Lamp represents the complete vision with improved software, better user experience, and a polished product offering.

Key improvements in Andon Lamp:

• Enhanced software architecture and reliability

• Streamlined user experience and setup process

• Production-ready hardware design

• Comprehensive documentation and support

• Active community and development

Visit getandon.com to learn more about Andon Lamp, or check out the Andon Lamp project page for technical details.

Historical Development: The original DeskThang development focused on:

• Implementing reliable USB communication protocols

• Developing the state machine for robust data transfer

• Creating a user-friendly command interface

• Designing the initial PCB

Follow the development blog for detailed insights into the challenges and progress that led to the creation of Andon Lamp.

Demo Videos

• DeskThang Demo Video - Watch DeskThang in action

• Wood Bending for DeskThang - Exploring wooden enclosure possibilities

• Cursor + DeskThang Integration - See how DeskThang enhances the Cursor IDE experience