The career change began with a narrow repeated job
An Indie Hackers editorial case study describes Rishi Mohan as a 32-year-old founder originally from India and based in Berlin. He moved from side projects to full-time entrepreneurship and launched Orshot in February 2025. Instead of promising a design system for every need, the product automates a specific workflow: turning existing templates into marketing visuals, PDFs, and videos through an API or no-code integrations.
That scope matters to freelancers and small teams. A repeated deliverable already has a buyer, an expected format, and a visible cost in time. The first business question is therefore not whether AI can generate attractive media. It is whether one customer group will pay for the same bounded result often enough to support the model, review, and support costs.
The $6.2K MRR result has important prerequisites
The July 2026 Indie Hackers article says Orshot operated without full-time staff, served more than 5,000 users, produced over 760,000 renders, and reached $6,200 in monthly recurring revenue. MRR is recurring revenue, not profit, and the article is an editorial case study rather than audited financial reporting. Those distinctions should remain visible whenever the number is reused.
Mohan also did not start without distribution. The same source says years of building in public had established an audience, and his earlier screenshot product Pika had already scaled beyond $100,000. That existing reputation, product experience, and audience are material advantages. Orshot and Mohan have no demonstrated usage or partnership relationship with APIToken, and another freelancer should not treat the reported result as an income promise.
Start with one deliverable and five real users
Choose the most repetitive output in work you already understand: a campaign image set, a property brochure, a product launch pack, or another format with clear inputs and acceptance rules. Ask five people who already buy or produce that output how often it occurs, what makes it unacceptable, how long correction takes, and what they would pay for a reliable result. Do this before building a broad platform.
Reduce the experiment to one template and one delivery promise. Write the acceptance checklist before any model request: required dimensions, fields, brand constraints, source accuracy, file format, and maximum correction time. A narrow contract makes failure visible and gives a customer something concrete to accept or reject. More features do not compensate for a result that nobody has agreed to buy.
Track the model cost, failures, and delivery margin
Create an isolated project key or label for the experiment. Check the current public channel status, then run one minimal real request with non-sensitive sample material. Record the effective model, response status, visible usage, retry count, rejected outputs, and human correction time. If the workflow uses several models, keep their tasks and costs separate so one inexpensive step does not hide an expensive failure loop.
Set a small request and time budget before testing. Compare the total delivery cost with the price a real user will pay, not with a model's headline price alone. Stop when repeated failures, manual editing, or support time erase the margin. A model appearing in a marketplace is only a candidate; the intended key, endpoint, template, and acceptance rule still need a minimal real call.
Sell one repeated result before expanding
https://APIToken.Company can serve as one example of a controlled multi-model testing entry point. Within the models currently and lawfully offered on the site, review the marketplace and public status, create an isolated key, set a small budget, and compare candidates on the same template. Keep usage and failure evidence alongside the price and correction time. Current models, prices, groups, and availability follow the live site pages.
This article is not advice to resign, an income guarantee, or a claim that Orshot used APIToken. The minimum action is to name one repeated deliverable you already understand, show its acceptance rule to five real users, and ask whether one of them will pay for a bounded result. Only after that evidence should you add more templates, models, integrations, or fixed costs.
Source and evidence boundary
The case facts and figures come from the July 17, 2026 Indie Hackers editorial article, From Side Hustle to $6.2K MRR: How Rishi Mohan Scaled Orshot Solo. It identifies Mohan's age and location, Orshot's launch timing and product scope, the reported user and render counts, the $6.2K MRR figure, and the existing Pika audience and building-in-public history.
This is treated as a grade B editorial source, not audited financial evidence. Reported revenue is not profit, prerequisites are not reproducible on demand, and no relationship with APIToken is implied.