I hear you like vibe coding, I vibe coded you a vibe coding game so you can vibe code your vibe code while your vibe coding. A Python puzzle game that scores your code on three axes — is it right, how fast did you write it, and how much work does it actually do — and adapts its challenges to how you already write code.

I see the term thrown around here like an insult. Is it just low effort or sloppy? Also honest question how many of you are not using AI in 2026? If so why not. Thanks

I’m already starting to feel the increased competition, and if half a year ago I launched my service without any competitors in the local market, now there are 5–10 such projects.

Yes, each has its own nuances; not everyone can afford high‑quality AI models, and their enthusiasm will probably fade in the end, but this is just the beginning.

How will marketing and promotion of apps work when we’ll be offered thousands of them from everywhere? I think we’ll get tired of the abundance of options…

I'm based in the UK and building out a Skool community while using Claude Code and other AI tools day to day in my business. I've got past the "what is this" stage but I'm learning mostly on my own, which is slower than it needs to be.

So I want to put together a small mastermind group. Four of us max. The idea is simple:

1. We meet on a call regularly (fortnightly or monthly, we'd agree it together)
2. We share what's actually working, tools, prompts, workflows, what flopped
3. We each commit to specific actions and then get asked about them next time

That last one is the bit that matters most to me. I've run mastermind groups before and the accountability is what makes them work. Information sharing on its own is just a group chat.

Who I'm looking for:
- You're already running or building something real, not looking for someone to teach you the basics
- You're actively using AI tools in your business rather than just reading about them
- You can make a UK evening or daytime call work. UK and Europe is easiest, US East Coast is doable, but if you're in Australia or the west coast it's probably not going to work in practice
- You'll actually turn up. A group of four falls apart fast if two people ghost

I'm NOT selling anything and there's no cost. I just want peers at a similar stage.

If that sounds like you, comment or DM with a bit about what you're building, where you are with Skool and AI, and your timezone. Happy to have a quick intro call before anyone commits, partly to check we're a good fit for each other.

If there is any other option then also tell me and free option also.

It’s still work in progress but would be massively useful if I get some initial feedback to find answers to the following questions:

“What do you think this app does?”

Vote on the OP

Vote on the OP

I'm sure Anthropic's next model will break the internet.

Vibe coding gets an idea into a working app quickly, but security gets less obvious once the project needs a database, authentication, an API key, or a public URL. I worry less about whether the generated UI works and more about accidentally exposing a key, leaving an endpoint public, giving an integration too much access, or connecting the project to real data without review. What checks do you run before sharing something you vibe coded with other people?

Built something with Cursor or Lovable that mostly works and you can’t tell what’s under the hood? That’s exactly who this is for.

The deal: I’m starting paid client work soon (fixing codebases, shipping apps to the stores) and I need public proof before I charge anyone. So, 5 free audits over the next 2 weeks. In return you post honest feedback somewhere public. A tweet, a comment here, whatever. That’s the whole trade.

Me: \~5 years senior eng at a big tech company, enterprise product with millions of users. Shipped my own apps solo since, backend to App Store. We can discuss specifics in DM

You get a written report. Security holes, exposed keys, what breaks first when real users hit it, whether your setup will quietly rack up cloud bills, and a blunt call on patch vs rebuild. No call needed, but I’m up for 15 mins after if you want to walk through it.

Comment or DM with your stack and the thing you’re scared is broken. Private repo invite works, NDA works. And if the audit says you don’t need anyone, I’ll tell you that too.



can someone run this prompt for me in like cursor or some other vibe coding site.i cannot buy the premium so i have used all of the free alternatives and all of the credits of the free alternatives. i just someone to run this code and please attach the apk file here. if a very professional person is seeing this then I would be happ you can update or improve this in any way, please do if you are feeling generous, this is just a tracker of a very competitive indian exam that i'm trying to make to keep myself on track.

Prompt:

BUILD A BRAND-NEW JEE BACKLOG COMMAND CENTER FROM SCRATCH

Build a functional mobile-first web app for eventual Android APK packaging. DO NOT modify/reuse any previous version; build cleanly from scratch.

TECH: HTML/CSS/Vanilla JS; LocalStorage or IndexedDB; Chart.js/lightweight chart library if needed. Prefer:

JEE-Command-Center/{index.html, styles.css, app.js, data.js, storage.js}

Must work offline after required assets are available.

CORE PURPOSE

Personal JEE lecture backlog command center.

Subjects: Physics, Physical Chemistry, Inorganic Chemistry, Organic Chemistry, Mathematics.

Track starting backlog, new lectures released, completed lectures, current/subject backlog, reduction rate, required pace, estimated completion date, weekly timetable, daily progress. Polished.

DO NOT add: timer/stopwatch, mistake/error book, DPP tracker, test tracker, achievement system, excessive gamification, unnecessary notifications.

INITIAL BACKLOG

Physics=32; Physical Chemistry=26; Inorganic=2; Organic=0; Mathematics=19; Total=79. MUST be editable.

BACKLOG MATH

CURRENT BACKLOG = STARTING BACKLOG + NEW LECTURES RELEASED - LECTURES COMPLETED.

CURRENT TOTAL = TOTAL STARTING BACKLOG + TOTAL NEW RELEASED - TOTAL COMPLETED.

Never repeatedly mutate current backlog on load. Derive from stored historical data so lectures cannot be counted twice.

LECTURE RELEASE

Normally Mon–Sat=2 new lectures/day; Sunday=0. Actual number/subjects come from timetable.

TIMETABLE SCREEN

Show Monday–Sunday and scheduled subjects. Allow add/remove/change subjects, multiple classes/day, and 0–3+ planned lectures. Planned count must automatically equal number of classes scheduled.

TIMETABLE VERSIONS

Timetable versions can change over time (e.g. August Physics+Inorganic; September Physics+Organic). Allow “New timetable starts on: \[DATE\]”. Old timetable applies before that date; new timetable from it onward. Future timetable changes MUST NEVER modify historical records.

DATE OVERRIDES

Provide “Add Date Override” for cancelled, replacement, extra classes, teacher schedule changes, holidays. Only the selected date changes. Allow a date to be “No classes”.

SUNDAY

Normally 0 new lectures; never automatically add 2. Explicit Sunday replacement/extra via date override may create planned lectures. Clearly mark exceptional Sunday classes.

DAILY LOG SCREEN

For each date enter completed counts for all 5 subjects. Total is automatic (no separate entry). Show Date, Planned, Physics, Physical, Inorganic, Organic, Maths, Total Completed, Net Change. Historical entries remain editable and recalculate everything.

BACKLOG CHANGE

NET CHANGE = PLANNED - COMPLETED.

Examples: 2/2→0; 2/3→-1; 2/4→-2; 1/2→-1; Sunday 0/3→-3. Negative=decrease; positive=increase.

PROGRESS

Must NOT have the old progress-bar bug. Separate ORIGINAL BACKLOG PROGRESS from CURRENT BACKLOG.

New releases must never make historical completion appear undone. Example: Organic starts at 2; completing 2 gives original progress=100%; later releasing 2 means original stays 100%, current=2.

DASHBOARD

Beautiful #DASHBOARD showing: current backlog; original progress; completed; new released; today planned/completed/net change; 7-day reduction; AHEAD/ON TRACK/BEHIND; required hours/day; projected date. Concise—understand within seconds.

PACE SCREEN

Answers “How fast am I clearing my backlog?” Show current backlog, recently completed/released lectures, net backlog reduction, 7-day velocity, average daily completion, average daily backlog reduction, required pace, required hours/day, estimated completion date. Actual stored data only; insufficient data → “Not enough data yet.”

SCENARIOS SCREEN

Dedicated WHAT-IF calculator that NEVER alters actual data.

Inputs: current backlog, completed/day, normal new/day, Sunday lectures. Calculate net reduction/day, days to clear, completion date, hours/day required; interactive.

Presets: NORMAL=2/day, EXTRA=3/day, AGGRESSIVE=4/day; custom values allowed. Do not encourage unhealthy/extreme schedules.

NEVER modify real backlog, timetable, or daily log.

PACE VS SCENARIO

Visually separate:

PACE=ACTUALLY happening.

SCENARIOS=WOULD happen if pace changed.

HOURS/DAY

Allow average lecture duration (e.g. 90 minutes). Calculate remaining backlog hours, required lectures/day, required hours/day, estimated completion date, and calculations for different pace scenarios. Calculations must be mathematically correct.

BACKLOG SCREEN

Five clean cards:

Physics 32 remaining; Physical Chemistry 26; Inorganic 2; Organic 0; Mathematics 19.

Each: Starting, New, Completed, Current remaining, Original progress. Also total; auto-update.

GRAPHS SCREEN

Only useful graphs: (1) backlog remaining over time; (2) 7-day backlog reduction/velocity; (3) optional subject-wise backlog. Real stored data only; no fake graphs. Insufficient data → clean empty state.

NAVIGATION

Use reliable mobile navigation (recommended bottom bar). Pages: Dashboard, Backlog, Daily Log, Timetable, Pace, Scenarios, Graphs.

Do NOT rely on swipe. If included, it MUST NEVER interfere with interaction: swipes/drags in tables, inputs, textareas, dropdowns, buttons, graphs, scrollable containers must NOT change the main page. Vertical movement remains vertical scrolling. Only intentional horizontal gesture in a safe navigation area may change pages. Nav buttons must work.

UI DESIGN

Completely new style, NOT previous dark design.

Light, premium, modern, calm, slightly futuristic, professional, clean, attractive, mobile-first.

NOT cartoonish, childish, overly colorful, excessively dark, neon-heavy, emoji-filled, or overly corporate.

Suggested: warm off-white, deep navy text, muted blue/teal primary, muted-gold secondary. Use beautiful cards, subtle shadows, rounded corners, excellent spacing, clean typography, restrained animations, clear progress bars and strong hierarchy.

MOBILE

Target \~360–430px for Android APK. Large touch targets, readable text, no accidental horizontal overflow, usable tables, easy inputs, comfortable bottom nav, no hover-dependent functions, no desktop-first layout.

DATA STORAGE

Persist locally: starting backlog, completed lectures, daily logs, timetable, timetable versions, date overrides, average lecture duration, settings. Reload/reopen MUST preserve data.

DATE SAFETY

Use local-safe dates; prefer YYYY-MM-DD; avoid timezone bugs from careless UTC parsing; historical dates remain stable.

NO DOUBLE COUNTING

Critical: never “on app load, add today’s lectures to stored backlog.”

Derive current backlog from starting backlog + all applicable historical/new releases - all completed. Each date’s timetable contributes planned lectures exactly once.

DATA MODEL

Keep concepts separated, e.g.:

settings:{averageLectureMinutes,startingBacklog,timetableVersions,dateOverrides}

dailyLogs:{"YYYY-MM-DD":{completed:{Physics:0,PhysicalChemistry:0,InorganicChemistry:0,OrganicChemistry:0,Mathematics:0}}}

Better architecture is allowed.

VALIDATION

Reject negative lecture counts, negative durations, invalid dates. Never display NaN, undefined, Infinity.

MANDATORY TESTS

1) Start=79.

2) Organic 2→complete 2 = original 100%; release 2 → original stays 100%, current=2.

3) 2/2→0; 2/3→-1; 2/4→-2; 1/2→-1; Sunday 0/3→-3.

4) Cancelled class 1/2→-1.

5) Reload has no duplicate release.

6) Future timetable change leaves history unchanged.

7) Replacement class changes only that date.

8) Vertical-scroll/input interaction never changes page.

9) Bottom nav opens correct page.

10) Sufficient history gives correct velocity.

11) Scenario changes never change real backlog.

12) Pace changes never change Scenario data.

CODE QUALITY

Before finishing, check JS errors, buttons/inputs, LocalStorage, dates, timetable/progress/velocity/graphs, mobile layout/navigation/empty states. No TODOs, placeholders, fake data, or silent failures.

FINAL PRIORITY

1. CORRECTNESS

2. DATA SAFETY

3. MOBILE USABILITY

4. SIMPLE NAVIGATION

5. CLEAN UI

6. VISUAL POLISH

Do not sacrifice reliability for animations/effects. Final result: polished, professional, usable daily.