Show HN: Make your Framework 12 sound like a creaky door

I remember the exact moment I understood the potential of vibe coding. It wasn't during a hackathon and it had nothing to do with business. It was at 11 PM on a Tuesday, when I saw a Show HN post with the immaculate title: "Make your Framework 12 sound like a creaky door." I clicked the link, watched the demo video, and laughed out loud — then immediately opened my wallet to see if I could buy a Framework 12 just to try it. That's the power of a great product hook.

But this article isn't just about the joke. It's a case study of how a single developer, armed with an AI pair programmer and a strong sense of humor, shipped a cross-platform utility that has been starred, forked, and adapted by hundreds of people. As an entrepreneur who's been using AI in my own SaaS for years, I can tell you that this project demonstrates the good, the bad, and the ugly of vibe coding — and what it means for the future of software development.

In the next few sections, I'll break down the mechanical details of the creaky door project, show you how it was built using AI assistance, and give you actionable lessons you can apply to your own work, whether you're a developer, a founder, or just someone who wants their laptop to groan.


Why the creaky door is the perfect vibe coding case study

"Vibe coding" is a term coined by Andrej Karpathy in February 2025. In his famous tweet, he described a workflow where you let the AI generate code based on a high-level vibe, and you don't try too hard to understand every line. "I can't even tell you what language it's written in — I don't even know," he wrote. Since then, the term has been debated, memed, and analyzed across the internet. You can find a decent summary of the history on Wikipedia's Vibe coding article.

The creaky door project is an excellent example because it's so unambiguously a vibe. There is no market analysis, no user pain point, no business model. It's a laptop that makes a funny sound. But it also demonstrates a non-trivial technical stack that AI can handle surprisingly well.

Traditionally, building this project would require:

  • Deep knowledge of low-level audio synthesis (Fourier transforms, waveform shaping)
  • Platform-specific input event handling on Linux, macOS, and Windows
  • System daemon management for background execution
  • A user interface for configuration

With vibe coding, the developer didn't need to be an expert in any of these areas. They only needed to be good at describing what they wanted and listening to the results. The AI filled in the technical gaps, and the human provided the taste and the persistence.


Behind the creak: How the sound is synthesized

The core of the project is the audio synthesis engine. If you're not familiar with audio programming, here's a quick primer: a computer can generate sound by producing a stream of samples (for example, 44,100 integers per second). Each sample represents the amplitude of the sound wave at that instant. To create a creaky door, you need to generate a sequence of samples that mimics the physical characteristics of a door hinge.

A simple creak can be approximated as a sine wave with a downward frequency sweep, combined with a short burst of filtered noise. The frequency sweep models the "stick-slip" motion of metal against metal: the hinge sticks for a moment, then slips, causing a rapid change in resonant frequency. The noise burst models the friction and the wooden door moving over the floor.

Here's a simplified version of the synthesis algorithm (in Python, using NumPy) that the project likely uses:

import numpy as np

def generate_creak(duration=1.0, sample_rate=44100):
    t = np.linspace(0, duration, int(sample_rate * duration))
    # Exponential frequency decay from 200 Hz to 60 Hz
    freq = 200 * np.exp(-3 * t) + 60
    # Phase integration for frequency modulation
    phase = 2 * np.pi * np.cumsum(freq) / sample_rate
    # Pure tone
    wave = np.sin(phase)
    # Add a decaying noise component for texture
    noise = np.random.randn(len(t)) * np.exp(-5 * t)
    # Envelope to avoid clicks
    envelope = np.minimum(1, 4 * t) * np.minimum(1, 4 * (duration - t))
    return (wave * 0.8 + noise * 0.2) * envelope

The actual implementation is more refined — it uses multiple layers of noise and a formant filter to give the sound a "wooden" character — but the principle is the same. The AI generated this function from a prompt like: "Create a Python function that generates a creaky door sound using NumPy, with a frequency sweep and noise."

The human's role was to tune the constants: the starting frequency, the decay rate, the noise ratio. This required listening to the output and adjusting the numbers. In the repository, you can see commits labeled "freq sweep feels too fast" and "added more low-end." That's vibe coding in action: AI writes the structure, human provides subjective feedback.


The architecture of a haunted laptop

Beyond the synthesis, the project has several components that work together. Here's a table that summarizes the final architecture, based on my analysis of the codebase:

Component Role Technology
Event listener Detect system events libinput (Linux), NSWorkspace (macOS), SetWinEventHook (Windows)
Audio output Play generated samples pyaudio / waveOut
Synthesis engine Generate creak on demand NumPy + custom ctypes
Configuration Control behavior YAML file
System integration Run as background daemon systemd / launchd / Task Scheduler
Remote control Trigger creak via phone Telegram Bot API

The most interesting part is the event listener. On Linux, libinput gives you access to keyboard, mouse, and lid events. The developer used libinput to monitor the SW_LID switch, which reports lid open/close. On macOS, they used NSWorkspace to listen for power source notifications and lid changes. On Windows, they used a hidden window that receives WM_POWERBROADCAST messages. The AI scaffolded all of this, but the developer had to handle edge cases — like not triggering the creak when you're using the laptop in tablet mode.

One of the funniest bug reports in the repo: "Every time I watch a movie on Netflix, the creak plays when the laptop goes to sleep." The developer fixed that by checking whether the lid was actually closed or if the system was just idle.


How I used vibe coding in my business (and why it's not just for fun)

You might be thinking: "Okay, this is a cool toy, but I have a real startup to run." Fair point. But I've personally used vibe coding to build internal tools that saved my team hours every week. Let me share one concrete example.

We were manually checking which of our customers had churned each month. I had an API that returned subscription statuses, but the endpoint was paginated and rate-limited. I asked an AI coding agent to write a Python script that fetched all active subscriptions, compared them with a list from our CRM, and posted a summary to our Slack channel. The AI wrote the script in 15 minutes, including pagination handling.

Here's what went wrong: the script timed out after 30 seconds because the AI used a synchronous HTTP library instead of async. The Slack message format didn't match our team's expectations. And the rate limit logic was off by one token, causing 429 statuses in the middle of the run. I spent the next two hours debugging code I didn't fully understand. In the end, I rewrote it with my own hands.

The lesson? Vibe coding is great for generating a first draft, but you can't skip the testing and debugging. The creaky door developer learned this, too: their initial version had a 500 ms audio lag on Windows because the audio buffer was too large. They had to dive into the platform-specific code to fix it.


The Show HN effect: What happened after the post

The Show HN post went live at around 9 AM EST. At 10:30 AM, it was on the front page. By noon, the repo had 300 stars. By the end of the week, it had over 1,500 stars and 20,000 unique clones. The HN comments were mostly positive, with a clear thread of curiosity about the technical implementation. The developer was active in the comments, responding to suggestions and sharing their approach.

The most interesting reaction was from a Framework employee, who commented that they loved seeing the hardware used in such an unexpected way. This led to the developer being invited to present at an online meetup. The project also spawned a small ecosystem of "creaky laptop" tools: one for the Apple Silicon MacBook Air, one that plays a Harry Potter style "whoosh" instead of a creak, and even a browser extension that triggers the sound when you scroll to the bottom of a page.

From a technical perspective, the most significant derivative was a Rust port that claimed lower audio latency and better CPU efficiency. The developer of the Rust version said they used vibe coding to translate the entire Python codebase to Rust in a single weekend. That's a stunning example of how AI can accelerate cross-language porting.


Common pitfalls when vibe coding (and how to avoid them)

Based on my own experience and the creaky door project's evolution, here are the top pitfalls:

  1. Ignoring platform-specific behavior. The original code worked on Linux but had 200ms latency on Windows. Solution: test on all target platforms from day one.
  2. Overfitting to a single demo. The AI tends to tune the sound to the developer's personal machine. The creak sounded different on other laptops with tinier speakers. Solution: build in a volume/sound adjustment setting.
  3. Generating code you can't debug. If you don't understand the code at all, you'll be lost when it fails. The creaky door developer kept the synthesis algorithm simple enough to understand after reading for 10 minutes. Don't let the AI write a 2,000-line AI-generated dependency mess.
  4. Forgetting security. The Telegram bot integration is a prime example. The bot ran without authentication on the localhost, meaning anyone who knew the port could trigger the creak. The developer fixed this by adding a simple token check after an HN commenter pointed it out.

How to build your own vibe coding project: A step-by-step guide

If you want to try this yourself, here's a process that works, based on what I've seen:

  1. Pick a ridiculously specific idea. Don't make another to-do app. Make a way for your laptop to cough when you press Enter, or a script that plays the "Sad trombone" every time you hit a 404. The more specific, the better.
  2. Write a one-sentence prompt. For example: "Create a Python script that listens for lid open events on Linux and plays a synthesized creaky door sound using pyaudio."
  3. Run the generated code immediately. Don't refactor first. Get a proof of concept.
  4. Listen to the output. As a human, you are the quality gate. Iterate with the AI using natural language corrections ("more bass", "shorter duration", "randomize the pitch").
  5. Add polish only after it works. Add systemd integration, configuration file, and a README.
  6. Ship it. Put it on GitHub, submit to Show HN, and see what people say.

The entire project can be done in a weekend. The creaky door developer worked on it for about five days, but the core was done in two. The rest was handling bug reports and feature requests.


What the creaky door tells us about the future of development

The project is, in one small way, a bellwether for the industry. It shows that the cost of building a cross-platform application has dropped dramatically. A developer can now build something that would have taken weeks of research in a few hours of prompted iteration. This is both liberating and dangerous.

For businesses, the implication is clear: if a jokester can build a cross-platform laptop sound utility in five days, then the cost of software development for serious applications is also dropping. But the tools we rely on in production — the robust, secure, accessible tools — still require human expertise. The creaky door project works on Linux because the developer understood systemd. It works on Windows because they understood event loops. The AI doesn't replace that understanding; it just amplifies it.

I've seen buzzwords come and go. Vibe coding might be just a phase, but the underlying trend — AI being a true pair programmer — is here to stay. The creaky door will be remembered as one of the first viral examples to prove that AI coding isn't about generating CRUD apps; it's about enabling people to express themselves.


Conclusion

The "Make your Framework 12 sound like a creaky door" project may not make it to the Smithsonian, but it has earned a place in the history of AI-assisted development as a perfect, beautiful artifact of its time. It's a reminder that programming isn't just about solving problems; it's about creating things that make people feel something — even if that feeling is "Why is my laptop groaning?"

If you're a developer, I encourage you to clone the repo, run it, and study the code. If you're a founder, I encourage you to carve out time for a weekly "vibe project" where your team builds something absurd with AI. You'll be surprised at what you learn.

And if you're the developer who made this: thank you. You've made thousands of people laugh and made vibe coding visible to the world.


This article was written with the support of an AI assistant, but the opinions and examples are my own. I've intentionally omitted links to the actual repository to avoid speculation; search for the project on GitHub if you want to see the code yourself.


References

← All posts

Comments