Hey everyone!

Hope all is well.

TL;DR Below

Context:

One of the projects I've been working on is a Windows AI workspace called Core48aii.

The idea came from a problem I kept running into while using ChatGPT, Claude, Gemini, and other AI tools for larger projects. Once conversations became long, important instructions were buried, useful outputs disappeared into old chats, and I found myself rebuilding the same context over and over.

So I built a project workspace that lets me organize prompts, reusable instructions, research, source material, workflows, and useful AI outputs in one place instead of relying on dozens of chat threads.

It's at the point where I am opening the project up to early testers, and I wanted to see if I could actually get qualified people to visit the tester page before spending more time on marketing or landing page copy.

Rather than guessing, I decided to run a small experiment.

I spent $20 on a Meta traffic campaign to see what would happen.

I wasn't expecting statistically significant results from twenty dollars. I simply wanted to learn where the biggest bottleneck in my funnel might be before investing more time and money.

The question for this experiment was:

Can I acquire qualified traffic cheaply enough that improving the landing page is worth the effort?

Rather than guessing, I spent $20 on a Meta traffic campaign.

TL;DR: I spent $20 running a Meta traffic campaign for my Windows AI workspace to see whether my biggest problem was getting visitors or converting them. The campaign generated 83 landing page visits at just $0.24 per visitor, but resulted in 0 downloads and 0 interest form submissions, even after changing the CTA halfway through the experiment. While disappointing, it helped isolate the bottleneck: acquiring traffic doesn't currently appear to be the biggest challenge; converting visitors is. My next step is to improve the landing page and messaging, then rerun the exact same campaign to see if the conversion rate changes.

Campaign Setup

Objective: Traffic
Budget: $5/day
Audience:

• United States
• Men & women 18+
• Interests around AI software, Windows software, productivity software, Microsoft Windows, and related topics

Creative:
A carousel introducing the problem of managing long-term AI projects and showing the application and how it helps.

Mid-Experiment Change

After about 40 landing page visits, I still hadn't seen a single conversion. At that point I started wondering if the CTA itself was introducing unnecessary friction.

Version 1

The original CTA was: "Start Your 90-Day Free Trial"

Clicking it took visitors to a Lemon Squeezy checkout page because the app currently uses license keys for activation.

Although the founder trial is completely free, I realized something that might have been hurting conversions.

The Lemon Squeezy checkout displays the full founder package price at the top of the page, and only shows the 100% discount ($0.00) near the bottom during checkout.

My concern was that some visitors might see the price, assume it wasn't actually free, and leave before ever seeing the discount.

I don't know if that was happening, but it seemed like a reasonable hypothesis to test.

Version 2

Around 40 landing page visits (halfway through), I removed the free trial CTA completely.

Instead, the page simply invited visitors to: "Apply to be an Early Tester"

The primary button became: "I'm Interested in testing Core48aii"

Instead of asking visitors to start a trial or download anything, now they only needed to fill out a short form.

My thinking was that removing the checkout entirely would reduce friction and let me personally onboard anyone who was interested.

Unfortunately, it didn't change the outcome.

Final Results

• $20.01 spent
• 2,535 impressions
• 2,185 people reached
• 83 landing page visits
• $0.24 per landing page visitor
• 0 downloads
• 0 interest forms submitted

Changing the CTA made no measurable difference.

My Takeaway

At first, seeing 0 conversions made this experiment feel like a failure.

After thinking about it more, I think it answered one of the biggest questions I had before opening Core48aii up to testers.

To me, it looks like the ad did what I was hoping it would do.
People stopped scrolling, clicked, and took the time to visit the landing page.
That suggests acquiring visitors may not be my biggest challenge.

It also tells me it's probably not time to start adding more features. If people aren't taking the first step, adding more functionality isn't likely to solve that problem.

At 24 cents per landing page visitor, buying traffic appears affordable enough that I can continue using it to test future versions of the landing page.

The bigger issue is what happens after people arrive.

Not one visitor downloaded the app, and changing the CTA to a simple interest form didn't produce any submissions either (in this short test).

That makes me think the next bottleneck is almost certainly somewhere on the landing page itself.

It could be:

• The messaging
• The positioning
• Building enough trust
• Explaining better what the product actually does
• Showing the value quickly enough
• Targeting the wrong audience
• Or some combination of those

I obviously can't say for certain which one it is from a $20 experiment.

But I can say that I no longer think, "Can I buy reasonably priced traffic?" is the biggest unknown.

The next experiment is much clearer: Improve the landing page, then run the same campaign again and see whether the conversion rate changes.

Why I'm actually happy I ran this

If visitors had cost me $2 each, I'd have two problems:

• expensive acquisition
• poor conversion

Instead I have one.
The experiment narrowed my focus.

What I'm doing next

I'm going to pause paid ads.

Before spending another dollar, I'm going to improve the testers landing page:

• clearer positioning
• stronger explanation of the product and the pain it solves
• more trust signals
• better communication of who it's for
• probably a product walkthrough video

Then I'll rerun essentially the same campaign and compare conversion rates.

I'd really appreciate some outside eyes.

If you landed on this page:

• What would make you leave?
• What information would you need before signing up?
• Would you immediately understand what the product does?
• Would you trust downloading a Windows desktop application from an unknown founder?

Any feedback is much appreciated.

I'm sharing this because I think unsuccessful experiments can be just as valuable as successful ones. This one didn't get me a single signup, but it gave me a much clearer idea of what I should improve next.

Thanks for reading!

Hey everyone,

Hope all is well!

TL;DR below.

A few days ago I posted about Day 1 of one of my side projects, ShuffleBall Arena (it's a free browser game combining shuffleboard scoring with the craziness of other games like bumper pool, pinball, and Frogger).

Full disclosure again: Yes, all 3 of my projects I may talk about were made with the help of AI. I know some people get weird about that, but frankly, I’m trying to use every tool available to help in every way possible.

Anyway, I'm trying to find the time to post somewhat consistently. I figured I'd post about days 1 to 14 of this project and hopefully try to add some value.

To try to speed up the catch up, I'm using a structured prompt to go back to my GPT sessions and extract the useful information. Hopefully the prompt can help anyone out there trying to keep track of, or extract value from, your past AI project conversations.

That said, posting an update for Day 4 of ShuffleBall Arena. Here's how that day went...

TL;DR: Day 4 was about getting ShuffleBall Arena ready to actually show people. I cleaned up a failed demo/broadcast idea and rebuilt it in a safer way, renamed the game from Galaxy Ball to ShuffleBall Arena / ShuffleBall, got the web version closer to being phone-ready, and fixed a confusing issue where the browser kept showing old text even after the update worked. Biggest lesson: not every build day is about adding flashy features. Sometimes the real progress is making the game clearer, safer, and ready for real people to try.

Summary and full technical breakdown below:

===========================================================

Day 4 Summary: There were three conversations to go through today with 2 file versions saved over 4 hours of building.

So Day 3 ended with a lesson: I tried to add a broadcast-style layout so the game could scale nicely for clips, demos, and livestream-style presentation, but my efforts broke the mobile layout. Buttons became hard to use, the screen scaling got messy, and the core mobile experience was at risk.

So I deleted the experiment and rolled back.

Part 1 of Day 4 was me coming back to that same idea, but with much stricter rules.

The new rule was simple:

Broadcast mode can change how the game is presented.
Broadcast mode cannot change the actual game.

No physics changes.
No scoring changes.
No bot behavior changes.
No mobile control changes.
No normal gameplay changes.

The goal wasn't to build real livestreaming or full multiplayer. It was to create a self-running presentation layer that could be used for testing, OBS, landing page footage, and short clips. Basically an arcade “attract mode” or featured match view.

Part 2 of Day 4 was renaming the app. Google search results made “Galaxy Ball” look like a problem, and there were potential trademark / legal issues. Coming up with a new name became a bit of a time sink. The final decision accepted that ShuffleBall may not be perfectly unique, but it was clear, descriptive, and paired well with ShuffleBall Arena as a broader brand.

This session I purchased shuffleballarena.com from Squarespace.

=========================================================

Full Technical Breakdown:

TECHNICAL ANALYSIS & DEBRIEF: DAY 4

STARTING POINT

Day 4 started with a working browser game that was close to being shareable, but still not launch-ready as a public product.

The project still had three unresolved launch problems:

1. The broadcast/demo layer existed, but its public framing was wrong. The game could already run in a self-playing broadcast/demo mode through ?broadcast=1, but the copy still exposed the internal implementation. It used labels like BOT SHOWCASE MATCH and BOT VS BOT, which made the feature feel like a dev test instead of a public-facing “featured match” presentation layer. The session explicitly framed the current automatic bot match as useful for “testing, OBS, landing page capture, and social clips,” but not something that should be presented as the product identity.
2. The app was still under the old Galaxy Ball identity. The files still referenced Galaxy Ball as the public name, even though search results made that name feel unsafe or too occupied. The session eventually moved toward a new split: ShuffleBall Arena as the app/domain and ShuffleBall as the game title.
3. The deployment path was not fully hardened. The goal was to make the game playable from a phone through the web, without needing an app store. That meant getting the deploy folder ready for Cloudflare Pages, keeping strict security headers, making the service worker safe, and proving that the game worked outside local testing.

SESSION OBJECTIVE

The session objective was to get the project closer to a real public launch without overbuilding.

The specific goals were:

1. Make the broadcast/demo mode look like a public featured-match view, not a bot-vs-bot dev tool.
2. Prepare the Cloudflare Pages deploy folder correctly.
3. Keep strict Content Security Policy instead of weakening security.
4. Decide whether Galaxy Ball needed to be renamed.
5. Rename the app safely after choosing the new brand.
6. Deploy and verify the renamed game.
7. Decide whether backend work should begin immediately or after domain setup.

The higher-level product goal was simple: make ShuffleBall Arena something someone could open on a phone, play, and understand.

WHAT WE ACTUALLY DID

1. Reframed broadcast mode as a presentation layer

The first meaningful decision was product framing.

The broadcast mode was not treated as real livestreaming, real multiplayer, or real player replays. It was defined as a self-running presentation layer that could be useful for OBS, landing page footage, social clips, and demo testing.

The chosen framing was:

Galaxy Ball = playable mobile marble/space game.
Galaxy Ball Live = featured match / replay / broadcast presentation layer.
Auto-demo bots = temporary content source for broadcast.

The important part was that the automated bots could stay, but the public UI should not call the feature “bot vs bot.”

2. Wrote a narrow Cursor prompt for broadcast copy cleanup

The first concrete patch prompt was Phase J4I: Broadcast Source Naming Cleanup.

The prompt told Cursor to patch only broadcast-facing naming and explicitly protect the rest of the game.

The core technical instruction was:

Add lightweight broadcast source structure in initBroadcastSettings(), such as:
 source: "autoDemo",
 sourceLabel: "FEATURED MATCH"

The prompt also required:

"BOT SHOWCASE MATCH" should become "FEATURED MATCH"
broadcast mode label should not display "BOT VS BOT" in header/footer presentation

And it explicitly said not to change:

gameplay
bot AI
physics
scoring
broadcast sizing
footer/ad architecture
asset loading
image cards
normal mode

This was a good example of a safe AI coding prompt: narrow goal, clear non-goals, and a verification checklist.

3. Cursor completed the broadcast naming cleanup

Cursor reported that only game.js changed.

The changes were:

initBroadcastSettings()
  Added:
  source: "autoDemo"
  sourceLabel: "FEATURED MATCH"

getBroadcastCardContext()
  Added:
  source: BROADCAST.source || "autoDemo"
  sourceLabel: BROADCAST.sourceLabel || "FEATURED MATCH"

BROADCAST_CARD_CONFIG
  Footer textBanner card title:
  "BOT SHOWCASE MATCH" → "FEATURED MATCH"

drawBroadcastHeaderLiveMatchCard
  Right pill fallback:
  bc.modeLabel → bc.sourceLabel

  Subtitle:
  "RED BOT VS BLUE BOT" → broadcastUpper(bc.sourceLabel)

drawBroadcastHeaderLayoutFeatureCard
  Layout label fallback:
  bc.modeLabel → bc.sourceLabel

drawBroadcastHeaderSponsorTextCard
  Right pill fallback:
  bc.modeLabel → bc.sourceLabel

The key constraint held: game.mode = "broadcast" and all automated bot behavior stayed unchanged. The patch was presentation-only.

4. Decided to use Cloudflare Pages for public phone testing

The next goal was practical: make the game accessible to someone else on a phone, outside local Wi-Fi.

The deployment target was Cloudflare Pages. You already used Cloudflare for other projects, so the session moved toward preparing a deploy folder and uploading it to the existing Cloudflare account.

The important decision: strict CSP would not be postponed. You rejected the idea of weakening CSP temporarily and wanted to build the deploy folder correctly the first time.

5. Made the deploy folder CSP-safe

The app originally had inline CSS and inline service worker registration, which conflicted with a strict policy like:

script-src 'self';
style-src 'self';

Cursor completed a CSP-safe refactor:

Created styles.css
Moved the full inline <style> block from index.html into styles.css.

Created app-shell.js
Moved service worker registration into app-shell.js.

Updated index.html
Removed inline <style>.
Added <link rel="stylesheet" href="styles.css">.
Removed inline service worker <script>.
Added <script src="app-shell.js"></script> after game.js.

Updated service-worker.js
ASSETS now lists:
/
index.html
styles.css
game.js
app-shell.js
manifest.webmanifest

The strict _headers policy stayed intact. No CSP weakening was required. Verification passed with node --check for game.js, app-shell.js, and service-worker.js, and both normal mode and broadcast mode loaded locally.

6. Investigated whether Galaxy Ball was a safe name

After deployment preparation, the session shifted into the naming risk.

Google search results made “Galaxy Ball” look like a problem. The conversation explored alternatives including:

Slot & Sphere
Tiltshot
Cluster Roll
NovaPocket
OrbitPocket
PocketNova
Marble Drift
Pocket Roll
Roll Arena
Rift Roll
ShuffleBall

Several names were rejected because they had search or meaning problems:

Galaxy Ball: likely unsafe or too occupied.
Tiltshot: already reads as a cinematography term.
Slot & Sphere: noisy because of casino slots and Sphere results.
Cluster Roll: conflicts with bakery/food search results.

A key product constraint emerged: the name should not lock the game into a space theme, because future themes could include different styles.

7. Chose the brand structure: ShuffleBall Arena / ShuffleBall

The session eventually settled on:

App/domain: ShuffleBall Arena
Game title: ShuffleBall
Main domain: shuffleballarena.com

You bought ShuffleBallArena.com and asked for a deep audit of the files before changing the name safely. The important naming distinction was:

ShuffleBall Arena = app/domain/container brand
ShuffleBall = game title

There was a brief intermediate state where the title used “Shuffle Ball” with a space, but the session corrected that to one word: ShuffleBall.

8. Renamed the app in the deploy files

Cursor completed the first rename pass:

index.html
  Apple web app title → ShuffleBall Arena
  document title → ShuffleBall Arena — Shuffle Ball

manifest.webmanifest
  name → ShuffleBall Arena
  short_name → ShuffleBall

service-worker.js
  Cache → shuffleball-arena-v2
  activate deletes all caches except the current one

game.js
  Added brand constants:
  APP_NAME
  GAME_NAME
  GAME_NAME_UPPER
  APP_SLUG
  LOG_TAG

  Updated:
  file comment
  broadcast comment
  footer card eyebrow
  live header text
  debug logs
  replay filename

  AUDIO_STORAGE_KEY → shuffleBallArenaAudio
  legacy migration from galaxyBallAudio

Then the one-word correction was made:

game.js
  GAME_NAME is now "ShuffleBall"
  Uppercase broadcast text becomes SHUFFLEBALL

index.html
  Document title is now ShuffleBall Arena — ShuffleBall

manifest.webmanifest
  Unchanged, already ShuffleBall Arena / ShuffleBall

9. Debugged stale broadcast text after deployment

After deployment, broadcast mode still appeared to show stale text.

The likely culprit was browser or service worker cache, not the Cloudflare site-level cache.

The fix was:

Open DevTools.
Go to Application.
Click Service Workers.
Click Unregister.
Go to Storage.
Click Clear site data.
Close DevTools.
Reload with Ctrl + Shift + R.
Test
Expected: SHUFFLEBALL LIVE.

You confirmed the fix worked. That proved the rename patch and deployment were good, and the remaining issue was stale local cache state.

10. Ended with the domain and backend plan

At the end of the session, the app was renamed and working on Cloudflare Pages, but the final domain was not yet attached.

The next plan was split into two tracks.

Track A: domain setup first.

Add shuffleballarena.com to Cloudflare Domains.
Change nameservers at Squarespace to the two Cloudflare nameservers.
Wait for Cloudflare to mark the domain active.
Go to Workers & Pages → galaxy-ball → Custom domains.
Add:
shuffleballarena.com
www.shuffleballarena.com

Test

Track B: backend setup after the domain is active.

The recommended backend was intentionally small:

POST /api/waitlist
POST /api/feedback
GET  /api/health

The planned D1 database:

shuffleball_arena_prod

The planned tables:

waitlist_signups
feedback_reports
game_events

The session explicitly rejected starting with real-time multiplayer because it would introduce matchmaking, state synchronization, cheating concerns, reconnects, and server authority before the launch funnel was even proven.

ROADBLOCKS AND FRICTION

1. The broadcast feature needed context

The session began with broadcast mode already in the code, but the reader would not automatically understand it. The day’s work only makes sense if broadcast is explained as:

A self-running presentation/demo mode for OBS, landing page footage, social clips, and public testing.

Without that explanation, “broadcast cleanup” sounds like a feature appearing out of nowhere.

2. The assistant moved too fast during deployment setup

The Cloudflare section created friction because too many steps were compressed together. You explicitly asked to slow down and give detailed instructions before touching Cloudflare.

The lesson: deployment tasks need different pacing than code edits. A missed click or wrong file shape can break the public app.

3. Strict CSP could have been postponed, but you chose not to

There was a real trade-off between quick deployment and correct deployment.

The faster path would have been to relax CSP temporarily. The chosen path was to keep strict CSP and refactor the app structure so all scripts and styles were local external files.

That took extra work, but it prevented “temporary insecure setup” from becoming permanent.

4. Naming became a major time sink

The name search created a loop because each candidate had a different problem:

Galaxy Ball: too occupied.
Tiltshot: wrong existing meaning.
Slot & Sphere: casino/search noise.
Cluster Roll: food/search conflict.
ShuffleBall: descriptive but close to shuffleboard terms.

The final decision accepted that ShuffleBall may not be perfectly unique, but it was clear, descriptive, and paired well with ShuffleBall Arena as a broader container brand.

5. Cache made a successful patch look broken

The stale SHUFFLE BALL LIVE issue looked like a failed code patch or a failed Cloudflare deployment. It was actually a browser/service-worker cache problem.

This was the most important technical debugging loop of the day.

DECISIONS MADE & TRADE-OFFS

Decision 1: Broadcast mode stays, but the bot language goes away

Chosen direction:

Keep auto-demo bot behavior.
Remove bot-facing public labels.
Use FEATURED MATCH as the public label.

Why:

The self-running match is useful for demos and clips, but “bot vs bot” makes the game feel unfinished.

Trade-off:

The session accepted that the broadcast layer is not real player streaming yet. It is a presentation layer powered by automation.

Decision 2: Strict CSP now, not later

Chosen direction:

Keep strict _headers.
Move inline CSS into styles.css.
Move inline service worker registration into app-shell.js.

Why:

You wanted to avoid building a temporary version that would need to be fixed later.

Trade-off:

The deploy folder required more cleanup before launch, but the security posture was cleaner.

Decision 3: Rename before public launch

Chosen direction:

Old public name: Galaxy Ball
New app/domain: ShuffleBall Arena
New game title: ShuffleBall

Why:

Galaxy Ball looked unsafe or too occupied based on search results. ShuffleBall was clearer and more aligned with the mechanics.

Trade-off:

ShuffleBall may have SEO noise from shuffleboard-related searches, but the app/domain wrapper ShuffleBall Arena gives it more brand identity.

Decision 4: Keep the old Cloudflare Pages project for now

Chosen direction:

Keep using the existing Cloudflare Pages project:
galaxy-ball

Why:

The Pages deployment path was already proven. The project name could remain internal while the public brand and custom domain changed.

Trade-off:

The internal Cloudflare project name still says galaxy-ball, but that does not have to be public-facing.

Decision 5: Domain before backend

Chosen direction:

Connect shuffleballarena.com first.
Build backend after the final public URL is active.

Why:

Forms, endpoints, analytics scripts, redirects, and future links should be built around the final domain.

Trade-off:

Backend work was delayed slightly, but the project avoided wiring infrastructure against a temporary URL.

Decision 6: No real-time multiplayer yet

Chosen direction:

Start with waitlist, feedback, and telemetry.
Defer multiplayer.

Why:

Real-time multiplayer would add complexity before the project had even proven public demand.

Trade-off:

The backend would not yet power live gameplay. It would power learning, signup, feedback, and future analytics.

BREAKTHROUGH / LESSON

The key realization from Day 4:

A feature can fail once, then come back safely if you rebuild it with stricter boundaries.

Broadcast mode was useful, but only when treated as a presentation layer. The safe rule was:

Broadcast can change how the game is shown.
Broadcast cannot change the core game.

That rule protected:

gameplay
physics
scoring
bot AI
mobile controls
normal mode

The second major lesson was technical:

A service worker can make a successful deployment look broken.

The fix was not to keep editing code. The fix was to unregister the service worker, clear site data, and hard reload before judging the deployment.

ARTIFACTS WORTH SHARING

Artifact 1: Broadcast cleanup prompt

Phase J4I — Broadcast Source Naming Cleanup
Use the attached current game.js and index.html only.
Goal:
Clean up broadcast-facing naming so Galaxy Ball Live looks like a featured/live match presentation layer, not a bot-vs-bot stream. Keep the automated bot behavior unchanged.
Requirements:
1. Add lightweight broadcast source structure in initBroadcastSettings(), such as:
 source: "autoDemo",
 sourceLabel: "FEATURED MATCH"
2. Update broadcast card context so renderers/cards can access:
 source
 sourceLabel
3. Replace default broadcast-facing bot language:
 - "BOT SHOWCASE MATCH" should become "FEATURED MATCH"
 - broadcast mode label should not display "BOT VS BOT" in header/footer presentation
4. Keep game.mode = "broadcast" and all automated bot behavior exactly as-is.
5. Do not change:
 - gameplay
 - bot AI
 - physics
 - scoring
 - broadcast sizing
 - footer/ad architecture
 - asset loading
 - image cards
 - normal mode
6. Keep footer as the future ad/sponsor area. Do not over-polish footer copy.
7. Verify:
 - index.html?broadcast=1 works
 - index.html?broadcast=1&sponsor=Core48aii works
 - header/footer card rotation still works
 - no missing asset loads while image cards are disabled
 - match auto-resets after match end
 - match number increments
 - normal mode still works
 - no console errors
After patching, run a syntax check and report exactly what changed.

Why it is worth sharing: it shows how to tell an AI coding tool to make a narrow public-facing cleanup while protecting the core game loop.

Artifact 2: CSP-safe deployment refactor

Created styles.css
Moved the full inline <style> block from index.html unchanged.

Created app-shell.js
Service worker registration moved here:
Registers /service-worker.js only when "serviceWorker" in navigator
Errors swallowed via .catch(() => {})

Updated index.html
Removed inline <style> block
Added <link rel="stylesheet" href="styles.css"> after the manifest link
Removed inline service worker <script> block
Added <script src="app-shell.js"></script> after game.js

Updated service-worker.js
ASSETS now lists exactly:
/, /index.html, /styles.css, /game.js, /app-shell.js, /manifest.webmanifest

Why it is worth sharing: it shows the difference between “disable CSP so the app works” and “make the app compatible with CSP.”

Artifact 3: Service worker cache debugging checklist

Press F12 to open DevTools.
Go to Application.
Click Service Workers on the left.
Click Unregister for the service worker.
Go to Storage on the left.
Click Clear site data.
Close DevTools.
Reload with Ctrl + Shift + R.

Then test

You want to see:
SHUFFLEBALL LIVE

Why it is worth sharing: it captures a common PWA/browser-game deployment trap. The code can be right, the deployment can be right, and the browser can still show old behavior because of the service worker.

FINAL STATE

By the end of Day 4:

The broadcast/demo mode was public-safe enough to show as a featured match layer.
The bot-vs-bot public labels were removed from broadcast presentation.
The deploy folder was made strict-CSP compatible.
Inline CSS was moved to styles.css.
Inline service worker registration was moved to app-shell.js.
The game was renamed from Galaxy Ball to ShuffleBall.
The app/domain brand became ShuffleBall Arena.
The title became ShuffleBall Arena — ShuffleBall.
The broadcast title became SHUFFLEBALL LIVE.
The service-worker cache problem was identified and fixed through browser cleanup.
The existing galaxy-ball Cloudflare Pages project was proven usable for deployment.
ShuffleBallArena.com domain was purchased.

So I’m testing a new board layout for my side project: ShuffleBall Arena.

It's a free mobile browser game that combines shuffleboard scoring with the craziness of other games like bumper pool, pinball, and even Frogger.

The new board I am testing has scoring rings that rotate like a carousel. If a ball lands in a scoring ring, it gets carried around by that ring until another ball knocks it out, or the round ends.

Here’s the edge case I’m debating:

In the video, one ball is already in scoring position and riding the carousel. Another ball is sitting dead in a gap between scoring rings. As the carousel rotates, the dead ball gets in the way and knocks the scoring ball out.

The reverse can also happen: a scoring ball riding the carousel can bump a dead ball and push it into a scoring ring.

So the bigger question is:

Should passive carousel collisions be allowed to change scoring?

Option A: No. Only the launched shot and its ricochet chain can create or remove scoring. The carousel can move balls physically, but passive movement should not award points or steal points.

Option B: Yes. The board is a chaos machine. If the carousel causes a ball to score, or knocks a ball out of scoring position, that counts.

I’m leaning toward Option B because it seems more fun, but I can see how Option A might better for fairness.

Still tweaking and testing but I’m putting the rotating layout up early HERE so people can try it and see which rule feels better.

Just choose "Orbit Overload" board for the rotating layout on the start page.

Would love to hear which option you would choose!

Hey everyone,

Hope all is well!

A couple days ago I posted in r/StructuredAI about Day 14 of one of my side projects, ShuffleBall Arena (it's a free browser game combining shuffleboard scoring with the craziness of other games like bumper pool, pinball, and Frogger).

Full Disclosure: Yes, this project was made with the help of AI. I know some people get weird about that, but frankly, I’m trying to use every tool available to help me in every way possible. Honestly, I don't understand why you wouldn't...

Anyway, I'm trying to find the time to post somewhat consistently, and hopefully try to add some value if possible.

Posting an update for Day 15. Here's how today went...

Promoting a new free mobile game

I'm about 5 to 6 days into posting ShuffleBall Arena on social media to see if anyone else finds it fun or has any ideas on how to make it more enjoyable.

So far there's about 13 videos on both TikTok and YouTube. The strategy is to post about 2-3 videos per day on each platform, then measure results to see if there is a format that does better to get out of this "view jail".

Currently, all the videos I have posted so far are capping out right around 100 views each, so now I'm trying to figure out if that's just because it's a brand new account, or if I need to up my game.

What does the data really say?

I looked at my Cloudflare and Google Analytics dashboards and noticed something interesting. My unique visitors were spiking, and server requests were 5x higher than the visitor count.

This told me that the tiny handful of people actually clicking through were staying and playing. This made me think maybe the game isn't bad. maybe my video opening is too slow to capture random scrollers before they thumb-swiped away. This is probably the next thing to test.

Sometimes you gotta pivot

So yesterday I completely redid the video format and made a “challenge” style short: I make a simple goal for the player to accomplish, and see if that increases interest and views.

I shortened the usual clip length, started the video directly in the gameplay action (instead of a first screen image of text), and tried to add punchier text hooks throughout the video to draw in attention.

It actually ended up being more time-consuming than I thought because it required a second UX flow and a different URL just to set up the challenge itself.

I also ended up spending a few hours tuning a separate bot strategy for the challenge. The goal here was to make the bot good enough so it was actually fun to play against, but not so good that it was unbeatable.

The major hurdle was the “Frogger” style moving lanes I added. The bot “acknowledged” they were there, but wouldn't play around them like it should. It kept holding its shots even though there was an opening, then shooting a horrible shot straight into them.

Stress-Testing My Second Tool

I don't remember if I've mentioned it, but the 3 projects I am working on all started from trying to make my personal daily workflow easier. The second of which is a transparent overlay system for content creators.

I wanted a dependable and easy way to drop text overlays into video editors, that would hopefully save me some time and make promoting my other projects easier.

I haven't finished final testing on it yet, but I was really happy with how the overlays held up when imported into CapCut today for the new ShuffleBall Arena challenge video.

The plan moving forward

Keep posting and keep iterating.

It seems that people are at least trying the game, even if they aren't taking the time to comment or provide feedback on social media yet. This led me to put a feedback request directly into the final scorecard of the challenge.

It's a simple question that asks them if they enjoyed the challenge, with a “tell us why” option if they care to share any additional details. Hopefully, this provides at least some direct results...

Well, that's all I got for now.
Happy days to you all and see you next time!

If anyone wants to try the challenge:
https://play.shuffleballarena.com/crossing-drift-challenge

Hey everyone,

ShuffleBall Arena is a free arcade style game I built for browser (mobile + desktop). The idea was to combine shuffleboard with other games like marbles, pinball, and bumper pool. I recently added a little Frogger style moving action, but I still think it's missing something.

This is a solo project with the help of AI. I designed the board layouts, the scoring, etc, but I heavily used AI to help me write the physics and debug the code.

The Ask: AI can write physics code, but it can’t tell me if a game is actually fun. A few buddies and I enjoy playing it over drinks at the bar, but I would love some real feedback on how the game feels, if it was fun to play, or any ideas for how to make it more enjoyable.

Thanks in advance!

Game Title: ShuffleBall Arena

Playable Link: https://play.shuffleballarena.com

Platform: Web Browser (Desktop and Mobile)

Description:

ShuffleBall Arena is a free browser-based marble game that combines shuffleboard-style scoring with arcade physics and fast competitive matches.

Players take turns launching marbles onto the board while trying to control scoring zones, knock opponents away from valuable positions, and use unique board mechanics to gain an advantage.

Current features include:

• Scoring rings
• Bumpers
• Gravity wells
• Wormholes
• Frogger-style moving lane layouts
• Timing-based shots
• Multiple board layouts
• 10-second shot clock

The game runs directly in your browser with no download, account, or installation required.

I'm currently looking for gameplay feedback rather than bug reports. My goal is to make the game more fun and create moments that keep players coming back for another match.

After playing a few games, I'd love to know:

• What felt fun?
• What felt repetitive?
• What mechanic would you add?
• What would make you play again tomorrow?

Free to Play Status:

[X] Free to play

Involvement:

I am the creator of ShuffleBall Arena. I designed the board layouts, website, live broadcast system, gameplay mechanics, physics feel, and ongoing updates. The game is actively being developed, and player feedback is helping shape future features.

Thanks for taking a look, any feedback is appreciated!

Edit: Music Credits:
"Boogie Party" Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/

Hey everyone,

I've been building a Windows desktop app I call Core48aii and I'm looking for a few heavy AI users who would be interested in testing it and giving honest feedback.

TLDR below...

After spending the last year or two using AI daily for coding, writing, research, brainstorming, planning, and long-form projects, I started feeling like the current "chat interface" they give us isn't good enough.

Chats are great for quick interactions, but once projects become larger and more persistent, things start breaking down.

I was constantly losing good ideas in dozens of conversations, rebuilding the same instructions repeatedly, juggling research / drafts / workflows / notes across multiple windows, fighting drift as the AI slowly forgets what matters, and trying to maintain continuity across projects.

Dealing with that eventually became more time consuming than the actual work I was getting done, so I ended up building Core48 to help.

The best way to describe it is an AI Interface / desktop workspace that I use beside whatever AI model I'm working with that day.

What started helping me the most was getting my projects out of giant linear conversations and into a workspace where different parts of the project could actually live separately.

Instead of rebuilding prompts constantly, I could start reusing workflows and instructions that already worked.

Instead of scrolling through old chats trying to find something important, I could quickly reload and reinject previous prompts or project setups in a couple clicks.

It also became way easier to keep momentum on longer projects because the project itself stopped feeling fragmented across dozens of tabs, chats, screenshots, bookmarks, and documents.

The mental overhead it removed has been noticeable. I've stopped trying to "remember where everything is" all day.

I also added things for myself along the way that ended up being surprisingly useful, like keeping quick notes or tasks beside conversations while working, validating whether the AI actually followed instructions correctly, reusing prompt structures that worked well, and organizing projects into separate visual workspaces instead of endless scrolling chats.

I still use ChatGPT, Claude, Gemini, Cursor, etc. every day. Core48aii just became the environment around those tools that helped me stop feeling buried by my own AI workflow.

I'm very interested if it helps other people the same way it's helped me. I am giving away a few 90 day free trials to early testers. It also comes with some free built-in AI usage (it uses GPT internally), so hopefully that helps anyone running into usage limits.

I'm also happy to help with on-boarding, and open to building requested features.

TLDR: I built a Windows Desktop AI Workspace app called Core48aii because my daily work with AI chat interfaces like ChatGPT started to break down for real projects. I am looking for testers or honest feedback on the product in hopes it can help others as it has helped me with my daily workflow.

3 minute demo: https://youtu.be/zjcwTLDkvV0

And the site if anybody wants to look through more screenshots/features:
https://core48aii.com

Thanks for reading!

Hey everyone,

Hope all is well out there.

Before I get going here, I do want to say that I am not here to promote, and this post is not being written by AI. I'm here having a daytime Captain Morgan (a wise man once told me you can't drink all day if you don't start early...), enjoying the weather in good ol' Missouri USA, and just reaching out. (Also, I am not a Captain Morgan sponsor.. just a dedicated rum drinker..)

Anyway, my only motive for writing this post is I am genuinely interested in honest feedback from you, the community. Good or bad is welcome and appreciated, as long as it's honest and hopefully constructive.

So I've been building (and using) a Windows desktop tool that I call Core48aii over the past few months because the same problems kept bugging me while working with GPT / Gemini / Cursor / any other chat model.

Once my projects got even moderately complex (or God forbid I tried to do two things at once in the same conversation), things got messy. I've since come to the conclusion that this whole chat interface thing, the primary way they give us to interact with AI today, just isn't good enough. (Yes, I realize it's literally a Large Language Model, so obviously language is the way to interact with it, but still.. I got shit to do...)

Anyway, I noticed pretty quick that I was constantly retyping instructions, scrolling/searching through dozens of old chats trying to find something important, copy/pasting useful outputs into multiple docs I then had to keep track of, having to start a new conversation as soon as the model starts drifting, and copy/pasting/rebuilding my prompts every day.

I realized I was spending just as much time trying to keep track of my project as I was getting the work done.

At first I built a minimal version just to save me some time and frustration, but it sort of evolved from there into a structured workspace I use along side whatever AI model I'm using.

The idea was to:
- organize anything important into a workspace made of "pads" and "drawers"
- build structured instruction / guardrail stacks
- save those pieces as single prompt templates or whole stack workflows in said "drawers"
- inject those pieces or workflows into whatever AI model I'm working with that day
- compare or reuse inputs and outputs without digging through conversations
- keep the entire project persistent and organized in one workspace that I can control

Since I've put AI into it, things have gotten really interesting, especially now that it controls the output.

I built this in silence, so I'd love to know if this actually solves a real pain point for other people, or maybe just works for me and my own projects.

I'd genuinely appreciate honest feedback, including criticism. (Yeah, I asked for it..)

3 minute Demo Video here: https://youtu.be/zjcwTLDkvV0

Website: https://core48aii.com

A few things I'd especially love feedback on (please don't feel obligated to answer them all):
- Does the problem make sense? Is it something that you deal with personally? If so, how often?
- Does the tool seem overcomplicated? Does anything feel unnecessary?
- Would something like this genuinely help or compliment your daily workflow?
- I am not used to making videos for socials, so any thoughts on the demo is appreciated.
- Any opinions on the website would be appreciated as well. It's the first one I've built.

Again, I am not looking to spam or sell anything here. In fact, please DO NOT purchase anything just because you read this post. I only want to know whether this approach to AI workflows resonates with other people outside my own use cases.

TL;DR:
I got tired of rebuilding my AI workflow every 20 minutes, so I built myself a structured workspace around GPT/Gemini/Cursor to stop rebuilding context and prompts every day. Now I need honest feedback from people other than myself.

Thanks in advance for your time, and please have a great day!