CosmicUp.me
Replace seven AI subscriptions with one — 30+ models, 10,000 users, no ops team.

- 10,000
- users served
- 30+
- models, one gateway
- 0 servers
- always-on servers
Context
A consumer AI platform that puts 30+ chat, image and audio models behind a single €16.99/month subscription, on web, iOS and Android. It runs fully serverless, scaled to 10,000 users, and every model provider sits behind one normalised gateway that also handles quota, billing and cost control.
The product
- What it sells
- One subscription replacing ChatGPT Plus, Claude, Gemini, Grok and several image and audio tools at once.
- Who buys it
- Consumers and small teams who want frontier models without paying for five separate subscriptions.
- Pricing
- Free tier, Plus at €16.99/month, or €169.90/year — positioned directly against the ~$240/year cost of ChatGPT Plus alone.
- Proof
- 10,000 users, 5/5 on Product Hunt, 4.1/5 on Trustpilot, plus an affiliate programme as a second acquisition channel.
The problem
People wanted to use several AI models but did not want several subscriptions, several interfaces and several billing relationships. The hard part was not the UI — it was serving unpredictable, bursty inference traffic under a flat monthly price, which means every architectural decision is also a margin decision.
Architecture
The gateway is the whole design. Because every request and every token passes through one normalised layer, quota, caching, routing and observability are all single-point changes rather than five separate integrations.
Technical specification
- Model catalogue
- 30+ chat models, 11 image models and 2 in-house audio agents, grouped into Free, Plus and Thunder tiers.
- Context windows
- Up to 1,000,000 tokens depending on the model; input accepts PDF, DOC, DOCX and 9 further formats, output writes PDF, DOC, CSV and TXT.
- Fair-use metering
- 2,000,000 input characters per month at full speed, then graceful degradation to a slower queue (2–10 min) instead of a hard cutoff — the flat price survives heavy users.
- Provider abstraction
- One normalised request/response shape; each provider's quirks are absorbed in an adapter, so adding a model is a config change, not a release.
- Streaming
- Server-sent streaming end to end, so perceived latency stays low even when a slow model is doing the work.
- Code execution
- Sandboxed Python runtime (AI Code Run) invoked as a tool from the chat surface.
- Platforms
- Web, iOS and Android from a single codebase.
- Infrastructure
- Fully serverless on Firebase and Node.js functions — no always-on servers, idle traffic costs nothing.
How I built it
Defined the product roadmap and built the whole thing on a serverless stack — Vue.js on the front, Node.js functions and Firebase behind it — so that idle traffic cost nothing.
Put every model behind a single normalised gateway: one request shape in, one streamed response shape out, provider differences absorbed in an adapter layer.
Made streaming the default so perceived latency stayed low even when a slow model was doing the work.
Added per-user quota accounting at the gateway, which later became the foundation for the cost work.
Ran the full growth funnel myself — market analysis, UX in Figma, TikTok and Google Ads, and direct customer support — and fed the support inbox straight back into the roadmap.
Shipped the same codebase to web, iOS and Android, so a feature reaches every platform in one release rather than three.
Built the surrounding product surface — folder organisation, prompt improver, document analysis, online search, deep research and a sandboxed Python runtime — on top of the same gateway.
Outcome
- Scaled to 10,000 users on infrastructure with no always-on servers and no dedicated ops team.
- New model providers became a one-adapter change instead of a release — the catalogue tracks the frontier without re-architecture.
- The metering design kept a flat subscription price profitable against usage that varies by orders of magnitude between users.
- Support conversations turned directly into shipped features — the loop stayed short because the same person read the tickets and wrote the code.