This content originally appeared on DEV Community and was authored by Harun Al Rasyid
A few days ago, I found myself curious about this whole “vibe coding” movement. You know, using AI-powered tools like Cursor or Copilot to speed up the flow of coding, especially in solo or creative projects.
I wasn’t chasing productivity or building a startup — I just wanted to see how it feels to build something serious but personal, with AI as a pair.
So I asked ChatGPT (yes, I even ask AI for the idea) for ideas that would:
- Simulated the real world project
- Stay safely outside of my current job’s non-compete zone
That’s when it suggested:
“How about building a cleanly architected, multi-tenant SaaS backend in Go?”
Boom!! A project name idea was invented:
Multi-Tenant SaaS Backend
I even had no idea what that meant. X))
Still, I thought hard about the project and figured I’d better start by abbreviating the name: MTSB.
How smart am I.
And instead of hiding it away, I decided to document every step — one post per task, like a devlog journal.
This is the first post in what might become a very long devlog series — one post per issue or PR. Basically a public journal of code, architecture, struggle, and vibes.
So be ready. It could be millions of posts. Or like, five.
Day 1 — Setting the Foundation with Docs
Before writing a single line of code, I decided to start with something most devs (myself included) usually skip or leave half-baked:
Documentation.
Why? Because it’s a great way to:
- Clarify what I’m actually building
- Lay out the structure before getting lost in implementation details
- Make the repo portfolio-ready from Day 1
- Make me looks like professional dev 😀
What I Wrote (or not written by me)
-
README.md– basic overview, goals, tech stack, and structure -
docs/architecture.md– Clean Architecture overview with Mermaid diagrams -
docs/data-model.md– sketches of key entities and relationships -
docs/tenant.md– a deeper look at the “tenant” concept and how it fits into the app -
docs/user-journey.md– a rough user flow from signup to project creation
Looks smart isn’t it? Unfortunately not. I didn’t write the docs alone. I used Cursor to keep the flow tight and fast. Combined with ChatGPT, it felt less like “writing docs” and more like sketching out a blueprint with a buddy who types faster and doesn’t complain.
Cursor helped:
- Suggest Markdown layout
- Autocomplete repetitive sections
- Keep my thoughts structured and clean
It was honestly the most painless documentation session I’ve ever had.
What I Learned
- Starting with documentation forces you to think before you build. Sounds obvious… but it’s so easy to skip.
- Defining architecture early sets the tone. Even if it changes later, you’ve at least set a direction.
- You don’t need to over-engineer docs. A few
.md(or more precisely.mdc) files can go a long way when done with intention. - You even don’t need to write article like this from scratch. Credit to chatGPT.
Links, If You’re Curious
Up Next: Domain Modeling
In next session, I’ll start building the core domain layer.
That means defining types like Tenant, User, Project, and laying the foundation for the actual business logic — all while keeping it clean, testable, and cursor-powered.
Thanks for reading! Stay tuned for more journal entries — and if you’re building something similar, let’s connect!
This content originally appeared on DEV Community and was authored by Harun Al Rasyid