Xiya

Day job: architect at a design firm. Night job: vibe coding my own SaaS. Some days I'm on a screen 12 hours straight. A "real" engineer would faint at my code. But it works, it has paying users, and it's mine. Designer soul, builder hands.

Solo founder doing the job of a 5-person team. AI is my team. What actually moved the needle: • Microsoft Clarity to watch real user sessions (saved my pricing) • AI agents for weekly reports + analytics • Cursor for the whole codebase You don't need headcount. You need leverage.

Let me be transparent about the money. RenderArchi has made ~$1,500 total. 85% of it from China — the market everyone calls impossible to monetize. It's not "quit your job" money. But local architects paying real cash proved my PMF is real. Domestic-hard ≠ domestic-impossible.

Fable 5 burns through tokens way too fast. My Max 5x quota just opened up, and it was gone again in less than an hour. Now I can only sit at my desk and wait for the quota to refresh. The thing is, I wasn’t even doing anything especially hard. This is ridiculous!! Just opened Trae. I’ll test how it performs and report back.

My account suddenly got restricted from logging in! It scared me so much. Luckily, they unlocked it again after a day. What did I even do?😭😭😭

Maybe this is the best era for people like us. I'll never climb a straight vertical line. Too many side roads I want to wander down. The economy is rough. I'll probably never out-earn my parents. But nobody confiscated the fun of exploring. Building solo isn't the safe path. It's the free one.

My biggest conversion win wasn't a feature. I used to force signup before anyone could even try the product. The bounce rate was brutal. So I flipped it: upload image → write prompt → sign up only right before "Generate." 20 days later: first paid order. Friction kills more products than bad code.

Your AI agent feels dumb? It's probably missing skills. The 4 I install before anything else: • skill-vetter — security check, run it FIRST (256K+ installs) • tavily-search — real-time web, or your agent is blind • self-improving-agent — learns from its own mistakes (#1 on ClawHub, 419K) • ontology-memory — remembers who you are Bookmark this. 🦞

Managing AI on a team isn't managing AI. It's managing trust. You turn untrustworthy output trustworthy with 3 things: ① objective standards ② interface contracts ③ process discipline All say the same thing: set the standard first, then let AI build.

3/ Never trust AI output by default. Every bug walks the same path: locate → reproduce on a REAL snapshot → fix → log → test → review → merge Truth lives in real output, not the spec. AI drifts when it guesses — I've watched it "find" the wrong root cause 3x before the real one.

Letting one person vibe-code with AI? Fine. Letting a team do it? Bugs grow exponentially, and nobody can tell which AI output to trust. It looks like 3 people are working. Actually, it's 6: 3 humans + 3 AIs. Managing AI isn't about speed. It's about trust. How I make AI output trustworthy.

@Techieohm yeah🥰

@RenderArchiAI That's crazzy bro, niche fields always have an advantage.

11 months ago I was a full-time architect who couldn't write a single line of code. Today RenderArchi has 2,500+ users.I built the MVP in 3 months with Cursor + open-source templates. My code would make a real engineer cry.Ship the ugly version. That's the whole secret.

➡️ renderarchi.com/en

1. **Read Before You Write**: read the existing code before writing. Check files, similar implementations, imports, and tests. If you are unsure about project conventions, ask instead of guessing. 2. **Think Before You Code**: state your assumptions before coding. If there are tradeoffs, list 2 to 3 options and recommend one. If the requirement is unclear, stop and ask. Do not fill the gap with code that “looks reasonable.” 3. **Simplicity**: write the smallest amount of code needed to solve the current problem. Do not abstract early, add unnecessary config options, or build flexibility for “maybe later.” 4. **Surgical Changes**: keep the diff minimal. Change only what was requested, match the existing style, do not refactor casually, and do not reformat unrelated code. 5. **Verification**: before fixing a bug, write a test that reproduces it, then run tests before and after the change. Test behavior, not implementation details. 6. **Goal-Driven Execution**: if the task is vague, turn it into verifiable success criteria first. For multi-step work, make a plan before executing, and make the plan clear enough for the user to correct the direction early. 7. **Debugging**: read the full stack trace, reproduce the issue first, change one thing at a time, and understand the root cause before fixing it. Do not add a workaround if you do not understand why it works. 8. **Dependencies**: before adding a dependency, check whether the project already has one, whether the standard library is enough, whether it is still maintained, and how large it is. Every new dependency is a long-term burden. 9. **Communication**: explain what you did and why. Proactively call out risks and uncertainties. Commit messages should say specifically what changed, not just “fix bug.” 10. **Common Failure Modes**: seven frequent mistakes: over-refactoring, changing things that were not requested; wrong abstraction, using a generic solution for a one-off problem; hidden decisions, making choices without saying so; only handling the happy path; API hallucination, using APIs that do not exist; style drift; uncontrolled cascading changes.

Said to be “the CLAUDE.md file Andrej Karpathy actually uses”:

Growth is definitely the part I find the hardest and most unclear to start with, compared to writing code or building the product. But it’s not something that can’t be learned systematically. This is one of the most useful growth skills I’ve seen. Saved and learning from it.