The full stack I used to build an AI product-validation engine as a solo founder
I build in public, so here's the honest version: I spent more time deciding what to build than actually building it. Which is ironic, because the product I ended up shipping — ShipFit — exists to fix exactly that. It's a 9-decision engine that takes a vague startup idea and forces it through nine sequential gates (who pays, what hurts, how to win, what's V1, how to charge, will they pay, how to launch) and outputs a ship-ready playbook grounded in real market data instead of AI vibes.
This post isn't the pitch. A few people asked what's actually under the hood, so here's the complete stack — infra, models, analytics, the lot — plus the decisions behind it and the parts I got wrong.
The whole thing, one screen
Frontend: React 19, TypeScript, Vite, TailwindCSS Backend: FastAPI, Python, PostgreSQL, Redis, Celery, asyncpg AI orchestration: Langflow for workflow execution; OpenRouter for LLM routing, with intentional Anthropic routing on the stages that need judgment; Groq and DeepInfra in the mix for speed/cost; Serper.dev and Tavily for search & researchInfra: Railway (separate environments), DNS on Cloudflare (proxied, Full Strict SSL), domain registered at GoDaddy; root shipfit.ai 301-redirects into the app Analytics & tags: Zaraz (consent + tag manager), RudderStack (CDP), GA4, Mixpanel, Hotjar, Sentry Revenue & comms: Stripe (payments + Customer Portal), SendGrid (transactional email)
Most of it is deliberately boring. The creativity went into two places: how the AI is orchestrated, and how models get routed. Everything else is glue I wanted to be reliable and forgettable.
Decision 1: Boring backend, on purpose
My own product tells users: "You don't need microservices. You don't need Kubernetes. You need to ship." It would've been embarrassing to ignore my own advice.
So it's FastAPI on PostgreSQL and Redis, with asyncpg doing the database talking so I'm not blocking the event loop while agents are running. Redis pulls triple duty — cache, Celery broker, and the pub/sub layer behind real-time updates — because one dependency doing three jobs is one thing to babysit instead of three.
The thing I underestimated: the whole product is long-running AI work. A single validation kicks off a market-research pipeline that runs several minutes, plus MVP-strategy generations in parallel. You can't do that inside an HTTP request. So Celery became load-bearing early — background workers, concurrency caps, retries. If I started again I'd wire in the job architecture on day one instead of bolting it on once requests started timing out.
Decision 2: Langflow for orchestration, OpenRouter for routing
This is the pair I get asked about most.
Every AI feature is a pipeline of specialized agents, not one mega-prompt. Market research alone chains four agents — landscape, persona, empathy map, problem definition. I build these visually in Langflow so I can rewire a handoff by dragging a node instead of redeploying a backend.
The part I'm happiest about is model routing. I don't call one provider — I route through OpenRouter, and I route deliberately. The stages that need real judgment (the roast, the strategic decisions) get Anthropic models on purpose. Stages where speed or cost matters more lean on Groq and DeepInfra. Same idea for research: Serper.dev and Tavilyboth feed the retrieval layer rather than betting the product on a single search API.
The lesson here, if you're building anything with LLMs in 2026: don't marry one model. A routing layer means the day a better/cheaper model lands, I change a config, not my architecture. And matching model to task — expensive judgment where it counts, cheap-and-fast everywhere else — is most of how the unit economics stay sane.
Decision 3: The feature that became the moat
The best decision was making the AI's thinking visible. When you run a validation you don't stare at a spinner — you watch each agent reason, step by step, streamed live over Redis pub/sub to the browser.
I built it thinking it was a nice-to-have. It became the thing people screenshot. Watching an AI work through your idea, instead of dumping a report, is what makes the output feel earned. If your product does long AI work, spend the extra week on streaming — it's the experience, not the polish.
Decision 4: The unglamorous infra that just works
Nobody writes threads about DNS, but this is where solo founders lose a weekend, so here's exactly how mine is wired:
Everything runs on Railway with separate environments, so I can break staging without touching production. The domain's registered at GoDaddy, but DNS lives on Cloudflare — proxied, on Full (Strict) SSL — so I get the CDN, the WAF, and clean certs in front of everything. Root shipfit.ai 301-redirects into the app so there's one canonical home and no split between the apex and the product.
None of this is clever. That's the point. Set it up once, on managed platforms, and never think about it again. The hours you save not running your own reverse proxy are hours you spend on the agent pipeline that actually differentiates you.
Decision 5: Instrument before you optimize
I wired the measurement stack in early because you can't fix what you can't see. Zaraz handles consent and tag management at the edge, RudderStack is the CDP that fans events out, and from there it's GA4 and Mixpanel for product analytics, Hotjar for session/behaviour, and Sentry for errors. One event schema, many destinations — so adding a tool later doesn't mean re-instrumenting the app.
For the money and the messaging: Stripe does payments and the Customer Portal (self-serve billing I didn't have to build), and SendGrid handles transactional email. Both are the boring, correct answers for a solo founder who'd rather not own subscription UI or an SMTP server.
What I'd tell past me
Ship the boring stack and spend your creativity on the hard part. Mine was the agent pipelines and model routing — not the database, not the DNS.
Route your models, don't marry one. OpenRouter plus intentional per-stage routing (Anthropic where judgment matters, Groq/DeepInfra where speed does) is the single decision I'd repeat first.
Design for async, and instrument, before you need to. Background jobs the moment work exceeds a few seconds; analytics before you start guessing at what to fix.
The demo is the product. Real-time streaming of the AI thinking did more for conversion than any landing-page copy.
That's the whole stack. Direct feedback welcome — especially from anyone running Langflow or multi-provider routing in production. That's the part I'm still learning.
Building ShipFit — kill bad ideas fast, make good ideas win. Happy to answer stack questions in the comments.
