nanobananaedit.com Review: Building an AI SaaS from 0 to 1 - The Practice & Pitfalls

In my opening manifesto, I laid out the path of "Indie Development + SEO."

My last post was a review explaining why SEO is my weak point. This post focuses on the other side: how I practiced the "Indie Development" part through the nanobananaedit.com project.

This article is purely a "technical review" and "process log," documenting how I went from 0 to 1 launching an AI SaaS internationally, filled with real pitfalls and reflections.

1. Project Kick-off: Why NanoBanana?

The project started simply: Google's newly released Nano Banana model was trending. It felt like a good opportunity to practice my skills and quickly validate the process of launching a product internationally.

My primary goal wasn't monetization but to run through the entire process of launching a website globally, just to get the feel of it. So, I decided to build an image generation site using the Nano Banana API for AI image enhancement features.

2. Requirements & Keywords

• Real Need: Ride the hype train, build a website.
• Keywords: NanoBanana
• Monetization (Secondary): Planned to use Google Ads and user subscriptions.

3. Foundational Setup: Domain, DNS & Hosting

This is the first step for an indie developer going global: making your site accessible worldwide. It requires coordination between three core service providers.

1. Domain (Namecheap)

• Choosing a Name: Consulted ChatGPT, combined with intent, settled on nanobananaedit.com.
• Purchase: Bought it on Namecheap on August 27, 2025. (Bought the domain the same day I decided to do it. I was actually quite excited then, felt like a new chapter was beginning.)

2. DNS (Cloudflare)

• Choice: Considering I'd use Cloudflare R2 for image storage later, from a system integration (Order) perspective, I decided to hand over DNS services to Cloudflare as well.
• Operation: Added nanobananaedit.com to Cloudflare, chose the free plan. Cloudflare provides two "nameserver addresses."
• Modification: Went back to Namecheap's domain management panel and changed the DNS server addresses to the two provided by Cloudflare.

3. Hosting (Vercel)

• Choice: Vercel is the top choice for front-end (Next.js) developers, offering an excellent deployment experience that let me focus on development itself (Self-Drive).

4. The Relationship Between the Three (Key Point)

The relationship between these three is often confusing for beginners:

• Namecheap (Domain Registrar): You bought the 'land' nanobananaedit.com here.
• Cloudflare (DNS Provider + CDN): It's the 'navigation system' for this land. You tell Namecheap: "Anyone looking for me, ask Cloudflare." It also provides free CDN acceleration.
• Vercel (Application Hosting Platform): This is the 'house' (your website application) built on your 'land'.

The final access flow is: User -> Cloudflare (CDN/Navigation) -> Vercel (Your House) -> Content Returned

4. Development & Deployment

1. Tech Stack Selection

• Template: Used the ShipAny template (v2.6.0), which conveniently included Creem payment integration, greatly accelerating the MVP build.
• Modification: Opened the project with Cursor (AI programming), referenced ShipAny's documentation, and quickly adapted it into nano-banana-edit.

2. Code Hosting (Github)

• Created a private repository nano-banana-edit on Github.
• Pitfall #1: Git Email Mismatch
  • My local global Git email was A (zengfeiyang@...), but my Github registration email was B (zenvelhq@...).
  • Consequence: git push failed.
  • Solution: Simply set the current project's git email in the project directory:
  • git config user.email '[email protected]' (This small detail reminds us that tool configuration also requires 'Order').

3. Vercel Deployment

• Created a new project on Vercel, importing the nano-banana-edit Github repository.
• Vercel deployed automatically, generating a temporary .vercel.app domain.
• Configuring Custom Domain:
  1. In the Vercel project Domains settings, entered nanobananaedit.com.
  2. Vercel provided 2 DNS records (1 CNAME, 1 A record).
  3. Went back to Cloudflare's DNS management panel and added these 2 records exactly as prompted by Vercel.
  4. Returned to Vercel, waited a few minutes, Vercel detected the DNS records had propagated and automatically configured the SSL certificate.
  5. At this point, https://www.nanobananaedit.com became accessible. Seeing my own website running on global nodes felt pretty empowering, that sense of 'creation' was strong.

5. Login & Registration

• Initial Approach: For registration and login, I initially used the Google and Github OAuth options built into the ShipAny template – simple, fast, and aligned with the MVP principle.
• Supplementary Approach: However, considering not all users have or want to use these platforms, I later added email login functionality, using Resend (https://resend.com) as the email sending service.
• Future Consideration: Perhaps in the future, I could consolidate everything into Supabase, as it supports email (including password recovery), Google, Github, and other login methods quite well. Managing it would be more convenient and better aligns with a systematic (Order) approach.

6. Configuring Core Functionality (R2 Storage & Creem Payment)

A SaaS application often needs storage and payment as standard features.

1. Cloud Storage: Cloudflare R2

The ShipAny template supported AWS S3. Since R2 is S3 API compatible and extremely cost-effective (mainly due to nearly free egress traffic), based on rational considerations of cost and performance, I decisively chose R2.

• Steps:
  1. Enabled R2 in the Cloudflare dashboard.
  2. Created a Bucket, e.g., nanobananaedit-images, to store user-uploaded images.
  3. Created R2 API keys (Access Key and Secret Key).
  4. Filled in the R2 ENDPOINT (Account ID), ACCESS_KEY, SECRET_KEY, and BUCKET name in the nanobananaedit.com project's .env environment variables.
• Pitfall #2: R2 Custom Domain vs. Vercel Root Domain Conflict (The Most Critical Pitfall!)
  • When configuring R2, it allows binding a "custom domain" to access bucket resources.
  • I mistakenly bound this custom domain directly to nanobananaedit.com (the root domain).
  • Consequence: Cloudflare got confused. Vercel wanted to occupy the root domain, and R2 wanted it too. A single hostname cannot point to two different places simultaneously.
  • Symptom: The Vercel dashboard persistently showed an Invalid Configuration error.
  • Solution: R2 custom domains must never be bound to the root domain. I unbound nanobananaedit.com and instead bound a subdomain, like images.nanobananaedit.com. The conflict was resolved, and Vercel returned to normal.
  • Reflection: This pitfall was quite deep, but it forced me to thoroughly understand the resolution logic for root domains and subdomains across different service providers. Understanding the rules (Order) is essential to avoid conflicts; consider it valuable tuition paid.

2. Payment: Creem

Stripe had too many restrictions, so I switched to integrating Creem payment.

• Process: The Creem integration process mainly required patience and communication.

• Pitfall #3: Creem Review Rejected

  1. Initial Rejection: After setting up the production environment, my payout verification request was rejected.
  2. Reason: "Some links on the landing page are invalid and should be removed" (e.g., placeholder social links like Twitter from the template that I hadn't configured yet).
  3. Solution: I immediately removed all invalid placeholder links and emailed [email protected] explaining the situation.
  4. Result: The review was approved the same day, very efficient. Effective communication with platforms (Rationality) can indeed solve many problems.

• Pitfall #4: Production Payment Failure

  • After approval, I tested production payments, and they still failed.
  • Reason: I had entered incorrect CREEM_ related configurations in Vercel's production environment variables.
  • Solution: Carefully checked, corrected the environment variables, and redeployed. Payment succeeded. This kind of basic error caused by carelessness is the best reminder for 'Order' and 'attention to detail'.

7. Finishing Up: Submitting to Google

With everything set up, the final step was to let Google know I exist.

• Logged into Google Search Console.
• Submitted the sitemap for nanobananaedit.com.
• After some time, the site was successfully indexed by Google.

8. Conclusion

The nanobananaedit.com project, although ultimately "paused" due to traffic issues (see previous post), fully achieved its mission as a practice run.

I successfully (and with pitfalls) navigated the complete process of indie development, international SaaS launch, domain setup, CDN, serverless deployment, R2 storage, and overseas payments.

This validation of my "Stamina" laid a solid foundation for my subsequent "Super Individual" experiments.