In September 2024, Google Labs introduced NotebookLM Audio Overviews on X. Two AI hosts could take a collection of sources and turn them into a surprisingly natural conversation. It was not simply a spoken summary. The back and forth gave the material a rhythm, and that made difficult ideas feel more approachable.

A few weeks later, I saw Andrej Karpathy share Histories of Mysteries, a ten-episode show he had curated with NotebookLM and published in roughly two hours. Seeing the research, generated conversations, artwork and Spotify page together made the path feel unexpectedly close. I decided to try it for myself. The result was The Notebook Pod.

I built the show around one artificial intelligence paper per episode. I started with papers I genuinely wanted to understand, gave the source material to NotebookLM and listened to the first Audio Overview. If the conversation helped me see the paper more clearly, it had done its job. If it stayed too high level or wandered away from the interesting part, I tried again.

That meant prompting my way through the learning experience: the focus of the discussion, which ideas needed more attention, the duration, the tone, the intro and the outro. Small instructions mattered. A tighter focus could reveal the actual contribution of a paper. A better question could make an unfamiliar concept click.

Along the way, I also learned what sits around a podcast. I listened back, edited, made artwork, wrote descriptions, prepared the audio and worked through Spotify's publishing flow. I had always wondered how those pieces came together, and suddenly I had a small show that forced me to learn each one.

The catalogue eventually reached Episode 23, covering topics such as multi-agent systems, analogical reasoning and backdoor attacks in LLMs. The episodes were not perfect. Sometimes the hosts sounded too polished or repeated a phrase. Still, seeing my own artwork, name and episodes inside Spotify was a small magical moment. A research paper had become something I could revisit while walking around.

The experiment changed how I think about generative AI. It can make the first draft almost instant, but direction still matters. The real work moved into choosing a worthwhile paper, noticing where the explanation was weak and shaping the conversation around what I wanted to learn. The show was the output. Better understanding was the point.

The Notebook Pod also left me with one bigger question: could I build the entire experience in one place, from finding a paper to having the conversation and preparing the finished audio? That question inspired Virtual Podcast Studio. The podcast is where the idea began.

I wanted to pull realtime voice apart without the whole conversation falling apart.

Realtime now owns microphone transport, VAD and transcription only. It does not generate a second assistant answer.

A single validated structured response commits the card, history, captions and exact speech. If the contract fails, nothing leaks through.

Every asynchronous result has an owner. Barge in and the old request and speech are cancelled before the new turn can land.

That separation is the fun part. I can swap the listener, renderer, speech or image resolver, then measure the result against a 41-case quality loop without changing the semantic spine.

The app supports several provider paths behind the same UI. AssemblyAI is the deployment safe live streaming path, Google Cloud Speech to Text remains a cloud baseline, and WhisperX runs through a separate Python worker for local ASR, alignment, and pyannote backed diarization. Parakeet and NeMo are present in the shared provider model, but are still scaffolded for future worker implementations.

That architecture is the main product decision. The Next.js app stays responsible for the browser experience, request validation, provider dispatch, and hosted deployment. The Python worker owns heavy local speech dependencies, model loading, diarization, and model cache persistence.

This separation makes the project easier to evaluate. The same recording flow can compare hosted AssemblyAI live capture, Google chunked transcription, and local WhisperX tiny.en without rewriting the UI each time. It also keeps Vercel deployment realistic: the hosted app can run AssemblyAI with only a server side API key, while self hosted local diarization lives on Docker or a VPS.

The current repo also hardens the edges around real audio. Direct media links are validated before submission, browser system audio capture requires explicit user permission, the worker validates decoded audio size, language codes are normalized for WhisperX, and model components are cached between requests.

The important constraint is that not every backend behaves the same way. AssemblyAI streams continuously over WebSocket. Google and local live paths use chunked audio, so speaker labels can reset between chunks. Upload is intentionally limited to WebM audio for the current adapter, and overlapping speech remains difficult for every local path.

The result is less a one off demo and more a practical diarization workbench. It makes the tradeoffs visible: hosted live speed, cloud baseline behavior, local model control, deployment complexity, and the messy reality of asking software to identify who said what.

Evidence corrected the brief. Monohydrate is already well absorbed; coffee does not appear to block it. Keep 3 g dry through brewing. Add it after.

Evidence, formulation, coffee and safety agents rejected carbonation, novel-form hype and shake-like additions. Agents narrow the search; a lab proves it.

A sealed 3 g post-brew capsule. Brew first. Add near serving temperature. It should disappear without changing aroma, taste, mouthfeel or the final sip.

Three gates: stability and residue; blind sensory tests; then tolerance and adherence. None exists yet. Fuse remains a testable question.

With this new change come new challenges. Not all the applications I was used to, or potential new ones, are immediately available. That can also be seen as a great opportunity to learn and build.

This is where Voco, my latest mini project, enters the conversation. I loved seeing how people are now dictating to their CLIs instead of typing, not just to CLIs, but in fact to a lot of applications. I really liked the idea and wanted to give it a try. To my surprise, Whisper Flow is not yet available on Linux. But what if I could build it myself? That could save me a few pounds at the expense of some precious tokens.

Voco is a free, open source desktop dictation tool for Linux. You press Alt+D, speak, and your words appear wherever your cursor is. Everything runs locally using whisper.cpp.

Just install it and go.

When I attended the first meetup, I was blown away that Andy Tyler, the Codex ambassador, saved a spot for people to demo what they had recently built. With the sponsorship of the Codex team, the winners received 12 months of ChatGPT Pro ($200/month). In today's world, tokens are very precious, in my opinion, so having those for 12 months means a big saving and creates the space to build, which I love.

The event started and it was filled with interesting people. Some I had met at the previous event, others I met for the first time. When it came to the demo session, I was completely locked in and ready to rock my idea.

I used some API credits to get real time voice working. Too bad this is not available through your ChatGPT subscription like Codex. I got the idea working, and I also brought an Arduino Uno to show that the experience could extend beyond conversation into real computer use, especially when interacting with and deploying code to an Arduino.

This is something that, a year ago, would have sounded completely crazy.

Not anymore.

Demo submissions opened and the organisers announced that Codex would choose which projects would be presented on stage. That was the first filter to get through.

A lot of people submitted demos, so reaching the stage already felt like a win.

I have been watching people online like Lucas Meijer, Peter Steinberger, and Armin Ronacher, from whom I have been learning a lot, deliver their presentations using HTML files.

For this one, I thought: I am going to do it like the big guys do, with style.

Once I was happy with my demo, I asked Codex to build me an animated HTML presentation to deliver my intro, including a nice limbic opening.

I feel like the demo itself was really bad because I only had three minutes to deliver the whole thing.

I could not even show the best part, which was Codex joking when I plugged my Arduino into my USB.

I do not even know why I pressed that button, but somehow I broke the whole thing.

That meant 12 months of $200/month worth of tokens from one of the leading AI labs. I was genuinely happy and proud of myself.

I cannot lie, this little win had a big impact on my self confidence, even if I thought the demo was rubbish. But hey, it was fun, and it was worth it.

I think people saw beyond the Arduino not working. They followed the story and understood what I was trying to build.

That constraint forces you to ship fast instead of being overly delicate or perfectionist.

In my case, I feel like that is exactly what I need: creativity bounded by limited time.

Here is the deck. I hope you like it!

What It Is

The template now uses the same visual system as this blog: the navigation, typography, spacing, project cards, archives, detail pages, light theme, and dark theme all behave the same. My identity and content are replaced with clear placeholder copy, example images, social profiles, project links, and repository links so another person can make it their own.

It is a clean Next.js 16 starting point with validated Markdown content, strong accessibility, responsive behavior, and secure defaults.

It is also designed for modern discovery. Every project and article has stable metadata and a canonical Markdown alternate, while feeds, structured data, llms.txt, and a deterministic content index give search engines, LLMs, and web agents reliable ways to understand the site.

There is no chatbot, model dependency, database, or request time content fetch. The focus is the publishing foundation.

What Is Included

Project and thought collections with realistic placeholder content The same editorial layout, spacing, cards, and detail pages used on this site Placeholder profile links, project links, repository links, and responsive images Responsive light and dark themes Canonical URLs, Open Graph metadata, and JSON-LD Markdown alternates, RSS, JSON Feed, sitemap, and robots policy llms.txt, full text context, and a versioned content index Draft and private repository protection Unit, accessibility, browser, metadata, and machine output tests

Why I Built It

New sites should begin with a consistent structure and a strong quality bar. This template makes the parts people often postpone, such as design consistency, accessibility, metadata, security, and machine readable publishing, part of the starting point.

Clone it, replace the example content, update the site configuration, and deploy.

Open the live template or create a repository from it.

The problem it solves is not long term literature management. It is the gap between "what is new in this area?" and "can I turn this paper into something I can listen to, share, or adapt?" That first pass benefits from tight constraints instead of accounts, saved libraries, databases, or ingestion pipelines.

The discovery screen focuses on robotics, computer vision, and large language models. The user chooses areas, optionally narrows topics, picks a count of 3, 6, 9, or 12 papers, then searches live arXiv results. The paper cards keep the title, authors, publication date, source, and abstract close to the action that sends a paper into script production.

The production screen treats generation as a deliberate second step. After a paper is selected, the user names both speakers and chooses a separate OpenAI model for each one. The repo currently exposes GPT 5.5, GPT 5.4, GPT 5.4 mini, GPT 5 mini, and GPT 5 nano as speaker model options.

Script generation creates an 8 turn grounded dialogue from the selected paper. Each turn has a defined conversational job, moving from problem setup to contribution, method, evidence, limitation, and takeaway. The generated script can then be replayed with a live dialogue animation.

The output is designed to leave the app cleanly. Users can download a plain text script or an ElevenLabs compatible JSON file, which makes the prototype useful as a bridge between research discovery and audio production rather than only as an on screen demo.

The architecture remains intentionally small. Paper discovery is fetched live from arXiv, search results use the abstract directly, script generation runs on demand through a Node 20 Express API and the OpenAI Responses API, and the app stores nothing. There is no auth, no paper history, no episode library, no background jobs, and no database.

The current version demonstrates a focused workflow built with React 18, TypeScript, Vite, Tailwind CSS, Radix UI primitives, Express 5, OpenAI, and arXiv. It is a live prototype for turning a noisy stream of papers into a smaller set of scripts that can be read, replayed, or handed off to a voice pipeline.

The useful part is the combination of guidance. A beginner does not only need a code snippet. They need to know which board they are using, what voltage the pins expect, where each component connects, and what to print over serial when the result is unclear.

That is especially important across boards. An Arduino Uno is a friendly 5V starting point. ESP32 and ESP8266 boards are powerful, but they are 3.3V devices with different pin behavior, boot constraints, and Wi Fi focused workflows.

So Arduino Maker keeps the assistant grounded in practical electronics habits: use resistors with LEDs, prefer INPUTPULLUP for simple buttons, add Serial.begin() and diagnostic prints, and avoid driving motors, relays, or high current loads directly from microcontroller pins.

The repository is packaged as a native OpenClaw plugin with a lightweight runtime entrypoint and a declared skill root. The value lives in the skill content, references, component notes, troubleshooting checklists, and project prompts.

The result is a simple helper for the moment when a project is close, but not working yet. It helps the user reason through the circuit and the sketch together until the board starts behaving in a way they can understand.

The Inspiration

OpenAI Dev Day in London, 2024. Their audio visualizations were mesmerizing. I wanted to build something similar.

What I Built

A real time audio visualizer where: Drag and drop any audio file Radial ripple effect from center Colors respond to frequency Smooth, hypnotic animations

Stack: Next.js, Web Audio API, Canvas

Key Learnings

1. Web Audio API is powerful

FFT analysis, frequency data, volume levels: all available in the browser. No external libraries needed for the audio processing.

2. Canvas performance matters

Naive drawing = choppy visualization. RequestAnimationFrame + careful canvas management = smooth 60fps.

3. Color mapping is an art

Mapping frequencies to colors that look good together is surprisingly hard. Ended up using HSL color space for smooth gradients.

4. Audio is personal

Everyone tests with their favorite songs. Build something that looks good across genres.

I am sure many Venezuelans living abroad feel the same.

Some of the worst affected areas are places that I used to visit frequently when I was living in Venezuela. I have great memories there with friends, family and the people who made those places special. The lives of those same people have changed forever. It is painful to think about, watch and hear the stories coming from the ground.

This tragedy has kicked off a personal reset of what truly matters to me... life itself, good health, family and loved ones.

Strong leadership is essential to overcome a crisis like this.

Unfortunately, government bodies have not demonstrated the level of response that people had every right to expect. It is infuriating, to say the least.

On the other hand, private companies and individuals have rallied with the spirit that characterises the Venezuelan people: empathy, unconditional support, hard work and, above all, love. Thank you to everyone who has helped, whether from Venezuela or from afar.

Used well, it can help people coordinate support, make sense of public information and create better opportunities for everyone who has been affected.

I am seeing first hand how people across the software industry are coming together to build solutions and help however they can.

I want to thank Hugging Face, especially Merve Noyan and Suvaditya Mukherjee, for their support and for helping the different teams using technology to support people on the ground.

With their generous donation of technology, I built Ayuda Venezuela 2026, a "bird's eye view" of the affected areas using public data.

The Hugging Face Space brings together open satellite imagery, a before and after comparison, source backed affected building context from Microsoft AI for Good and HDX, and wider public signals from NASA, USGS, HOT/OSM and other trusted sources.

It is intentionally a public, read only view. It does not accept personal information or pretend that automated analysis can replace the people doing the work on the ground.

The demo above shows the core experience: compare imagery from before and after the earthquakes, explore affected building context and go directly to organisations offering support.

The main goal for this experiment is to give people another perspective on the damage and the areas that have been impacted.

If it helps one more person understand what has happened or find an organisation already doing the work, then it has served its purpose.

This will be a long process with many phases, so ongoing support will be needed in many different forms.

If you work for an organisation that can offer assistance beyond financial support, please reach out so we can coordinate and make the most of every contribution.

Thank you.

The problem is familiar: deciding what to eat can feel surprisingly repetitive. A planner that begins with blank fields asks the user to do the hard part first. Breakfast Burst flips that order by starting with inspiration, then giving the user a path into recipes, timings, and planning.

The interface is designed to feel closer to browsing a food magazine than managing a task list. Featured breakfasts, tags, prep times, and recipe cards do the first layer of work by making options feel concrete before the user commits to anything.

That matters because food planning is emotional as much as practical. A breakfast idea needs to look good, feel achievable, and fit the time someone has. The visual treatment helps the product communicate those things quickly.

For an end user, the value is simple: open the site, find a breakfast that feels right, and move from inspiration into a plan. The product is meant to reduce morning indecision without making the process feel heavy.

The current version demonstrates a polished, responsive food planning surface built with Next.js, React, Tailwind CSS, and Vercel. It shows how a small utility can feel more useful when the presentation respects the mood of the task.

The current version starts with a simple weekly calendar. Breakfast, lunch, and dinner sit in view together, which makes the planning problem concrete before the app asks anyone to make more decisions.

That is the main shift from a generic meal idea tool. Casa Weekly treats the week as the product surface: fill open slots, swap meals, lock what already works, and keep the rhythm visible.

Groceries are part of the planning loop rather than an afterthought. The app looks at what is already in the basket, favours shared ingredients, and turns the plan into a smaller shopping list.

The family guide gives the planner its shape. Household context, avoid list ingredients, planning promises, favourites, skips, and notes all feed into what the app suggests next.

The result is intentionally modest. Casa Weekly is a small household tool for agreeing on food, reusing what is already there, and letting each browser remember the meals that made the week easier.

The Concept

Design portfolios take themselves way too seriously. "I craft pixel perfect experiences that delight users through innovative solutions." Please.

This portfolio actively mocks the industry it is trying to get hired in while still being genuinely good.

What I Built

A portfolio site that: Uses design buzzwords ironically Has actually good design (the irony is intentional) Shows real work while not taking itself seriously Proves you can be self aware and professional

Stack: Next.js, Tailwind CSS, Framer Motion

Key Learnings

1. Humor is a differentiator

Every portfolio looks the same. "Clean. Minimal. User focused." Standing out means having a personality. Self deprecating humor works.

2. You can be serious about not being serious

The execution has to be excellent. The joke only lands if the design itself is good. Sloppy design + irony = just sloppy.

3. Authenticity reads

Hiring managers see hundreds of portfolios. The ones that feel like real people stand out. Being genuine being perfect.

Think about the moments before attending an event, a conference, or any place where you expect to meet new people. You want a simple way to introduce yourself and share your contact details without friction.

That is where this project came from.

QR codes are everywhere, especially at conferences and events where people want to share information quickly. Sometimes that is a product page, sometimes a signup form, and sometimes it is just a fast way to connect.

What if that same idea could be personalized for the specific event you are attending, so you can share your details seamlessly in a way that feels clean and intentional?

That is what this project is about: a simple, straightforward event QR code generator designed for real world meetings.

I hope you enjoy it.

Update · July 13, 2026. I originally bought one month of access to SportMonks so I could get the first live football version moving quickly. When that subscription ended, I still wanted the experience to feel as close to live as a personal project reasonably can, without pretending that a free feed is the same thing as a contracted broadcast data service.

I did not remove the SportMonks integration, its historical records or its identifiers. Instead, I built a provider neutral route beside it and switched the active match day mode to HybridFree. SportScore is now the primary source for scores, match state, the clock, incidents and whatever line up or statistical detail is available. An API Football adapter can supplement missing statistics and events within its free tier allowance, but it remains optional. If I renew SportMonks later, the original route is still there.

The important part is that the rest of the system did not need to change. Every provider is translated into the same canonical Salesforce records, and the existing CRM data streams continue carrying those records into Data 360. After a live snapshot is saved, Salesforce publishes a Platform Event so the command centre can refresh immediately; a 60 second browser refresh remains as a safety net.

There is one honest limitation. SportScore is a cached REST source rather than a WebSocket, SSE or webhook stream, so the upstream feed is usually around one or two minutes behind broadcast time rather than sub second. The screen reacts as soon as Salesforce receives the change, while its source and freshness indicators make that boundary visible instead of disguising it. For me, that trade off is part of the experiment: the provider can change, but the trusted data model, lineage and supporter experience remain intact.

The target movement is deliberately narrow: a two hand hardstyle/Russian kettlebell swing. That choice matters because "good form" is not a single universal shape. The app is trying to read a hip dominant hinge pattern, neutral torso and head stack, relaxed arms, and a bell path driven by hip extension.

Before scoring, the coach asks for a standing calibration sample. That gives it a personal baseline for upright hip angle, knee angle, torso lean, body proportions, visibility, and jitter. From there it can evaluate swing phase, rep count, hinge to knee ratio, lockout, shoulder lift, spine stack, depth travel, camera quality, and confidence.

The feedback model is intentionally practical. It flags a missing side view or poor framing, squat dominant backswing, shallow depth, incomplete hip extension, arms lifting the bell, and spine or neck stack issues. The app estimates the bell from the wrist midpoint, so it stays lightweight enough for a live browser session.

The latest visual layer is the biggest shift from the original concept. The mirrored camera feed is projected into body, muscle, skeleton, and Gaussian correction overlays, while a Three.js scene shows a simplified 3D anatomy rig driven by the same pose landmarks.

Those layers are not pretending to be clinical motion capture. They are a product design choice: the user needs to understand why the app is giving a cue, not just see a red or green score. Showing uncertainty, joint risk, posterior chain demand, shoulder lift risk, and depth travel makes the system easier to interrogate.

The current limits are still explicit. Monocular pose landmarks are not calibrated multi camera biomechanics, dense depth is not fused yet, and pain or rehab decisions still belong with a qualified human coach or clinician. The next serious engineering step would be an optional dense depth worker, likely using Depth Anything V2 or a WebGPU depth model, fused with pose landmarks and camera calibration.

The live prototype focuses on the rhythm around training. Before class, set one technical intention. During training, observe what actually happens under pressure. Afterward, record the lesson without turning the product into a scoreboard.

The interface reflects that philosophy. It is calm, sparse, and fundamentals first: current focus, session count, next review, posture, base, patience, current work, and the next lesson. The product is trying to support discipline rather than performance theatre.

The repository still shows the broader platform shape behind the prototype: Next.js, TypeScript, Tailwind, Radix UI, Supabase authentication, and dashboard paths for students, instructors, admin, classes, progress, students, and techniques.

The biggest learning was that BJJ software gets better when it narrows its attention. A complete platform can touch scheduling, content, analytics, identity, community, and coaching workflows, but the first useful version needs to help someone train better this week.

That is where MasterJJ became more interesting: less about cataloguing everything, more about helping the practitioner arrive with one intention, leave with one correction, and keep showing up.

The Story

My daughter was learning the months of the year. Flashcards are boring. Games are fun. So I made a game.

What I Built

A memory matching game where: Cards have month names Match pairs to clear them Track time and attempts Beautiful 3D animations

Stack: JavaScript, Three.js, p5.js

Key Learnings

1. Kids are brutal testers

"This is boring" is honest feedback. Had to add animations, sounds, and celebrations to keep engagement.

2. 3D in the browser is mature

Three.js makes beautiful 3D accessible. The card flip animations were possible with surprisingly little code.

3. Learning games need progression

Starting with 12 months is overwhelming. Built difficulty levels: seasons first, then halves, then all months.

4. Inspired by X

Saw beautiful p5.js animations on X/Twitter and wanted to learn. Analyzing others' creative code is a great way to level up.

The Problem

Most online MP3 converters feel grimy. Pop ups, fake buttons, rate limits, broken providers, and public APIs that can disappear overnight. I wanted the opposite: a clean interface backed by infrastructure I actually control.

What I Built

mp3 is a self hosted audio extraction app with a matching Chrome extension: paste a video URL into a minimal web UI stream extraction progress live in the browser convert to MP3 through local yt dlp + ffmpeg download the finished file from your own backend point the extension at the same /api/extract endpoint

The important shift is architectural. The old dependency on a public extraction API is gone. The app now runs through a Next.js backend that spawns the local extractor directly, stores output in temporary job folders, and serves the final MP3 through its own download route.

Stack: Next.js 16, React 19, Tailwind CSS 4, yt dlp, ffmpeg, Chrome Extension

Key Learnings

1. Critical dependencies should be owned when possible

The public extraction flow worked until it didn’t. When the external API started requiring JWT auth, the product broke for reasons completely outside the app. That was the signal to bring the core path back in house.

2. Good UX still matters in utilitarian tools

This is not a flashy product. It is one field, one button, one outcome. But that simplicity is the feature. Utility software earns trust when the interface feels quiet, clear, and honest.

3. Long running work needs visible progress

Media extraction is not instant. The app now streams newline delimited progress events back to the client so the user sees real movement instead of a dead button and a prayer.

4. Extension drift is real

If the web app evolves and the extension doesn’t, one of them becomes fiction. Keeping both pointed at the same backend makes the project more coherent and much easier to reason about.

Current Status

The repo is up to date with GitHub and in a stronger state now: the self hosted backend is live in the codebase /api/extract validates input, inspects media, and streams progress updates /api/download serves the generated MP3 from temporary job storage the web app is clean, fast, and visually consistent the Chrome extension is aligned with the same backend model the production build passes cleanly

What's Next

deploy the extractor on a host with reliable yt dlp and ffmpeg add cookie or auth support for providers that need more context decide whether format and bitrate controls should become real features or disappear from the extension UI consider a video download mode once the audio path is fully settled

The Problem

Every morning, same debate: "Which bus should we catch?" Google Maps gives too much info. TfL app requires too many taps. We needed a single purpose tool.

What I Built

A mobile friendly web app that shows: Your saved bus stops Real time arrivals Walk time to each stop Clear "catch this one" recommendation

Stack: Next.js, TfL API, Geolocation

Key Learnings

1. Single purpose beats feature rich

Citymapper does everything. This does one thing. For the school run, one thing done well wins.

2. TfL API is excellent

Free, well documented, reliable. Real time bus data for all of London. More cities should have APIs this good.

3. Mobile first isn't optional

This app is used while walking, one hand holding a child. Touch targets need to be huge. Information needs to be glanceable.

4. Personalization is key

Saved stops, favorite routes, morning vs. afternoon mode. Generic bus apps serve everyone poorly.

The Problem

Brazilian Jiu Jitsu improvement is hard to measure. Unlike lifting weights, there's no obvious metric. "Did I get better this month?" is genuinely difficult to answer.

What I Built

A comprehensive training platform for BJJ practitioners: Log training sessions and techniques Track what positions you're winning/losing Identify patterns in your game Set goals and measure progress

Stack: React, Node.js, MongoDB

Key Learnings

1. What gets measured gets improved

Simply tracking which submissions I hit (and got caught in) revealed patterns I was blind to. Data creates awareness.

2. BJJ is uniquely complex

Thousands of techniques, positions, transitions. The data model had to be flexible enough to capture this without overwhelming users.

3. Consistency beats intensity

The app's most useful feature isn't fancy analytics: it's the simple training log that shows attendance over time. Showing up matters most.

4. Community features require community

Built social features, but a training app needs critical mass to be social. MVP should focus on personal tracking.

The Problem

I have ideas in the shower, while walking, mid conversation. By the time I can type, they're gone. I needed to capture thoughts by talking.

What I Built

A voice first note taking app: Press record, start talking Real time transcription AI summarization Extracted action items Organized, searchable notes

Stack: Next.js, OpenAI Whisper API, GPT 4

Key Learnings

1. Voice capture is liberating

No editing while speaking. Just raw thought capture. The AI cleans it up later. Frees your mind to actually think.

2. Real time transcription changed the game

Seeing words appear as you speak creates a different experience than recording and transcribing later. More interactive, more engaging.

3. Summaries need structure

"Key points" and "action items" are more useful than a plain summary. The output format matters as much as the content.

4. This is genuinely useful

Not a demo, not a portfolio piece. I actually use this daily. That's the best validation.

The repo has since grown into a more ambitious product surface. The current app is a public React and Vite studio for designing, simulating, and eventually building self contained smart plant pots.

The first screen frames the project as a design system rather than a gadget. From there, the studio moves through pot geometry, electronics, environmental simulation, and a final build path for moving toward a printable prototype.

The CAD page treats the pot as a machine with shape, reservoir capacity, sensor routing, tubing, electronics access, and material choices. It uses Three.js to make the concept visible while the controls expose the parameters that matter.

The simulation layer models practical plant care variables: plant profile, water demand, reservoir autonomy, ambient temperature, humidity, light, target moisture, and pump dose. It is not pretending to be a finished physics engine yet; it is the foundation for one.

The hardware direction is deliberately serviceable. The repo points toward ESP32 S3 control, capacitive soil moisture sensing, reservoir level detection, environment sensing, and a peristaltic pump so the fluid path stays maintainable.

That matters because this is not just an IoT dashboard problem. A useful self contained pot has wet and dry areas, cleaning access, overflow strategy, printable split lines, calibration, fault detection, and alerts that arrive before the plant is already stressed.

The next meaningful milestone is to connect the studio to real production artifacts: parametric CAD generation, STL export, a bill of materials, firmware configuration, wiring notes, and validation plans for a first physical smart pot.

The old version was closer to a waveform generator. The current repo has grown into a one page production workspace for turning one episode idea into a platform ready launch pack.

The app focuses on YouTube, Spotify, and X. Each platform has its own asset set: long form masters, Shorts frames, thumbnails, podcast playlist art, video podcast covers, square audio cards, vertical clips, launch cards, and quote cards.

That scope makes the product more useful. Instead of exporting one generic image, the user chooses a platform and asset format, edits the visual layers, checks the copy, and exports the right PNG for the selected destination.

The visual editor is built around practical podcast packaging. It has artwork, platform badges, headline hooks, episode titles, hook copy, CTAs, waveform strips, and footer details. Layers can be selected, toggled, and reflected in the preview, export, contact sheet, and JSON production brief.

Audio still matters, but it is now one layer in a larger workflow. Users can upload audio for decoded waveform rendering, or rely on the studio fallback waveform when no source audio is available.

The repo also treats release quality as part of the product. Export QA downloads and verifies 15 generated PNGs: 12 platform assets plus contact sheets for YouTube, Spotify, and X. It checks dimensions, file size, nonblank pixels, and unsupported platform copy.

The result is a tighter creator tool. It is not trying to be a full video editor; it is the packaging step between finishing a conversation and having enough visual material to publish it cleanly.

The left paddle is the learning agent. It observes a simplified game state, chooses up, hold, or down, receives a reward from the rally, and updates a stored action value. Over time, the hit rate, exploration level, learned states, memory tiles, Q value cards, and policy map make that process visible.

The app starts with an educational walkthrough, then runs a timed training session. A viewer can choose a 30, 60, or 120 second run and watch the same loop repeat at a readable pace: observe the state, act, receive feedback, and update one remembered value.

The latest version adds an active recall check. Instead of only watching the dashboard, the viewer predicts whether memory should choose up, hold, or down, then compares that answer with the strongest visible Q value. That small prompt turns the interface from passive observation into a retrieval practice loop.

The training view also has a practical rhythm. The lesson card explains one reward update in plain language, the Next Lesson control jumps to the next useful feedback moment, accelerated practice compresses less interesting repetition, and the demo mode freezes learning so the user can see how the trained policy performs without more exploration.

That framing matters because reinforcement learning is often explained with either abstract equations or finished demos. Pong Learn sits in the middle. It keeps the environment simple enough to understand while still showing the mechanics that make learning from reward work.

The project is inspired by the learning loop made famous by DeepMind's AlphaGo work: estimate useful actions, estimate future outcomes, improve from repeated experience, and then act from the improved policy. Pong Learn is not a recreation of AlphaGo. It uses tabular Q learning instead of neural networks so the process is inspectable.

The result is a small teaching tool for an important AI idea. The user does not just see a score improve. They can watch memory form, see exploration drop, inspect action values, test their own prediction, and understand why the paddle starts making better choices.

The goal is simple: make a Raspberry Pi project easier to start and easier to finish. Instead of sending a beginner across scattered tutorials, pinout charts, forum posts, and half matching code snippets, the plugin keeps the guidance close to the work.

That matters because hardware problems are rarely abstract. A small mistake can be physical: the wrong GPIO numbering mode, a missing resistor, a sensor connected to the wrong bus, or a motor wired directly to a pin that should never drive that load.

So the project treats safety and clarity as part of the product. It is built around low voltage learning projects, clear GPIO guidance, recommended libraries such as gpiozero and RPi.GPIO, and troubleshooting flows for common Raspberry Pi issues.

The repository is packaged as a native OpenClaw plugin. It includes the skill file, supporting reference material, project guides, metadata, and a local validator so the plugin can be checked before it is shared or published.

The result is intentionally straightforward. Raspberry Pi Maker is not trying to be a large app. It is a focused guide that helps someone move from "I want to build this" to "I understand how this circuit and code work together."

The Story

The SoTa & Cocoa Robot Rave Hackathon in London, January 2026. 24 hours. A room full of makers. One goal: build something that dances to music.

Ravitto was born.

What We Built

A music reactive robot that: Analyzes audio in real time Moves servos to the beat Displays expressive animations on LED matrix eyes Actually looks like it's vibing

Stack: Raspberry Pi, Python, Servos, LED Matrix, FFT for beat detection

Key Learnings

1. Hackathons are about shipping, not perfection

We had grand plans for complex choreography. Shipped simple head bob and arm wave that actually worked. Better than ambitious and broken.

2. Hardware debugging is brutal under time pressure

Loose servo connection killed 2 hours. Always test mechanical connections first, then write code.

3. Personality comes from the eyes

The LED matrix "eyes" made Ravitto feel alive. Same movements without eyes looked mechanical. With eyes, it looked like it was having fun.

4. Teams matter

Solo, I would've given up at 3am. With a team, we pushed through and had something to demo.

The idea came from a post by @Etklen asking about bookmarking and taking notes while listening to podcasts. That stuck with me because it describes a common failure in the listening workflow: you hear something useful, pause too late, open another app, and lose the original moment.

The project explores a simple interaction model. While audio is playing, you capture a timestamp, write the note, and keep that note attached to the playback position. Later, the note is not just text; it is a doorway back to the exact part of the podcast that made the idea matter.

That context is the product insight. A note like “great point about distribution” is weak on its own. The same note linked to the exact minute where the speaker explains the point is much more useful, because the listener can recover tone, examples, and surrounding detail.

The prototype also exposes the real constraints. Spotify playback control in the browser depends on authentication, SDK behaviour, and Premium access, so the live demo focuses on communicating the workflow rather than pretending every production integration problem is solved.

For an end user, the value is straightforward: listen normally, capture ideas quickly, and come back later with the context still intact. A fuller version could combine timestamped bookmarks, richer notes, export flows, and AI summaries into a personal knowledge layer for podcasts.

The Experiment

I wanted to test how quickly Grok 3 could create a working game. The answer: faster than I expected.

Vertical Brick Pong is a modern twist on the classic: rotated 90 degrees with brick breaking elements added.

What I Built

A simple arcade game where: Paddle moves up/down (not left/right) Ball destroys bricks on the opposite side Progressive difficulty High score tracking

Stack: JavaScript, HTML5 Canvas

Key Learnings

1. LLMs are genuinely good at games

Clear rules + visual output = great LLM use case. The AI understood game mechanics quickly and produced working code.

2. Orientation changes everything

Same mechanics, different angle. It feels like a new game. Vertical pong requires different reflexes than horizontal.

3. Polish is quick wins

Sound effects, particle explosions, screen shake. Added in an hour, made the game 10x more satisfying.

The Concept

Great video memes need three things: timing, captions, and punchlines. This tool helps you add all three without professional editing software.

What I Built

A simple video editor focused on meme creation: Add text captions at any timestamp Insert sound effects Apply meme style effects Export in meme friendly formats

Stack: JavaScript, FFmpeg WASM, Canvas API

Key Learnings

1. FFmpeg in the browser is real

FFmpeg compiled to WebAssembly means video processing client side. No server costs, privacy preserved, instant feedback.

2. Templates accelerate creation

"Impact font, white text, black outline" as a preset. Don't make users recreate the meme aesthetic from scratch.

3. Timing is everything

The difference between funny and not funny is often 0.3 seconds. Frame precise controls matter for comedy.

I’ve been building out some of my ideas over the past two years, and it’s been both rewarding and exhausting. As exciting as this has been for me, it has also caused a tremendous amount of anxiety and stress as I try to keep up with the ideal workflow, the optimal large language model, and the best techniques to make sure I’m using the latest and greatest technology available. In doing so, I forgot about one of the most rewarding elements of building: understanding. Could that be why I feel so exhausted and anxious? Am I chasing the dopamine hit of building things quickly, instead of leaning and understanding them?

Gaining knowledge is a practice that takes time. Agentic workflows are tricking us into thinking that, because we can prompt an idea, we actually understand it. Lately, I have been feeling the complete opposite. The quicker I build a project and test it, the faster I realise how much more foundational work I need to do, because the solution doesn’t feel right.

One example is Voco, a dictation project I started with the goal of bringing a free, open-source voice dictation app that runs locally into the Linux ecosystem. The app works well, but my expectations are higher, and no matter how much I prompt my agents to make changes, I know deep down that there is a big gap in my technical understanding that I have to address in order to take it to the level I want.

Craftsmanship is my new North Star. I’m done with collecting project badges as if they were accomplishments. In all honesty, that’s what having a new github repo felt like before. But if I cannot understand what is happening at every layer of abstraction within my projects, I cannot enjoy them as before. There is something magical about going through cycles of iteration and improvement that are grounded in knowledge development, not prompt refinement. I guess what I’m looking for is meaning…meaning in the work I do and the actions I take in my everyday life.

Inspired by people like Mario Zechner (@badlogicgames), particularly his blog post “Thoughts on Slowing the Fuck Down”, and Armin Ronacher (@mitsuhiko), with his post “Some Things Just Take Time”, I’m pivoting to a new approach to building and refining projects. The new approach is simple: build through understanding. Leverage the incredible technology currently available to help build knowledge, not just projects at a healthy and sustainable way.

I find it fascinating that these two voices in the industry are fathers and Europeans. It seems like the SF Kool-Aid is not as effective on veterans of the software development European community who also enjoy being more than programmers: fathers, husbands, friends, community enablers… humans.

There is an evident dopamine-reward game at play with the current wave of agentic AI, which can be both fascinating and unhealthy. Let’s make sure we promote ideas, practices, and standards that aim to elevate our understanding of ourselves, our creations and environment in the most positive way.

In the past, I had to step back from social media in order to reclaim a part of myself. However, as someone deeply passionate about Artificial Intelligence, I recognised that this digital isolation came at the price of missing invaluable opportunities for learning and connection with the AI community. Inspired by recent changes in the social media landscape, I decided to re-engage.

Podcasts became my window into the world of Generative AI. Hearing stories of cool innovations, often shared on Twitter, piqued my curiosity. Around the same time, Elon Musk acquired Twitter. I found myself intrigued to experience these changes firsthand as I am a big fan of his work. My short-term objective was straightforward: I wanted to explore whether Twitter could be my go-to for latest news on AI. To no surprise, it did not disappoint. Now, not only am I an active X user, but I’m also curious to see how it can complement my own new site.

After procrastinating for years, I was inspired by stories of other blogs to finally start my own digital space which I can happily say is live and you are reading my first post! This digital notepad is my little corner on the web where I plan to share small AI projects and write down ideas in the form of essays. I like to think of this as a pathway to both my professional and personal growth. However, this journey hasn’t been easy. Balancing a full-time job and family responsibilities demands laser focus and effective time management, skills that I’m still in the process of honing. As the AI landscape keeps evolving at a rapid pace, I aspire to be consistent with my posting and interaction with the community.

Re-starting my online presence from scratch seemed like a terrifying idea a few months back. In my short experience as an active X user, I’ve been able to meet new people, learn about new technologies, and also shake hands with some of the most up-and-coming figures in the AI community. For instance, a few weeks ago I met with Hugging Face CEO Clement Delangue in San Francisco. All of this happened because I was online at the right time and looked at the right information. After this experience, and the feedback that I have received so far on X, I’m excited about the future, especially at the intersection of my day job, my passion for AI, and my ambition to undertake AI projects.

It’s time to build!