DEV Community: Andy Schelb

Doodle Gallery - a Moderated art wall

Andy Schelb — Wed, 14 Oct 2026 14:09:00 +0000

A few weeks ago I added a Gallery to Disco Doodle — my little side project with drawing-prompt generators (Daily Doodle, Monster Maker, Theme Park Edition) — so people could actually show off what they drew instead of the prompts just disappearing into the void. Simple idea. But I didn't know how much would go into doing something like this.

I wanted to be sure to have a moderation component because, the internet being the internet, people are always trolling.

What it does

The Gallery is pretty straightforward on the surface: a person draws something from one of the prompt generators, snaps a photo, and submits it through a simple form. But nothing shows up on the public Gallery page until I've actually looked at it.

A submission form (wall/submit.html) that takes the photo plus which pack/prompt it was for
Every submission lands in a private moderation queue — invisible to the public, only I can see it
I get an email notification the moment something's waiting on me
I approve or reject from an admin page, and only approved photos ever hit the public Gallery
A basic profanity filter runs client-side too, in case someone tries to get something inappropriate into a custom category text

The build

Nothing fancy on purpose — I wanted this running on the same free-tier, no-backend-server stack the rest of the site uses, because it's a hobby project and I'm not trying to run a server for it.

Firebase Realtime Database holds the moderation queue. Submissions write in as "pending," and only get flipped to visible once I approve them.
Cloudinary hosts the actual images. We chose them because of the completely free tier. Another version we looked at had a free tier, but you had to have a credit card incase the volume got too high.
EmailJS fires off a notification email when something new comes in, so I'm not manually checking a queue every day. Free tier caps at 200 requests a month, which appears to be plenty for the moment.
A plain admin page, gated behind Google Sign-in through Firebase Auth, is where I actually approve or reject things
The whole moderation page is blocked in robots.txt too, since there's no reason for it to show up in search results

It all seemed to work ok. There was some back and forth on getting the google services side wired up and being sure I copied the right text into the right spaces in the setup.

The profanity filter is intentionally basic — it normalizes leetspeak, collapses repeated letters, and matches whole words so it doesn't flag things like "classic." It's client-side, so it's a deterrent, not a guarantee — a determined person could get around it.

We added a way for someone to send an email to notify us if their artwork was uploaded to our site without their permission. We also put a disclaimer checkbox, making the person agree that it's their artwork and reminding them that we're not claiming ownership of it.

Do you have any questions about this build? What should we have done differently? Let us know in the comments.

I'm Not a Developer, But I Directed an AI to Build a Real Internal Tool

Andy Schelb — Wed, 07 Oct 2026 14:09:00 +0000

A few months ago I sat down and described a broken process to an AI, piece by piece, until it wasn't broken anymore. I'm not a developer. I didn't read documentation. I just refused to stop until the thing actually worked. This is the story of that process — what it replaced, what it took to build, and the three separate times it broke in ways that made the final version better.

The problem

Part of my job involves collecting the same kind of repetitive information from a group of people, on a regular schedule, and turning it into a finished document that has to go somewhere else for approval. Think: expense-style reporting. Everyone fills something out, attaches proof of what they spent, and it all needs to land in a consistent, complete format — not five slightly different versions that someone then has to clean up by hand.

That "someone" was me.

Everyone wanted to help, but when there's not one consistent format each person's info was just a little bit off. Every submission had 2-3 things to correct. Sometimes involving a back and forth email chain requesting info and waiting on the response.

The first fix was simple: a basic online form that at least got everyone's submissions into a consistent shape and emailed to me automatically. That alone cut my own processing time by roughly half to two-thirds. It was a real improvement. It also had a hard ceiling — it could collect information, but it couldn't think. It couldn't look at what someone submitted and decide whether it was actually complete. It couldn't assemble anything. It just handed me a pile of slightly-more-organized raw material and I still did the rest by hand.

Why I didn't just buy something off the shelf

Whatever I built had to live inside tools my organization already trusted. That ruled out a lot of otherwise reasonable options — new software means procurement reviews, security reviews, and a price tag, and none of that was going to happen for an internal process serving a couple dozen people. It had to be free, it had to work on a phone in a parking lot, and it couldn't require anyone else to install anything or sign up for anything new.

That combination — free, already-trusted, zero new sign-ups — pointed toward building something custom inside the Workspace/Office ecosystem the organization already used, rather than adopting a new product.

How it actually got built

Here's the part I want to be honest about, because I think the honest version is more useful to other non-engineers than the impressive-sounding one: I didn't teach myself to code. I sat down with an AI assistant and described the problem — what the people submitting needed, what the final output had to look like, what was breaking in the old process — and we built it together, piece by piece, testing it against real submissions the whole way.

My job in that process wasn't writing syntax. It was staying relentlessly clear on what "done" actually meant, and refusing to accept an answer that technically worked but didn't solve the real problem.

I wanted to sometimes yell at the computer because it kept suggesting answers that either didn't solve my problem, or solved it, but in a way that our users wouldn't be able to access or input info.

This is where my problem solving skills were put to the test and stretched to the limit.

I think that's the actual skill that mattered here, more than any programming knowledge would have: knowing the process well enough, and caring about it enough, to keep saying "not quite" until it was actually right.

It wasn't a straight line — three real breaks

None of this worked perfectly the first time. Three separate failures stand out, because each one taught me something I wouldn't have known to ask about in advance.

1. The attachment that claimed to exist but didn't

Early on, a real submission came back and something the person had attached wasn't actually in the finished document. The tool had technically logged that a file existed — it even wrote a line saying so — but it had never actually embedded or attached it anywhere. It was a confident, specific, completely false claim. That's a special kind of dangerous bug: not a crash, not an error message, just quiet, plausible-looking data loss.

The fix wasn't a patch — it was a rule change. Now nothing can be marked as "included" unless the system can prove it actually embedded the file, and every attachment gets its own dedicated page in the final document instead of a thumbnail or a link that can quietly go stale.

Yeah it did seem like at this moment that the solution was going to work in theory, but not in real live situations.

2. The link that looked fine and did nothing

I tried to build a simple companion page linking out to the tool — logo, a button, one clear call to action. It rendered beautifully on the first platform I tried. Then I clicked the button. Nothing happened. I tried a second platform. Same result: looked perfect, dead on click. It took a third attempt, and a fair amount of research into how each platform actually sandboxes embedded content, before I landed on an approach using that platform's own native building blocks instead of injected custom code — which turned out to be the one thing that reliably kept links clickable.

Was I going crazy? Was it me? The browser? The User? Was it me again? I can't accurately convey how frustrating it is to not be able to figure out why something isn't working.

3. The instructions that quietly fell out of date

I'd built a step-by-step guide early on to help people use the tool. Then the tool kept improving — which was good — except the guide didn't improve with it. It was still showing an older version of the interface by the time I actually looked at it again. The fix was less "patch the guide" and more "stop hand-maintaining it" — I rebuilt the process so the guide gets generated fresh from the real, current version of the tool every time, instead of being a snapshot that quietly rots.

What it does now

The finished version handles the things that made the old process so heavy by hand: it knows who's submitting and fills in what it can predict, it enforces that nothing gets submitted incomplete (no more chasing someone down after the fact for a missing attachment), it turns multiple file types into a single consistent finished document automatically, and it delivers that finished document the moment someone hits submit — no manual assembly step left for me to do at all.

The actual takeaway

I started out trying to build a slightly better form. I ended up with a process that takes fewer touches from everyone and produces a better result than the original had. What we ended up with: a free, mobile-friendly tool that auto-fills each traveler's home office, handles multiple trips per submission with address auto-fill, requires a receipt on every expense before it'll let you submit, and emails a submission-ready packet the moment someone hits Submit.

It's all built out using a google script in a web app (which I did not know was a thing before this), and it assembles it all seamlessly. I started out building a form, and came away with a process that takes less touches and accomplishes more.

Have you ever started to solve a problem and get a much better solution than you set out to find?

More than a smiley face...creating expressions

Andy Schelb — Wed, 30 Sep 2026 14:09:00 +0000

When you first start drawing you learn a smiley face. It's easy, it's simple, it's universally understood to mean happy.

I made Disco Doodle as a prompt generator for drawing. The natural outgrowth of that was thinking about characters and expressions. If I wanted to improve my subjects, they can't just all be the classic happy or sad. They could use some real emotions!

I wanted a prompt that forced a little more range: spin a wheel, land on a feeling, draw that face on your character.

That became Expressions — a spinning wheel of emoji "faces" that lands on top of a hand-drawn character body, shows a plain-language definition of the feeling, and keeps a little history so you can see what you've drawn so far.

Here's roughly where it landed:

Starting with a spec, not a sketch

I didn't have art yet, so the first version was built against a full written spec: a three-tier taxonomy of feelings (Surface Moods, Deep Waters, Complex Blends), a spinning wheel behind a circular "head" viewport, sound effects, and a rolling history of the last five spins. The plan going in was: build the whole interaction against a placeholder, then swap in real art once it existed — as opposed to designing around a fixed drawing from day one.

That turned out to matter, because the real art changed the layout more than once (more on that below).

The taxonomy itself went through a few passes of quality control. Early on it included feelings like "Hopeful" and "Nostalgic" that don't really have a dedicated face emoji — you end up reaching for something like 🙏 or 🌇 that doesn't actually read as a face, which defeats the point of a drawing prompt. Anything without a genuine face emoji got cut. It also went through a couple of rounds of "does this word actually mean what the emoji looks like" — 😬 ended up as "Nervous" rather than "Conflicted," 😐 became "Meh" instead of "Calm," and 🫠 landed on "Overwhelmed" with a definition that nods at embarrassment too, since that melting-face emoji covers a specific mix of feelings that no single word quite captures on its own.

Final lineup: 25 feelings across the three tiers — 8 surface, 10 deep, 7 complex.

const EMOTIONS = [
  // surface
  { tier:'surface', emoji:'😊', feeling:'Happy', definition:"Happy is that warm, bright feeling you get when something good happens..." },
  { tier:'surface', emoji:'😐', feeling:'Meh', definition:"Meh is that shrug feeling when you don't feel excited or upset about something..." },
  // deep
  { tier:'deep', emoji:'😬', feeling:'Nervous', definition:"Nervous is that jittery, jumpy feeling in your stomach right before something big..." },
  // complex
  { tier:'complex', emoji:'🫠', feeling:'Overwhelmed', definition:"Overwhelmed is when so much is happening at once — maybe you're embarrassed too — that you just smile and think 'this is fine'..." },
  // ...25 total
];

Getting real art into a responsive layout

Once I had a hand-drawn body — t-shirt, pants, shoes, no head, on plain white paper — the job was turning a photo of paper into something that could sit believably underneath a spinning emoji.

That meant:

Alpha-keying the drawing. Instead of a white background, the ink line work needed to become a transparent PNG so it could layer under the spinning head. I inverted the luminance of the scan and used that as the alpha channel, then recolored the remaining ink to match the site's actual brand color, so it doesn't look like a pasted-in scan.
Cropping tight. Bounding-box crop down to the art itself, plus a small safety margin, so there's no dead space around the body.
Compressing it. Ran the result through pngquant to bring the file size down before embedding it as a base64 data: URI directly in the page — no separate image request, no loading flash.

129KB scanned PNG → alpha-keyed, recolored, cropped → ~26KB compressed

The trickier part wasn't the image processing — it was getting the emoji to sit exactly where a head should sit, responsively, across every screen width. The first pass used fixed pixel values for the head size and wheel geometry while the body image itself scaled fluidly with width: 100%. That's a bug waiting to happen: on a narrow phone screen, the art scales down but the head window doesn't, and suddenly the emoji is floating in the wrong spot.

The fix was to stop hardcoding pixels entirely and make everything a percentage of the containing stage:

.stage {
  position: relative;
  width: 100%;
  aspect-ratio: 1000 / 784;
}

.wheel-viewport {
  position: absolute;
  top: var(--head-top);
  left: 50%;
  transform: translateX(-50%);
  width: var(--head-size);
  aspect-ratio: 1;
  border-radius: 50%;
  overflow: hidden;
}

Then, since the wheel's tile height still needs to be an actual pixel number for the animation math, I measure the rendered viewport at runtime instead of assuming a value:

function measureItemH() {
  const rect = wheelViewport.getBoundingClientRect();
  ITEM_H = rect.height;
}

...with a debounced resize listener calling it again whenever the layout changes. That combination — percentage-based CSS plus a JS layer that measures rather than assumes — is the part of this build I'd reach for again on basically any "art that has to line up with an animated element" problem.

The mockup pivot: emoji in front, body behind

This was how Claude saw the idea orginally.

This was my first sketch mockup where I knew we were close.

I initially had the drawing layered above the wheel, with the emoji peeking out through a circular cutout — basically a porthole. It looked fine. Then I got a mockup with a big, expressive emoji head and a small, simple body underneath, with a note that the emoji should be the visual focus and the body should read as secondary — layered under the head, even mid-spin, not equal to it.

That was a real "redo the compositing" moment, not a tweak: it meant flipping the z-index relationship between the two layers and resizing the head window to match the proportions in the mockup rather than the proportions I'd guessed at originally.

.wheel-viewport { z-index: 2; } /* head: on top now */
.body-image     { z-index: 1; } /* body: underneath, always */

I matched the mockup's proportions by overlaying a measurement grid on the reference image and then checking the live implementation against those same ratios with a headless browser, reading back the actual rendered bounding boxes rather than eyeballing it. It's a small technique but a reliable one whenever someone hands you a rough mockup and says "make it look like this."

I was so happy when it finally looked like I wanted. We'd come a long way to get Claude to understand exactly what I was asking for. Sometimes it even felt like I was just in an hours long argument, trying to restate my case so that Claude could do exactly what I wanted.

Sound design, and a rejected experiment

The spin needed sound — something in the spirit of a game-show wheel, not a system beep. This went through more iterations than anything else in the build.

First pass: a simple square-wave tick on every tile that scrolls past, plus a soft chime on landing, all synthesized with the Web Audio API (no audio files, just oscillators and gain envelopes) — no strong opinion here initially, just "does it make noise."

Second pass: slowing the whole animation down and giving it a two-phase feel — fast at first, then easing hard into a slow, dramatic settle, like it's building anticipation for which face you're about to get. This also got a filtered noise-burst "clack" instead of a plain tone, to feel more like a physical wheel clicker.

That second version got a clean "I don't like this one, go back" — which is a completely normal thing to happen partway through a build, and honestly a useful signal: the two-phase timing sounded more sophisticated in my head than it felt in practice. So it got fully reverted — the phase-split logic, the extra easing curve, the noise-burst clack, all of it — back to the original single continuous ease with a plain, simple tick:

function easeOutQuint(t){ return 1 - Math.pow(1 - t, 5); }

function playTick(){
  const osc = ctx.createOscillator();
  const gain = ctx.createGain();
  osc.type = 'sine';
  osc.frequency.value = 700;
  gain.gain.linearRampToValueAtTime(0.12, t0 + 0.004);
  gain.gain.exponentialRampToValueAtTime(0.0001, t0 + 0.05);
  osc.start(t0);
  osc.stop(t0 + 0.06);
}

And on landing, a short three-note ascending flourish (G5 → B5 → E6) instead of a single chime — enough to feel like a small "ta-da" without turning into a jingle:

function playChime(){
  const notes = [784, 987.77, 1318.51]; // G5, B5, E6
  notes.forEach((freq, i) => {
    // staggered oscillators, each with its own gain envelope
  });
}

Keeping the wheel, the card, and the history honest with each other

There's a rolling history of your last five spins, and each entry is clickable — tap an old one and it brings back that feeling's definition card. The bug that showed up here was subtle: clicking a history item updated the definition card, but not the actual face sitting on the drawing. So you could end up looking at a card that says "Bittersweet" while the drawing still shows the surprised face from two spins ago — visually incoherent in a way that undermines the whole "practice drawing this specific expression" point of the feature.

The fix ties both together through one function, so there's no path where the card updates without the wheel (or vice versa):

function selectHistoryEntry(entry) {
  const emotionIdx = EMOTIONS.indexOf(entry);
  const pos = ORDER.indexOf(emotionIdx);
  if (pos !== -1) {
    setTrackY(-pos * ITEM_H); // scroll the wheel to match
  } else {
    // the tier filter changed since this was spun — just paint the tile directly
    tileEls[centerIndex].textContent = entry.emoji;
  }
  renderCard(entry);
  renderHistory(entry);
}

That "tier filter changed since this was spun" branch matters because of the other feature in here: a slider that lets you filter the wheel down to just Surface Moods, just Deep Waters, just Complex Blends, or all of them combined. If you spin something from "all," then narrow the filter to "surface" only, a history click on that older entry can't just scroll the now-filtered wheel to it — it has to paint the tile directly instead.

What resets, and what doesn't

Worth calling out directly: nothing here is saved to the browser. No localStorage, no cookies — that's a deliberate, site-wide choice on Disco Doodle, not an oversight. So the history, the mute setting, and whatever face is currently showing all live in plain JavaScript memory for that page session. Reload the page, close the tab, come back later — it's a clean slate every time.

It was really important to me that it's all browser based. I want a site that feels zippy to use and loads quickly. Any moment waiting and I'm putting my phone down or scrolling on to something else.

We'll see where this takes me. I'm not sure what should be added next. Do you have any ideas? Post them in the comments!

Monster Maker! It's like Daily Doodle but with 100 percent more Monsters

Andy Schelb — Wed, 23 Sep 2026 14:09:00 +0000

Disco Doodle is my hobby site — free, no-signup drawing prompt generators, a division of my little umbrella brand Plaid Labs. Daily Doodle was the original: pick a few categories (animal, occupation, prop, style...), hit spin, get a silly little drawing idea. Sometimes you just need to get past that blank page. More on that here.

A while back I asked Claude to build a second generator, Monster Maker, as a straight-up fork of Daily Doodle's engine but with monster-flavored categories: eyeballs, horns, skin texture, arm style, eyestalks, patterns, a "silly / scary / sleepy" vibe dial. Same beginner/advanced modes, same spin animation, same everything under the hood — just a new skin and a new set of categories.

That part went fast. What I actually want to write about is everything that happened after "it works" — the design back-and-forth, a Firebase security rules rabbit hole, building a share feature that doesn't feel like an ad, and then talking an AI agent into recording its own tutorial video of the thing it just built.

Monsters are different than drawing animals or people. I relate to drawing them because they can't look, "wrong". No one can say your proportions are off, or you forgot to add a nose, or hey that arm is longer than the other...because it's a monster. They only enter our world at nighttime while we're sleeping. Via a network of magical doors... oh wait.

Forking an app by pasting it into a fresh chat

Small but real gotcha worth mentioning: I was working in a fresh Cowork session, and it had no memory of Daily Doodle's code — it lives on my machine / in the repo, not in the AI's head. So the very first thing that happened wasn't code, it was a clarifying question: do you have the file, can I reach your computer, or should I build from scratch?

I pasted the whole daily-doodle.html file in. From there the fork was genuinely mechanical — same CSS custom properties, same category-card component, same slot-machine spin animation, just new data:

const categories = {
  eyeballs:    { label: "Eyeballs",     icon: "👀", color: "card-teal",   items: ["No Eyes","One Eye","Two Eyes","Three Eyes","Five Eyes","A Dozen Eyes"] },
  horns:       { label: "Horns",        icon: "😈", color: "card-blue",   items: ["No Horns","One Horn","Two Horns","Three Horns","Four Horns","A Crown of Horns"] },
  skinTexture: { label: "Skin Texture", icon: "🖐️", color: "card-purple", items: ["Hairy","Slimy","Scaly","Bumpy","Fuzzy","Leathery"] },
  // ...armStyle, eyestalks, pattern, vibe
};
const CORE_KEYS = ['eyeballs', 'horns', 'skinTexture']; // beginner mode

The sentence builder was the one piece that actually needed new logic, since "Your monster has Two Eyes and Four Horns, with Hairy skin, wiggly eyestalks..." doesn't follow the same grammar as Daily Doodle's "a [style] drawing of a [job] [animal] wearing [outfit]." Small thing, but it's the difference between a reskin and something that reads like it was actually written for monsters.

The background took longer than the app did

This is the part I'll happily admit: I could not settle on a background, and the AI just... kept building whatever I said next. Light blue polka dots. Then "big scalloped scales, olive green and khaki" (which, credit where due, it built as actual CSS radial-gradient math and got right on basically the first try — no image assets, just gradients tiled in an offset grid). Then "actually just olive green with giant polka dots." Then "remove the polka dots." We landed on flat olive green.

I really just didn't want it to look ugly, but wanted it to be fun when you changed from Daily Doodle to Monster Maker. A few of the tries were exactly what I asked for, and what I asked for was wrong and hideous!

The one genuinely useful thing that came out of that back-and-forth: once the background got dark, the plain gray subtitle/instruction text became almost unreadable against it. Rather than just darkening the text globally, the fix was giving those bits of text the same rounded "pill" treatment the app already used for buttons and badges — so it reads as an intentional design choice instead of a patch:

.subtitle {
  display: table; margin: 8px auto 0;
  background: rgba(255,255,255,0.8);
  padding: 2px 14px; border-radius: 999px;
}

Small detail, but it's the kind of thing that's easy to miss when you're iterating fast — worth actually looking at your own contrast, not just trusting that "it compiles."

A Firebase rules rabbit hole

Both generators share one Firebase Realtime Database for their visitor counters — /counters/dailyDoodle and /counters/monsterMaker, two independent keys in the same JSON tree. That part's simple. What wasn't obvious to me was why the counter worked for one and not the other, and whether I needed a whole second Firebase project.

I ended up screenshotting my actual Firebase console rules tab a couple of times and just asking "does this help?" The short version of what I learned: Realtime Database rules can be scoped to a specific path or left wide open at the root, and my original rules were the default test-mode rules — open, but with a hard expiry date baked in ("now < <timestamp>"). That's the kind of thing that quietly breaks a hobby project months later with zero warning. We replaced it with a permanent rule scoped just to /counters:

{
  "rules": {
    "counters": {
      ".read": true,
      ".write": true
    }
  }
}

Open where it needs to be, closed everywhere else, no expiry ticking down in the background.

Building a share feature that doesn't feel like an ad

The ask was: after you spin, let people save an image — the result sentence, a counter badge, something you'd actually want to post next to a photo of your drawing — without it screaming "please post my app." That "not overly promotional" constraint mattered more than it sounds like it should.

The whole thing is a <canvas> element, never attached to the page, rendered on demand and downloaded as a PNG:

async function buildShareImageBlob() {
  // measure the sentence first on a scratch canvas, so the final
  // canvas can size itself to the text instead of leaving dead space
  const lines = wrapCanvasText(measureCtx, sentenceText, cardWidth - cardPadX * 2);
  const cardHeight = cardPadY * 2 + lines.length * lineHeight;
  const H = Math.max(680, cardY + cardHeight + 160);
  // ...draw wordmark, badge, card, and a small watermark bottom-right
  return new Promise(resolve => canvas.toBlob(resolve, 'image/png'));
}

That "measure first, then size the canvas" step mattered a lot in practice — a short beginner-mode sentence and a long seven-category advanced-mode sentence are wildly different lengths, and a fixed-size card either wastes half the image on empty space or clips the text. Sizing the canvas to the content fixed both at once.

The watermark is one small line of text in a corner, not a banner. That was the actual design decision — the whole point is that someone wants to post this next to their own art, and a self-promotional overlay works against that.

This is a screenshot from the test of the daily doodle verison. I probably misplaced the Monster Maker one.

The part I didn't expect: scripting a tutorial video with a fake mouse cursor

This is the bit I'd actually recommend trying yourself. Once the app worked, I asked for a vertical walkthrough video — and rather than screen-recording a live demo, the approach was to script an actual headless-browser session that performs the demo itself: type into the input, click spin, click share, all timed out, with a synthetic cursor and text captions injected directly into the page so they show up in the recording.

async function tapEl(page, selector) {
  const handle = await page.$(selector);
  await handle.scrollIntoViewIfNeeded();
  const box = await handle.boundingBox();
  await moveCursorTo(page, box.x + box.width / 2, box.y + box.height / 2);
  await handle.click();
}

The cursor and captions are just DOM elements injected via page.evaluate() before the "recording" starts — a styled <div> that animates to each click target, and a caption pill that updates at each beat ("Add your own ideas to any category," "Tap Spin for an instant idea!"). Since they're real elements on the real page, Playwright's built-in video recorder captures them for free.

Two bugs worth knowing about if you try this:

Playwright's video recorder doesn't actually scale to the size you give it. If your recordVideo.size is bigger than your CSS viewport, it pastes the unscaled frame into the corner of the bigger canvas instead of stretching it — you get a video that's mostly gray dead space. Fix: record at your real viewport size and let ffmpeg do a proper upscale afterward.
Your page's own background needs to fill the full viewport height, or the same dead-space problem shows up below short pages. A one-line CSS fix (html { min-height: 100%; background: ...; }) injected just for the recording session solved it without touching the real site's CSS.

ffmpeg -i raw.webm -f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100 \
  -vf "scale=1080:1920:flags=lanczos,fade=t=in:st=0:d=0.4" \
  -c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p \
  -c:a aac -shortest -movflags +faststart walkthrough.mp4

(The silent audio track is deliberate — some platforms handle video-with-no-audio-stream oddly, so anullsrc gives it one for free.)

Where the AI actually hit a wall

I asked for a voiceover next, and this is the honest part: there's no ElevenLabs- or OpenAI-quality voice available in that sandbox. What was available: espeak-ng (classic robotic TTS, works instantly, zero setup) and Piper, a free offline neural TTS that's a meaningful step up in naturalness — installable in about thirty seconds, no API key, no network dependency at runtime.

I still haven't posted this video. I'm not sure why. Anyone else get super self-conscious before posting to social media? Me neither!

What I did get out of the AI: a clean, timed caption script broken into beats that match the video almost to the second, ready to paste into whatever TTS tool I wanted:

0:00–0:03 — "Welcome to Monster Maker."
0:03–0:06 — "Add your own ideas to any category."
0:10–0:15 — "Tap Spin for an instant monster!"
0:18–0:20 — "...or share it as an image!"

That felt like the right division of labor, honestly — the AI is great at the mechanical parts (timing, syncing captions to on-screen actions, getting the technical plumbing right) and much less useful the moment "which voice sounds right for my brand" becomes the actual question.

What I'd take away from this

You should absolutely ask to get a video generated on how to use your product. It may not be great for marketing or even an explainer video. You do get to see how someone will use your idea before hitting publish. Who knows, it may give you some insight on things to tweak or change. Ways to really make your idea even shinier.

If you want to see the actual result, both generators are live and free at discodoodle.com — no signup, just pick your categories and hit spin.

While you're there, make a Monster and doodle it up on a post-it. Share Your Art in our Doodle Gallery. We could always use more submissions!

I tried to add a simple hit counter to my app and ended up learning why "simple" free APIs quietly fail on mobile

Andy Schelb — Wed, 16 Sep 2026 14:09:00 +0000

Social proof is good when you have a new app. I wanted people to know that others were using the app. I literally asked Claude for a 90s style website counter. I used the example of the famous burger sign that says, "billions served."

Image source: The Flintstones Wiki on Fandom
side note- this movie was so magical when I was a little kid!

Turned out to be a good little rabbit hole, so I figured it was worth writing
up on its own — not just "here's a counter," but what actually broke along
the way and why.

🔗 See it in action: https://theplaidscientist.github.io/dailydoodle/
💻 Code: https://github.com/theplaidscientist/dailydoodle

Attempt 1: a free, no-signup counter API

Daily Doodle
is a static site on GitHub Pages — no backend, no server I control. So the
first move was a free public counter service
(countapi.mileshilliard.com) — no
account, no API key, just a GET request that increments a number tied to a
key I made up:

fetch(`https://countapi.mileshilliard.com/api/v1/hit/${COUNTER_KEY}`)
  .then(r => r.json())
  .then(data => { counterEl.textContent = data.value; });

Worked immediately on desktop. Yay! It's working! This is gonna be so cool.

Then it quietly stopped working on mobile

I switched to my phone before sending the link to my friend and realized it was still at triple ---. No matter what I did, I couldn't get the counter to update..

The counter would just... not move on mobile. No error the user would ever
see, because I'd deliberately built it to fail silently (dashes on screen
instead of a broken-looking blank) rather than break the actual app if the
counter service ever had a bad day.

First fix I tried: fire the request two ways at once — the normal fetch()
call, plus a fallback using an <img> tag pointed at the same endpoint,
since some ad blockers treat image requests differently than fetch/XHR calls:

const pixel = new Image();
pixel.src = `https://countapi.mileshilliard.com/api/v1/hit/${COUNTER_KEY}?_=${Date.now()}`;

Didn't help. Which was actually useful information — if both request types
fail identically, that's not a request-type problem, that's the whole
domain being blocked at the network level (an ad blocker, a mobile
carrier's filtering, a DNS-level blocklist like NextDNS/AdGuard). Generic
counter/analytics-sounding domains get swept up in filter lists a lot more
than people realize.

Attempt 2: Firebase instead

The fix wasn't cleverer code — it was picking a backend domain that's
essentially never blocklisted, because too much of the internet depends on
it. Firebase fit: firebaseio.com is Google infrastructure that a huge
number of mainstream apps rely on, so blocklists generally leave it alone.

Setup, for anyone who wants to do this on their own static site:

Create a free project at Firebase Console (no credit card needed for the free Spark plan)
Add a Realtime Database, start it in test mode (public read/write — fine for something as low-stakes as a number)
Use Firebase's REST API directly, no SDK, no auth needed in test mode:

// Read the current count
fetch(`${DB_URL}/counters/dailyDoodle.json`)
  .then(r => r.json())
  .then(value => { counterEl.textContent = value || 0; });

// Increment it atomically (safe even if two people spin at once)
fetch(`${DB_URL}/counters/dailyDoodle.json`, {
  method: 'PUT',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ '.sv': { 'increment': 1 } })
})
  .then(r => r.json())
  .then(value => { counterEl.textContent = value; });

That .sv: { increment: 1 } bit is Firebase's server-side increment — the
math happens on their server, not in the browser, so there's no race
condition if two people hit spin at the same moment.

The honest tradeoff

Test mode means the database is publicly writable by anyone who finds the
URL — genuinely fine for a number nobody can really abuse in a meaningful
way, but worth knowing if you're reusing this pattern for anything with
actual sensitive data.

Sources / further reading

countapi.mileshilliard.com — the free counter service I started with
Firebase Realtime Database REST API docs
Firebase Console

Have you had this problem? Did you solve it similarly or differently?

Does anyone have suggestions on who I should follow? I’m completely brand new, and every article I read so far feels very technologically deeper than my current skills. Drop comments for suggestions. I’m just a beginner.

Andy Schelb — Wed, 09 Sep 2026 20:44:31 +0000

I vibe-coded my first app ever — a daily drawing-prompt spinner (Beginner + Advanced modes, sound, the works)

Andy Schelb — Wed, 09 Sep 2026 14:09:00 +0000

I was at dinner and my friend asked me if I'd ever vibe coded. He was like you really should try it. It's incredible what you can do. I took web design in high school, but in the year 2000 it was all about learning HTML tags. That was the most coding I've ever done.

So I built Daily Doodle — a drawing-prompt spinner. Pick which categories
you want in play, hit spin, and it mashes them together into something like
"a Pencil Anime-style drawing of a Detective Octopus wearing a Hoodie, with a
Boombox, riding a Scooter, looking Happy, in the Woods." No two spins land
the same, and it's built to actually get used, not just looked at once.

🔗 Try it: https://theplaidscientist.github.io/dailydoodle/
💻 Code: https://github.com/theplaidscientist/dailydoodle

What it does

Nine categories, all toggleable: Animal, Occupation, Prop, Vehicle, Style,
Medium, Outfit, Mood, Setting. Each one is fully editable — add your own
items, clear a category out completely, or restore the original starter
list if you mess with it too much.

Two modes so it doesn't overwhelm anyone on first visit:

Beginner — just the original three (Animal, Occupation, Prop), no toggles, nothing to configure. Load it and spin.
Advanced — all nine categories, each with its own on/off switch, so you build exactly the level of chaos you want.

A few other things that ended up in there:

A live counter (backed by Firebase) tracking total spins across everyone who's used it, styled to match the rest of the app instead of looking like a bolted-on stat
Retro synthesized sound effects — a boop-boop-boop while it spins, a tada when it lands — built entirely with the Web Audio API, so there's no audio file to load and nothing to license
An "avoid repeats until all shown" option, so a category won't repeat an item until everything in it has come up once
A copy button that grabs the result as shareable text, plus a collapsed "recent doodles" list holding your last 3 spins

When my oldest was little. They'd always ask me for ideas of things to draw. I'm a massive Walt Disney World fan and I've read almost anything I can on the subject of the creation and maintenance of the most magical place on earth.

I remember reading this quote from the head of Disney Imagineering:

“There are two ways to look at a blank sheet of paper. It can be the most frightening thing in the world, because you have to make the first mark on it. Or it can be the greatest opportunity in the world, because you get to make the first mark—you can let your imagination fly in any direction, and create whole new worlds!”

— Marty Sklar, Creative Leader of Walt Disney Imagineering, from his memoir Dream It! Do It!: My Half-Century Creating Disney's Magic Kingdoms

This was his go to when in 1974 when taking over Walt Disney Imagineering to help the team overcome paralysis and self-doubt.

Github, Pull, Push, and endless screenshots asking, Am I doing this right?

I'd not coded before. I pulled some software for my 3d printers from github years and years ago, so it existed and what it was vaguely for, but I didn't have any idea how to use it.

I was super nervous that my human touch would be the part where the ideas would break.

The stack is about as simple as it gets: one index.html file, vanilla
JavaScript, no framework, no build step, no local dev environment — I edit
it directly in the GitHub web UI. In the beginning I was copy and pasting full html files to edit the site because I wasn't sure how to use github desktop.

It's hosted completely free on GitHub Pages, and the whole thing — including
the live counter — costs nothing to run.

What's next

This is the second entry in Plaid Labs, a little hub of web experiments
I keep building and then figuring other people might want too. First one was
Droid Tycoon Fusion Cookbook,
a fan checklist for tracking fusion recipes — more on the way.

Are you also new to coding/app creation? Put your newbie experience posts below in the comments and I'll read them and comment back!

I built a checklist for Droid Tycoon fusion recipes so I’d stop scrolling screenshots

Andy Schelb — Wed, 02 Sep 2026 15:21:46 +0000

Recently in Droid Tycoon, a Star Wars game built in Fortnite, they added a feature where you could fuse multiple droids together. They kept the recipes a secret, but people started making lists. I grabbed a screenshot from the forum, but when I kept using the markup tool on my phone it never saved right. Probably because I was multitasking between my TV and my phone.
I thought I just need a simple checklist so I know what droid blueprints to target off the belt.
So I built Droid Tycoon Fusion Cookbook — a simple checklist for tracking Droid Tycoon’s fusion recipes. Check off the parts you’ve collected, and the result glows green the moment you’re ready to fuse it.

🔗 Try it: https://theplaidscientist.github.io/fusioncookbook/
💻 Code: https://github.com/theplaidscientist/fusioncookbook
What it does
Droid Tycoon’s fusion system has 17 not-so-secret recipes for new hybrid droids, across four rarity tiers, each one combining three specific parts into a new droid. Cross-referencing a static image against “wait, do I have two GONKs or one?” got old fast. So the tool is just:
• Tap each part as you collect it
• All three parts checked → the result lights up green, no more digging back through a screenshot
• Tap the result once you’ve actually fused it in-game → the row strikes through and fades, so what’s left on your list is only what’s left to do
I kept having the issue where I had ⅔ of any equation, but nothing I could actually use.
The build:
Nothing fancy on purpose — it’s a single index.html, vanilla JavaScript, no framework, no build step. I just wanted an easy persistent checklist that wasn’t dependent on my paying too much attention.
The one detail I actually like: progress saves to localStorage, keyed per recipe, so closing the tab or restarting your phone doesn’t lose your checkmarks — but nothing leaves your device and there’s no account to manage. Add it to your home screen via browser and it behaves like its own tiny app.

It’s an unofficial fan tool — not affiliated with Epic Games, Lucasfilm, or Disney — just something I wanted to exist and didn’t see anywhere else.
What’s next
This is the first in a series I’m doing on Plaid Labs, a little hub of web experiments I keep building for myself and then figure other people might want too — there’s also Daily Doodle, a drawing-prompt generator, with more on the way.
Have you ever built something to make your video game more fun? What was it?