Building My First Global SaaS Tool from Scratch

After some encouragement from my colleagues, I finally decided to build my own SaaS tool for the global market.

On September 8, I got a Mastercard that supports international payments. Right after that, I bought a domain, initialized the project, and started building.

The first version went live on day one.

As soon as it was deployed, I submitted the site to Google Search Console (GSC) and Bing Webmaster Tools, hoping to get it crawled and indexed as early as possible.

This post is a record of that process: choosing a domain, setting up the stack, deploying the product, working with AI coding tools, and figuring out a development workflow that works for a solo developer.

Choosing a Domain

I wanted to build a music-related utility site, so the first step was finding a suitable domain.

After comparing registrars, I found that the same domain was cheaper on Spaceship than on Namecheap, so I went with Spaceship.

I had read quite a few discussions about domain selection before starting. My main takeaways were:

1. If your budget allows, .com is usually the safest choice. .ai and .app are also worth considering.
2. Keep the domain short and easy to remember. Ideally, include a keyword related to the product.
3. Avoid hyphens, obscure English words, and random letter combinations whenever possible.

One reason .ai and .app can work well is search behavior.

People often search for phrases such as xxx app or xxx ai. If your domain naturally matches that intent, it can make the product easier to understand and remember.

At this stage, though, I did not want to spend too much money on a domain.

So I ended up buying:

musictool.tools

It costs roughly €6 per year.

Good enough for an early-stage experiment.

Setting Up the Project

For an SEO-driven product targeting international users, I prefer a stack that supports Server-Side Rendering (SSR).

The main reason is simple: search engines can receive relatively complete HTML directly, which reduces the amount of work required for crawling and indexing.

Because of that, I did not want to build the site as a purely client-rendered SPA.

This is also one of the reasons frameworks such as Next.js have become so popular among SEO-focused products.

That said, I personally find the Next.js development experience a bit heavier than I would like, so I chose TanStack Start (RC) instead.

For project initialization, I used an open-source stack generator I had used before:

https://better-t-stack.dev/

Once the initial scaffold was ready, I started adapting it to my own requirements with the help of AI.

Here is the stack I ended up using.

Engineering and Tooling

Category	Technology	Purpose
Monorepo	pnpm workspaces + Turborepo	Multi-package management and parallel builds
Language	TypeScript	End-to-end type safety
Code Quality	Oxlint + Oxfmt	Linting and formatting
Environment Variables	@t3-oss/env-core + Zod	Server and client env validation (packages/env)

Frontend and Full-Stack Framework

Category	Technology	Purpose
Full-Stack Framework	TanStack Start	SSR, file-based routing, Server Functions
Routing	TanStack Router	Type-safe routing and SSR integration
Build Tool	Vite 8	Development and production builds
SSR Runtime	Nitro	Server-side rendering and Vercel deployment support
UI Library	React	Component-based UI
Styling	Tailwind CSS v4	Utility-first CSS
Component Library	shadcn/ui (packages/ui)	Shared UI primitives
Icons	lucide-react	Consistent icon system
Theme	next-themes	Dark mode
Animation	Motion	Page and component animations
Notifications	Sonner	Toast notifications

Data and State Management

Category	Technology	Purpose
Server State	TanStack Query	Data fetching, caching, and SSR integration
Client State	Jotai	Shared UI and session state
Forms	TanStack Form	Form state and validation
API Layer	oRPC	End-to-end type-safe RPC with OpenAPI integration
ORM	Drizzle	TypeScript-first database access
Database	PostgreSQL	Primary data storage
Local Database	Docker Compose	Local PostgreSQL development environment

Authentication and Internationalization

Category	Technology	Purpose
Authentication	Better Auth	Sessions, social login, and TanStack Start integration
Login	Google OAuth	Third-party authentication
Internationalization	Paraglide JS + inlang	Compile-time i18n and locale-based URLs for SEO

AI

Category	Technology	Purpose
AI SDK	Vercel AI SDK	Streaming responses and Server Actions
Model Provider	@ai-sdk/google	Google model integration

Infrastructure and Third-Party Services

Service	Purpose
Vercel	Hosting, CI/CD, and Serverless Functions
Cloudflare	Domain DNS
Google OAuth	User authentication
Waffo Pancake	Subscription payments and Webhooks
Resend	Transactional email and user feedback
Cloudflare R2	S3-compatible object storage with presigned uploads
Google Analytics 4	Production traffic analytics
Microsoft Clarity	User behavior analytics and session recordings
Sentry	Frontend and backend error monitoring

Most of these services provide free tiers, which is more than enough for an early-stage solo project.

Payments

For payments, I chose Waffo, mainly because it is relatively friendly to independent developers.

I discovered it somewhat randomly while browsing online.

Stripe usually requires more preparation depending on where you are based, including considerations around business entities and banking.

I have not opened a Hong Kong bank account yet, so Waffo was the more convenient option for me at this stage.

The integration itself was straightforward.

I followed the official documentation, gave the relevant docs, prompts, and Skills to the AI coding agent, and let it handle most of the implementation.

If your setup allows it, Stripe is still worth evaluating based on your own business requirements.

Deploying the Product

Launching a small SaaS product today is much easier than it used to be.

Modern Serverless infrastructure is mature enough that lightweight SaaS tools often do not need a manually maintained server running 24/7.

Platforms such as Vercel and Cloudflare can handle most of the infrastructure for you while scaling automatically when necessary.

For this project, I connected the Git repository directly to Vercel.

Every push automatically triggers a new build and deployment.

There is almost nothing to manage manually.

At the current stage, deployment costs are also close to zero.

For object storage, I use Cloudflare R2.

Its free tier is generous enough for the early stage of the project, so storage has not added any meaningful cost yet.

The main expenses currently come from third-party APIs used by some features. Those require a small amount of prepaid credit, but the overall cost is still manageable.

For solo developers, the infrastructure barrier to launching a project has become extremely low.

You can build the first version almost entirely on free tiers.

Once the product has real users and revenue, you can upgrade infrastructure based on actual usage instead of guessing in advance.

My Development Process

The initial infrastructure setup took roughly one day.

After that, I moved on to actual feature development.

If you are unfamiliar with the target market, I think it makes sense to start with an AI-assisted research phase.

You can use AI Research tools to study competitors, identify common features, understand user expectations, and map out the basic product landscape.

In my case, I already knew this domain fairly well and had a clear idea of what I wanted to build.

So I went straight into AI Coding.

My development process has two main stages:

1. Design the feature.
2. Break down the requirements and implement them.

Designing with AI

For design work, I mainly use Pen.

After connecting it to DeepSeek and enabling x6, the overall design workflow became quite efficient.

My AI Coding Workflow

For implementation, I mainly use Matt's workflow.

The process looks roughly like this:

1. /grill me
   
   Discuss the requirements with AI in detail and clarify the implementation approach.

2. /to-spec
   
   Convert the discussion into a complete specification and high-level implementation plan.

3. /to-tickets
   
   Break the plan into smaller tasks that can be implemented independently.

4. /implement-spec
   
   Implement the feature step by step based on those tasks.

5. /code-review
   
   Ask AI to review the implementation, then do a final manual review myself.

I have found this workflow surprisingly comfortable.

It reduces the amount of improvisation during implementation and gives the coding agent much clearer boundaries.

Letting AGENTS.md Accumulate Project Knowledge

One practice that has worked particularly well for me is asking AI to record mistakes, corrections, and project-specific rules in AGENTS.md.

Whenever something goes wrong, I try to convert that mistake into a reusable rule.

That gives future coding sessions access to the context accumulated from previous work.

Over time, the project starts developing its own operating manual.

This helps reduce repeated mistakes and makes future implementation more consistent.

The process becomes a kind of feedback loop:

Build → Find problems → Update rules → Build again

As the project's Harness becomes more complete, AI-assisted development also becomes much smoother.

For features that resemble something already implemented, a clear requirement and good task decomposition are often enough for the AI agent to handle most of the work.

I still review the result at the end.

Fully autonomous coding without verification is not something I am comfortable with yet.

The Token Problem

The biggest frustration during development has actually been Token limits.

I started with Cursor's $20 monthly plan.

I burned through the quota in roughly four days, mostly while using Grok.

After that, I switched to the $20 Codex plan.

The overall experience was decent, but I frequently had to wait around five hours for the usage quota to reset.

That interrupted the development flow more often than I expected.

I also used Tibo after its quota reset, but that still was not enough.

Later, Z Code gave users a huge Token allowance, on the order of hundreds of millions of Tokens.

There has been some controversy around it recently, but by then I had already used it extensively.

Eventually, I adjusted my workflow.

The current version looks like this:

Use GPT 5.6 or GPT 6 for requirement analysis, architecture, and task decomposition. Then hand clearly defined implementation tasks to lower-cost models such as GLM.

At first, I was skeptical about this setup.

I assumed that anything even moderately complex should be implemented by the strongest available model.

After trying it in practice, my view changed.

If the architecture has already been thought through and the tasks are broken into sufficiently small units, models such as GLM can handle a surprisingly large amount of real implementation work.

They perform especially well when:

• The task boundaries are clear.
• The expected behavior is explicit.
• The implementation path is already defined.
• The relevant project context is available.

For this type of task, the output is often good enough for my needs.

After eventually exhausting my Z Code quota as well, I subscribed to Command Code's $10 plan and started using DeepSeek 4.1 Flash more often.

Among Chinese models, the ones I currently find most practical for coding are GLM and DeepSeek.

They occasionally enter what I jokingly call "thunderous deep-thinking mode" and spend far too long reasoning about a very simple problem.

Still, their coding ability is already quite solid.

One small lesson from my own usage:

Start with the reasoning level set to "High." Unless the task is genuinely difficult, there is usually little reason to leave it on "Extra High" all the time.

Expensive Models Do Not Need to Do Everything

One of the biggest changes in my AI coding workflow has been realizing that the most expensive model does not need to handle every task.

A stronger model can focus on:

• Requirement analysis
• Architecture
• Technical design
• Edge cases
• Task decomposition

Then a lower-cost model can handle:

• CRUD implementation
• UI adjustments
• API wiring
• Repetitive refactoring
• Well-defined feature work

This creates a fairly practical division of labor.

You get the reasoning quality of stronger models where it matters most, while keeping Token costs under control during implementation.

For a solo developer, that balance can make a significant difference.

Learning SEO Along the Way

Recently, I have also been spending more time learning SEO.

Before building this project, my understanding of SEO was fairly shallow.

I assumed that semantic HTML, good page titles, and a clean page structure covered most of the important work.

Once I actually started building a global tool site, I realized there is much more to it.

For example:

• Keyword research with tools such as SEMrush
• Search volume analysis
• Keyword difficulty analysis
• Site architecture planning
• Core keyword optimization
• Long-tail keyword targeting
• Content planning
• Continuous page optimization

Ultimately, all of this has the same goal:

Increase the site's visibility in search engines.

When someone searches for a problem related to your product, you want your site to appear as high as possible in the results.

That gives you a chance to turn search traffic into:

Search → Click → Visit → Sign up → Use → Pay

I am still very early in this process, so I am learning as I go.

Final Thoughts

That is where the project stands for now.

My main goal with this post was to document what it looks like to start building a global SaaS tool from scratch as a solo developer.

The infrastructure is cheap.

Deployment is easy.

AI can already take over a meaningful amount of implementation work.

The harder part is gradually building a workflow that makes all of those tools work together reliably.

For me, that currently means:

Research → Design → Spec → Tickets → Implement → Review → Update AGENTS.md → Repeat

I am still learning, especially when it comes to SEO, distribution, and turning the project into something that consistently attracts users.

If I discover anything useful along the way, I will keep sharing what I learn.

Try it
Free account with starter credits, no card required: musictool.tools

Welcome to give me feedback on any suggestions for improving the website.👏

Comments

[Mohith kumar]

Congrats on shipping! One thing I wish I had done earlier on my first SaaS: ask every signup a single question ("what are you hoping this will do for you?"). Those answers shape the roadmap and the landing page better than any analytics.