Interview with Sanskar Tiwari, Solo Founder Building a Portfolio of Tiny Apps to a Reported $1M

Building a portfolio of tiny apps worked for Sanskar Tiwari through repeated launches, narrow features, and distribution inside existing platforms. In his Starter Story interview with host Gus, the Bangalore-based founder behind MagicSlides, SheetAI, and other tools reported more than $1 million in cumulative revenue over six years, with eight revenue-generating products from more than 30 launches.

The useful part is not the launch count. It is how Sanskar reduced the size of each bet, found paying customers, and stopped treating one unproven idea as a permanent assignment.

Table of Contents

• TL;DR
• Founder and business snapshot
• How did Sanskar get started building small software products?
• How does building a portfolio of tiny apps work?
• How did the apps get their first customers?
• How does Sanskar find app ideas people might pay for?
• What tools does Sanskar use to build the apps?
• What do the reported revenue numbers actually mean?
• Roger’s Take: What is actually replicable?

TL;DR

• The reported result: More than $1 million in cumulative revenue, not annual revenue or profit.
• The operating model: A solo founder, roughly 1,000 monthly paying customers, and eight products that generated revenue.
• The product strategy: Solve a narrow problem, often through Chrome extensions or Google Workspace add-ons.
• The distribution: Facebook groups, AppSumo, product-specific YouTube channels, and Instagram experiments.
• The practical lesson: Test whether someone will pay before spending months adding features.

Founder and business snapshot

• Founder: Sanskar Tiwari, based in Bangalore, India.
• Business: A portfolio including MagicSlides, SheetAI, Blurweb, MagicForm, AskVideo, TalkingPDF, and SendSimple.
• Reported cumulative revenue: More than $1 million over six years, including more than $85,000 through AppSumo.
• Reported early performance: No revenue during the first two years.
• Team: Sanskar said he operated alone, without employees.
• Key tools: Next.js, Supabase, Cloudflare, Resend, Google Apps Script, and Claude.

How did Sanskar get started building small software products?

What happened before the successful apps?

Sanskar’s path included call-center work, an eight-month sales job, and a long stretch without meaningful business results. His account is considerably less tidy than “built an app, made a million.”

He decided against college after becoming interested in independent software businesses. The following two years did not produce the progress he expected, so he took conventional jobs while continuing to learn and build.

Sharing interface work became an important turning point. Using the username IndianAppGuy, he posted sign-in and sign-up screens and received encouraging feedback. Building something shareable gave his learning a concrete output.

He also drew inspiration from Pieter Levels. Eventually, he launched two products with lifetime deals and reported generating revenue within two days of those launches. Those early sales helped him leave employment and continue building independently.

Why did he move from one product to more than 30?

Sanskar said spending his first year on one product taught him that persistence can become attachment. He was trying to sell something he believed should work without sufficient evidence that customers wanted it.

His response was to run more experiments. Across more than 30 products, eight generated revenue. That distinction matters: the portfolio was not 30 successful businesses, and the $1 million was not evenly distributed across every launch.

Experience also changed his judgment. By learning how to build and ship, he became better at estimating development effort and identifying ideas that were realistic for one person.

How does building a portfolio of tiny apps work?

What makes these products “tiny”?

The products generally have a narrow central job, not an ambition to replace an entire software category. Sanskar emphasizes making the purpose easy for both the builder and the customer to understand.

Several products illustrate that approach:

• MagicSlides: Converts source material, including documents, PDFs, and YouTube URLs, into presentations. It includes an editor and supports editable PPTX exports.
• AskVideo: Lets users ask questions about content supplied through a YouTube URL.
• Blurweb: A Chrome extension for hiding sensitive information.
• SheetAI: Brings AI functionality into Google Sheets.
• MagicForm: Extends his product exploration into Google Forms.
• TalkingPDF: Applies a conversational interface to PDF content.
• SendSimple: A Google Sheets add-on for sending emails through a Gmail account.

“Tiny” does not mean featureless. MagicSlides has editing and export capabilities. The constraint is a clear primary outcome rather than a sprawling list of unrelated promises.

Why build inside Google Workspace or Chrome?

Sanskar described Chrome extensions and Google Workspace add-ons as a common foundation across his products. He preferred extending an existing platform to building every part of the experience from scratch.

SendSimple gave him about two years of experience building a Google Sheets add-on before MagicSlides. That familiarity helped him understand the development work involved in related products.

His ideas also connected. SheetAI reportedly reached roughly $2,000 in monthly recurring revenue. An investor’s request for a pitch deck then prompted the idea behind MagicSlides. After exploring Sheets and Slides, he considered Forms, which led to MagicForm.

The repeatable advantage was not simply having more ideas. It was carrying useful platform knowledge from one project into the next.

How did the apps get their first customers?

Where did Sanskar make his first sale?

Sanskar said his first sale came from Facebook. He joined groups containing the target audience for the product and introduced the relevant tool there.

He later launched on AppSumo, which became another source of sales. He reported more than $85,000 in revenue through the platform across his journey.

These channels served different purposes. Facebook groups put him near a specific audience. AppSumo provided another place to launch an offer. Neither required waiting for a large personal following before asking for a purchase.

Why create separate YouTube channels for individual products?

Sanskar created product-specific channels because the products served different audiences. Mixing every application into one feed risked making the content less relevant to each customer group.

He highlighted channels for MagicSlides, MagicForm, and SheetAI. His reasoning was straightforward: content explaining one product should attract people interested in that product’s problem.

He also valued the useful life of searchable content. Older tutorials could continue bringing customers years after publication, rather than depending entirely on a fresh post every day.

He cited a MagicForm example at roughly 145,000 views and SheetAI examples around 17,000, 10,000, and 7,000 views. He attributed SheetAI’s growth to more than $2,000 in monthly recurring revenue to YouTube content. That attribution is his account, not a channel-by-channel measurement of incremental revenue.

How did he approach Instagram without being an expert?

Sanskar treated Instagram as another testing ground, not a production studio. He described recording short product demonstrations on his phone and adding titles and captions with Instagram’s Edits app.

He reported publishing 10 short clips within an hour. The point was to test different product explanations without first solving lighting, equipment, and elaborate editing.

He explicitly did not position himself as an Instagram expert. The useful lesson is the experiment design: publish several clear demonstrations, observe the response, and learn which explanations connect.

How does Sanskar find app ideas people might pay for?

Which signals does he use to find ideas?

Sanskar recommended looking at TrustMRR for company revenue information, following relevant builders on Twitter, and noticing problems encountered while doing real work.

Each source answers a different question:

• Revenue information: Is there evidence that people spend money in this category?
• Builder discussions: What products, workflows, and frustrations are people discussing?
• Personal problems: What task is already inconvenient enough to suggest a useful tool?

His caveat about personal problems is important. A frustrating task is not automatically a business opportunity. The intended customers must value the solution enough to pay.

He specifically warned against assuming that problems experienced by people who rarely buy software will produce a viable paid product.

How would he validate an app before building it?

Sanskar’s recommendation is to publish a simple preorder page with a purchase option before developing the full product. The page should explain the offer and state when the minimum viable product will become available.

His proposed sequence is deliberately small:

1. Describe one outcome. Explain what the application will help a customer accomplish.
2. Create a basic landing page. He suggested using an AI-assisted coding tool rather than overcomplicating the page.
3. Label the offer as a preorder. Make the product’s unfinished status clear.
4. State a delivery window. His examples were 10 to 30 days, based on the work required.
5. Use a purchase as a demand signal. His proposed build timer starts after the first sale.

Roger’s take: I would steal the small test, not the casual estimate. A preorder creates a delivery obligation. The date should reflect what the builder can actually ship, not what makes the landing page look confident.

A buy button without a clear offer or a relevant audience also proves little. Sanskar’s own first sale involved finding the right people, not merely publishing a page and waiting.

What tools does Sanskar use to build the apps?

What is his development stack?

Sanskar described a web application stack built around Next.js, Supabase, and Cloudflare, with Resend and Google Apps Script for email-related work. He also identified Claude as a major part of his coding workflow.

• Next.js: The application framework he uses for web development.
• Supabase and Cloudflare: Backend and supporting infrastructure.
• Resend: An email-sending option.
• Google Apps Script: Another tool he uses for email-related workflows.
• Claude: AI assistance for development.

This is a description of his stack, not evidence that every product uses an identical architecture. He did not provide a complete operating-cost breakdown or product-by-product technical specification.

The more useful constraint is familiarity. Reusing tools and platform knowledge reduces the amount of unfamiliar work involved in each experiment.

What do the reported revenue numbers actually mean?

Did Sanskar make $1 million a year?

No. Sanskar reported crossing $1 million in total revenue over six years. He also said the first two years produced no revenue and that progress built gradually afterward.

He reported roughly 1,000 paying customers on a monthly basis and said he had no employees. Those figures describe scale and staffing, but they do not establish profit, current monthly recurring revenue, or operating expenses.

Several boundaries keep the case useful:

• Revenue is not profit. Infrastructure, payment, and other business costs were not fully itemized.
• Cumulative revenue is not an annual run rate. Six years of sales cannot be treated as one year’s earnings.
• Eight revenue-generating products do not mean eight equal contributors. Sanskar identified MagicSlides as his biggest app.
• More launches do not guarantee more winners. Most of his launches did not become revenue-generating products.

Roger’s Take: What is actually replicable?

What should a solo builder copy, and where is the hype?

I would copy the narrow scope, reusable platform knowledge, and early payment test. I would not copy “launch 30 apps” as a target. A launch count is an activity metric wearing a business costume.

Sanskar’s strongest pattern is a connected loop: notice a problem, make a small offer, reach a relevant audience, and carry the learning into the next attempt. His content experiments follow the same logic as his product experiments.

The limits matter too. This account does not establish which product produced which share of revenue, how much ongoing support each requires, or whether a new builder would get comparable distribution. Years of practice are part of the result.

The mistake to avoid is replacing one oversized project with 30 unfinished ones. A portfolio helps only when experiments produce usable evidence.

What can a builder test this week?

I would start with one workflow and one buyer, not a portfolio plan. The immediate task is to make the offer specific enough that a relevant person can accept or reject it.

• Choose a platform: Start somewhere the builder already understands.
• Name the buyer: Identify who experiences the problem and might pay.
• Write the outcome: Explain one useful result without a feature catalogue.
• Find the audience: Locate a relevant community or create a focused demonstration.
• Test the offer: If taking preorders, clearly state the unfinished status and a realistic delivery window.

The next action today: write a one-page offer for one narrow problem. Building a portfolio of tiny apps starts with testing one useful purchase, not announcing eight future businesses.

Source: I made $1M from 30 different apps by Starter Story, hosted by Gus with Sanskar Tiwari.

Meta description: Building a portfolio of tiny apps: Sanskar Tiwari’s reported $1M journey, validation process, marketing channels, and solo development stack.

FAQ

How many apps did Sanskar Tiwari build?

Sanskar said he built more than 30 products, eight of which generated revenue. He identified MagicSlides as his biggest application.

How long did it take Sanskar to reach $1 million?

He reported crossing $1 million in cumulative revenue over six years. He said the first two years generated no revenue.

Can a solo founder run multiple apps?

Sanskar reported running his portfolio alone, with roughly 1,000 monthly paying customers and no employees. His approach emphasizes narrow product scope and familiar platforms.

How did Sanskar market his apps?

His channels included Facebook groups, AppSumo, separate YouTube channels for individual products, and short Instagram demonstrations.

What was his biggest mistake?

Sanskar described spending too long on a single product that was not working. His advice was to test willingness to pay earlier rather than continuing to add features.