Minimal Customer Support Architecture for Solo Rork Devs — Running Inquiries for Multiple Apps Alone

Step 1: Host the FAQ on the Web, Render It in WebView

Don't ship the FAQ inside the bundle. Host it on the web and load it in a WebView so you can update content without an app release.

// src/screens/SupportScreen.tsx
import { WebView } from "react-native-webview";
import { Platform } from "react-native";
 
const FAQ_URL = "https://your-domain.example/app-faq?app=wallpaper";
 
export function SupportScreen() {
  const url = `${FAQ_URL}&os=${Platform.OS}&lang=${getCurrentLocale()}`;
  return (
    <WebView
      source={{ uri: url }}
      contentInsetAdjustmentBehavior="automatic"
      decelerationRate="normal"
    />
  );
}

Pass app, os, and lang as query parameters and let the server render the right slice of FAQ entries. Showing iOS-specific issues to Android users is friction; cutting it lifts self-solve rates.

I also have a personal rule: every time a single question shows up three or more times in inbound mail, I write a new FAQ entry that same day. I've kept that rule since 2022 and the compounding payoff is real. Most FAQ additions begin reducing inbound volume roughly four to six weeks after publication.

Step 2: Auto-Attach Diagnostics in the Form

For users who didn't find their answer in the FAQ, this is the layer that does the heavy lifting. If you just call mailto: here, you'll receive "doesn't work" messages that take twenty minutes each to triage. Build the form yourself and collect device context automatically.

// src/screens/InquiryFormScreen.tsx
import * as Application from "expo-application";
import * as Device from "expo-device";
import * as Localization from "expo-localization";
import { Platform } from "react-native";
import { sendInquiry } from "../api/inquiry";
import { getRecentLogs } from "../debug/logBuffer";
import { getPurchaseHistory } from "../iap/purchaseStore";
 
type InquiryPayload = {
  body: string;
  category: "bug" | "billing" | "feature" | "other";
  diagnostic: {
    appVersion: string | null;
    buildNumber: string | null;
    osName: string | null;
    osVersion: string | null;
    deviceModel: string | null;
    locale: string;
    timezone: string;
    recentLogs: string[];     // last 100 log lines
    purchases: string[];      // restorable purchase IDs, no PII
    crashLastSeen: string | null;
  };
};
 
export async function buildInquiryPayload(body: string, category: InquiryPayload["category"]): Promise<InquiryPayload> {
  return {
    body,
    category,
    diagnostic: {
      appVersion: Application.nativeApplicationVersion,
      buildNumber: Application.nativeBuildVersion,
      osName: Platform.OS,
      osVersion: Device.osVersion,
      deviceModel: Device.modelName,
      locale: Localization.locale,
      timezone: Localization.timezone,
      recentLogs: await getRecentLogs(100),
      purchases: await getPurchaseHistory(),
      crashLastSeen: await readLastCrashTimestamp(),
    },
  };
}

The principle is "don't make the user type what the app already knows." Asking for OS version manually loses over half the users mid-form. Collect it silently and only show a collapsed "what will be sent" summary on the confirmation step.

A Ring Buffer for In-App Logs

getRecentLogs(100) reads from an in-memory ring buffer. I do not log directly with console.log in production — every log call goes through a wrapper that stores entries for later inspection.

// src/debug/logBuffer.ts
const BUFFER_SIZE = 300;
const buffer: string[] = [];
 
export function logEvent(tag: string, message: string, level: "info" | "warn" | "error" = "info") {
  const ts = new Date().toISOString();
  const line = `[${ts}] ${level.toUpperCase()} ${tag}: ${message}`;
  buffer.push(line);
  if (buffer.length > BUFFER_SIZE) buffer.shift();
  if (__DEV__) console.log(line);
}
 
export async function getRecentLogs(count = 100): Promise<string[]> {
  return buffer.slice(-count);
}

This is plenty to get the moments leading up to a crash. It is complementary to Crashlytics or Sentry stack traces, not a replacement.

Redacting Personal Data Before Sending

Strip PII before the payload leaves the device. I learned this the hard way in 2020 when a log line included the user's email address that the user had also pasted into the message body — the same value ended up in our inbox twice and our worker logs once. Since then, every outbound payload passes through a redactor.

// src/debug/redact.ts
const EMAIL = /[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/g;
const PHONE = /\+?\d{1,3}[- ]?\d{2,4}[- ]?\d{2,4}[- ]?\d{2,4}/g;
const TOKEN = /(eyJ[a-zA-Z0-9_-]+\.){2}[a-zA-Z0-9_-]+/g; // JWT-shaped
const IPADDR = /\b\d{1,3}(?:\.\d{1,3}){3}\b/g;
 
export function redact(input: string): string {
  return input
    .replace(EMAIL, "[redacted-email]")
    .replace(PHONE, "[redacted-phone]")
    .replace(TOKEN, "[redacted-token]")
    .replace(IPADDR, "[redacted-ip]");
}

Run the same redactor on the server as a defense in depth — if anything leaks through the client, you still strip it before it lands in your inbox.

Step 3: A Minimal Server — Just Forward to Email

The server doesn't need a database or a queue. Mine is a single Cloudflare Worker that converts each POST into an email.

// worker/inquiry.ts (Cloudflare Workers)
export default {
  async fetch(req: Request, env: Env) {
    if (req.method !== "POST") return new Response("Method not allowed", { status: 405 });
    const payload = await req.json<{ body: string; category: string; diagnostic: Record<string, unknown> }>();
 
    const subject = `[${env.APP_NAME}] ${payload.category}: ${truncate(payload.body, 40)}`;
    const text = renderEmailBody(payload);
 
    // Resend / Mailgun / SendGrid all work. This example uses Resend.
    const result = await fetch("https://api.resend.com/emails", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${env.RESEND_API_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        from: `${env.APP_NAME} <no-reply@your-domain.example>`,
        to: env.SUPPORT_INBOX, // your own Gmail address
        subject,
        text,
        reply_to: payload.diagnostic.contactEmail ?? undefined,
      }),
    });
 
    if (!result.ok) return new Response("Send failed", { status: 502 });
    return new Response("ok");
  },
};
 
function truncate(s: string, n: number) {
  return s.length > n ? s.slice(0, n) + "…" : s;
}

The Cloudflare Workers free tier covers 100k requests per month, so for an indie support endpoint you'll run this free for years. I use Resend on the email side because their first 3,000 messages per month are free.

Step 4: Let Gmail Sort It For You

Once mail lands in Gmail, the labels and filters do the prioritization. I manage filters through Apps Script instead of the GUI so they are reproducible and version-controllable.

// Google Apps Script
function ensureFilters() {
  const rules = [
    { from: "no-reply@your-domain.example", subject: "[wallpaper-app]", label: "App/Wallpaper" },
    { from: "no-reply@your-domain.example", subject: "[healing-app]", label: "App/Healing" },
    { from: "no-reply@your-domain.example", subject: "billing:", label: "Priority/Billing" },
    { from: "no-reply@your-domain.example", subject: "bug:", label: "Priority/Bug" },
  ];
  // Use Gmail API to create or update filters — diff against existing first.
}

The two labels I open first every day are Priority/Billing and Priority/Bug. Billing escalations need to land before the user contacts Apple or Google directly. Bug reports often arrive ahead of the public review wave, giving you a few hours of head start. Everything else I batch-process once a day.

Step 5: Reply Templates and Localization

I keep replies in Gmail templates (formerly Canned Responses). About ten templates cover the bulk of inquiries. After building them, my average reply time dropped from around four minutes to under one.

Example template categories (anonymized):

• Cannot install — "Thank you for reaching out. Based on the diagnostic data you sent, this is usually caused by storage pressure or an OS-level permission. Please try the following…"
• Too many ads — "Thanks for the honest feedback. Ads keep the app free for everyone, but the frequency is something I review continuously. The placement you mentioned is under active testing and will change in version X.Y."
• Specific feature not working — "Thanks for the report. The diagnostic info points to a known condition triggered when [X]. A fix is scheduled for version X.Y.Z."

I run the same templates in English and Japanese. I draft the translations with Gemini and Claude assisting, then tune phrasing until it reads like a native message rather than a localized one. Always add one or two custom sentences at the top before sending — pure templates feel hollow, but a short "I read through your message and noticed…" personalizes the whole reply.

Step 6: Decide What You Won't Answer

Treating every inquiry equally is how solo support collapses. I sort inbound into three lanes:

• Same-day — billing, crashes, data loss, anything legal
• Within three days — functional bugs, how-to questions
• Within a week or no reply — feature requests, subjective complaints, spam

The key word is "no reply." Some categories don't get a personal response, and that's by design. Otherwise support time grows without bound and eats production time. Feature requests I read carefully and feed into the roadmap, but I do not reply to each one individually.

Step 7: Loop Back into the FAQ Monthly

At the end of every month I sweep all the answered inquiries. Anything I answered three or more times becomes a new FAQ entry. I keep a Google Sheet with the monthly tally so I can watch the curve.

After running this loop for about two years, monthly inbound volume settled at roughly 30% of its peak. The resolution rate climbed in parallel, and the share of 4.5★+ reviews stabilized.

Step 8: Three Habits That Keep Solo Operation Stable

A few habits that, in hindsight, did more for sustainability than any tool I added:

1. Reserve a fixed window for replies. Mine is 6:30–7:00 every morning. Outside that window I do not open the support inbox — it pulls me out of creative work for the rest of the day.
2. Read the messages you decided not to answer. Even the lane I never reply to, I skim every message. Shifts in what users complain about show up here before they show up in store reviews.
3. Detect crashes and billing errors through other channels. Don't depend on inbound mail. Crashlytics crash-free-rate alerts and Stripe / RevenueCat error-rate alerts wired into Slack catch the real emergencies hours ahead of the first complaint.

Closing Note

For solo developers, "answering politely" matters less than "designing so the inquiry never happens." The flow — in-app FAQ, auto-attached form, automatic sorting, templated reply — is what has let me keep a dozen apps in production single-handedly. If I could ship today's setup back to my 2014 self, I'd probably have added three years to my career.

Thanks for reading. I hope it helps anyone else running multiple apps alone.