Vibe coding works best when the user is you
I fell in love with Thailand a little over two years ago.
It started on an adventure sail across the Andaman Sea with 13 strangers from around the world. No shared background. No shared routine. Just long days on the water, stories at night, and that rare feeling that your life just got wider.
A few months later, I went back and met an unexpected love. Her name is Arisara.
Now we’re working toward building our future and path in rural northeast Thailand.
And that’s where “learning Thai” stopped being a nice-to-have.
It became personal.
Her English is improving. My Thai has been harder. Not because I don’t care. Because consistency is brutal when the practice loop is clunky.
So I built my own accelerator.
Not as a startup.
As a tool I needed.
The best reason to vibe code
Vibe coding is the fastest way I’ve ever seen to go from idea to working software.
But the real unlock is not the AI.
It’s the feedback loop.
The best vibe-coding projects start when:
you have a real problem
you feel the friction daily
you can tell, instantly, what’s working and what’s not
When you build for yourself, you don’t need motivation hacks. You don’t need fake deadlines. You just want the problem gone.
That’s why personal tools are the perfect playground for vibe coding.
What I built
I built Sawasdee Speak:
https://sawasdeespeak.com/
The goal is simple: make Thai practice easier than procrastination.
Short sessions. Real repetition. Focus on phrases I actually use. Minimal friction to start.
Not “the best Thai app.”
The best Thai app for my life.
How I built it
I used OpenAI (ChatGPT) to turn the messy idea into a one-page spec and a tight MVP loop.
Then I shipped it using a stack that optimized for speed and deployment, not ideology:
Concept development and requirements in ChatGPT
Built on Google AI Studio
Running on Google Cloud Cloud Run
Domain hosted on Amazon Web Services
This mix matters.
Vibe coding rewards momentum. The stack is whatever keeps you moving.
What vibe coding looked like in practice
This is the workflow that worked for me and is repeatable.
1) Describe outcomes, not implementation
I did not start with “build a language learning app.”
I started with:
I want a daily Thai practice loop
I want short reps
I want the phrases I care about
I want low friction: open → practice → done
2) Get a one-page MVP spec
I asked for:
the smallest possible feature set
the screens and states
what data needs to exist
what is explicitly out of scope
That “out of scope” list is the guardrail that keeps vibe coding from turning into a bloated mess.
3) Build the thinnest version that works
The temptation is to accept every shiny idea.
I resisted.
If it didn’t improve the practice loop, it didn’t ship.
4) Deploy early so the feedback is real
Local builds lie.
Production tells the truth.
Once it was live, the app stopped being a project and became a habit. That’s the entire point.
Why building for yourself is the cheat code
When you are the user, you automatically have:
real requirements (you feel what’s missing)
instant QA (you notice what’s annoying)
relentless prioritization (only what matters survives)
Most projects fail because the feedback loop is imaginary.
Personal tools don’t have that problem.
Guardrails so it doesn’t become future pain
Personal apps have a funny habit of becoming real.
A few rules I follow so “quick” doesn’t turn into “fragile”:
keep secrets out of the frontend
add basic logging early
assume inputs are hostile if the app is public
rate limit anything exposed to the internet
write down what you will not build (and honor it)
Speed is great. Maintainable speed is better.
If you want to try vibe coding this week
Don’t start with “a SaaS.”
Start with one recurring irritation in your life or work.
Do a single sitting sprint:
Write the problem in 3 bullets
Define the loop (open → do the thing → done)
Ask an LLM for a one-page MVP spec
Build only that
Deploy it somewhere you will actually use
That’s it.
You are not proving you can build a company.
You are proving you can ship something useful.
What I’m improving next
Now that I’m using Sawasdee Speak, the next steps are obvious because I can feel the friction:
faster “start session” flow
smarter repetition (missed items return more often)
pronunciation support
lightweight streak or reminder loop
Not because a roadmap said so.
Because I want the practice loop to be automatic.
Closing
I didn’t build Sawasdee Speak to create another project.
I built it because I’m building a life in Thailand, and language is part of that.
Vibe coding is powerful, but the real advantage is purpose.
Build something you need.
Use it tomorrow.
Improve it next week.
That’s the cheat code.