DEV Community: Nando Rama

Day 12 — Do well by doing good

Nando Rama — Sat, 30 Aug 2025 01:19:10 +0000

Me> Let’s wire up Stripe so managers bring their own merchant account; we skim a tiny, grandma-safe platform fee, and bake T&C consent into checkout—visible, not buried.

AI> Wow—you’re on a roll, Nando. I’ve tightened the plan; nudge any line and we’ll start shipping.

Day 12 — Do well by doing good

Before today, running a Squares game meant the host had the least fun.
You know the dance: spreadsheets and DMs, “Which square is mine?”, “Did you get my payment?”, “When are numbers drawn?”, “Who pays who?” Then the fourth-quarter scramble to calculate winners, move money, and explain the rules—again. The person trying to make game day more fun becomes the unofficial accountant, referee, and customer-support desk.

Today we fixed the two biggest hassles: collecting money and proving who paid.

Before vs. After

Before

Players call dibs in a chat; the grid drifts out of date.
Payments arrive in five different apps with six different emojis.
Host manually marks “paid,” chases stragglers, and prays the math adds up.

After (what we shipped today)

Manager links their own Stripe account.
Players pick a square → pay → get marked “paid” automatically, all in one flow.
The app keeps a clean ledger; the host keeps their sanity.
I take a tiny per-transaction platform fee (low enough not to scare anyone), and the money itself goes straight to the manager.

It’s the old motto: do well by doing good. Make the host’s life easier, and the whole party gets better.

Why “bring your own Stripe”?

Control and clarity. The manager is the merchant of record; funds land in their Stripe right away. I’m not holding prize money or sitting in the middle—I’m just orchestrating a smoother path from “I want that square” to “Paid.” That single decision removes a ton of compliance and reduces support emails to “How do I link Stripe?” (Answer: one button.)

Prize mode on the horizon

This ties directly into the next unlock: Prize mode.
Once payments are clean and verified, fulfilling prizes stops being a spreadsheet ritual and starts becoming a button press. Winners can be confirmed by the app; payouts can be structured; confusion disappears. That’s when the game starts to feel…professional.

How we work (still vibing)

The rhythm is the same every day:

A spark (“What if we just let managers bring Stripe?”)
A quick vibe-storm with AI
An implementation outline
Build the smallest thing that changes reality

I’m learning Stripe as I go—dashboards, settings, the boring bits—because I’ll need those instincts when real users arrive. Vibe now, understand deeply later. If we hit our two-month goal and go commercial, I’ll be ready.

What’s next

Tomorrow: wire up Prize mode—the skeleton first, the polish later.
Make the host’s job lighter, make game day smoother, and keep shipping while the idea’s hot.

Short version: We turned “host-as-accountant” into tap → pay → play. Fun leads again.

About this journey
I’m a former embedded coder who left Lockheed in the mid-1990s and haven’t seriously coded since. Beyond reading about today’s platforms, I came into this project knowing nothing about React, Next.js, Firebase, Vercel, or modern web app infrastructure. My goal is to have ChatGPT handle 99% of the coding while I guide the design, test the app, and provide feedback. What you’re reading is a day-by-day journal of building “Squares” — a commercial-ready sports squares app — with AI as my development partner.

Day 11 — Vibe the hard thing while you’re excited

Nando Rama — Thu, 28 Aug 2025 21:07:54 +0000

Love it. Here’s a lightly polished, tighter pass that keeps your voice, jokes, and rhythm—just cleans up flow, headings, and formatting.

Day 11 — Do the hard thing while you’re excited

Big idea today: when an idea pops up, go for it. Start with a vibe brainstorm session then dive in on the implementation. Do the complicated thing while the spark is hot. We leaned straight into two gnarly threads—prize mode and deeper Stripe integration—because future-me never has more energy than present-me.

I’ll keep saying it: for Squares, the UI *is* the product. Nail the feel and everything else (emails, backend, automation) lines up behind it. That’s why we shipped the multi-game invite selector and left the email as a polite placeholder. Pixels first; paragraphs later.

Refactor without guilt

When a control wants to live in more than one place (hello, Time Zone), pull it out and make it a component. Consistency is mercy.

My Ricky Gervais PhD in Time Zones

I’m basically writing a dissertation in “Optimal Human Time Selection.” Why are there so many time-zone IDs when there are only 24 hours? Because every city council since 1912 tried remixing daylight saving like a DJ with commitment issues. Now we have hundreds of IDs so computers can remember that one summer in 1977 when a mayor declared “extra sunlight for morale.” Ricky would shrug: “I don’t care.” Users do—so we make it painless.

How we vibe (even writing this)

This whole project—and this blog—is vibe-driven storytelling with just enough structure to ship.

I brain-dump messy voice notes (bad spelling, worse metaphors) and ask AI to make it into a blog using what it know we did today.
AI does a formal first pass. I roll my eyes, laugh, then steer it.

AI first pass (too stiff):

“Day 11 activities, emphasizing payment orchestration via Stripe Connect, UI refinements to the time zone selector, and preliminary specifications for prize-mode workflows. Subsequent iterations will address email templating and fulfillment operations.”

My reprompt (translation: vibe up, suit off):

“Way less detail. High-level, philosophical, funny. Keep the Ricky Gervais / PhD-in-time-zone-picker joke. Conversational. Short beats. Pixels first; backend later.”

I then vibe up the Cover Image Chat.

give me cover art for this blog post, keep my hair from yesterday mostly bald but put a bit on the front. Have the AI say "I Don't care" in one of the frames.

then about 10 iterations latter I settle. Vibing is not without its frustrations. Trying to get that UI to be perfect...might have to change courses, there are other options

What we ship:
You’re reading it—“Do the hard thing while you’re excited.” Pixels first, payouts next, jokes intact.

We co-edit fast: keep the weird, trim the wobble, delete anything that smells like a status report.
We hit publish while the idea’s warm. No over-polishing, no ceremony—Build → Feel → Adjust.
Same loop for code: extract the gnarly piece, refactor without guilt, make it reusable.
And yes, AI helps—but it’s a brilliant toddler. I’m the adult in the room setting boundaries and taste.

North star for the next lap

#1 Stripe end-to-end (connect, charge, fee).
Prize mode skeleton behind a flag—max prizes, simple categories; redemption later.
Multi-game invites wired to real delivery once the screens settle.

Short version of Day 11: chase the spark, extract the gnarly bits, keep the jokes, and let the pixels lead.

Building “Squares” with ChatGPT: From Prompts to a Commercial-Ready App (Day 10)

Nando Rama — Wed, 27 Aug 2025 17:40:22 +0000

Day 10 — Vibe Coding, Smarter Hand-offs, and Using Downtime Well

Today’s theme was orchestrating the work between a human and AI so neither of us just… waits.

What worked today

Smarter chat hand-offs. When I start a new chat, I first ask the old chat to update its memory with what we just shipped. Then I open the new chat with a crisp question and share context—like the current file tree or a single file. The AI shouldn’t guess what’s in my repo; I give it the exact source of truth.
Always upload the current file. Before asking for edits, I upload the file I’m about to change and then re-ask for the change on that file. This avoids “ghost edits.”
Pictures beat paragraphs. Screenshots were a cheat code for quickly converging on the time-zone picker UI. The AI and the human both see the same thing, so feedback is concrete.
Systemic editing, not YOLO. I open files via the file manager first, then let AI propose edits. Flow: open → propose → apply → verify.
Brainstorm first, code second. For thorny UX or policy choices, I ask AI for a brief, no-code brainstorm to align on best practices. Then we implement. Fewer rewrites, faster merges.

Vibe coding = use the gaps

There are natural pauses: a long code render, or a Vercel build (mine is ~1:30 now and will grow). Instead of staring at a spinner:

Do a tiny chore (dishes, vacuum, reset your brain).
Or open a parallel chat to explore adjacent ideas. Today I used side chats to compare domains and sketch how managers might collect card fees. Progress compounds.

My working playbook (repeatable)

Close the loop: Ask old chat to “save what we did today” to memory.
New chat kickoff: Post a clear question + paste the current file or a file tree.
If visuals matter: Drop a screenshot; ask the AI to react to what it sees.
Brainstorm (no code): Align on approach, edge cases, and UX first.
Targeted edits: Request a single-file change against the uploaded file.
Verify quickly: Run it, screenshot if needed, iterate.
Use downtime: Chore or parallel chat—never idle.

Tiny gotchas logged

ZIP uploads: Too large to be useful; stick to single files or short bundles.
Context drift: Don’t assume the AI remembers your repo layout—paste it.
UI clarity: Regional noise in time zones is real; we curated canonical zones and a “nearby” slice to keep the list readable.

Scaffolding & drift (new lesson)

Sometimes the AI’s response scaffolding (how it structures diffs/sections internally) can get out of sync with a long discussion. That’s when previously fixed screen widths reappear, or a “diff” doesn’t match the current file. This should improve as AI evolves—but the practical fix right now is a stricter “Do It” hand-off.

My “Do It” packet before any code:

Exact target(s): File path(s) and only those files.
Decisions recap: Bullet points from the brainstorm (UX choices, constraints, widths).
Acceptance criteria: What success looks like (e.g., “matches Manager width,” “time-zone list shows ‘nearby’ first”).
Source of truth: Paste the current file contents (even if we edited earlier).
No extras: Ask AI to touch nothing outside the stated files.

When I collect and paste that packet, the AI’s output is consistent, the diffs line up, and the “wrong code showed up” problem disappears.

Closing thought

Vibe coding isn’t about rushing; it’s about keeping both the human and the AI in flow. Small, well-framed tasks; tight feedback; and making the most of the quiet moments—plus a clean “Do It” packet—made Day 10 surprisingly productive.

Building “Squares” with ChatGPT: From Prompts to a Commercial-Ready App (Day 9)

Nando Rama — Tue, 26 Aug 2025 16:51:31 +0000

Day 9 — Pairing With an AI (Without Losing the Plot)

Today wasn’t about a giant feature drop—it was about how a human–AI pair worked together to ship the right things and get un-stuck fast.

The jam session, not the checklist

Instead of obsessing over a bullet list of UI widgets, the pair treated the work like a jam:

The human set the product intent (“Invites should feel native, not tacked on.”).
The AI sketched options and trade-offs (what to gate, what to defer).
The conversation stayed anchored to the user flow, not code golf.

That rhythm turned a rough “Create Square” form into a coherent flow with invites and helpful copy—without spiraling into yak-shaving.

React errors & the “don’t hallucinate” rule

Opaque React errors (those minified numbers) are where an AI can drift—proposing plausible but irrelevant fixes. The human pulled the AI back to the actual render path and insisted on proof.

Shared debugging playbook:

Reproduce on the real route that breaks.
Binary-search the UI: swap custom parts with native tags to isolate the culprit.
Stub first, re-introduce slowly.
Use console breadcrumbs, not vibes.
Touch only files on the execution path.

That discipline turned “mystery #130” into a straightforward fix; the build went green the moment a misplaced file was moved.

Keep the chat history

A surprise hero was the saved chat. Earlier sessions had removed 'use client' in specific places—on purpose. Having the receipts stopped regression and prevented undoing good changes.

Mini-practice: keep a tiny changelog inside the chat—what changed, why, and whether it’s final or experimental.

Vibe-coding is a partnership

“Vibe-coding” works when the human leads with product intuition and reality checks, and the AI proposes concrete options:

The human set guardrails (“don’t chase files we didn’t touch”).
The human kept the flow honest (“Manager → Create → Form”).
The human made the calls on UX semantics (invites can be staged but only send after the square exists).

The AI moved fast, but the human decided what mattered. That’s how a tight loop ships useful code instead of clever detours.

Patterns to keep

Gate actions on existence. No sending invites until a square exists. Predictable and safe.
Inform, don’t block. Grey “already invited” contacts but keep them selectable for re-send.
Inline education. Tiny “i” helpers and context-aware copy beat long docs.
Neutral language. Tools support fundraisers or margin—UI doesn’t moralize.
One path at a time. If a file wasn’t changed, don’t debug it today.

Why today worked

A shared mental model of the flow.
Ruthless focus when errors popped up.
Chat as living documentation.
Quick product decisions (what to gate, grey, or default).

Tomorrow’s polish will layer on (max squares per player, post-create sending, small UX flourishes), but the real win today was the process: ship with intent, debug with evidence, and keep the loop tight between human and AI.

Building “Squares” with ChatGPT: From Prompts to a Commercial-Ready App (Day 8 - 8.5)

Nando Rama — Mon, 25 Aug 2025 20:34:50 +0000

Day 8 → 8.5: Linked Squares shipped (mostly) — and the React #130 detour that proved why “vibe coding” needs a human driver

Project: fan “Squares” app (Next.js / Firebase)
Theme: shipping a new Linked Squares concept, then spending the back half untangling a gnarly React error in production.

The fun part (morning): Linked Squares 🧩

We added a Linked Squares model so managers can spin up a series of identical grids that share configuration and (optionally) a shared pot:

Create Square → auto-creates Series S + first Square P1
If demand exceeds capacity, auto-create P2, P3… with same grid, numbers, teams
Shared pot (series-level) vs per-square payouts (single grid): we picked shared pot for linked series; lottery fallback if a single grid has unclaimed hits
Redirect after create to the square page with a ?created=1 banner and a copy-link / invite CTA

All green locally. Then we hit React error #130 in Preview.

The not-so-fun part (afternoon): React #130 and the loop of doom

Symptom:

Minified React error #130 (“Element type is invalid: expected a string (for built-in components) or a class/function…”)

First instinct (my AI pair):
Chase /pools/[poolId] show page. We stubbed the page to raw HTML and still saw #130. We started combing wrappers, layouts, and error boundaries. Lots of motion, not enough progress.

What changed the game:
We traced the actual user flow end-to-end (Manager ➝ Create ➝ Form ➝ Save ➝ Redirect) and stubbed where the app actually was when it crashed: the CreateSquareForm. With a two-line stub we proved the route was fine. Then we restored sections incrementally.

The real root cause:
Our custom Textarea import resolved to undefined in Preview (Linux, case-sensitive FS). The file/export didn’t match the import casing/shape, so React tried to render undefined as a component → #130.

Switching to the native <textarea> made the page render immediately, confirming the hypothesis. We then added a proper components/ui/Textarea.tsx (correct casing, "use client", named export) and the form rendered.

Why this took longer than it should have

Error boundary masked the real throw. Our custom error page broke too, which kept us staring at #130 instead of the underlying message.
Mac vs Linux gotcha. Locally, case-insensitive FS lets Textarea vs textarea pass; Vercel Preview fails.
Vibe coding stall. We were iterating on the wrong surface (/pools page) while the failure happened earlier (create form).

Lesson: AI can brainstorm quickly, but humans must steer when we start looping. A small, targeted hypothesis (“let’s stub the form itself”) beat broad scanning.

The fix, boiled down

Prove it’s the form: stub the component to pure HTML; if the error persists, it’s higher up. It disappeared → it was the form.
Add a one-line import sanity check:

   console.log('[CSF imports]', { Textarea, Card, Input, ... });
   // Anything undefined? That’s your #130.

Swap to native <textarea> to unblock.
Restore custom UI with correct path + export:

File: components/ui/Textarea.tsx (PascalCase, "use client")
Export: export function Textarea(...) { ... }
Import: import { Textarea } from "@/components/ui/Textarea"

Tiny process improvements we adopted

Human “stall detector.” If we repeat a hypothesis twice without new signal, change layers (stub, log, or isolate).
Incremental re-introduction. Re-add components one at a time until the error returns; that’s the culprit.
Case-sensitive audits before shipping: grep for @/components/ui/textarea vs Textarea.
Diff markers that don’t collide with code. Instead of + / - (which you might paste into files), use your custom markers:
- -!*& = remove
- +&% = add
Error boundary toggle. Temporarily rename app/error.tsx / global-error.tsx to reveal the true stack trace.

A simple debugging playbook (copy/paste)

Stub the exact component where the crash shows up.
Log typeof of imported UI components — any undefined means wrong path/export.
Swap to native HTML for suspect components (e.g., <textarea>) to confirm.
Check casing on paths; Vercel is case-sensitive.
Turn off custom error UIs to see the real runtime error.
Add back code in small chunks until the break reappears.

“Vibe coding” requires a human co-pilot

This was a classic example of why AI + human works best when the human is ready to change tactics. An engineer who can read console output, stub components, and reason about app flow can keep the session from going in circles. Without that, vibe coding risks getting stuck in a hallucinated hypothesis loop.

What we still shipped today ✅

Linked Squares concept & series model
Shared-pot payout approach (with single-grid lottery fallback)
Create flow + invites writing
UI consistency (Accordion layout, mobile-friendly form)
Fixed Textarea component & eliminated the React #130 blocker

Tomorrow: Refine the create square and manager dashboard UI for linked squares. Onward.

Building “Squares” with ChatGPT: From Prompts to a Commercial-Ready App (Day 7)

Nando Rama — Sun, 24 Aug 2025 21:18:40 +0000

About this journey

I’m a former embedded coder who left Lockheed in the mid-1990s and haven’t seriously coded since. Beyond reading about today’s platforms, I came into this project knowing nothing about React, Next.js, Firebase, Vercel, or modern web app infrastructure. My goal is to have ChatGPT handle 99% of the coding while I guide the design, test the app, and provide feedback. What you’re reading is a day-by-day journal of building “Squares” — a commercial-ready sports squares app — with AI as my development partner.

Day 7: Email-Link Auth that Actually Works + Safer Preview Testing on Vercel

Theme: untangling Firebase Email-Link auth on Vercel, aligning domains and env vars, and adding a guarded “dev login” for Preview so I can iterate without hitting quotas.

What broke (and why)

auth/unauthorized-continue-uri: Magic links failed because my runtime app was pointed at the wrong Firebase project (env mismatch), even though the allowlisted domain looked right.
Local .env* confusion: Repo had .env.local, .env.staging, .env.production. Vercel uses its own Environment Variables; those files were misleading the build.
Quota exceeded: Rapid testing hit auth/quota-exceeded, which pushed me to add a Preview-only bypass.

The fixes that stuck

1) Make the continue URL deterministic

Build continueUrl from NEXT_PUBLIC_AUTH_RETURN_BASE (Preview uses https://squares-staging.vercel.app), falling back to window.location.origin.
Log runtime Firebase config (apiKey/projectId/authDomain) and the final continueUrl for instant visibility.

2) Use Vercel envs as the source of truth

Verified Preview variables:
- NEXT_PUBLIC_FIREBASE_API_KEY
- NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN
- NEXT_PUBLIC_FIREBASE_PROJECT_ID
- NEXT_PUBLIC_AUTH_RETURN_BASE=https://squares-staging.vercel.app
Moved local .env* files out of the app tree to avoid accidental use during builds.

3) Map the domain to the right environment

Vercel → Project → Settings → Domains Connected squares-staging.vercel.app to Preview (branch staging). Result: magic links that land on /auth resolve in the same environment that sent them.

4) “Remember this device” and route after sign-in

Set Firebase persistence to browserLocalPersistence so signed-in users skip auth on revisit.
Email-link completion reads ?role=manager|player and routes accordingly.
If already signed in and not on a link-complete URL, route to the last chosen role.

5) Preview-only dev login (no email needed)

Client flag: NEXT_PUBLIC_BYPASS_MAGIC_LINK=true (Preview only).
Server route: /api/dev-login issues a short-lived custom token via Firebase Admin only if:
- A secret header matches DEV_LOGIN_SECRET, and
- The request is from the Preview deployment.
Production path is unchanged; the bypass is Preview-scoped and guarded.

Small but meaningful UX tweaks

Manager dashboard
- Added a Logout button next to Create New Square.
- Free tier status now: “Free tier • 1 square at a time until {Mon DD} • Active squares: N”
- Purchase panel starts collapsed; Free Tier activation appears inside the dialog (less “prototype,” more “product”).

What I learned (again)

If the error says “domain not allowlisted,” verify the runtime Firebase project. Logging apiKey/projectId/authDomain beats guessing.
Vercel Preview vs Production is mostly domains + env vars. Map correctly, set envs correctly, and the rest gets pleasantly boring.
Quotas are real. A guarded Preview bypass keeps velocity high without compromising production auth.

Reflections from Day 7

This was a classic “it’s configured… just not the way you think” day. Once I surfaced the runtime values and mapped the domain to Preview, Firebase Email-Link auth behaved. The guarded dev login let me iterate without poking the quota hornet’s nest. Bonus: a couple of small UI touches made the Manager dashboard feel like a product, not a demo.

✅ Next steps

Vibe-code the “Create New Square” flow
- Minimal form: matchup/title, grid size (5×5 / 10×10), start/end, visibility.
- Client validation + friendly errors.
- Firestore write (draft → active), with optimistic UI on create.
- Invite flow stub (paste emails now; deeper contact picker later).
- Preview-only safeguards (no billing), Prod path ready to integrate with purchasing.

Building “Squares” with ChatGPT: From Prompts to a Commercial-Ready App (Day 6)

Nando Rama — Sun, 24 Aug 2025 20:57:41 +0000

Building “Squares” with ChatGPT: From Prompts to a Commercial-Ready App (Day 6)

About this journey

I’m a former embedded coder who left Lockheed in the mid-1990s and haven’t seriously coded since. Beyond reading about today’s platforms, I came into this project knowing nothing about React, Next.js, Firebase, Vercel, or modern web app infrastructure. My goal is to have ChatGPT handle 99% of the coding while I guide the design, test the app, and provide feedback. What you’re reading is a day-by-day journal of building “Squares” — a commercial-ready sports squares app — with AI as my development partner.

Day 6: Wrestling with Vercel Deployments and Resetting to a Clean Build

If Days 4–5 were about code quality and TypeScript discipline, Day 6 was about facing the realities of deployment. The goal was simple: get a successful build running in Vercel and make sure the app could be accessed in a browser. The reality? A full day of chasing build errors, learning how Vercel interprets commits, and finally rolling back to a known good state.

Key Focus Areas

Stripe build errors: Vercel repeatedly failed with Module not found: Can't resolve 'stripe' despite the dependency being present. We experimented with postinstall checks, dynamic imports, and package.json cleanup. In the end, these fixes were less important than realizing we had drifted into a messy state with too many half-fixes.
Error boundaries: Along the way, new errors cropped up around Next.js error pages (/404, /500) involving hooks like useContext. Some of these were introduced while debugging Stripe, highlighting how easy it is to destabilize an otherwise clean build.
Git strategy: The breakthrough came from stepping back and treating Git as a safety net. I created “rescue” branches, inspected commit history, and eventually rolled main back to a known clean build commit (dddc1ae). Using GitHub Desktop’s Force Push Origin, I reset remote main to the working state and re-aligned Vercel with that baseline.
Vercel settings: Verified build settings (npm ci for install, next build for build, Node 22.x) and used Clear build cache to avoid stale state. The preview deployment of the clean commit built flawlessly and was promoted to production.

Workflow Lessons

Today was less about code and more about process:

Keep commits clean and frequent. If I had checkpointed before diving into Stripe debugging, rolling back would have been even easier.
Understand how Vercel ties deployments to Git commits. “Redeploy” builds the same commit; if that commit is bad, only a reset or new commit will fix it.
Use force push with care. It’s not something you do lightly, but when you know exactly which commit is good, it’s the fastest way to reset the project’s source of truth.

Reflections from Day 6

This was a frustrating but ultimately empowering day. The Stripe build errors consumed hours, but the real win was learning to manage Git branches, commits, and force pushes in a way that gave me back control. By evening, I had the app cleanly deployed on Vercel and accessible in a browser — a milestone worth celebrating.

More importantly, I realized this: not every problem is solved by more code. Sometimes the smartest move is to stop, roll back, and protect the integrity of the project. That’s a lesson both in software engineering and in working with AI partners.

✅ Next steps: With the clean build now live on Vercel, the focus shifts to testing access from a web browser and validating end-to-end flows (auth, Firebase, Stripe stubs). Once stable, I’ll circle back to payments and subscriptions with a fresh perspective.

Building “Squares” with ChatGPT: From Prompts to a Commercial-Ready App (Days 4–5)

Nando Rama — Sun, 24 Aug 2025 20:44:23 +0000

About this journey

I’m a former embedded coder who left Lockheed in the mid-1990s and haven’t seriously coded since. Beyond reading about today’s platforms, I came into this project knowing nothing about React, Next.js, Firebase, Vercel, or modern web app infrastructure. My goal is to have ChatGPT handle 99% of the coding while I guide the design, test the app, and provide feedback. What you’re reading is a day-by-day journal of building “Squares” — a commercial-ready sports squares app — with AI as my development partner.

Days 4–5: Debugging, Refactoring, and Preparing for Deployment

After the whirlwind of Days 1–3 where we got a local prototype running in under 72 hours, the next phase (Days 4–5) was less about flashy new features and more about hardening the codebase, fixing TypeScript/ESLint issues, and preparing for a production-grade deployment on Vercel.

Key Focus Areas

Linting and TypeScript strictness: We encountered dozens of any type warnings and unused imports across files like firebase.ts, auth/page.tsx, crypto.ts, and graphics components like FlyingBall.tsx and SquaresGridDemo.tsx. Rather than ignoring these errors, we systematically replaced them with explicit, strongly typed definitions.
Crypto utilities: Refactored lib/crypto.ts to properly track salts using WeakMap instead of mutating CryptoKey objects with any. This eliminated no-explicit-any warnings and ensured cleaner key handling.
Error boundaries: Updated error.tsx and global-error.tsx to use properly typed props (Error & { digest?: string }) instead of any.
Firestore timestamps: Standardized on serverTimestamp() for createdAt, updatedAt, and joinedAt fields in pools.ts, subscriptions.ts, and other data files. This improves consistency and avoids mixing client and server clocks.
Stripe setup: Fixed missing dependency issues (Module not found: Can't resolve 'stripe') by installing Stripe properly and ensuring it was listed in package.json.
Firebase Admin: We reclassified firebase-admin as a devDependency where appropriate to resolve build issues but also ensured runtime dependencies are in the right place for Vercel.
Pre-commit hooks: Cleaned up Husky’s pre-commit script to run linting without blocking commits (warnings don’t prevent progress, but errors are still flagged).

Workflow Refinement

We also refined how ChatGPT provides code changes. Instead of sending full rewritten files (hard to track) or plain prose (easy to miss changes), we settled on diff-style updates with + and - prefixes. This way, I can copy changes directly into Atom, delete the + symbols, and apply them efficiently. It feels like pair programming with a very fast, meticulous partner.

Reflections from Days 4–5

This stretch wasn’t about rapid new features — it was about quality and confidence. Every any eliminated, every unused import cleaned, and every build warning squashed made the app feel more production-ready. It was also when I really saw the rhythm of this collaboration take shape: I provide direction and context, ChatGPT does 99% of the coding, and we iterate until things are stable.

It’s a different kind of software engineering — more like orchestrating and testing than sitting down and grinding through syntax. And frankly, it feels like the future.

✅ Next steps: With linting and type safety under control, the focus shifts to deploying on Vercel with staging Firebase projects and tackling subscription/payment flows end-to-end.

Building “Squares” with ChatGPT: From Prompts to a Commercial-Ready App (Day 1 -3)

Nando Rama — Sun, 24 Aug 2025 20:42:28 +0000

Vibe coding with ChatGPT (Days 1–3)

I’m not a professional web developer. In fact, I haven’t coded seriously since the mid-1990s, when I left Lockheed as an embedded systems programmer. Since then, I’ve worked in other domains, and while I kept up with reading about technology trends, I had zero practical experience with modern platforms like React, Next.js, Firebase, or Vercel.

My goal: have ChatGPT write 99%+ of the code while I provide design ideas, product concepts, and do the testing.

In just 3 days we had a working local prototype. Here’s what we achieved.

🚀 From Zero to Prototype in 3 Days

With ChatGPT guiding me step by step, we had a local working prototype in just 3 days. That included:

A functional auth flow with magic links (passwordless login).
A Manager Dashboard with accordion-based UI for Active Squares, Past Squares, Manage Contacts, and Purchase Options.
Mock data for testing without a database.
A Firestore schema drafted to handle managers, players, contacts, invites, and payouts:contentReference[oaicite:0]{index=0}.

Each time I got stuck — whether it was a linting error, a missing dependency, or “where do we put this string?” — ChatGPT provided not only code fixes but best-practice explanations about why modern apps are structured this way.

🖼️ The Accordion UI: Prompt-Driven Design

One of the most satisfying outcomes was the accordion-driven dashboard.

I suggested:

“Wouldn’t it be better if purchase options were expandable lists, so the UI can scale as we add bundles and sales?”

ChatGPT translated that into React components using Tailwind, complete with nested accordions and purchase dialogs. It wasn’t just code — it was a scalable UI design pattern that will handle future growth without rewrites.

This became a theme: I provided the vision in plain English, ChatGPT provided drop-in file replacements (like full page.tsx files), and together we iterated until it felt right:contentReference[oaicite:1]{index=1}.

📊 Database Schema: Modernizing My 1990s Mindset

Coming from embedded systems, I thought in terms of tables and rows. ChatGPT helped me modernize that thinking into Firestore’s document-oriented design.

We ended up with a schema that balances manager-centric contact lists with player-centric identity:

Managers with contact/payment IDs and their owned Squares.
Players with unique UIDs, multiple emails (primary + alternates), and payment preferences.
Squares with grid mappings, costs, payout %, and invites.
Contacts searchable by prefixes, powered by a helper script.
Invites to reconcile pending and claimed squares, even if emails change:contentReference[oaicite:2]{index=2}.

I learned how modern identity systems use UIDs as the stable key (instead of emails, which can change). ChatGPT explained trade-offs I wouldn’t have thought of on my own.

🛠️ Helpers and Developer Experience

We also built scripts to support real-world development:

Seeder scripts to populate mock data.
Backfill scripts for search indexes.
help.js — a custom CLI helper that documents all npm run scripts and explains why and when to use them:contentReference[oaicite:3]{index=3}.

This last one was a game-changer. Instead of scrolling through package.json or pasting old ChatGPT answers, I can now just run npm run help and get a living developer guide.

⚡ Dealing with Chat Memory Limits

One surprising challenge wasn’t technical at all: ChatGPT’s memory window.

As the project grew, the chat slowed down, and responses became less focused. To solve this, I worked with ChatGPT to:

Create context snapshots (summaries and even scripts like make-ai-context.mjs) to carry between chats.
Save project summaries and architecture notes as Word/Markdown files.
Restart fresh chats without losing continuity:contentReference[oaicite:4]{index=4}.

This process let me keep momentum — even when the conversation hit the AI’s limits.

💡 From Lockheed to Vercel

When I left Lockheed in the ’90s, deploying meant burning code into ROM or distributing binaries. Now, with ChatGPT walking me through, I’m deploying with a couple of clicks on Vercel.

The staging workflow we set up:

GitHub repo connected to Vercel.
.env.staging with Firebase credentials.
Firebase console configured for email-link auth and domain whitelisting.
Automatic redeploys on git push:contentReference[oaicite:5]{index=5}.

The contrast couldn’t be more stark: 3 days to a working web app with global hosting, compared to months of setup in the old world.

🏁 What We’ve Achieved So Far

✅ Mobile-friendly auth and dashboard UIs.

✅ Database schema and helpers.

✅ Mock data + seeding scripts.

✅ Deployment pipeline (GitHub → Vercel → Firebase).

✅ Developer ergonomics (help.js, husky hooks).

✅ A working prototype I can demo to real users — in under a week:contentReference[oaicite:6]{index=6}.

🎯 Next Steps

Replace mock data with live Firestore queries.
Build out claiming and payment validation flows.
Test end-to-end notifications (email during games, win alerts).
Continue refining UI polish for both managers and players.