I’ve been writing code without touching the keyboard. Not as a gimmick — as my actual daily workflow for the last few weeks.

The setup has two parts:

• Wispr Flow for voice input
• An 8BitDo Micro bluetooth controller for everything else

That’s it.

The 8BitDo Micro. About the size of a keychain.

Why the controller?

Voice input alone doesn’t work. Claude Code constantly hands you things you have to press a key for — and it’s not just “approve” prompts. Sometimes it’s a list of options to pick from, sometimes you want to cancel what it’s doing mid-stream, sometimes you need to scroll through a diff or jump between files. Saying “yes” into Wispr just types the word “yes” into the chat box — not what you want.

You need real keys: Enter to accept, Esc to cancel, arrows to move through options, Shift+Tab to step backward. A keyboard does this fine — but then you’re back at the keyboard.

So I bought a tiny gamepad, put it in keyboard mode, and mapped its buttons to the exact keys Claude Code Desktop listens for. Accept, reject, navigate, escape. Done.

Quick note: the 8BitDo desktop app didn’t work for me (couldn’t see the controller), but the iOS app did — I mapped everything from my phone.

Button mapping in 8BitDo’s Ultimate Software. Enter, Esc, arrows, Shift+Tab — the keys Claude Code actually cares about. The up/down arrows look swapped because I hold the controller rotated (see the GIF below), so the D-pad ends up pointing the “right” way from my grip.

How it actually works

Hold Ctrl+Cmd+`, say what I want, let go. Wispr transcribes it straight into the Claude Code chat box. (Wispr defaults to fn, but fn can’t be mapped to a controller button, so I use the key combo and bind it to the controller instead.)

Two push-to-talk shortcuts — I use the Ctrl+Cmd+` combo because it’s mappable to the controller.

Claude Code goes off and does the thing. Reads files, edits them, runs the dev server, screenshots the preview. When it asks for approval, I hit the accept button on the controller. When I want to redirect it, I hold the combo and talk again.

Claude Code Desktop. Chat on the left, live preview on the right. Controller does the approvals.

Here’s a real clip — me describing a feature, Claude Code doing it, me approving with the controller, done:

Zero keystrokes. The feature is in the preview before I’ve finished my coffee.

Why I actually do this

Thought it would be a novelty. It’s not. A few real reasons it stuck:

Productivity. Talking forces me to explain what I want — intent, constraints, edge cases — instead of jumping into code. Claude gets a better brief, the first attempt is closer to right. My “thinking out loud” became the spec.

Less time hunched over the keyboard. Eight hours a day of typing catches up with you. Offloading most of the keypresses to voice + a thumb on a controller means my wrists and shoulders get an actual break, even on long days.

It feels like Iron Man. Honestly. Talking to your environment, pressing one button to act, watching things build themselves in front of you — it’s a bit absurd, a bit magical, and it makes me want to keep working instead of wanting a break.

One nice bonus: Wispr Flow keeps a history of everything you dictate. If Claude eats your prompt, or you want to reuse a description, it’s all there in the transcript panel.

The setup in 30 seconds

1. Install Wispr Flow (free tier works fine). Set push-to-talk to a key combo you can map to a button (I use Ctrl+Cmd+`).
2. Get an 8BitDo Micro (or any programmable bluetooth controller). Map the buttons you need — Enter for accept, Esc for reject, arrows for navigation, plus your Wispr shortcut.
3. Open Claude Code Desktop. Focus the chat box.
4. Talk. Press the button when it asks. Repeat.

The interesting part isn’t the tools. It’s noticing how much of coding is describing intent — and how much better that works out loud, with a controller in your hand, than hunched over a keyboard.

Setting up your dev environment with Claude Code previews

At FirstPromoter, our platform spans four distinct frontends — an Admin Dashboard, an Affiliate Portal, a Support Dashboard, and our public Docs site — all living as git submodules inside a single monorepo alongside our Rails API and dbt analytics project. Wiring this up to Claude Code’s new desktop preview feature took a single file, .claude/launch.json:

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "Admin",
      "runtimeExecutable": "docker-compose",
      "runtimeArgs": ["up"],
      "port": 5173,
      "autoPort": false
    },
    {
      "name": "Affiliate",
      "runtimeExecutable": "docker-compose",
      "runtimeArgs": ["up"],
      "port": 3001,
      "autoPort": false
    },
    {
      "name": "Support",
      "runtimeExecutable": "docker-compose",
      "runtimeArgs": ["up"],
      "port": 5175,
      "autoPort": false
    },
    {
      "name": "Docs",
      "runtimeExecutable": "docker-compose",
      "runtimeArgs": ["up"],
      "port": 3003,
      "autoPort": false
    }
  ]
}

Each frontend is declared as a preview configuration that shells out to docker-compose up, mapped to the port its service is exposed on. Because every preview shares the same Docker Compose stack, launching any one of them brings up the entire backend — Rails API, Postgres, Redis, Sidekiq, Elasticsearch — so Claude can click through the Admin UI, hit a real API, and watch the console for errors without me juggling a dozen terminals.

Once it’s wired up, the workflow gets even more hands-free: I just say “open the Admin preview” (or Affiliate, Support, Docs) and Claude starts the right one and opens it in the side panel. No terminal, no remembering ports.

The result: Claude can preview a feature, review the diff inline, and push the PR through CI to merge — all without leaving the desktop app, and without writing a single bespoke dev script on top of the Docker setup FirstPromoter already had.

The FirstPromoter dashboard — the page that used to time out

Here’s what a typical week looks like in production:

That’s more than double the throughput from last year (15.7M → 35.5M) — while simultaneously making things faster. We process payment webhooks from Stripe, Chargebee, Braintree, and Paddle — about 1.47 million per day. Each one needs to be fast and reliable because it directly affects revenue attribution for our customers.

Here are seven lessons we learned the hard way.

1. Counter Caching Saves More Than You Think

Our dashboard showed counts everywhere — active promoters per campaign, pending referrals, total commissions. Each one a COUNT(*) query hitting PostgreSQL in real time.

Promoter detail view — counts everywhere, each one a potential COUNT query

Rails’ built-in counter_cache got us started, but we graduated to counter_culture for conditional counts and multi-level caching.

The real lesson wasn’t “add counter caches” though — it was scope your cache refreshes. We were recalculating counters for archived and inactive companies on every cron sweep. Scoping the refresh to active companies only cut our background job time dramatically:

# Before: refreshing everything, including dead data
Campaign.counter_culture_fix_counts

# After: scope to what actually matters
Company.active.find_each do |company|
  Campaign.counter_culture_fix_counts(
    where: { company_id: company.id }
  )
end

We also moved reconciliation to an async worker that reads from a replica database — so the hourly counter refresh doesn’t touch the primary at all:

CounterCulture.configure do |config|
  config.use_read_replica = Rails.env.production?
end

Our dashboard stats endpoint went from 10s+ to 2.5s, and the promoter listings that used to choke on COUNT queries now load in under 500ms.

2. N+1 Queries: Preloading Too Much Is as Bad as Too Little

Everyone knows to fix N+1 queries. The less obvious lesson: preloading too aggressively can be just as bad. We’ve seen developers throw every association into includes and wonder why memory usage spikes.

We run Bullet and Prosopite in development to catch issues, but the real discipline is profiling first, then adding preloads only for what the serializer actually touches. Nothing more.

3. Redis for the Hot Path

When you’re processing 1.47M webhooks per day, every millisecond in your hot path counts. We use Redis for four things:

Webhook queue. We don’t process webhooks inline. Validate the payload, enqueue a Sidekiq worker, return 200. The actual business logic happens in the background. That’s how we handle 10M+ webhooks per week — the response time is just validation and enqueue.

Atomic counters. Email send counts, tracking events — anything high-frequency that would cause database contention. We increment in Redis and flush to PostgreSQL periodically.

Revenue caching. Dashboard revenue calculations that join multiple tables get cached in Redis with Sidekiq workers refreshing on a schedule. The dashboard loads instantly while data stays reasonably fresh.

Rails cache store. Query and fragment caching backed by Redis with connection pooling — essential to prevent connection exhaustion under load.

4. Sidekiq: Tune It Like an Engine

With over 100K scheduled jobs in queue at any given time, Sidekiq tuning isn’t optional.

Dedicated processes for critical paths. We run separate Sidekiq processes for tracking (most latency-sensitive), mailers, and general work. A bulk CSV export shouldn’t be able to starve real-time webhook processing.

Queue limits. sidekiq-limit_fetch sets explicit concurrency limits per queue. Without it, a flood of low-priority jobs monopolizes every worker.

Consolidate related workers. We had separate workers for archiving promoters, referrals, and commissions. Consolidating them into a single job with SQL FILTER aggregation cut database round-trips and was far easier to reason about.

# sidekiq.yml — separate concerns
:queues:
  - [tracking, 10]
  - [critical, 8]
  - [mailers, 5]
  - [default, 3]
  - [low, 1]

5. Know When PostgreSQL Isn’t Enough

Our dashboard analytics — trending charts, revenue breakdowns, time-series comparisons — were bringing PostgreSQL to its knees. Queries scanning millions of records timing out at 30 seconds. Not slow — literally timing out.

We migrated the analytics layer to Google BigQuery. Same queries that timed out in PostgreSQL now run in under 2 seconds. But not everything belongs in BigQuery — we initially moved too aggressively and actually reverted some queries back when the added complexity wasn’t justified. Our rule of thumb: if a query scans hundreds of thousands of rows or involves complex time-series aggregations, BigQuery. Everything else stays in PostgreSQL.

Here’s where things stand now — 95th percentile response times over the last 30 days:

95% of API requests complete under 3.4s. These are the same analytics queries that used to time out at 30s.

6. Database Views for Complex Reports

We started with the Scenic gem to create PostgreSQL views for reporting queries that would otherwise require joining five or six tables every time. That worked until it didn’t — the views got too complex and too slow as the data grew. We ended up moving the heavy ones to BigQuery, where the same join logic runs over millions of rows without breaking a sweat. The simpler views still live in PostgreSQL where they belong.

7. Batch Size Is a Tuning Parameter

When exporting large datasets, batch size dramatically affects both memory and speed. We iterated from the Rails default of 1,000 up to 50,000 (memory issues) and back down. The answer: different sizes for different models. A lightweight model handles 50K batches fine. A model with multiple eager-loaded associations might cap out at 5K before memory gets uncomfortable.

Where the Traffic Comes From

Payment webhooks dominate our traffic. Here’s the breakdown by provider:

Each integration has its own payload format, retry behavior, and edge cases. We keep an eye on all of it through AppSignal for performance monitoring, Better Stack for logs, Bullet/Prosopite for N+1 detection, and strong_migrations to keep deploys safe.

These lessons came from years of working on FirstPromoter. If you’re building a SaaS and thinking about launching an affiliate or referral program, give it a try.

Find me on LinkedIn or GitHub.

Most of my bugs can’t be reproduced on localhost.

Unlocking doors over HTTP

The booking app lets people reserve a phone booth, walk up to it, and unlock it from their phone. We integrate with Salto and Tapkey hardware locks. When a user taps “unlock,” our API sends a command to a physical lock on a physical door in a physical building somewhere.

This changes how you think about error handling. HTTP timeouts mean something different when the consequence is someone standing in a hallway. We built fallback flows with OTP codes, lock status polling, and graceful degradation for when the hardware goes offline.

The interesting edge case: what happens when someone is inside and their card declines? You can’t lock someone inside a room because their card declined. The physical world doesn’t care about your payment flow.

The booking flow — find a room, reserve it, walk up and unlock

The data pipeline nobody warned me about

Every ROOM unit has a Particle IoT device inside it. Tracks occupancy — when someone enters, when they leave, signal strength, device health. That data flows through Google Pub/Sub into BigQuery, and our Rails API pulls it back out for analytics dashboards.

Sounds simple: device sends event, Pub/Sub queues it, BigQuery stores it, Rails reads it back. In practice: devices drop offline, send duplicate events, have clock drift. A unit in Tokyo and a unit in New York need their sessions in the right timezone. Devices sometimes report “occupied” when nobody’s there (the sensor picked up movement outside the booth). You end up writing reconciliation logic you never planned for.

The portal shows office managers how their spaces are actually used. Turns out most companies have no idea. The data is usually surprising — the meeting room that seats 4 gets used by 1 person for calls, and the phone booths are at 90% utilization.

The Sense dashboard — utilization data from IoT sensors across offices

Two stacks, same door

The B2B portal is Rails — organizations, offices, units, NetSuite for invoicing, Salesforce sync. The consumer app is Node with Prisma and TypeScript — sessions, Stripe payments, magic link auth.

Different products, different users, different tech stacks, same physical units.

A unit registered in the portal needs to show up in the booking app. Pricing changes in one system need to reflect in the other. We made it work but it was a recurring source of bugs. Back when I was just getting started with Rails I thought picking the right framework was the hard part. Turns out keeping two of them in sync is harder.

What I took away from this

Software for physical spaces is humbling. You can’t roll back a deployment when someone is locked inside a phone booth. Latency matters differently when it’s the gap between tapping a button and hearing a lock click. Your test suite can’t open a real door.

Before ROOM everything I built lived in the browser. IoT work broke that mental model. Redis caching, background job patterns, careful error handling — I learned all of it here the hard way, because a sensor was lying about occupancy at 3am.

Biggest surprise: how much of this job is communication. Understanding what a client actually needs vs what they’re asking for. Figuring out why a project is stuck when the code is fine. Got better at this mostly by getting it wrong a few times.

I want to get serious about performance in 2019. The projects are outgrowing my understanding of caching, background jobs, and database optimization. I’ve been leaning on Rails defaults and they’ve been fine, but “fine” won’t cut it much longer.

Related: our team’s 2018 year in review on the Wolfpack Digital blog.

Rails backend (obviously), Here maps for location, and whatever else they gave us — Telegram, IBM Cloud, Snips. The code was terrible but it worked. Won a special prize from Here, got a trip to Krakow for another hackathon.

Honestly the best part was just building something without process. No tickets, no standups, no PR reviews — just two people trying to ship before the timer runs out.

The Wolfpack team also wrote about this on their blog.

Quick clarification because this trips people up: Ruby is the language, Rails is the framework on top of it. Handles routing, database stuff, the whole request lifecycle — so you skip the boilerplate and get to the actual product.

Two things hooked me. Convention over configuration — Rails decides where files go, how URLs work, how models connect to the database. You can override it all, but the defaults are good. And the gem ecosystem. Need auth? Devise. File uploads? CarrierWave. Admin panel? Rails Admin. Almost never starting from zero.

“But does it scale?” — yes. Shopify runs on Rails. GitHub ran on it for years. Basecamp still does. When things are slow it’s usually a query problem, not a Rails problem.

Not for everything — mobile apps, heavy computation, static sites, use something else. But for web apps and APIs, which is most of what we build here, nothing gets you moving this fast. After two years of Java, Ruby feels like a different world. Glad I made the switch.