0 Lines of Hand-Written Code, 3 Hours to Build an AI Product That Can Take Payments

A Counterintuitive Case: Live in 3 Hours, Paid the Next Day

In most people's minds, going from an idea to a product that can collect payments often takes weeks or even months: assembling a team, writing code, endless debugging, and getting the payment flow working. But a case that recently went viral on Bilibili shatters this assumption—the creator built and launched an AI product in 3 hours with zero hand-written code, and received a real payment the very next day.

Even more noteworthy: the 11 people who followed along and worked in real time during the session all produced running products that same day. This shows the entire process isn't reliant on the lucky, one-off performance of some expert, but rather a methodology anyone can replicate.

Behind these numbers lies a deeper shift in the product development paradigm of the AI era: when code can be generated by AI, deployment can be done with one click, and payments can be integrated at low cost, an entrepreneur's true competitive edge has shifted from "engineering ability" to "demand judgment" and "business loop design."

The Product Itself: The Portrait Studio of Time

The product built in this case is called "The Portrait Studio of Time," and its logic is simple and direct: users upload a casual photo, and the AI automatically generates finished images in various styles such as ID photos, business headshots, portraits, and stickers.

The choice of demand is quite deliberate. ID photos and business headshots are inherent necessities—getting them shot and retouched at a photo studio costs both money and time; portraits and stickers, meanwhile, carry the "fun, shareable" social attribute. In other words, this product simultaneously hits both a practical willingness-to-pay point and a social-spreading point, giving it growth momentum along both dimensions.

From a technical implementation standpoint, these AI products are hardly mysterious. Their foundation rests on the explosively developing AI image generation technology of recent years—understanding this technological evolution helps in judging which product opportunities are truly viable.

From GAN to Diffusion Models: A Generational Leap in Image Generation Technology

Early image generation relied on GANs (Generative Adversarial Networks), whose core mechanism pits a "generator" against a "discriminator" in a game to gradually produce realistic images. GANs once achieved stunning results in face generation (such as the StyleGAN series), but engineering problems like unstable training and mode collapse remained persistent bottlenecks. After 2020, diffusion models represented by Stable Diffusion, DALL-E, and Midjourney gradually replaced GANs as the mainstream.

The operating principle of diffusion models can be understood through an intuitive analogy: imagine a clear photo being repeatedly overlaid with grainy noise until it becomes pure noise. What the model learns is the reverse of this "restoration" process—starting from a blob of random noise and "denoising" step by step to reconstruct a complete image. This mathematical framework of forward noise-adding and reverse denoising traces back to Langevin Dynamics in physics, which describes particle diffusion, and was introduced into the field of generative models by researchers in 2020. Combined with the text encoder CLIP (Contrastive Language-Image Pretraining, released by OpenAI in 2021), diffusion models achieved the ability to precisely control generated content using natural language. Stability AI fully open-sourced the Stable Diffusion model weights in 2022, rapidly moving this technology from academic research to commercial adoption and making it the underlying engine of the vast majority of current AI image applications.

It's worth adding that the impact of the diffusion model open-source ecosystem on the commercialization barrier goes far beyond the technology itself. Hugging Face, as the "GitHub" of AI models, currently hosts over 500,000 open-source models and tens of thousands of fine-tuned variants based on Stable Diffusion, forming the world's largest AI model-sharing community. Developers don't need to train from scratch—they only need to select a pre-trained model suited to their scenario from the community and integrate it directly with an API platform, with a marginal cost that's virtually negligible. Diffusion models comprehensively surpass GANs in generation quality, stylistic diversity, and output stability, forming the technical prerequisite that makes vertical scenarios like ID photos and portraits commercially viable.

For ID photo and portrait scenarios, there's also the specialized LoRA fine-tuning technique (Low-Rank Adaptation), which allows developers to layer specific styles onto a base model at extremely low cost. LoRA was originally proposed by Microsoft Research in 2021 for parameter-efficient fine-tuning of large language models, and was subsequently widely adapted by the image generation community. Its core insight is that the parameter update matrix in a pre-trained large model has an "intrinsic rank" that is often far lower than the actual dimensions of the matrix—in other words, the amount of real information needed for fine-tuning is far less than the full parameter count. LoRA's approach is: freeze the full parameters of the original large model, insert two low-rank matrices A and B (with dimensions d×r and r×d respectively, where the rank r is far smaller than the original dimension d) as a bypass alongside the key attention layers of the Transformer, update only these two small matrices during training, and add their product back to the original weights during inference.

The engineering significance of this design is profound: an ID-photo-style LoRA file is typically only a few dozen MB in size, its training cost can be as low as a few dollars, yet its effect can precisely control output style, background color, and composition standards. More importantly, LoRA files can be freely shared and reused within the community like plugins—platforms like Civitai already host tens of thousands of LoRA models for different scenarios available for free download, from switching ID photo backgrounds between white and blue to one-click application of various artistic styles. Nearly every conceivable vertical scenario has ready-made LoRA resources. Independent developers don't need to train models from scratch—they only need to call ready-made models via the APIs of platforms like Replicate, Alibaba Cloud PAI, or ByteDance's Volcano Engine to process each image at an extremely low marginal cost. This dramatic lowering of the technical barrier is precisely the fundamental prerequisite that makes "live in 3 hours" possible. The real barrier lies not in technology, but in whether you've chosen the specific scenario where "users are willing to pay."

What's Truly Worth Copying: Not the Product, but the Loop

The creator repeatedly emphasizes in the video: what's truly worth copying is not the product, but its loop.

This statement pinpoints the fundamental reason most AI product startups fail—many people are obsessed with "building powerful tools" but ignore the complete circuit from user demand to completed payment. The so-called loop refers to a minimal system that can self-validate and continuously iterate, broken down into four steps:

Step One: Pick a Niche Demand with Willingness to Pay

Don't build general-purpose tools; focus on scenarios that are specific, vertical, and have short decision chains. ID photos are the classic example: the demand is clear, users have clear expectations of the result, the payment barrier is low, and the motivation is strong.

Behind this judgment lies a classic demand-screening framework worth referencing: the "Jobs To Be Done (JTBD)" theory, proposed by Harvard Business School professor Clayton Christensen. Its core viewpoint is that users buy products to "complete a specific task," not simply because they like the product itself. The most famous case of JTBD theory comes from Christensen's research on McDonald's milkshakes: McDonald's originally thought the milkshake's competitors were other milkshakes, but research found that a large number of consumers bought milkshakes during their morning commute, with the real purpose of "making the long drive less boring and staying full through the morning"—their actual competitors were bananas and bagels. This shift in perspective completely changed the direction of product improvement.

Examining the ID photo demand through this framework—the "task" users truly want to "complete" is "getting a compliant photo at the lowest time and money cost," not "experiencing AI technology." The practical value of JTBD theory is that it forces entrepreneurs to step out of the "what features did we build" perspective and instead ask "in what situation, and to solve what specific problem, do users use this product." The answer to this question often reveals the true competitors and the real user pain points, both of which differ greatly from intuitive judgment. Focusing on tasks rather than features is the key mental shift for finding a real willingness-to-pay scenario.

Step Two: Build Only the Minimum Version in 3 Hours

"Minimum" is the key word of this step, backed by the ultimate practice of the "Minimum Viable Product" (MVP) concept from the Lean Startup methodology. The MVP concept was systematically articulated by Eric Ries in his 2011 book The Lean Startup, while its intellectual roots trace back to the core philosophy of "eliminating waste" in the Toyota Production System, as well as the "Customer Development" methodology proposed by Steve Blank.

Ries defines an MVP as "the version of a product that enables a team to collect the maximum amount of validated learning about customers with the least effort." Its core logic is that the biggest risk for a startup is not technical risk, but "building something nobody wants." A frequently cited cautionary tale is Webvan—this late-1990s American online grocery delivery company invested $1 billion directly into building a warehouse and logistics system without adequately validating real user demand, ultimately going bankrupt in 2001. Dropbox took the opposite approach: before writing a single line of code, founder Drew Houston recorded a three-minute product demo video. After posting it on Hacker News, it garnered 75,000 waitlist signups in a single day—validating real demand with a "video of a fake product" before beginning development.

The MVP methodology has gained a new accelerator in the AI era. The "waterfall model" of traditional software development splits requirements analysis, design, development, testing, and deployment into strictly sequential phases, with cycles often measured in months; Lean Startup replaces this with the rapid "Build-Measure-Learn" cycle. And the emergence of the AI toolchain has further compressed the MVP build cycle from "days" to "hours." A key cognitive shift is this: an MVP is not a "defective version of a product," but "the most streamlined version designed specifically to validate a core hypothesis"—the difference being that the former is a reluctant compromise, while the latter is a conscious strategic choice. The 3-hour time constraint is itself a form of forced discipline, compelling you to cut all non-essential features and directly answer the most core question: "Will users pay for this?"

Step Three: Add an Unlock Action, Launch First to Validate

The product must include a business action like "pay to unlock"—only real payment behavior is the most reliable signal of demand validation. Free users' likes can't prove a market; payments can.

This principle is called the "Willingness To Pay (WTP)" test in business validation theory. Behavioral economics research shows there's a huge gulf between people's psychological attitudes toward "free" and "paid"—even a symbolic 0.1-yuan payment can filter out a large number of pseudo-demand users who are "interested but won't actually use it." Nobel Prize-winning economist Richard Thaler's "Mental Accounting" theory offers a profound explanation: when consumers pay for a service, they activate a completely different cognitive evaluation mechanism, distinct from the casual clicking during a free trial.

From a data perspective, this principle is equally well-supported. Paul Graham once pointed out in an article that one of the most common mistakes early-stage entrepreneurs make is using "active user count" instead of "paying user count" as a validation metric—there is often a conversion gap of dozens of times between the two. For an early-stage product, 10 paying users are more convincing than 1,000 free signups, because the former directly validates the core hypothesis of the business model. A more practical operational suggestion is: even if the product isn't yet polished, you should set up a payment barrier from day one of launch, even at an extremely low price—this action itself will help you filter out your true target users, and the feedback quality from these users is far higher than that from free users.

Step Four: Replicate More Styles Based on Feedback

Once the core path is proven, expansion becomes low-cost and low-risk: if ID photos can collect payments, then add business headshots, portraits, stickers... Each new style is an incremental replication built on a validated foundation, not a gambling-style redevelopment.

This expansion strategy corresponds to the early form of "Platformization" thinking in product strategy: first validate user trust and payment habits with one vertical scenario, then replicate horizontally to adjacent scenarios. WeChat initially only handled communication among acquaintances, then rolled out Moments after validating user activity; Notion first polished its core note-taking experience, then expanded to databases, project management, and other features—both essentially follow the same logic. This strategy has a clear economic explanation: once you've obtained the user's "first trust payment," the user's decision cost when you subsequently launch related products drops significantly, which is called the "compound interest effect of trust assets." For independent developers, this means that every "style addition" is a low-risk decision backed by data, rather than blind feature stacking.

The Transferability of This Methodology

According to the original video, the complete execution process is broken down into a 10-step SOP covering several key stages:

• How to choose a topic: how to identify niche demand with clear willingness to pay;
• How to write prompts: how to use prompts to drive AI in generating product logic and content;
• How to deploy the product: the complete no-code/low-code path from generating code to going live;
• How to design payment collection: how an individual can compliantly set up a payment collection solution without a business license.

"Zero lines of hand-written code" is made possible by the AI-assisted development and no-code deployment toolchain that has rapidly matured in recent years. The formation of this toolchain ecosystem is the product of multiple technological trends converging over the past five years, and is worth breaking down separately to understand.

The Infrastructure Layer for Modern Independent Developers

At the code generation layer, AI programming tools represented by Cursor have evolved from "code completion" to "conversational full-stack development." Cursor is built on VS Code with deep integration of large language models like Claude and GPT-4, allowing developers to describe requirements in natural language (such as "help me write a Next.js app that accepts image uploads and calls the Replicate API to process them") and directly generate complete, runnable code, with support for continuous modification and debugging within the same conversation. Understanding the capability boundaries of such tools is equally important: current AI programming tools perform excellently when generating independent functional modules with clear inputs and outputs, but still have limitations when handling large refactoring tasks that require global architectural understanding. For independent developers, the most effective way to use them is to break down requirements into several small tasks with clear boundaries and combine them step by step, rather than describing the entire system all at once.

Slightly different from Cursor's positioning, v0.dev (from Vercel) and Bolt.new (from StackBlitz) focus on frontend interface generation, allowing users to directly generate previewable, deployable React components and complete pages through natural language descriptions. Such tools lower the "can't program" barrier from "unable to get started" to "able to describe requirements," enabling even entrepreneurs without a technical background to obtain a visually complete product interface within hours. GitHub Copilot, on the other hand, focuses more on real-time inline completion during the writing process, suitable for developers with some programming foundation who want to improve efficiency.

At the deployment layer, the emergence of Vercel has completely transformed the experience of launching web applications. Vercel's technical architecture is based on the "Edge Network" concept, compiling application code into serverless functions and static resources that can run on globally distributed nodes. User requests are automatically routed to the geographically nearest node, achieving low-latency responses. Compared to the traditional operations workflow of "renting a server, manually configuring Nginx, and handling SSL certificate renewals," Vercel packages all these operations into an automated pipeline triggered by a single "git push" command. Its free tier is entirely sufficient for personal projects, truly achieving a zero-ops experience of "push code to go live." Platforms like Railway and Render build on this by adding support for backend services and databases, suitable for scenarios requiring persistently running server processes.

At the Backend-as-a-Service (BaaS) layer, Supabase provides an out-of-the-box PostgreSQL database, user authentication, file storage, and real-time subscription features. Developers don't need to set up and maintain servers, and can call these directly from the frontend via an SDK. Supabase's design philosophy is "an open-source alternative to Firebase"—it wraps PostgreSQL (one of the world's most mature open-source relational databases) into a service accessible via REST API and real-time WebSocket, while providing fine-grained permission control based on Row Level Security (RLS). This means developers can read and write to the database directly from frontend code, without writing separate backend API interfaces for each data operation, greatly reducing the code volume of full-stack applications. Firebase is a similar solution offered by Google, with some access restrictions in China. Together, these tools form the complete pipeline of "describe requirements → AI generates code → one-click deploy → go live and collect payments," compressing work that originally required a full-stack engineer several weeks into a standard process that can be completed within hours.

The payment collection stage also merits special explanation. Independent developers in China face a real barrier when setting up payment solutions: standard merchant onboarding for WeChat Pay and Alipay typically requires providing enterprise qualifications such as a business license. But there are various compliant workarounds on the market, and understanding the applicable scenarios and limitations of each solution is the prerequisite for making the right choice.

Payment Collection Path Choices for Individual Developers

Compliant payment collection solutions for individual developers in China can be roughly divided into three categories: The first is the platform-parasitic model, using the merchant qualifications of platforms like Xianyu (virtual goods) or Afdian (creator sponsorship/paid content) to collect payments, with the platform taking a certain percentage as a fee (Afdian charges about 8%). This is suitable for early-stage validation, has almost zero barriers, but offers weak brand independence. The second is the aggregate payment platform, such as Ping++ (now renamed Qingge Pay), which uses the platform's qualifications as an intermediary layer to connect to WeChat Pay and Alipay. Individual developers integrate via API, with a lower barrier than directly opening a merchant account, suitable for scenarios where the developer has some development capability and wishes to deploy their own payment page. The third is registering as an individually-owned business, which can now be handled entirely online in multiple Chinese cities, typically completed in 3-7 business days. With a business license, one can directly apply for a standard merchant account with lower fee rates (WeChat Pay's standard rate is 0.6%), suitable for the stage where product validation is complete and one is ready to scale operations.

It's worth noting that regardless of which path is chosen, funds collected through a platform's qualifications must ultimately be withdrawn through a personal bank account. Once annual withdrawal amounts exceed a certain threshold, the platform is obligated to report transaction data to the tax authorities, so understanding the relevant tax filing requirements in advance is a necessary compliance awareness. For products targeting overseas users, Stripe and LemonSqueezy offer international payment collection solutions that are extremely friendly to individual developers. Among them, LemonSqueezy acts as the "Merchant of Record," handling global VAT compliance issues on behalf of developers, making it especially suitable for independent developers who haven't yet registered a company. Choosing the right payment collection path is often the final hurdle for an independent developer to go from "a product that runs" to "a business that makes money." The original video provides a dedicated solution approach to this problem, which is a concrete value point for individual entrepreneurs.

The Barriers to AI Entrepreneurship Are Being Reconstructed

The real insight of this case lies not in "AI can generate photos" itself, but in the fact that it demonstrates an entirely new rhythm of entrepreneurship:

Validation over perfection, the loop over features, payment over scale.

When engineering stages like writing code, building interfaces, and running deployments can all be dramatically compressed by AI toolchains, an entrepreneur's scarcest ability instead returns to the most fundamental essence of business—can you find a real demand that someone is willing to pay for, and then get it running as fast as possible.

This trend corresponds at the macro level to a "structural downward shift in the entrepreneurship cost curve." Y Combinator founder Paul Graham predicted in his 2013 article "Do Things That Don't Scale" that the maturation of technical tools would continuously lower the startup barrier to entry. Back then, he envisioned changes over a scale of years, but the explosion of the AI toolchain has sharply accelerated this process during 2023-2024—according to YC's public data, over 20% of the startups it recruited in 2024 were solo founder teams, a proportion that was almost negligible five years ago. Behind this number lies a deeper structural reason: the traditional startup premise that "you need an engineer co-founder" has been partially removed since the emergence of AI programming tools; the pay-as-you-go pricing model of cloud services has eliminated the capital investment barrier for early-stage infrastructure; and the maturation of global payment infrastructure has made the path from "idea" to "receiving the first payment" shorter than ever for a single person.

This structural change has also spawned another phenomenon worth noting in the entrepreneurial ecosystem: the rise of the "Micro-SaaS" (micro Software-as-a-Service) model. Unlike traditional SaaS that pursues millions of users and funding-driven growth, the typical form of Micro-SaaS is: one person, solving one niche problem, with annual revenue in the range of tens of thousands to hundreds of thousands of dollars, no funding, and no team expansion. This model already has numerous success cases in the Indie Hackers community, and the economic logic behind it is highly consistent with the "3-hour loop" discussed in this article: the AI toolchain reduces the cost of a single person maintaining a small product to an extremely low level, while focusing on niche scenarios makes customer acquisition efficiency far higher than that of general-purpose tools. "One person, one computer, one weekend" as a viable starting point for entrepreneurship is becoming a real phenomenon.

For independent developers who want to enter the AI product race, rather than agonizing over technology choices, it's better to first ask yourself one question: Will someone pay for the thing I'm about to build, tomorrow? If the answer is yes, then everything that remains—may truly only take 3 hours.

Key Takeaways

Key Takeaways

Key Takeaways

Key Takeaways