DEV Community: jason rauch

How I added Solana Pay USDC to a SaaS app — a real implementation, not a tutorial

jason rauch — Sun, 10 May 2026 07:21:13 +0000

Most Solana Pay tutorials are synthetic. Here's the actual code running in production on transpiler.us, a developer tools platform I built solo.
Why Solana Pay instead of Stripe-only
I already had Stripe. But Stripe doesn't work everywhere, and USDC settling instantly with near-zero fees is genuinely better for global users. It wasn't about looking good — it was the right technical choice.
The implementation
The flow: user clicks "Pay with USDC" → backend generates a reference keypair → frontend displays a QR code with the Solana Pay URL → backend polls the RPC endpoint until it sees a confirmed transaction matching the reference → credits are added to the user's account.
No third-party wrapper. I read the Solana Pay spec and built it directly.
[Walk through the key code sections — QR generation, reference keypair, polling loop, transaction verification]
What I'd do differently
Use a dedicated RPC endpoint from day one instead of the public mainnet endpoint. Public RPC rate limits will bite you in production.
The full source is MIT licensed: https://github.com/Jeah84/devtools-platform
Live platform: https://transpiler.us

# 5 Railway.io Config Mistakes That Silently Break Deployments (And How to Fix Them)

jason rauch — Tue, 05 May 2026 19:22:34 +0000

If you've used Railway.io for more than a week, you've probably experienced the special frustration of a deployment that looks like it worked — green checkmark, no errors — but your app is completely unreachable. No traffic. No response. Just silence.

Most of the time it comes down to a config mistake that Railway doesn't loudly flag. Here are the five that get developers most often, with exact fixes for each.

1. Hardcoding the PORT

This is the #1 Railway gotcha and it catches almost everyone at least once.

Railway injects a $PORT environment variable dynamically at runtime. Your app must read and listen on that port. If you hardcode port 3000 or 8080, your service starts fine but never receives traffic — Railway is sending requests to a port your app isn't listening on.

Broken:

{
  "variables": {
    "PORT": "3000"
  }
}

Setting PORT as a static variable doesn't help — Railway's injected value overrides it anyway.

Fixed — in your app code:

const port = process.env.PORT || 3000;
app.listen(port);

Fixed — in a Dockerfile:

# Don't do this:
EXPOSE 3000

# Do this — let Railway set the port at runtime:
CMD ["node", "server.js"]
# And in server.js: app.listen(process.env.PORT)

This applies to every language and framework. Python with Flask, Go with net/http, Ruby with Puma — they all need to bind to process.env.PORT (or the equivalent env var read in your language).

2. Using an Invalid Builder Value

Railway supports four builders: nixpacks, dockerfile, heroku, and railpack. That's it. If you write anything else — "node", "auto", "docker" — Railway either ignores it or fails silently.

Broken:

{
  "build": {
    "builder": "node"
  }
}

Fixed:

{
  "build": {
    "builder": "nixpacks"
  }
}

If you're using Railway's newer Metal infrastructure, you're likely moving to Railpack (the successor to Nixpacks). In that case, use a railpack.json file with the correct providers array instead:

{
  "$schema": "https://schema.railpack.com",
  "providers": ["node"],
  "deploy": {
    "startCommand": "node server.js"
  }
}

3. No Restart Policy — Crashed Services Stay Down

By default, if your service crashes Railway won't automatically restart it. You need to explicitly set restartPolicyType.

Broken (service stays dead after a crash):

{
  "deploy": {
    "startCommand": "node server.js"
  }
}

Fixed:

{
  "deploy": {
    "startCommand": "node server.js",
    "restartPolicyType": "ON_FAILURE"
  }
}

Valid values are ON_FAILURE, ALWAYS, and NEVER. For most production services you want ON_FAILURE. Using ALWAYS means Railway will restart even intentional shutdowns — usually not what you want.

4. Missing or Broken healthcheckPath

If you define a healthcheckPath, it must start with a /. If it doesn't, Railway either rejects the config or the health check never passes — causing your service to restart in a loop.

Broken:

{
  "deploy": {
    "healthcheckPath": "health"
  }
}

Fixed:

{
  "deploy": {
    "healthcheckPath": "/health"
  }
}

Also make sure that route actually exists in your app and returns a 200 status. A common mistake is defining /health in the config but forgetting to add the route handler in the code.

If you're not ready to implement a health endpoint, remove the healthcheckPath field entirely rather than leaving it broken — Railway will fall back to basic process monitoring.

5. npm install Instead of npm ci in Build Steps

This one is subtle but causes non-deterministic builds — meaning your app works locally and in one deployment but breaks in the next.

npm install can silently upgrade packages within the ranges defined in package.json. npm ci installs exactly what's in your package-lock.json — no surprises.

Broken (nixpacks.toml):

[phases.install]
cmds = ["npm install"]

Fixed:

[phases.install]
cmds = ["npm ci"]

Broken (railpack.json):

{
  "steps": {
    "install": {
      "cmds": ["npm install"]
    }
  }
}

Fixed:

{
  "steps": {
    "install": {
      "cmds": ["npm ci"]
    }
  }
}

Same rule applies to Dockerfiles — RUN npm ci instead of RUN npm install.

Catching These Automatically

These five mistakes are easy to make and annoying to debug because Railway doesn't always give you a clear error message. I got tired of finding them manually so I built Railway DevTools — paste your config and Claude AI audits it instantly, flags issues by severity, and shows you the exact fix.

It supports railway.json, railway.toml, Dockerfile, nixpacks.toml, railpack.json, and Procfile. Free to try with no sign-up.

Summary

Mistake	Symptom	Fix
Hardcoded PORT	App unreachable	Read `process.env.PORT`
Invalid builder	Build fails silently	Use `nixpacks`, `dockerfile`, or `heroku`
No restart policy	Crashed service stays down	Set `restartPolicyType: ON_FAILURE`
Bad healthcheckPath	Restart loop	Start path with `/`
npm install vs npm ci	Non-deterministic builds	Use `npm ci`

If you've run into other Railway gotchas that aren't on this list, drop them in the comments — I'll add them to the article and potentially to the validator too.

How I Built an AI That Translates Code Between 27 Languages (Solo, No Budget)

jason rauch — Tue, 28 Apr 2026 23:15:10 +0000

Every developer has hit this wall.

You have working code. It does exactly what you need. But it's in the wrong language. Maybe you're migrating a Python service to Go. Maybe a client needs a JavaScript utility rewritten in TypeScript. Maybe you inherited a PHP codebase and the whole team wants out.

So you copy it into ChatGPT and ask it to translate. And it kind of works — until you look closer and realize the imports are wrong, the error handling is missing, and the output would never survive a code review.

That frustration is what led me to build transpiler.us.

What I Actually Built

Transpiler.us is an AI-powered code translator built specifically for this problem. Not a general-purpose chatbot with a translation prompt bolted on — a tool built from the ground up to produce production-quality output across 27 programming languages.

That means real imports. Real error handling. Idiomatic patterns for the target language, not just syntax-swapped source code.

Beyond translation, the platform includes:

AI Code Reviewer — structured feedback covering bugs, security, performance, and style
GitHub Integration — translate and push directly to any repository via OAuth
JSON/YAML Formatter — validate, format, and convert between formats
Regex Tester — live pattern matching with named group support
CLI Tool — code-translator-ai on npm for terminal and pipeline use

The Stack

I kept it simple because I was building alone:

Frontend: React + Vite + TailwindCSS, deployed on Vercel
Backend: Express + TypeScript, deployed on Railway
AI Model: Llama 3.3 70B via Together AI API
Payments: Stripe (credit packs + $20/month Pro subscription)
Auth: GitHub OAuth for the repo integration

The AI choice was deliberate. I tested several models and Llama 3.3 70B consistently produced the cleanest translations — especially for less common language pairs like Rust to Zig or COBOL to Java.

What Actually Goes Into a Good Translation

The naive approach is: send the code to an LLM, return the result. That produces garbage 30% of the time.

What actually works is being very specific in the prompt about what "good" means in the target language, and structuring the output so it can be parsed reliably. Here's the actual system prompt used in the translator:

function buildSystemPrompt(
  source: Language,
  target: Language,
  preserveComments: boolean,
  addExplanations: boolean
): string {
  return `You are an expert code translator. Translate code from ${source.name} to ${target.name} accurately.

Rules:
1. Translate faithfully — preserve all logic and behavior
2. Use idiomatic ${target.name} patterns
3. Use appropriate ${target.name} standard library equivalents
4. ${preserveComments ? "Preserve all comments" : "Remove comments unless critical"}
5. ${addExplanations ? "Add brief inline comments explaining non-obvious translations" : "Keep output clean"}
6. Output ONLY the translated code — no markdown fences, no explanations before or after
7. If something cannot be directly translated, add a comment explaining why

After the code, on a new line write "NOTES:" followed by any important notes.
After that, write "WARNINGS:" followed by any potential issues.`;
}

And the response parser that extracts the code, notes, and warnings cleanly:

function parseResponse(rawText: string): TranslationResult {
  const notesSplit = rawText.split(/^NOTES:/m);
  const codeSection = notesSplit[0].trim();
  let notes: string[] = [];
  let warnings: string[] = [];

  if (notesSplit.length > 1) {
    const warnSplit = notesSplit[1].split(/^WARNINGS:/m);
    const notesText = warnSplit[0].trim();
    const warningsText = warnSplit[1]?.trim() ?? "";

    if (notesText && notesText.toLowerCase() !== "none") {
      notes = notesText.split("\n")
        .map((l) => l.replace(/^[-*•]\s*/, "").trim())
        .filter(Boolean);
    }
    if (warningsText && warningsText.toLowerCase() !== "none") {
      warnings = warningsText.split("\n")
        .map((l) => l.replace(/^[-*•]\s*/, "").trim())
        .filter(Boolean);
    }
  }

  const cleaned = codeSection
    .replace(/^```
{% endraw %}
[\w]*\n?/m, "")
    .replace(/\n?
{% raw %}
```$/m, "")
    .trim();

  return { translatedCode: cleaned, notes, warnings };
}

The model runs at temperature: 0.1 — low creativity, high consistency. The structured NOTES/WARNINGS format means the UI can surface important information separately from the code itself without any guesswork.

The difference between a naive "translate this" prompt and this approach is enormous. Output goes from "this kind of works" to "I'd actually commit this."

Building the CLI

One of the best decisions I made was publishing a CLI alongside the web app.

npm install -g code-translator-ai

translate file app.py --from python --to go

Developers spend most of their time in the terminal. A CLI means the tool fits into their existing workflow instead of requiring a context switch to a browser. It also drives organic discovery through npm and developer communities.

The CLI supports batch translation of entire directories, code review, JSON/YAML formatting, and regex testing — the full feature set, accessible from the terminal or piped into a build script.

I licensed it MIT with Commons Clause, which means free to use and modify but not to resell as a commercial service. That keeps it open for developers while protecting the commercial side of the platform.

The GitHub Integration

This was the feature that took the most work but made the biggest difference in how the product felt.

Without GitHub integration, the workflow is: translate on the web → copy the output → switch to your editor → paste → commit. That's four steps where one would do.

With it: translate → select your repo and branch → push. Done.

Getting the OAuth flow right, handling different repo structures, and making the push feel instant took real effort. But developers who try it don't want to go back to copying and pasting.

Revenue Model

Three tiers, all live:

Free — 10 translations to try it, no card required
Credit packs — one-time purchases for casual users (Starter, Builder, Power)
Pro — $20/month for unlimited access to everything

The free tier exists to get people in the door. The credit packs serve developers who need translation occasionally. Pro is for teams and power users who are using it regularly.

What I'd Do Differently

Start with one language pair. I built support for 27 languages on launch. In hindsight, Python → TypeScript alone would have been enough to validate the idea, and I could have added languages based on what users actually asked for.

Ship the CLI earlier. The npm package drives more genuine interest than anything else I've done for distribution. Developers trust tools that live in their terminal.

Don't underestimate the prompt engineering. The quality difference between a naive prompt and a carefully engineered one is significant. I spent more time on prompts than on any other single part of the codebase.

What's Next

The individual developer use case is the wedge. The real opportunity is enterprise code modernization — companies running legacy COBOL, PHP, or Python 2 codebases that need to migrate at scale.

On the roadmap: VS Code extension, team plans, CI/CD integration, and a validation engine that compile-checks translated output.

Try It

If you've ever spent an afternoon manually porting code from one language to another, transpiler.us is built for you.

Web app: transpiler.us
CLI: npm install -g code-translator-ai
GitHub: Jeah84/transpiler-app

Free tier includes 10 translations — no card required. Break it, tell me what's wrong, and I'll fix it.

Building in public. Happy to answer anything in the comments.

How I Built an AI That Translates Code Between 27 Languages (Solo, No Budget)

jason rauch — Fri, 24 Apr 2026 22:16:49 +0000

Every developer has hit this wall.

That frustration is what led me to build transpiler.us.

What I Actually Built

That means real imports. Real error handling. Idiomatic patterns for the target language, not just syntax-swapped source code.

Beyond translation, the platform includes:

AI Code Reviewer — structured feedback covering bugs, security, performance, and style
GitHub Integration — translate and push directly to any repository via OAuth
JSON/YAML Formatter — validate, format, and convert between formats
Regex Tester — live pattern matching with named group support
CLI Tool — code-translator-ai on npm for terminal and pipeline use

The Stack

I kept it simple because I was building alone:

Frontend: React + Vite + TailwindCSS, deployed on Vercel
Backend: Express + TypeScript, deployed on Railway
AI Model: Llama 3.3 70B via Together AI API
Payments: Stripe (credit packs + $20/month Pro subscription)
Auth: GitHub OAuth for the repo integration

What Actually Goes Into a Good Translation

The naive approach is: send the code to an LLM, return the result. That produces garbage 30% of the time.

function buildSystemPrompt(
  source: Language,
  target: Language,
  preserveComments: boolean,
  addExplanations: boolean
): string {
  return `You are an expert code translator. Translate code from ${source.name} to ${target.name} accurately.

Rules:
1. Translate faithfully — preserve all logic and behavior
2. Use idiomatic ${target.name} patterns
3. Use appropriate ${target.name} standard library equivalents
4. ${preserveComments ? "Preserve all comments" : "Remove comments unless critical"}
5. ${addExplanations ? "Add brief inline comments explaining non-obvious translations" : "Keep output clean"}
6. Output ONLY the translated code — no markdown fences, no explanations before or after
7. If something cannot be directly translated, add a comment explaining why

After the code, on a new line write "NOTES:" followed by any important notes.
After that, write "WARNINGS:" followed by any potential issues.`;
}

And the response parser that extracts the code, notes, and warnings cleanly:

function parseResponse(rawText: string): TranslationResult {
  const notesSplit = rawText.split(/^NOTES:/m);
  const codeSection = notesSplit[0].trim();
  let notes: string[] = [];
  let warnings: string[] = [];

  if (notesSplit.length > 1) {
    const warnSplit = notesSplit[1].split(/^WARNINGS:/m);
    const notesText = warnSplit[0].trim();
    const warningsText = warnSplit[1]?.trim() ?? "";

    if (notesText && notesText.toLowerCase() !== "none") {
      notes = notesText.split("\n")
        .map((l) => l.replace(/^[-*•]\s*/, "").trim())
        .filter(Boolean);
    }
    if (warningsText && warningsText.toLowerCase() !== "none") {
      warnings = warningsText.split("\n")
        .map((l) => l.replace(/^[-*•]\s*/, "").trim())
        .filter(Boolean);
    }
  }

  const cleaned = codeSection
    .replace(/^```
{% endraw %}
[\w]*\n?/m, "")
    .replace(/\n?
{% raw %}
```$/m, "")
    .trim();

  return { translatedCode: cleaned, notes, warnings };
}

The difference between a naive "translate this" prompt and this approach is enormous. Output goes from "this kind of works" to "I'd actually commit this."

Building the CLI

One of the best decisions I made was publishing a CLI alongside the web app.

npm install -g code-translator-ai

translate file app.py --from python --to go

The CLI supports batch translation of entire directories, code review, JSON/YAML formatting, and regex testing — the full feature set, accessible from the terminal or piped into a build script.

The GitHub Integration

This was the feature that took the most work but made the biggest difference in how the product felt.

Without GitHub integration, the workflow is: translate on the web → copy the output → switch to your editor → paste → commit. That's four steps where one would do.

With it: translate → select your repo and branch → push. Done.

Getting the OAuth flow right, handling different repo structures, and making the push feel instant took real effort. But developers who try it don't want to go back to copying and pasting.

Revenue Model

Three tiers, all live:

Free — 10 translations to try it, no card required
Credit packs — one-time purchases for casual users (Starter, Builder, Power)
Pro — $20/month for unlimited access to everything

The free tier exists to get people in the door. The credit packs serve developers who need translation occasionally. Pro is for teams and power users who are using it regularly.

What I'd Do Differently

Ship the CLI earlier. The npm package drives more genuine interest than anything else I've done for distribution. Developers trust tools that live in their terminal.

What's Next

The individual developer use case is the wedge. The real opportunity is enterprise code modernization — companies running legacy COBOL, PHP, or Python 2 codebases that need to migrate at scale.

On the roadmap: VS Code extension, team plans, CI/CD integration, and a validation engine that compile-checks translated output.

Try It

If you've ever spent an afternoon manually porting code from one language to another, transpiler.us is built for you.

Web app: transpiler.us
CLI: npm install -g code-translator-ai
GitHub: Jeah84/transpiler-app

Free tier includes 10 translations — no card required. Break it, tell me what's wrong, and I'll fix it.

Building in public. Happy to answer anything in the comments.

I Built an AI Customer Service Platform You Can Deploy in One Click

jason rauch — Fri, 24 Apr 2026 01:18:04 +0000

I Built an AI Customer Service Platform You Can Deploy in One Click 🤖

After spending weeks building customer service bots for different projects, I kept rebuilding the same infrastructure: database setup, Redis caching, AI integration, sentiment analysis, escalation logic...

So I packaged it all into a one-click deployable template.

What It Is

An open-source, production-ready AI customer service platform that handles:

💬 Multi-channel support - Chat, email, and SMS (via Twilio)
🧠 Claude AI integration - Intelligent, context-aware responses
📊 Sentiment analysis - Detects frustrated customers automatically
🚨 Smart escalation - Knows when to hand off to humans
💾 Full conversation history - PostgreSQL database with analytics
⚡ Redis caching - Fast response times at scale
🔌 Real-time WebSockets - Live updates via Socket.io

Why I Built This

Most AI customer service solutions are either:

Enterprise-only (expensive, complex)
Code-heavy (requires weeks of setup)
Closed-source (can't customize)

I wanted something that just works - deploy it, add your API key, and you're handling customer support with AI in minutes.

The Tech Stack

// Core dependencies
- Claude AI (Anthropic) - The brain
- PostgreSQL - Conversation storage
- Redis - Session caching
- Socket.io - Real-time connections
- Express.js - API server
- Node.js - Runtime

Key Features I'm Proud Of

Intelligent Escalation

The bot doesn't just blindly respond. It analyzes:

Customer sentiment (positive/negative/neutral)
Message intent (question/complaint/request)
Conversation complexity

When it detects frustration or confusion, it automatically suggests human escalation.

Multi-Channel Support

Same conversation, different channels:

// Customer starts on chat
POST /api/conversations

// Switches to email
POST /api/conversations/:id/messages

// Bot maintains context across channels

Built-in Knowledge Base

Feed it your docs, FAQs, product info - it'll reference them in responses:

const kbArticles = await aiService.searchKnowledgeBase(query);
const response = await aiService.generateResponse(
  conversation,
  messages,
  kbArticles
);

One-Click Deploy

The entire thing deploys to Railway in literally 60 seconds:

Click the button
Add your Anthropic API key
Done. PostgreSQL and Redis auto-configure.

Live Demo

Check it out running live: ai-customer-service-agent-production.up.railway.app

The /health endpoint shows all services connected:

{
  "status": "healthy",
  "timestamp": "2026-04-23T00:34:08.719Z",
  "ai": true
}

API Endpoints

Once deployed, you get:

GET  /health                          # Health check
POST /api/customers                   # Create/get customer
POST /api/conversations               # Start conversation
POST /api/conversations/:id/messages  # Send message
GET  /api/conversations               # List conversations
POST /api/conversations/:id/escalate  # Escalate to human
GET  /api/dashboard                   # Analytics

How AI Responses Work

Here's the flow when a customer sends a message:

Search knowledge base for relevant articles
Analyze sentiment of customer message
Extract intent (question/issue/request)
Generate response using Claude with context
Check escalation - does this need a human?
Save everything to PostgreSQL
Broadcast via WebSocket for real-time updates

const aiResponse = await aiService.generateResponse(
  conversation,
  messageHistory,
  knowledgeBaseArticles
);

if (aiResponse.needsEscalation) {
  await escalateToHuman(conversationId);
}

What's Next

I'm working on:

[ ] Voice support (Twilio Voice API)
[ ] Multi-language detection
[ ] Custom AI training on conversation history
[ ] Slack integration
[ ] API rate limiting per customer

Try It Yourself

GitHub: github.com/Jeah84/ai-customer-service-agent

Deploy: railway.com/deploy/ddWbPN

Stack: Node.js, Claude AI, PostgreSQL, Redis, Socket.io

Built this because I needed it for my own projects. Figured others might too.

What features would you add? Drop a comment! 👇

Also submitted this as a Railway Template - hoping to help more developers ship AI-powered support faster.

How I turned a code translator into a full dev toolkit — GitHub push, code review, and more

jason rauch — Sun, 19 Apr 2026 12:11:07 +0000

A while back I built transpiler.us — an AI tool for translating code between 27 programming languages. The core use case was simple: you have working code in Python, you need it in Go.

Since then I've kept building. Here's what's been added and why.

GitHub Integration

The most-requested feature. You connect your GitHub account via OAuth and after translating, you can push the output directly to any repo — pick the branch, set the file path, commit message, and push. No copy-paste, no local git required.

This was the most technically interesting piece. Managing OAuth token refresh, handling repos with existing files vs new files, and making the UX feel simple on top of what's actually a multi-step API flow was a good challenge.

AI Code Reviewer

Paste any code and get back a structured review: bugs, security issues, performance improvements, and general suggestions. Llama 3.3 70B handles this surprisingly well.

JSON/YAML Formatter

Validate, format, and convert between JSON and YAML. I use this one constantly myself.

Regex Tester

Write regex patterns and see live match highlighting as you type.

Editor Customization

Choose your theme (VS Code Dark, GitHub Dark, Monokai, Dracula and more), font size, line numbers, and word wrap.

The Stack

Frontend: React + Vite + TailwindCSS on Vercel
Backend: Express + TypeScript on Railway
AI: Llama 3.3 70B via Together.ai
Auth: JWT + email verification
Payments: Stripe

CLI Tool

Also published as code-translator-ai on npm if you want terminal access:

npm install -g code-translator-ai
translate file script.py --from python --to javascript
translate review myfile.ts

Try It

Free tier included — no credit card needed.

https://transpiler.us

Would love feedback — what would you build next?