DEV Community: Vientapps

I Built a Dead Simple App Because Claude Code Couldn't Hear Me

Vientapps — Wed, 15 Apr 2026 22:19:16 +0000

I use Claude Code through Bedrock at work. That version doesn't give the AI access to your microphone, so the voice input that makes the native Claude desktop client fast just isn't there. I like speaking to Claude more than typing. Over several months that small friction accumulated into something I actually wanted to fix.

The fix was obvious: an app that listens, transcribes, and puts the text on the clipboard. Switch to whatever terminal or text field you're using, paste. One step in the middle instead of typing everything out.

What it does

Mic to Clipboard is one screen, one button. Tap the mic, speak, tap again. The transcript lands in your clipboard. You paste it wherever you want.

That's the whole app. No accounts, no sync, no settings beyond a light/dark mode toggle. It runs on-device: Apple's speech recognizer does the transcription locally so nothing leaves your phone.

The stack

React Native via Expo, because I wanted to ship to iOS without writing Swift. Two packages do all the real work:

expo-speech-recognition wraps Apple's SFSpeechRecognizer API
expo-clipboard writes the final transcript to the system clipboard

Expo's managed workflow meant I could build the whole thing without opening Xcode during development. I only touched Xcode when it was time to configure things for the App Store submission.

Continuous transcription

The interesting part of the core hook is how continuous speech recognition actually works. Apple's recognizer fires result events repeatedly as it processes audio. Each result is either interim (still processing, may change) or final (committed). But when you speak in long sentences with natural pauses, you get multiple final results in a row, not one big one at the end.

So I keep a ref that accumulates the committed finals:

useSpeechRecognitionEvent("result", (event) => {
  const text = event.results[0]?.transcript ?? "";

  if (event.isFinal) {
    if (text.trim()) {
      accumulatedRef.current = accumulatedRef.current
        ? accumulatedRef.current + " " + text
        : text;
      setState((prev) => ({
        ...prev,
        transcript: accumulatedRef.current,
        interimTranscript: "",
      }));
    }
  } else {
    setState((prev) => ({
      ...prev,
      interimTranscript: text,
    }));
  }
});

The accumulatedRef is a plain ref rather than state because I don't want re-renders every time it updates mid-sentence. State updates only happen on final results. When the session ends, the accumulated string is what gets written to the clipboard.

The display text that appears on screen combines both pieces: whatever is committed plus the in-flight interim, so you see words appearing as you speak:

return {
  ...state,
  toggle,
  displayText: state.interimTranscript
    ? (accumulatedRef.current
        ? accumulatedRef.current + " " + state.interimTranscript
        : state.interimTranscript)
    : state.transcript,
};

On-device vs. network fallback

Newer iPhones support fully on-device speech recognition. Older ones fall back to Apple's servers. Rather than just picking one, the app checks at runtime and uses the right config:

const supportsOnDevice =
  await ExpoSpeechRecognitionModule.supportsOnDeviceRecognition();
const config = supportsOnDevice ? SPEECH_CONFIG : SPEECH_CONFIG_NETWORK;

ExpoSpeechRecognitionModule.start(config);

The two configs are identical except for requiresOnDeviceRecognition: true. On-device is preferred because nothing leaves the device, but requiring it on older hardware would just fail silently. The fallback handles it without any user-visible difference.

Silencing the `no-speech` error

If you tap the mic button and then don't say anything, the recognizer fires an error event with code no-speech. I was initially treating that the same as real errors, which meant the UI would flash an error state every time someone changed their mind or accidentally tapped the button.

useSpeechRecognitionEvent("error", (event) => {
  if (event.error === "no-speech") {
    return;
  }
  // handle actual errors
});

Silence isn't an error. Filtering it out means the button just returns to idle with no drama.

The hard part: App Store paperwork

The code took a weekend. Getting through App Store review took longer and was more tedious than I expected.

Apple's privacy manifest system requires a structured XML declaration of which system APIs you use and why. expo-speech-recognition accesses the microphone, and apps using certain APIs need to explain themselves in a format Apple can parse. The permission strings in Info.plist also needed to be specific enough to pass review.

There was also the encryption declaration. Any app that uses HTTPS, even passively (every app does), technically uses encryption and needs to be flagged as non-exempt. It's a paperwork step, not a security review, but a missing checkbox gets the submission bounced.

Screenshot requirements were the most mechanical part: specific pixel dimensions for iPhone 6.7" and 6.5" layouts, taken from simulators at exactly those resolutions. Three to five screens minimum. It's a twenty-minute process once you know the sizes. Discovering them for the first time mid-submission is not ideal.

Where it is now

Live on the App Store. Works on iPhone and iPad. Apple automatically makes it available on Apple Silicon Macs via the "Designed for iPad" compatibility layer, which means zero extra work on my end.

I use it every day. I'll draft a long Claude prompt on the walk to my desk, open the app, say it, and paste it into the terminal. Fast enough that it doesn't break the flow.

What I'd do differently

Skip Mac Catalyst configuration. The automatic Mac compatibility through "Designed for iPad" covers everything I wanted. I spent time setting up Catalyst entitlements, sandbox configs, and Xcode targets that turned out to be unnecessary.

Take screenshots during development. I treated them as a final step and got stuck mid-submission setting up a simulator at the right resolution. They could have been done any time.

Budget a full day for App Store paperwork. The code was done in two days. Getting the privacy manifest, encryption declaration, permission strings, screenshots, and privacy policy all correct and in place took another full day. It's not hard, just time-consuming, and you can't skip it.

I Built an AI Trading Bot That Watches Trump's Truth Social Posts

Vientapps — Mon, 13 Apr 2026 20:56:48 +0000

It started the way these things always do. I was watching the market one afternoon and saw a stock move right after a Truth Social post. Not a subtle drift, either. A real move. And I thought: what if I could catch that automatically?

Not in a "get rich quick" way. More like a genuine curiosity question. Could an AI read a social media post, figure out which sectors it might affect, and place a trade before the market fully priced it in? I wanted to test the idea. So I built a bot to find out.

What it does

The bot monitors Trump's Truth Social posts via an RSS feed, sends each post to Claude for sentiment analysis, runs the result through a 9-layer risk management system, and if everything checks out, executes trades through Alpaca's API. The whole pipeline runs in a loop, polling every 30 seconds.

Claude reads the post and returns a structured analysis: is this market-relevant? What's the sentiment? Which sectors are affected? Should we buy, sell, or hold? The response maps to specific ETFs across 19 sectors, from technology (XLK) to defense (ITA) to crypto (BITO). The full source is on GitHub if you want to poke around.

If the market is closed when a post comes in, the analysis gets queued and the trades execute when the market opens.

The stack

Python was the obvious choice here. The trading ecosystem in Python is mature, and Alpaca's SDK (alpaca-py) made the brokerage integration straightforward. Anthropic's SDK handles the Claude calls. SQLite stores the audit trail because I wanted every decision logged without needing to spin up a database server.

The whole thing runs in Docker. One container, one docker-compose up -d, and it's watching.

I used Pydantic for config management and data validation. Every environment variable, every risk parameter, every API response gets validated before anything touches real money. Structlog handles logging with enough context to trace any trade back to the original post that triggered it.

The prompt that drives the whole thing

Getting Claude to return consistent, actionable analysis was the core challenge. The system prompt has to be specific enough to produce structured JSON every time, but flexible enough to handle the unpredictable nature of political social media posts.

SYSTEM_PROMPT = f"""You are a financial analyst AI. Your job is to analyze social media posts
from the President of the United States and determine their potential impact on financial markets.

You must evaluate each post and return a structured analysis. Be conservative in your assessments.
Only mark posts as relevant if they clearly relate to economic policy, trade, specific industries,
regulations, international relations affecting markets, or similar market-moving topics.

Posts about personal matters, birthdays, endorsements of non-market candidates, or general
political commentary without clear economic implications should be marked as NOT relevant.
...
Be specific about which sectors are affected. If the impact is broad/unclear, use "broad_market".
Only suggest "buy" or "sell" when you have reasonable confidence. Default to "hold" when uncertain."""

That "default to hold when uncertain" line does a lot of heavy lifting. Without it, Claude tends to find market relevance in everything.

Nine ways to say no

The risk management system was something I was genuinely proud of. Before any trade executes, it has to pass through nine sequential checks. Fail any one of them and the trade gets rejected.

def evaluate(self, analysis, post_id, portfolio_value, current_positions):
    if analysis.confidence < settings.confidence_threshold:
        return []
    if not analysis.is_relevant:
        return []
    if analysis.direction == "hold":
        return []
    if self.last_trade_time:
        elapsed = (datetime.now() - self.last_trade_time).total_seconds()
        if elapsed < settings.trade_cooldown_seconds:
            return []
    if current_positions >= settings.max_open_positions:
        return []
    trades_today = self.db.get_trades_today()
    if self._daily_loss_exceeded(trades_today, portfolio_value):
        return []

Confidence threshold, relevance check, direction check, cooldown timer, position limits, daily loss limit, equity floor, buying power buffer, and short exposure cap. Short positions get extra scrutiny: 3% of portfolio max per position versus 5% for longs, tighter stop losses (2% vs 3%), and a 15% cap on total short exposure.

Every rejection gets logged with the specific reason. I wanted to be able to look back and understand exactly why a trade didn't happen.

Gap protection

One thing that kept me up at night was gap risk. What happens when a post drops at 8pm, the bot queues a trade, and by the time the market opens, the price has already gapped way past where the stop loss should have been?

def check_gap_positions(self, db):
    positions = self.client.get_all_positions()
    closed = []
    multiplier = settings.gap_protection_multiplier

    for position in positions:
        entry_price = float(position.avg_entry_price)
        current_price = float(position.current_price)
        gap_threshold = stop_pct * multiplier

        if is_long and current_price <= entry_price * (1 - gap_threshold):
            self.client.close_position(symbol_or_asset_id=symbol)
            closed.append(symbol)
    return closed

The gap protection runs every tick during market hours. If a position has moved 1.5x past its stop loss percentage, it force-closes the position immediately. It's a safety net for the scenario where Alpaca's bracket order stops haven't triggered because the price jumped right past them.

What went wrong

Paper trading worked beautifully. Claude's analysis was often right. The sector mapping made sense. The risk system caught bad trades. On paper, the strategy was profitable.

Then I turned on real money and learned a painful lesson about latency.

The problem is the pipeline. The RSS feed updates every 30 seconds or so. Then Claude needs a few seconds to analyze the post. Then the trade needs to submit and fill. By the time all of that happens, the market has already moved. The people who profit from these posts are the ones who see them in real time, not 30-45 seconds later.

Paper trading doesn't punish you for this. Paper fills happen at the price you request. Real markets don't work that way. The slippage between what I expected to pay and what I actually paid ate into every trade. A move that looked like a 2% gain on paper turned into a 0.5% gain or even a loss in practice.

The analysis was often correct. Claude would correctly identify that a post about tariffs was bearish for emerging markets, and EEM would indeed drop. But by the time my order filled, the easy money was already gone.

Where it is now

The bot still runs on paper trading. It's a genuinely interesting system for studying how social media sentiment translates to market movements. The SQLite database has become a decent dataset for analyzing which types of posts actually move markets and which ones are noise.

As a real trading system, it needs a faster data source to be viable. The strategy itself isn't broken. The execution speed is.

What I'd do differently

Ditch the RSS feed entirely. RSS was convenient but it's fundamentally too slow for this use case. Some kind of direct web scraping or websocket connection to Truth Social would cut the detection time from 30+ seconds to near-instant. That alone might make the difference between profitable and not.

Pre-build analysis patterns. Claude is smart, but it's also slow relative to market speed. If I could build a pattern library from historical posts (tariff mentions = short EEM, deregulation mentions = long XLF), I could skip the API call entirely for common post types and only use Claude for genuinely novel content.

Start with limit orders instead of market orders. Market orders during volatile moments guarantee bad fills. Limit orders might mean some trades don't execute, but the ones that do would be at prices that actually make the strategy work.

The core idea, using AI to parse social media for market signals, isn't wrong. The execution just needs to be measured in milliseconds, not seconds. And that's a fundamentally different engineering problem than the one I solved.

Building Roamly: AI-Powered Group Travel Planning

Vientapps — Thu, 09 Apr 2026 16:12:03 +0000

Every time my friend group tries to plan a trip, it falls apart the same way. Someone throws out a city, someone else says it's too expensive, a third person can't make those dates, and a fourth person has already been there and doesn't want to go back. Three weeks of back-and-forth in a group chat later, we either settle on somewhere nobody's that excited about or give up entirely.

I've been on both sides of this. I've been the one with strong opinions that kill momentum. I've been the one who just wants something on the calendar and agrees to whatever. Neither feels great. So I built Roamly.

What it does

Roamly is a group travel planner. You create a group, invite your friends, and everyone privately fills out their preferences: where they want to go, where they don't, what their budget is, what dates work for them, how adventurous they're feeling. When everyone's ready, the group planner triggers an AI search. Claude reads all those preferences, does some web research, and generates a set of destination recommendations with full day-by-day itineraries tailored to the group.

The key word is privately. Nobody sees what anyone else submitted until after the AI runs. That keeps people honest instead of anchoring to whoever spoke first.

You can try it at roamly.vientapps.com. Check out the Roamly project page for a full feature overview.

The stack

Next.js 15 (App Router) deployed to Cloudflare Workers via OpenNext
Supabase for auth, database, and real-time subscriptions
Anthropic Claude for itinerary generation, with streaming responses
Stripe for subscription billing
Tailwind v4 and shadcn-style components for the UI

The real-time piece is important. When members fill out their preferences, every other person in the group sees their status update live. No polling, no refreshing. Supabase's Postgres change subscriptions handle it cleanly:

const channel = supabase
  .channel(`group-prefs-${groupId}`)
  .on(
    "postgres_changes",
    {
      event: "*",
      schema: "public",
      table: "member_preferences",
      filter: `group_id=eq.${groupId}`,
    },
    (payload) => {
      if (payload.eventType === "UPDATE") {
        setPreferences((prev) =>
          prev.map((p) =>
            p.user_id === (payload.new as MemberPreferences).user_id
              ? (payload.new as MemberPreferences)
              : p
          )
        );
      }
    }
  )
  .subscribe();

One subscription, three event types handled, no full refetch. It just works.

The hard part: getting the AI to behave

The core feature is the AI search, and it was the hardest thing to get right. The goal is simple: take a group's mixed preferences and produce a useful, structured itinerary JSON. The reality is that language models are not naturally reliable at this.

Early outputs were all over the place. Destinations that blew someone's budget. Missing fields that caused the UI to crash. Hallucinated dates. Responses that ignored explicit exclusions like "no beach destinations."

The fix was iterative and unglamorous: better constraints in the system prompt, explicit hard rules around budget and exclusions, and treating the JSON schema as a contract that the model had to follow. I also built in a credit refund system for cases where the model hits token limits or refuses a request. Users shouldn't lose a search credit because Claude decided to truncate at 8,000 tokens.

The model selection is tiered by subscription level. Three Claude models mapped to three tiers:

export const AVAILABLE_MODELS: ModelConfig[] = [
  {
    id: "claude-haiku-4-5-20251001",
    label: "AI Basic",
    tier: "budget",
    description: "Quick results, good for exploration",
  },
  {
    id: "claude-sonnet-4-5",
    label: "AI+",
    tier: "standard",
    description: "Great quality and detail",
  },
  {
    id: "claude-opus-4-5",
    label: "AI Pro+",
    tier: "premium",
    description: "Most thorough itineraries",
  },
];

Haiku is fast and free. Opus takes longer but produces noticeably richer itineraries. Most people will land on Sonnet.

Streaming and recovery

AI responses take time. For a complex group itinerary, Claude can run for 15-30 seconds. Showing a blank screen that long is not acceptable, so I stream the response directly to the client as it generates. The UI shows the tail of the stream in real time so users know something is happening.

The trickier problem is what happens when the stream gets interrupted. User closes the tab, network drops, phone locks. I track active searches in localStorage with a 120-second TTL:

export function getActiveSearch(
  groupId: string,
  userId: string
): ActiveSearch | null {
  try {
    const raw = localStorage.getItem(STORAGE_KEY);
    if (!raw) return null;
    const entry: ActiveSearch = JSON.parse(raw);
    if (entry.groupId !== groupId || entry.triggeredBy !== userId) return null;
    const age = Date.now() - new Date(entry.startedAt).getTime();
    if (age > 120_000) {
      localStorage.removeItem(STORAGE_KEY);
      return null;
    }
    return entry;
  } catch {
    return null;
  }
}

When a user lands back on the search page and a recent search marker exists, the app polls the database every 3 seconds for up to 30 attempts looking for a saved result. If it finds one, it loads it. If not, it shows a failure state. The user doesn't lose their credit either way on a connection error.

What went wrong: Cloudflare

Deploying Next.js to Cloudflare was rougher than I expected. The first assumption I made was wrong: Next.js cannot be deployed as a Cloudflare Pages project the normal way. It has to run as a Worker, using OpenNext as the adapter. The config itself ends up being trivially simple:

import { defineCloudflareConfig } from "@opennextjs/cloudflare";
export default defineCloudflareConfig();

But getting there involved a lot of failing builds and confusing error messages.

The other headache was secrets. Environment variables that work fine in Vercel don't automatically show up at runtime in Cloudflare Workers. You have to use wrangler secret put to push them, and the compatibility flags in wrangler.toml matter for Node.js APIs to work at all:

compatibility_flags = ["nodejs_compat", "nodejs_compat_populate_process_env"]

That second flag, nodejs_compat_populate_process_env, is the one that actually makes process.env work. Without it, all your secrets are undefined at runtime and you get a wall of cryptic auth errors. I spent more time than I'd like to admit figuring that out.

Where it is now

Roamly is live and free to use. There's a paid tier that unlocks more monthly searches and access to better models. It's early. The user base is small. But the core loop works, and I've actually used it with my own friends to plan a trip, which was the original goal.

What I'd do differently

If I started over, I'd use plain React instead of Next.js. Not because Next.js is bad, but because Cloudflare Workers is where I wanted to deploy from the start, and the Next.js-on-Workers story involves the OpenNext adapter as a middle layer. That layer works, but it's an extra thing to maintain and debug. A Vite-based React app with a separate API layer would have been faster to ship and easier to reason about on the edge.

The second thing I'd change is how I approached the AI prompting. I iterated my way to something that works, but it took longer than it needed to because I didn't think clearly enough about the output contract upfront. Starting with the JSON schema and working backwards to the prompt would have saved a few frustrating weeks.

The group travel problem is real. Roamly doesn't solve all of it, but it solves the part where nobody can agree on where to go. That's a start.

DEV Community: Vientapps

I Built a Dead Simple App Because Claude Code Couldn't Hear Me

What it does

The stack

Continuous transcription

On-device vs. network fallback

Silencing the no-speech error

The hard part: App Store paperwork

Where it is now

What I'd do differently

I Built an AI Trading Bot That Watches Trump's Truth Social Posts

What it does

The stack

The prompt that drives the whole thing

Nine ways to say no

Gap protection

What went wrong

Where it is now

What I'd do differently

Building Roamly: AI-Powered Group Travel Planning

What it does

The stack

The hard part: getting the AI to behave

Streaming and recovery

What went wrong: Cloudflare

Where it is now

What I'd do differently

Silencing the `no-speech` error