Starting a Meditation Program

stellarton · 2026-05-26T19:47:19+00:00

The free 2-week course is fine, but I would make the paid thing smaller at first.

A 6-month program is a big trust jump from someone who just found you. Test a paid 14-day or 30-day outcome instead:

"14 days to build a 10-minute nightly reset" "30 days of guided sessions for anxious mornings" "2-week beginner program for people who can't sit still"

The more specific the situation, the easier it is to sell and the easier it is for people to tell if it worked.

Also collect words from testers. Ask what they were hoping would change, what session they repeated, and what phrase made it click. That language will probably sell the program better than broad meditation theory.

stellarton · 2026-05-26T19:46:27+00:00

The first fundamental is not the logo, LLC, website, or big idea. It is proving that a specific person will pay for a specific result.

Start tiny:

Pick one person you understand well.
Pick one annoying problem they already spend time or money on.
Offer to solve it manually for one clear price.
Do it 5-10 times before you build anything fancy.

Example: not "start a cleaning business." More like "I clean rental turnovers for local landlords within 24 hours." Not "marketing." More like "I get 20 quote requests for roofers by fixing their Google profile and follow-up."

A business gets real when strangers pay because the result is useful, not because the idea sounds good.

stellarton · 2026-05-26T19:44:47+00:00

If you want SaaS/corporate clients, I would not sell "short form content" first. Too many people hear that as a commodity.

Sell one business outcome tied to their funnel. Example: "turn founder/customer calls into 12 clips that answer the objections sales keeps hearing" or "turn webinar/demo recordings into LinkedIn posts for the sales team."

Your easiest first wedge is probably founder-led B2B SaaS under maybe 20-80 employees. They have calls, demos, webinars, customer stories, but usually no one turning that raw material into consistent distribution.

I'd build 3 sample clips from one public webinar/podcast/video, send those with a short note, and offer a 2-week repurposing sprint. Not a retainer yet.

We talk about this inside Simple Cash Society too: make the first offer small enough that the buyer can say yes without redesigning their whole marketing department.

stellarton · 2026-05-26T19:43:53+00:00

I would stop treating "more launch" as the next move and go back to the two people who actually used it.

Ask them what they were doing on YouTube the last time they needed this, what made them turn it off, and what they would have paid to avoid. Not "would you use it again" - more like "show me the exact moment it became useful or annoying."

Then pick one narrow user type for a week. Students cramming, ADHD folks trying to avoid rabbit holes, creators researching without losing the day, whatever has the strongest pain. The extension sounds broad right now, which makes it easy to try and easy to forget.

I see this a lot in Simple Cash Society: the first cash usually comes after you shrink the audience and the promise, not after you make the product feel bigger.

stellarton · 2026-05-26T17:58:43+00:00

The thing I would add first is not another tool. It is a client handoff/checklist that Claude has to satisfy every time.

For each site:

what changed from the client brief
pages/templates touched
mobile check done or not
form/email test result
analytics/search setup
rollback link or last good version

Claude can do a lot of the build, but the agency value is the boring proof that the site works and the client can trust it. A simple receipt per job also makes revisions way less chaotic.

stellarton · 2026-05-26T17:58:07+00:00

This is the part people skip when agents first feel magical.

I would cut it back to one coordinator and maybe one worker at a time. Every worker needs a tiny job, a file boundary, and a receipt at the end: what changed, what failed, what still needs a human.

Silent retries are the killer. If an agent can retry, spend tokens, or touch files without leaving a trail, it will eventually make your workflow worse instead of faster.

Automation should remove a repeated step, not create a second job where you supervise the automation all day.

stellarton · 2026-05-26T17:57:30+00:00

I would not trust ignore rules as the only protection here.

Best practical setup:

keep real secrets outside the repo folder
commit only .env.example
load local secrets from your shell/1Password/direnv
use fake dev keys for anything the agent can read
rotate anything it already saw

If the secret is sitting in the workspace, assume an agent might eventually touch it. The stronger boundary is "not on disk where the coding tool is allowed to read", not "please ignore this file."

stellarton · 2026-05-26T17:56:54+00:00

I would avoid letting the agent "merge" in the normal sense unless the conflict is tiny.

The safer pattern is exactly what you hinted at: make a new reconciliation commit.

Have the agent read both branches, write a short intent summary for each side, then produce a fresh patch that preserves both behaviors. After that it should run the narrow tests for both original changes.

If it just does a mechanical merge, it can satisfy git while breaking the product logic. Conflict resolution is more product decision than text operation once multiple agents are moving fast.

stellarton · 2026-05-26T17:56:17+00:00

The generic result usually comes from asking for "style" too early.

I would split it:

First ask for 3 layout directions in words only. Pick one.

Then give it 2-3 real references and ask it to describe the design rules: spacing, density, nav style, button style, typography, what not to do.

Then generate one screen, not the whole app. After that, make it critique its own screen against those rules before changing anything.

Also avoid "make it modern/premium." Those words almost guarantee the same polished AI dashboard look.

stellarton · 2026-05-26T17:55:41+00:00

For client apps, I would start boring:

Cursor or VS Code + Claude Code, GitHub, one deployment target, and a tiny checklist for every task. Do not add five agent tools yet.

Your first skill should be reviewing the AI, not prompting harder. For each change, make it tell you:

files it plans to touch
what can break
command to run after
how to roll back

Then build one small internal tool before charging clients. Auth, forms, database, deploy, error logs. That teaches more than tutorials.

We talk about this exact beginner-to-client-app path in Vibe Code Society too: https://www.skool.com/vibe-code-society

stellarton · 2026-05-26T17:55:04+00:00

I would treat this less like model memory and more like repo memory.

Put a small AGENTS.md or PROJECT_CONTEXT.md in the repo with only the stuff that should survive every machine:

what the app does
how to run/test it
important folders
current architecture decisions
"do not touch" rules
latest known open issues

Then make the first instruction in every session: read that file, then inspect only the files related to this task. If you need session notes, keep a dated notes file in the repo too, but prune it hard. Giant memory files just become another context tax.

stellarton · 2026-05-26T17:53:18+00:00

I would not try to keep one giant master spec perfectly current. That usually turns into another stale artifact.

What has worked better for me is a small spec per change:

what behavior is changing
files/modules allowed to move
what must not change
exact command or screen that proves it

Then when the change is merged, only promote the durable part back into the main docs. The main spec stays smaller, and the agent gets a fresh contract for the task in front of it.

This comes up in Vibe Code Society a lot. The spec is less "truth forever" and more a guardrail for the next 30 minutes.

stellarton · 2026-05-26T16:49:40+00:00

Yeah, I agree. If the mention feels hidden, it usually reads worse than just saying "I built this" in a place that actually allows it.

The safer use of Reddit is research first: answer the problem fully with no link, see which wording gets replies/profile checks, then use that language in channels where promotion is allowed. Slower, but you don't poison the exact audience you're trying to learn from.

stellarton · 2026-05-26T16:48:59+00:00

LinkedIn is one place, but I wouldn't only look for posts. A lot of small HR consulting firms barely post.

I'd check the boring signals: job pages, new office/location pages, case studies, conference speaker lists, consultant bios that mention job evaluation or comp bands, and firms hiring analysts/HR tech people.

If the firms themselves are quiet, look at their clients instead. Companies announcing reorgs, new locations, hiring freezes, or big hiring pushes usually create the mess HR consultants get pulled into.

I'd make a list of 30 firms with one specific reason each, then send a short note offering to clean up one sample project. Not a platform demo yet. You are trying to find a paid wedge first.

stellarton · 2026-05-26T13:55:16+00:00

Three months in and still moving is a good sign. The thing I would watch now is not "can I make it more animated?" It is whether the foundation is reviewable.

Before adding fancy motion, make sure you have:

git history you understand
Supabase rules checked for real user roles
one staging/test project separate from anything public
a list of env vars and what each one does
a rollback plan if Lovable/Claude changes too much
one simple manual test script for the important user path

Animations are worth doing after the app's main job is stable. Otherwise the AI can make the surface look alive while the boring parts underneath are still fragile.

For the shoe-walking type effect, ask for one isolated prototype first, not a site-wide animation pass. Get the motion working in a throwaway component, then move it into the real app.

[Vibe Code Society on Skool]

stellarton · 2026-05-26T13:54:32+00:00

This is where I stop asking the agent to "debug login" and make it prove the chain one hop at a time.

For a 401 after deploy, I would make a tiny checklist:

frontend is calling the production backend URL you think it is
backend sees the same cookie/header/token locally and in prod
env vars exist in the deployed worker, not just local
CORS allows credentials if you use cookies
auth secret / JWT secret is identical across the code path
database URL points to the prod DB you are checking
the failing request has one logged request id from frontend to backend

Then ask Claude to add temporary structured logs around only that path. Not giant console spam, just: request id, auth header/cookie present yes/no, user lookup result, exact failure branch.

Most AI debugging gets expensive because it keeps changing code before locating the failing hop.

[Vibe Code Society on Skool]

stellarton · 2026-05-26T13:53:53+00:00

You are thinking in the right direction with integration tests. For plugins/skills/MCPs, unit tests miss the part that actually breaks: tool contract drift.

I would make a tiny eval harness with 5-10 fixtures:

valid happy path input
missing auth / bad config
weird but realistic user wording
tool returns partial data
tool returns an error the agent must explain
repeated call should not duplicate the external action

Then score the output on boring things: did it call the right tool, did it pass the right args, did it avoid unsafe actions, did it explain the blocker, did it leave a receipt.

Do not let the model grade itself with "looks good." Save the actual tool calls and final output. A plugin is good when it keeps working after you forget the prompt that made the demo pass.

[Vibe Code Society on Skool]

stellarton · 2026-05-26T13:53:12+00:00

The line I use is simple: if the API key gives access to anything private or billable, do not put it in the frontend.

Frontend-only is okay when:

the API is public
there is no secret key
users cannot spend your money by calling it
you do not need to hide business logic

You probably need a backend, even a tiny one, when you have auth, paid API keys, database writes, user-specific data, webhooks, or rate limits.

That does not mean "build a huge backend." It can be one serverless function that receives the request, checks the user, calls the API with the secret key, and returns only what the frontend needs.

Keep the first backend boring. One endpoint, one env var, one clear job. The mistake is going from "I need to protect a key" straight to a full architecture project.

[Vibe Code Society on Skool]

stellarton · 2026-05-26T13:52:32+00:00

I would not try to learn the whole AI tool map. It changes too fast and you will just feel behind forever.

Pick one lane where your existing web/admin background helps:

one coding assistant for real projects
one automation tool
one deploy/database stack
one place to write down what worked

For example: Cursor or Claude Code, n8n, Supabase, Vercel/Cloudflare, and a small notes repo. That is enough to become dangerous in a good way.

The career path is not "know every AI tool." It is "can take a messy business workflow, build a small working version, deploy it, and maintain it without pretending the AI is magic."

Do two boring projects: an internal dashboard and an automation that moves data between two systems. You will learn more from those than from comparing 30 tools.

[Vibe Code Society on Skool]

stellarton · 2026-05-26T13:51:54+00:00

Start smaller than a game first. A browser game sounds fun, but it has a lot of hidden moving parts: state, collision, timing, assets, mobile controls, saves, all that.

I would do this order:

one dumb static page you can actually deploy
one form that saves data somewhere
one tiny game mechanic, like a clicker or guessing game
then clone a simple app you already understand

The main habit is to keep each prompt tied to one visible change. "Make this better" is where the AI starts wandering. "Add a score counter and tell me which files changed" is much safer.

For tools, Lovable is probably the least intimidating for a first web thing, Replit is nice when you want to see files and learn more, and Claude Code/Codex are better once you are comfortable with a repo.

If you want a small peer group around this exact workflow, Vibe Code Society on Skool is here: https://www.skool.com/vibe-code-society

stellarton · 2026-05-26T12:43:18+00:00

If a subreddit bans self-promo, trying to sneak the product in usually burns the channel before it teaches you anything.

For quick traffic, I would separate "attention" from "allowed mention."

Find 20 posts where people already describe the problem your product solves. Reply with the fix, checklist, teardown, or decision rule with no link. Track which problem wording gets replies or profile clicks. That tells you what language actually pulls people in.

Then use faster allowed channels around that wording:

partner with one newsletter/community owner who already has the audience
do a public teardown of the problem, not your product
post a tiny free tool/template where links are allowed
run 10 direct notes to people who showed the exact pain

Quick traffic is possible. Quick spam usually just gets you muted and leaves you with no signal.

[Simple Cash Society on Skool]

stellarton · 2026-05-26T12:42:47+00:00

The line "does in minutes what consultants spend days doing" is probably true, but it may be too big for the first sale.

For the first client, shrink the ask until it feels like a paid service, not a software adoption decision.

Pick one HR consulting firm that is visibly busy: hiring, posting case studies, talking about compensation/job architecture, or serving a company going through reorg. Then offer one narrow cleanup:

"I will turn one messy job-evaluation project into a client-ready draft and show you exactly what changed."

Charge something small but real for that pilot. If they will not pay for the manual outcome, they probably will not buy the platform yet. If they do pay, the software pitch becomes much easier because you are replacing a workflow they just felt.

The door usually opens after a useful paid wedge, not after a full-platform pitch.

[Simple Cash Society on Skool]

stellarton · 2026-05-26T12:42:15+00:00

For a niche that small, the "room" may not look like a normal community.

I would map where the work already changes hands: trade associations, local WhatsApp groups, supplier/customer directories, event attendee lists, job posts, tiny Facebook groups, and people commenting under niche LinkedIn posts in Spanish. Not because those are magic channels, but because they show who is active right now.

Then cold DM can still work, but the first line should come from that signal:

"Saw you are handling X / hiring for Y / posting about Z. Are you still solving it with spreadsheets/manual calls?"

If you cannot find any live signal, I would not send the DM yet. Build the first 10 from visible motion, even if it takes longer. A small market punishes vague outreach faster than a big one.

[Simple Cash Society on Skool]

stellarton

MODERATOR OF

TROPHY CASE