Forem: Vientapps

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.