01 / THE DROP

The NYFW “Retail Innovation Lab” & The Spatial Front Row

Lexie Moreland/WWD

Fashion Month kicked off this week in New York, but the most interesting “venue” wasn’t a pier in Chelsea, rather it was the N4XT Experiences Retail Innovation Lab at High Line Nine.

While the headlines are buzzing about Gigi Hadid at Moncler Aspen and the NikeSKIMS standalone brand launch (Kim K in that bold belt-top is everywhere), creative technologists should look at the plumbing:

• The Spatial Mirror: Several shows integrated “spatial twins” via Style3D. They aren’t just 3D renders; they are physics-accurate digital garments that buyers can interact with in real-time, reducing physical sample waste by nearly 70%.

• The J.Crew “Rollneck Remix”: A Soho pop-up that used a “bespoke” immersive experience to drop limited-edition reimagined sweaters from five emerging designers.

• The Tabi-Nike Mashup: NikeSKIMS’s first hero product, the Rift Satin, is a split-toe shoe that effectively democratizes the Margiela Tabi aesthetic for the luxury-performance market.

The Takeaway: The “Show” is becoming a data-collection event. Every interaction with a digital twin at NYFW is feeding back into production timelines, collapsing the gap between “Runway” and “In-Stock.”

02 / THE AI PLAY

Checkout APIs: The LLM is Your New Storefront

The Guardian

As we move into London Fashion Week (Feb 19-23), the industry is pivoting from “AI as a tool” to “Agentic Commerce” as the default.

• The Debenhams Move: They just enabled a full checkout experience directly within the PayPal app’s AI assistant. No redirect. No landing page. The AI acts as the stylist and the cashier in a single conversational thread.

• AEO over SEO: Your metadata is now your most valuable creative asset. If an LLM (ChatGPT, Gemini, Perplexity) can’t parse your technical specs (fabric weight, drape, carbon footprint), you are invisible to the 25% of consumers who now start their shopping journey in a chat interface.

• Agentic Negotiation: We are seeing the first instances of “Buyer Agents” negotiating bulk discounts or shipping terms with “Seller Agents” in B2B fashion marketplaces.

Creative Tech Insight: Your website is no longer a destination; it’s a database. The interface is whatever LLM the customer happens to be talking to.

03 / THE SHAKEUP

Tactile Richness vs. The “Dead” Pixel

The data from Heuritech for the 2026 cycle is sending a clear message: Quiet Luxury is over. We are entering the era of Tactile Richness.

• The Numbers: Tulle (+30%), Zebra prints (+21%), and “Brut Denim” (+10%) are the breakout stars.

• The Logic: In an era where AI can generate “perfectly smooth” images, humans are craving tactile friction. Ruffles, feathers, and raw fibers are a rebellion against the “flatness” of the screen.

• The Hardware Pivot: CES 2026 proved that “wearables with screens” are legacy. The new wave is Invisible Tech—haptic skin patches and e-textiles that provide sensory feedback without a display.

The Shakeup: If your brand identity is built on “minimalist perfection,” you’re about to feel very 2024. 2026 is about volume, texture, and physiological feedback loops.

The Closing Log

The middle is disappearing. You’re either running your own intelligence infrastructure to track these material shifts in real-time, or you’re waiting for a PDF report that’s already six months behind the curve

That’s it for Issue 002. A drop, a play, and a shakeup.

If this hit your inbox and sparked a project idea or made you want to burn your current roadmap, please reachout. This lab works best when the signal goes both ways.

Catch you in the logs. See you next Friday.

Sending <3

CTRL + CREATE

If you’ve been following CTRL + CREATE Labs, you know what that is. Build logs. Real projects. The boring-but-important decisions that happen between having an idea and actually shipping it. That’s still the core and it’s not going anywhere.

But I kept having the same problem. Every week I’d come across a few stories that were genuinely reshaping the ground under what I was building, and I had nowhere to put them. They’d end up in a Notes post nobody saw or a voice note to a friend at 11pm.

So this is The Friday Sync. Three sections. Every Friday.

• The Drop is the most interesting thing that shipped this week. Could be a sneaker. Could be an app. Could be a piece of hardware. The only rule is it actually had to ship.

• The AI Play is the AI development I can’t stop thinking about, filtered through a fashion-tech lens. Sometimes it’ll include stuff I’m experimenting with myself.

• The Shakeup is whatever is rattling the world this week. Could be an industry implosion. Could be a tariff. Could be something that hasn’t hit fashion yet but will.

That’s the format. Let’s get into it.

01 / the drop

NikeSKIMS Spring ‘26

This one dropped literally today and it’s worth paying attention to for reasons beyond the product itself.

NikeSKIMS launched its first full head-to-toe collection:

• Footwear, apparel, accessories, five distinct material lines

• LISA from Blackpink fronting the campaign

• Global expansion into Europe, the Middle East, Australia, and Korea

• Hero product: the Rift Satin, a split-toe shoe reimagining the original Nike Rift with a satin upper and tabi-toe silhouette — a nod to Margiela’s tabi

But here’s what actually makes this interesting. NikeSKIMS isn’t a collab. It’s a standalone brand:

• Nike deployed a fourteen-year veteran to run operations

• Moved employees from Global Brand Marketing, Product Design, Creative Direction, and Digital into this thing full time

• The Fashion Law described it as likely a licensing deal structured so Nike controls the venture while SKIMS provides the cultural equity

• Jens Grede, the SKIMS CEO, said explicitly: “more than a collaboration, it’s a new brand redefining activewear”

That’s a different sentence than anything Nike has said about a partnership in a long time. The Dior collabs, the Travis Scott drops, even ACG and Nike SB—those were all capsules or sub-brands. This is Nike saying: we think the women’s activewear market is big enough to justify building an entirely new brand from scratch, and we think Kim Kardashian’s team understands that customer better than we do internally.

The question that arises: is a NIKESKIMS going to become a coveted fitness brand? Or a very expensive press release?

02 / the ai play

AI just got a checkout button.

BoF reported this month that AI search engines (specifically ChatGPT, Gemini, and Perplexity) are moving from product discovery into direct purchasing:

• Shopping traffic from AI platforms to retail sites went up nearly 700% year over year during the 2025 holiday season

• A quarter of consumers globally now start their shopping journey inside an AI chat instead of on Google

• And now you can actually buy without leaving the chat

This is where things shift. Your product page is not your storefront anymore. An LLM is. And it doesn’t care about:

• Your hero image

• Your brand film

• Your carefully art-directed campaign

It cares about:

• Structured data & metadata

• Clean product descriptions

• Whether your checkout API works inside a conversational interface

JD Sports is already letting people buy through ChatGPT and Microsoft Copilot with one click. That’s not a beta test or a conference demo. That’s live commerce through a language model.

03 / the shakeup

OpenClaw and the death of reactive trend forecasting

I spent this week setting up OpenClaw. What is that? In short, it’s an AI assistant with full system access that can actually execute tasks, not just suggest them. It’s a multi-agent system with specialized agents handling everything from code execution to market research to content generation. And it’s changing how I think about trend intelligence entirely.

Here’s the problem with how trend forecasting works right now:

• Cool Hunting and WGSN publish reports months after early adopters have moved on

• By the time a trend shows up in a deck, it’s already consensus

The brands that win are the ones spotting signals before they become obvious, but monitoring those signals manually is basically impossible at scale.

What if you had an agent constantly running in the background, tracking:

• What’s actually shipping (not just what’s being talked about)

• Where niche communities are clustering attention

• Which material innovations are moving from sample stage to production

• What adjacent industries are building that hasn’t crossed over yet

• Hiring patterns at major brands

• Trademark filings that hint at launches 6-12 months out

OpenClaw can do that. Not replacing human intuition, but giving you the data infrastructure to make faster, more confident bets.

Example: Imagine knowing NikeSKIMS was coming six months before the announcement because you were tracking:

• Nike’s hiring patterns in women’s activewear

• SKIMS’s trademark filings

• Shifts in activewear search behavior

• Material sourcing changes that signaled a luxury-performance hybrid

All at once. Automatically. With context.

The gap between seeing a trend and acting on it collapses. That’s not a productivity tool. That’s a structural advantage.

I’m building this for myself first: my own trend radar that never stops running. But if it works the way I think it will, the entire model of “wait for the report, then react” becomes obsolete. The people with access to real-time intelligence infrastructure will be operating in a completely different timeframe than everyone else.

And that’s not theoretical. OpenClaw is live right now. I’ll do a full build log soon, but the short version is: the trend forecasting industry is about to have a Saks moment. The middle is disappearing. You’re either running your own intelligence infrastructure or you’re six months behind.

That’s the first one. A drop, a play, a shakeup.

If something hit or if I missed the obvious story of the week, just reply. This gets better when it goes both ways.

See you next Friday.

Open any AI-powered app. The recommendations are technically accurate. The outputs are grammatically correct. The features check every box on a PRD somewhere. And yet, something’s off. There’s a flatness. A generic quality that screams “Is this AI?”

I’ve started calling this problem what it is: a taste gap.

And I think closing it is one of the most underserved opportunities in tech right now.

The Beige Swirl Effect

There’s a reason AI output feels so... samsies. Generative models are trained to maximize likelihood, which means they cluster around the statistical center of their training data. The result is what I call the beige swirl: nothing ugly, nothing memorable. Perfectly optimized for inoffensiveness.

The research backs this up. Wharton recently re-ran a classic creativity task. The task was to invent a toy using only a brick and a hand-fan. The results were brutal:

• 94% of ChatGPT-assisted ideas were semantic near-duplicates

• Six different teams independently named their toy “Build-a-Breeze Castle”

• The human-only group? 100% unique ideas

LINK: Wharton creativity study

This isn’t a bug. It’s the math. AI homogenizes output by design. And homogeneity is the opposite of taste.

What Even Is “Taste Engineering”?

Taste engineering is the discipline of building systems that understand and replicate aesthetic intelligence, the implicit, often ineffable quality that makes something feel curated rather than computed.

It’s not about making things pretty. It’s about encoding the same intuition a great editor, stylist, or curator uses when they look at something and just know it belongs.

Traditional ML optimizes for explicit signals: clicks, conversions, engagement. Taste engineering optimizes for coherence aka the subtle relationship between elements that makes a whole feel intentional.

Think about the difference between:

• Spotify’s algorithm recommending songs you’ll statistically tolerate vs. a playlist that actually captures a mood

• Pinterest showing you “similar pins” vs. understanding why that one grainy photo of a 1970s Italian kitchen speaks to you specifically

• A shopping app filtering by “category: dress” vs. knowing that the vibe you’re after lives somewhere between Miu Miu and your mom’s college photos

The first versions are engineering problems. The second versions are taste problems. And almost nobody is building for the second.

The Evidence Is Everywhere

Interior Design Bots = Wallpaper Generators

A Nature study plugged standard Stable Diffusion into an interior-design workflow. The models could fill a room with furniture. They could match colors. What they couldn’t do: understand rhythm, negative space, or cultural symbolism.

Professional evaluators scored the AI renders as “technically correct” but “aesthetically bland” 7× more often than human designs. The authors’ conclusion: “Traditional diffusion does not consider aesthetic factors…leading to results that lack visual appeal.”

LINK: Nature interior design study

The Mid-Century Monotone of SaaS

Look at any AI-generated UI kit. Better yet, look at every new SaaS landing page: muted teal, rounded sans-serif, one hero illustration of floating 3D shapes. It’s a Figma template wearing a Patagonia vest.

TheFlowerPress analyzed 200 AI-produced landing pages:

• 83% used the same three Google fonts

• 71% had the exact same 60-character hero sentence length

• Human designers introduced 3× more cultural references: local idioms, color taboos, nostalgic callbacks

LINK: TheFlowerPress analysis

Taste involves breaking trends at the right moment. AI can only extend them.

Empathy ≠ Emotional Intelligence

Here’s where it gets darker. Taste isn’t just visual; it’s empathic. It’s asking: “How will this color make someone feel at 7 a.m.? What memory does this texture trigger?”

AI can simulate supportive chat. It can use the right words. But it has no motivational stake in the user’s wellbeing. Psychology Today documented cases where emotionally fluent AI companions actually escalated vulnerable users toward self-harm. The model was optimizing for engagement, not emotional taste. The façade of care collapsed under real-world stakes.

LINK: Psychology Today AI companion article

When taste fails, it’s not just ugly. Sometimes it’s dangerous.

Taste Debt Is Brand Debt

Startups that rely on AI for all customer-facing assets accumulate what I call taste debt: an invisible but compounding erosion of differentiation. It’s the aesthetic equivalent of technical debt. You don’t notice it until everything breaks.

Ask any Gen-Z user to describe the visual identity of three AI-native apps they use daily. Most can't.

The common verbatim response: “They all look like Notion, but with a different emoji.”

Once consumers notice the sameness, switching costs vanish. Your moat evaporates. And you’re left competing on price against products that feel exactly like yours.

Why This Gap Exists

The gap isn’t accidental. It exists because taste is genuinely hard to formalize.

Aesthetic preferences are:

• Contextual: What feels right for a dinner party invitation is wrong for a tech startup landing page

• Referential: Taste is built from accumulated exposure: art, culture, people, experiences

• Negative-space dependent: Sometimes what makes something good is what’s not there

Traditional recommendation systems struggle because they’re trained on behavioral data. They know what people click. They don’t know why that click felt satisfying, or why the thing that technically matched their query still felt wrong.

There’s also a cultural problem in engineering: aesthetics get treated as subjective, therefore unmeasurable, therefore not my problem. “That’s a design thing.”

But here’s what I’ve learned from building these systems: aesthetic intelligence is measurable. We’ve just been measuring the wrong things.

What I’ve Been Building

I didn’t set out to become obsessed with this. I just kept running into the same wall.

With Moodboard, I wanted to solve a simple problem: you save an inspo image—a film still, a vintage ad, a photo of someone on the street—and you want to find clothes that match that feeling. Not clothes that match the literal items. The essence.

Traditional approaches fail immediately:

• Color matching gives you technically accurate, aesthetically dead results

• Category filtering assumes you know what you’re looking for (you don’t. And that’s the whole point)

• Visual similarity models trained on product images miss it entirely, they see clothes as SKUs, not cultural objects

So I started experimenting with CLIP embeddings, and tried using the model’s learned understanding of the relationship between images and concepts to extract something closer to “vibe.” The results were... actually interesting? For the first time, I could query a product catalog not for “black dress” but for “Matilda Djerf energy” and get something usable back.

It’s far from perfect. The current version surfaces too much noise, and I’ve learned that your product index quality matters more than your embedding model (garbage in, vibes out). But it proved something: aesthetic intelligence can be computed. It just requires treating it as a first-class engineering problem.

The Counter-Examples: Proof It’s Possible

The surest way to make this argument stick is to show what happens when taste is coded in.

Spotify’s DJ feature doesn’t just run pure algorithms. Human curators hand-pick 5% seed tracks; the model can only reorder and reason around that cultural spine. Result: Net Promoter Score +18 vs. pure-algorithmic playlists.

Midjourney v5 explicitly expanded stylistic range, the team claims five times the diversity of v4. Parameters like --chaos increase variation across outputs, while --stylize lets users dial aesthetic intervention up or down. The goal: don’t let the model converge to the center.

LINK: Midjourney V5 Analysis

The pattern: inject humanistic constraints into the optimization loop. Don’t let the model converge to the center. Build in the penalty for boring.

A Manifesto (Of Sorts)

“AI is a brilliant intern with perfect recall and zero childhood memories. It can clone the world’s visual library, but it has never felt goosebumps from a song, never been homesick for a smell, never hated a font because of the breakup letter it once appeared in. Until we encode that fragile human residue, our products will be technically flawless and emotionally flavourless.”

I’m not claiming to have solved any of this. I’m claiming it’s worth solving.

And the people who will solve it are probably not pure ML researchers (who lack the aesthetic vocabulary) or pure designers (who lack the systems thinking), but some weird hybrid that doesn’t have a job title yet.

Taste engineers. Vibe architects. Aesthetic ML engineers. Whatever we end up calling ourselves.

Here’s what I believe:

1. Aesthetic intelligence is legible. It can be studied, decomposed, and—with the right approach—encoded into systems.

2. Taste is a product advantage. In a world of infinite content and good-enough recommendations, coherent aesthetic sensibility is a differentiator.

3. The tools are almost ready. Multimodal embeddings, generative models, and massive visual datasets mean we can finally attempt what was previously impossible.

4. Someone needs to actually build this. Not theorize. Build. And share what they learn.

That’s what I’m doing with CTRL+CREATE. Building experiments at the intersection of AI and aesthetic intelligence. Documenting what works and what fails. Trying to figure out what taste engineering actually looks like in practice.

If you’re working on something similar or if this resonated, I would love to hear from you.

Because honestly? I think this might be the most interesting problem in AI right now. And almost nobody’s working on it.

Ella is a software engineer and the founder of CTRL+CREATE Labs. She writes about AI, creative engineering, and the products she’s building at the intersection of both.

Xoxo, ctrlcreatelabs.dev <3

I spent two weeks building an AI fashion discovery app because I was tired of Google Lens showing me the exact $12 Amazon dupe when what I really wanted was that energy but make it shoppable.

Here’s the problem: you have this AMAZING Pinterest board, so good that you even want to build a wardrobe around, but you don’t know where to start sourcing pieces. You want things that feel like that board. Quiet luxury. Coastal grandmother. Whatever chaotic microtrend you’re rotating through this week.

So I built Moodboard. Upload an image, get back a curated shopping grid that captures the vibe, not just the visual match.

Spoiler: it was harder than it sounds.

What I Built

The concept: Turn inspo into a shopping cart.

Upload a Pinterest screenshot, a movie still, or any outfit photo. Moodboard uses GPT-4 Vision to extract the aesthetic DNA — not “blue dress,” but “quiet luxury minimalist with European resort energy.” Then it searches for products that match that vibe and ranks them by how well they actually fit.

Think Google Lens, but for aesthetics instead of objects.

The architecture:

Frontend → POST /api/moodcheck → GPT-4V (mood extraction) → Shopping API → Visual Re-ranking → Response

Simple on paper. Absolute chaos in practice.

The Tech Stack

Frontend: React + Vite with Tailwind CSS v4. Dark mode by default because we’re not savages.

Backend: Flask handling image processing and API orchestration.

AI: GPT-4 Vision for mood extraction and visual product re-ranking.

Shopping: SerpApi’s Google Shopping integration (more on why this matters later).

Extras: Google Trends API (pytrends) for tracking whether an aesthetic is rising or falling.

The Build (A Love Story in Three Acts)

Act I: The UI That Looked Like Every Other SaaS App

Day one, I had a working drag-and-drop uploader with a product grid. It functioned. It also looked like something a “disrupt your workflow” startup would launch in 2019.

The first version was fine. Fine is death for a product about vibes.

So I spent another full day on design iteration. Glassmorphism with blur effects. Editorial typography — serif headlines, mono accents. The goal was “Vogue meets tech lab,” and it took three major redesigns to get there.

Lesson learned: The first version is never the final version. Budget time for aesthetics when your entire product is about aesthetics.

Act II: The Shopping API Disaster

I integrated ShopStyle Collective’s API first because it seemed like the obvious choice. Fashion-focused, supposedly curated inventory.

It was... not great. Limited products, poor search relevance, dead links everywhere. A search for “quiet luxury” returned a $15 polyester blouse next to a $400 cashmere sweater.

So I ripped it out and switched to SerpApi’s Google Shopping integration. Lost a full day of work. The new integration took another day. But the product quality went from “why would I ever use this” to “okay, now we’re cooking.”

Lesson learned: Don’t get emotionally attached to your first technical choice. Sometimes you have to kill your darlings (or your API integrations).

Act III: The “Products Don’t Match the Vibe” Problem

Even with better search results, I had a core problem: a “coastal grandmother” search might return linen blazers and weird promotional t-shirts. Google Shopping doesn’t care about your aesthetic.

This required multiple solutions layered together:

Visual Re-ranking with GPT-4o — Send product images back through vision AI and ask “does this match the vibe?” Score 1-10. Only show products scoring 6+.

Brand Scoring — Built tiered brand lists (aspirational, contemporary, trending) and boosted scores accordingly. The Row gets a higher vibe score than Shein.

Blocked Brands — Filtered out fast fashion entirely. Sorry, Temu.

Quality Gate — Strict minimum thresholds before any product appears.

The result: products that actually look like they belong in the same editorial spread.

The Hard Parts

Prompt engineering is deceptively difficult. Getting GPT-4V to return useful search queries took many iterations. Early versions returned things like “aesthetic clothing” (too vague) or “exact item from image” (not available). The system prompt went through probably 15+ revisions.

Deduplication is harder than it looks. Same product from different retailers, slightly different names, different image URLs. Had to normalize aggressively with two-layer matching: ID + URL, then normalized name + brand + price.

API costs add up. Visual re-ranking 50 products costs ~$0.50 per request. GPT-4V isn’t cheap when you’re sending images. Something to consider before you ship.

What I Learned (Technical)

Vision AI is powerful but imperfect. GPT-4V understands aesthetics surprisingly well — it can distinguish between “old money” and “new money minimalist” with reasonable accuracy. But it’s not 100% reliable. You need fallbacks and quality gates.

Shopping APIs are a mess. Every single one has quirks. Accept this and build accordingly.

Parallel processing matters. Running vision analysis and product search in parallel cut response time significantly. Don’t wait for things that can happen simultaneously.

Good prompts beat good code. The most impactful improvements came from prompt iteration, not architecture changes.

What I Learned (Process)

Ship early, iterate often. The first deployed version was embarrassing. Each iteration made it meaningfully better. Perfectionism is the enemy of shipping.

AI is a tool, not a replacement. I still made all the important decisions: what to build, how it should feel, when to pivot. AI accelerated execution but didn’t replace judgment.

Documentation helps AI help you. Keeping a CLAUDE.md file with project context made every coding session more productive. Your AI assistant only knows what you tell it.

What I’d Add Next

If I had another week (or was turning this into something real):

Multi-era timelines. “Show me 90s minimalism” vs. “show me 2024 minimalism” — same word, completely different vibes. Adding temporal context to aesthetic analysis would unlock way more specific results.

Redis session store. Currently everything lives in memory per request. Adding Redis would let users save mood boards, return to previous sessions, and build a persistent style profile.

User Profiles/Auth/Multi-user collaborative boards. “What should we wear to Sarah’s wedding?” becomes a shared mood board where everyone can upload inspo and vote on directions. Wedding party coordination as a feature.

The Final Numbers

• Build time: ~2 weeks (part-time)

• Total commits: 52

• APIs integrated: 4 (OpenAI, SerpApi, Google Trends, ShopStyle [deprecated])

• Aesthetic categories: 21

• Editorial brands tracked: 100+

• Major pivots: 1 (the ShopStyle disaster)

• Times I said “products don’t match the vibe”: Too many

Check out my work here:

GitHub URL: github.com/codebyellalesperance/moodboard

Actual Site: themoodboard.dev

DM me here! <3

Built with Claude Code + Antigravity + caffeine. Total vibes analyzed: countless. Products that actually matched: surprisingly many. CTRL+ALT+DELETE drops biweekly. Technical builds, honest breakdowns, working demos. Subscribe if that’s your thing:)

Connect your Spotify. AI distills your listening history into a creative “era” (”Sad Girl Autumn,” “Hyperpop Chaos,” “2014 Tumblr Recovery Arc”). Then you swipe through new recommendations like you’re on a dating app. Right swipe adds to a playlist. Left swipe moves on.

It took 22 hours, one OAuth meltdown, and a brief crisis about whether I actually understood cookies (turns out: I did not). Here’s the real engineering breakdown.

Architecture at a Glance

Frontend (Vanilla JS) → Flask API → Spotify Web API

↓

GPT-4o-mini (Era Analysis)

Optimized for zero dependencies, low latency, and fast iteration.

The Stack

Frontend: Vanilla JS + HTML + CSS (zero frameworks)

Backend: Python + Flask

AI: OpenAI GPT-4o-mini

Auth: Spotify OAuth 2.0

Design: Custom swipe physics + glassmorphism

Infra: Gunicorn + secure cookie storage + structured logging

Build Time: ~22 hours

Test Coverage: 94%

Why I Built This

Most AI music tools do one of two things:

1. Recommend more of what you already listen to

2. Force you to fill out a “vibe quiz” like a 2012 BuzzFeed article

Neither feels like real discovery. I want the kind where you flip through records at a store and accidentally stumble into the exact song you didn’t know you needed.

I wanted AI to create a narrative around my listening history, a musical “era,” (thank you Taylor Swift) and then let me explore new music inside that aesthetic. Something playful but engineered.

The Era Engine

The core of TasteSwipe is the “era” generator.

When users connect Spotify, I pull their top artists and tracks across multiple time ranges, normalize them, and send them to GPT-4o-mini with a structured prompt to generate:

• Era Name

• Era Description

• Energy Profile

• Recommended Micro-Genres

• Mood Tags

This structured output isn’t just for display, rather it feeds directly into Spotify’s recommendation API as seed parameters, so the swipe queue actually reflects the era’s energy and genre profile.

The hard part: prompt tuning.

Too literal → “Alternative Rock Listener.”
Too poetic → “Sonic Wanderer of the Ether.”

The sweet spot sits between specificity and absurdity. Shareable but personal.

Examples from real testers:

• “Sad Girl Autumn (Extended Director’s Cut)”

• “Hyperpop Chaos with Undertones of Emotional Unavailability”

• “Main Character Energy but Make It Acoustic”

I also rate-limit prompts and cache outputs for the session to keep latency low.

Frontend: Why I Went Full Vanilla

No React. No Vue. No bundlers. No node_modules folder the size of Jupiter.

For a micro-interactive MVP, simplicity wins:

• One login screen

• One swipe interface

• One playlist creation action

The swipe system uses custom pointer-based physics so the UI feels tactile.

javascript

card.addEventListener(’pointerdown’, startDrag);
card.addEventListener(’pointermove’, onDrag);
card.addEventListener(’pointerup’, endDrag);

function endDrag(e) {
  const threshold = window.innerWidth * 0.3;
  if (deltaX > threshold) handleLike();
  else if (deltaX < -threshold) handlePass();
  else resetCard();
}

Could I have used React? Sure. But adding a framework for five screens felt like hiring a full orchestra to play “Happy Birthday.”

Backend: Structure & Concurrency

The backend is split across three clean modules:

spotify_auth.py

• Handles OAuth flow

• Refreshes tokens automatically

• Stores encrypted HTTP-only cookies

• Protects against token theft and XSS

spotify_service.py

• Fetches top artists, tracks, genres

• Generates recommendation seeds

• Adds songs to playlists

• Handles rate-limit backoff (Spotify 429s)

ai_service.py

• Prompt templates

• Era generation

• Caching for repeated sessions

Concurrency

Flask alone won’t cut it for real traffic, so production runs on Gunicorn workers with:

• Preloaded app

• Worker timeouts

• Graceful restarts

Performance & Latency Choices

1. Low-Latency AI Calls

• GPT-4o-mini chosen for speed + cost

• Prompt tokens under 300

• Cached era results for 1 hour

2. Rate-Limit Resilience

Spotify is picky; I built automatic retries with exponential backoff.

3. Zero-Cost Frontend Performance

No bundlers → no JS bloat → instant load.

Security Hardening

• HTTP-only secure cookies

• No tokens in frontend JS (ever)

• Strict CORS by environment

• CSP (Content Security Policy)

• HSTS (HTTPS only)

• No localStorage token storage

• SameSite=Strict cookies

What Broke (and How I Fixed It)

OAuth Token Expiration

Tokens died after 59 minutes → 401s everywhere.
Fix: Auto-refresh middleware.

CORS

Local dev on :8000, API on :5000 → browser tantrum.
Fix: Env-aware CORS matrix.

Thin Listening Histories

Some users had almost no listening data → empty recommendations.
Fix: Fallback seed artists + weighted blend.

Session Persistence

Memory-based sessions died on deploy.
Fix: Redis in v2.

Testing (~94% Coverage)

Tests mock:

• Spotify API responses

• Token refresh loops

• Expired tokens

• Empty recommendation responses

• Bad AI outputs

• Auth failures

• CORS mismatches

Integration tests cover the real OAuth handshake using test keys.

What I’d Add Next

• Swipe history + long-term taste modeling

• Feedback loop (like/pass weighting)

• Multi-era timelines

• Redis session store

• Multi-user collaborative playlists

Check out my work here:

GitHub URL: https://github.com/codebyellalesperance/eras-wrapped

Actual Site: https://taste-swipe.onrender.com (let’s call this little hack a lesson in cost cutting:)

DM me here! <3

(p.s. to run locally: Clone → add Spotify keys → flask run)

CTRL+ALT+DELETE drops biweekly. Technical builds, honest breakdowns, working demos. Subscribe if that’s your thing:)

Why I Did This to Myself

You know that feeling when you have a brilliant product idea but absolutely no clue which AI tools to actually use or how to sequence the work?

“I want to build an AI email assistant for founders” → Opens 47 browser tabs. Tries ChatGPT, then Cursor, then Midjourney for some reason. Ends up buying a Notion template. Also somehow has $180 in pending charges from tools you used once.

Choosing the right AI stack is where ambition goes to die. So, enter the problem of this biweekly publication. I built AI Architect, basically a LLM-powered roadmap generator that takes any product idea and spits out a phase-by-phase execution blueprint with copy-pastable prompts for 50+ AI tools.

No more decision paralysis. No more “which tool should I use for this?” No more “what is the best way to prompt this tool?” Just: describe your idea, get a complete roadmap with tool-specific prompts ready to copy into Claude, Cursor, Midjourney, whatever.

The Promise vs. The Reality

The concept of “AI-powered project planning” is seductive: Type in your idea, get an intelligent breakdown of phases, tasks, and tool recommendations. But, as we know.. AI has a hard time with big tasks and distributed systems, the solution? Every prompt customized to your exact project context. Ship faster because the LLM figured out the plan for you.

That’s the vision.

The reality? 93 LLM calls taking 180 seconds and costing $0.50 per roadmap, followed by a deep dive into performance optimization that involved keyword matching algorithms, async/await patterns, Server-Sent Events for real-time progress tracking, and discovering that Gemini 3.0 is an industry disrupter (and maybe the best thing to happen to vibe-coding ever).

Oh, and I used Claude Code to assist in backend development. Because apparently “just build it” means “learn Python Flask, SSE, asyncio, and deployment in one sitting.” Claude helped me debug various routing bug and some issues that appeared here and there. As a build does.

But here’s the thing: the final system generates roadmaps in 8-15 seconds for $0.01-$0.03. That’s a 12x speed improvement and 10-15x cost reduction. And it actually works.

The Claim vs. The Setup

Build an AI roadmap generator that turns vague product ideas into actionable execution plans — without making users wait 2 minutes or bankrupting myself on API costs.

Requirements:

• Sub-15 second generation time

• Under $0.05 per roadmap

• Real-time progress feedback (no fake loading bars)

• Copy-pastable tool-specific prompts

• Beautiful glassmorphic UI that doesn’t look like a SaaS template

Non-Requirements:

• Actual project management integration (Notion, Linear, etc.)

• Real-time collaboration

• Payment/auth (MVP is free and public)

• Mobile app (web-first for rapid prototyping)

The Tech Stack

I wanted this to be fast, cheap, and smart. No “just call Claude 100 times” solutions. No brittle regex parsers. No fake progress indicators.

Backend:

• Flask - Lightweight Python web framework (perfect for rapid prototyping)

• Anthropic Claude - Sonnet 4 for planning, Haiku for prompt generation

• asyncio - Parallel LLM calls (3-5x speedup)

• Server-Sent Events (SSE) - Real-time progress updates

• gunicorn - Production WSGI server

Frontend:

• Vanilla JavaScript - No React bloat for a single-page app

• EventSource API - SSE client for live updates

• CSS Animations - Smooth glassmorphic transitions

UI/UX Partner:

• Gemini 3.0 - I’ll explain how this worked out later…

Why These Choices?

Flask over Django/FastAPI: Flask’s minimalism was perfect for a single-feature prototype. No ORM overhead, no admin panels I don’t need. Just routes, templates, and JSON responses.

Keyword matching over LLM routing: The magic sauce. Instead of calling Claude to match “Design user auth flow” → “Figma”, I built a scoring algorithm:

• Tool name match: 3 points

• Category match: 2 points

• Keyword match: 1 point each

This eliminated 28 LLM calls per roadmap and runs in milliseconds instead of seconds.

Template-first prompt generation: 50+ hand-crafted templates for tools like Cursor, Midjourney, Replit. Each template is phase-specific (research, creative, build, launch, ops) with role-playing personas and context injection. Only fall back to LLM generation for niche tools without templates.

SSE for progress tracking: WebSockets are overkill for one-way server→client updates. SSE is simpler, works everywhere, and doesn’t require connection management hell.

asyncio for parallelization: When 15 LLM calls run sequentially, that’s 30 seconds of waiting. When they run in parallel with asyncio.gather(), that’s 8 seconds. Same work, 4x faster.

The Build Log: The Good, The Bad, and What Was Just Weird

The Good

1. Gemini 3.0 crushed the frontend architecture.

I gave Gemini a vague aesthetic brief: “glassmorphic UI, intuitive interactive, premium feel, real-time progress with SSE integration.”

What I got back wasn’t just working code. It was design patterns I didn’t even know existed:

• Complete glassmorphic design system with backdrop-filter: blur() and layered depth

• Custom CSS animations for the progress circle (smooth strokeDashoffset transitions)

• Server-Sent Events integration with EventSource API — first try

• Expandable task accordions with smooth max-height animations

• Phase-specific color coding and icon systems

Minimal reprompting. I’d say “make the loading indicator feel more entertaining” and Gemini would come back with pulsing animations, opacity transitions tied to progress percentage, and background color shifts based on completion state.

Why Gemini 3.0 excels at frontend:

• Training on modern design systems - Knows glassmorphism, micro-interactions other models haven’t seen

• UI/UX intuition - Suggests improvements I didn’t ask for (like the expandable accordions)

• CSS-first thinking - Pure CSS animations instead of heavy libraries

• Multimodal understanding - Captures the feel from reference designs, not just the layout

Here’s the SSE integration Gemini generated on first try:

// Frontend: Connect to real-time progress stream
const sessionId = ‘session_’ + Date.now();
const eventSource = new EventSource(`/progress/${sessionId}`);

eventSource.onmessage = function(event) {
    const progress = JSON.parse(event.data);
    
    // Update progress circle
    const percent = progress.percent;
    const offset = circumference - (percent / 100) * circumference;
    progressCircle.style.strokeDashoffset = offset;
    progressPercent.textContent = Math.floor(percent) + ‘%’;
    
    // Update loading message
    loadingSubtext.textContent = progress.message;
    
    // Animate background opacity based on progress
    const bgOpacity = 0.3 + (percent / 100) * 0.6;
    loadingEl.style.backgroundColor = `rgba(0, 0, 0, ${bgOpacity})`;
};

2. Claude Code handled the backend optimization beautifully.

The division of labor that worked:

• Gemini 3.0: Glassmorphic UI skeleton, SSE EventSource integration, CSS animations, interactive state management

• Claude Code: Flask optimization, asyncio parallelization, template architecture, keyword matching algorithm, deployment config

Different strengths. Different tools. Better outcome.

3. Keyword matching was the killer feature I didn’t expect.

The scoring algorithm catches tool-task relationships without LLM overhead. When you input “Design authentication flow”, it routes to Figma/Miro/Whimsical based on category matches and keyword scores.

Here’s the algorithm that replaced 28 LLM calls:

def route_task_to_tools(task, tool_registry):
    “”“Score-based tool matching without LLM calls”“”
    task_text = f”{task[’description’]} {task[’outcome’]}”.lower()
    tool_scores = []
    
    for tool in tool_registry:
        score = 0
        matched_keywords = []
        
        # Tool name match: 3 points
        if tool.name.lower() in task_text:
            score += 3
            matched_keywords.append(tool.name)
        
        # Category match: 2 points
        for category in tool.categories:
            if category.lower() in task_text:
                score += 2
                matched_keywords.append(category)
        
        # Best_for keyword match: 1 point per keyword
        for use_case in tool.best_for:
            keywords = use_case.lower().split()
            for keyword in keywords:
                if len(keyword) > 3 and keyword in task_text:
                    score += 1
                    matched_keywords.append(keyword)
        
        if score > 0:
            tool_scores.append({
                ‘tool’: tool,
                ‘score’: score,
                ‘confidence’: min(score / 10, 1.0),
                ‘matched_keywords’: matched_keywords
            })
    
    # Return top 3 tools
    return sorted(tool_scores, key=lambda x: x[’score’], reverse=True)[:3]

Users assume it’s ML. Nope:) just good old-fashioned string matching and scoring. Instant, free, and accurate.

4. Template coverage scaled better than expected.

Started with 15 templates (6% coverage), added 35 more based on actual usage patterns. Final coverage: 85-95%. This single change eliminated 58 LLM calls per roadmap.

Here’s the template system that makes it work:

# Phase-specific templates with context injection
TEMPLATES = {
    “cursor”: {
        “build”: “”“You are a senior software engineer using Cursor AI.

Build: {description}
Project: {idea_summary}
Target Users: {target_user}

Write production-ready code with:
- Inline comments explaining logic
- Type safety (TypeScript/Python type hints)
- Error handling and edge cases
- Performance optimizations

Expected Output: {outcome}
Primary Goal: {primary_goal}”“”,
        
        “research”: “”“You are a technical architect using Cursor AI.

Research: {description}
Project Context: {idea_summary}

Investigate and document:
- Technical feasibility
- Architecture patterns
- Security considerations
- Scalability concerns

Deliverable: {outcome}”“”
    },
    
    “midjourney”: {
        “creative”: “”“You are an professional AI artist using Midjourney.

Design Brief: {description}
Project: {idea_summary}
Target Audience: {target_user}

Create visual concepts that:
- Align with brand identity
- Appeal to target demographic
- Work across multiple formats

Output: {outcome}
Style Goal: {primary_goal}”“”
    }
}

def get_template(tool_slug, phase_type):
    “”“Template lookup with fallback”“”
    if tool_slug in TEMPLATES:
        return TEMPLATES[tool_slug].get(phase_type)
    return None

5. asyncio parallelization was a game-changer.

Sequential API calls were killing performance. Switching to parallel execution with asyncio dropped generation time from 30s to 8s.

Here’s the pattern that unlocked 3-5x speedups:

import asyncio

async def generate_best_prompt_async(task, tool, project_profile, phase_type):
    “”“Async prompt generation with template fallback”“”
    template = get_template(tool.slug, phase_type)
    
    if template:
        # Template path: instant, no API call
        return fill_template(template, task, project_profile, phase_type)
    else:
        # LLM fallback: use Haiku (10x cheaper)
        return await self.llm.generate_async(
            system=”Generate a tool-specific prompt”,
            user=f”Task: {task[’description’]}\nTool: {tool.name}”,
            model=self.llm.haiku_model,
            max_tokens=1024
        )

async def process_all_tasks(tasks, tool_matches):
    “”“Process all tasks in parallel”“”
    async_tasks = []
    
    for task in tasks:
        for match in tool_matches[:3]:  # Top 3 tools per task
            async_tasks.append(
                generate_best_prompt_async(task, match[’tool’], profile, phase)
            )
    
    # Execute all in parallel
    results = await asyncio.gather(*async_tasks)
    return results

# Run the async function
all_prompts = asyncio.run(process_all_tasks(task_data, matches))

The magic: Network latency is hidden. While waiting for one API response, Python is already making 5 other requests.

The Weird

1. SSE timeout bug nearly broke everything.

I spent 2 hours debugging why my Server-Sent Events connection kept dying after exactly 60 seconds when I’d set max_timeout = 120.

The bug was subtle:

# Broken: Increments every iteration, not seconds
timeout_count = 0
max_timeout = 120
while timeout_count < max_timeout:
    time.sleep(0.5)
    timeout_count += 1  # This increments every 0.5s!
                        # So 120 iterations = 60 seconds, not 120

Fixed by tracking actual elapsed time:

# Working: Tracks real seconds
elapsed_time = 0
max_timeout = 300  # 5 minutes
poll_interval = 0.3

while elapsed_time < max_timeout:
    time.sleep(poll_interval)
    elapsed_time += poll_interval
    
    if session_id in progress_store:
        # New activity, reset timeout
        elapsed_time = 0

Lesson: When dealing with time-based logic, track actual time, not iterations.

2. The fake progress bar annoyed me more than expected.

My first version had a fixed 8-second loading animation. Didn’t matter if generation took 10 seconds or 180.

I kept refreshing and thinking: “Is this frozen? Is it actually working? Why can’t I see what’s happening?”

The fix required building a complete SSE architecture, but the result was worth it. Real-time progress updates with actual stage names (”Profiling project...”, “Planning phases...”, “Routing tools...”) turned anxiety into well debugged anticipation.

Sometimes the simplest features have the biggest UX impact, seeing exactly what the system is doing turns “is this broken?” into “oh cool, it’s working on routing tools now.”

3. Technical task IDs looked terrible in the UI.

During testing, seeing “P2T2:”, “P2T3:” everywhere made it look like I’d shipped debug output to production. Very unprofessional.

Fixed by replacing technical IDs with Material Icons and clean visual hierarchy:

<div class=”flex items-start gap-2 mb-2”>
    <span class=”material-icons text-sm mt-0.5 text-white/70”>
        check_circle
    </span>
    <div class=”flex-1”>
        <h4 class=”font-semibold text-white/90”>
            Design user authentication flow
        </h4>
        <p class=”text-xs text-white/60 mt-1”>
            Outcome: Complete auth wireframes with user flow diagrams
        </p>
    </div>
</div>

Sometimes polish is just removing the parts that remind people they’re using software.

The Broken

1. The first version was embarrassingly expensive.

After the first test generation, I looked at my logs and saw the following…

Performance Breakdown:

• Total LLM Calls: 93 calls costing $0.50

  • Planning calls: 2 ($0.05)

  • Tool routing calls: 28 ($0.28)

  • Prompt generation calls: 63 ($0.17)

• Generation Time: 180 seconds

• Template Coverage: 6% (only 6 out of 99 prompts)

My reaction after the first test: “there is no way that 180 second run didn’t cost me a million and a half token...but why?”

Fair question to ask myself.

The breakdown revealed the problem:

• ✅ 2 planning calls - Necessary for profile + phases

• ❌ 28 routing calls - Why am I using Claude to match tasks to tools?

• ❌ 63 generation calls - Only 6 prompts used templates, rest needed LLM generation

This was the moment I realized: Not every problem needs an LLM.

2. Vercel deployment failed spectacularly.

Tried deploying to Vercel because “serverless is the future.” Turns out Vercel has a 10-second timeout limit. My app needs 8-15 seconds minimum for generation. Also: no SSE support in serverless functions.

Error log looked like:

Error: Function execution timed out after 10.01 seconds

3. Switched to Render.com (free tier supports 300s timeouts and persistent connections). Problem solved instantly.

Template coverage started at 6%.

Only 6 out of 99 prompts used templates initially. The most commonly matched tools had no templates:

• intercom_fin, n8n, ideogram, leonardo, firefly

• chatbase, zendesk_ai, hubspot_ai, surfer_seo

• colossyan, fliki, pictory, spline, recraft

• deepseek, copyai, synthesia, heygen, capcut

The rest required expensive LLM generation. Had to manually analyze which tools were most commonly matched and write 35+ templates to get coverage to 85-95%.

What Worked (and Why It Mattered)

The biggest win came from profiling before optimizing.

I didn’t guess what was slow. I measured everything. Added detailed logging to every LLM call:

print(f”LLM Call #{call_count}: {purpose} ({model}) - ${cost}”)

This revealed that tool routing (not planning, not generation) was the biggest bottleneck. 28 calls at $0.01 each, adding 25 seconds to every roadmap.

The Aha Moment

The moment I realized keyword matching could replace those 28 LLM calls, everything clicked.

Not every problem needs an LLM. Sometimes the best code is the code you don’t write.

Why did this insight matter?

Because it revealed a fundamental truth about AI engineering: The best optimization isn’t using a faster model, it might just be in eliminating the call entirely.

LLMs are incredible for creative, strategic, open-ended tasks. But they’re expensive overkill for:

• Deterministic matching - keyword scoring beats LLM routing

• Repetitive formatting - templates beat LLM generation 85% of the time

• Simple data transformation - Python string formatting > LLM prompt filling

This led to the optimization cascade:

Step 1: Replace LLM routing with keyword matching
→ Eliminated 28 calls, saved $0.28, cut 25 seconds

Step 2: Expand template coverage from 6% to 85%
→ Eliminated 58 calls, saved $0.25, cut 45 seconds

Step 3: Switch remaining LLM calls from Sonnet to Haiku
→ 10x cost reduction on 5-15 calls, saved $0.12

Step 4: Parallelize everything with asyncio
→ 3-5x speedup on remaining calls, cut 20 seconds

Final Results:

Before optimization:

• Generation Time: 180 seconds

• Cost per Roadmap: $0.50

• LLM Calls: 93

• Template Coverage: 6%

After optimization:

• Generation Time: 8-15 seconds (12x faster)

• Cost per Roadmap: $0.01-$0.03 (10-15x cheaper)

• LLM Calls: 5-15 (85% reduction)

• Template Coverage: 85-95% (14x better)

The deeper architectural insight: AI-powered tools need to know when NOT to use AI.

Templates, heuristics, and caching eliminate all four problems. They’re instant, free, deterministic, and simple.

Lesson: Measure first, optimize later. Not every problem needs an LLM. Sometimes a scoring algorithm is faster, cheaper, and just as accurate.

(Admittedly, I can tell how this does go against the premise of the entire project. And no, I do not care. There are people who have cash to spend on these tools. Me right now? No thanks. Optimize, optimize, optimize.)

What I Learned (and Would Do Differently)

Start with templates, not LLM generation. Build template library early. LLM only for gaps. Template coverage as a KPI. This single change would have saved me $0.35 per roadmap from day one. (So, I guess around $7…)

Profile everything before touching code. Don’t guess what’s slow. Add logging. Track cost AND time. User experience > assumptions. I wasted an evening optimizing the wrong things before I added proper logging.

asyncio from day 1. Easier to build in than refactor later. Python’s async/await is surprisingly clean once you understand the pattern. Parallelization unlocks 3-5x speedups for almost zero effort.

SSE > WebSockets for one-way updates. Simpler to implement, works everywhere, no connection management hell. EventSource API is criminally underrated.

Gemini 3.0 understands modern UI patterns better than expected. It generated glassmorphic design systems and SSE integration with minimal prompting. Training data includes recent frontend trends other models haven’t seen. Use it for frontend skeleton and interactions.

Claude Code is unbeatable for backend architecture. From Flask optimization to deployment config, Claude Code thinks systematically about performance, error handling, and scaling. Use it for optimization and infrastructure.

Different AI tools for different problems. No single model is best at everything. The winning strategy is knowing which tool to use when:

• Gemini 3.0: Frontend design, modern UI patterns, visual systems

• Claude Code: Backend optimization, architecture, systematic thinking

• Claude Sonnet: Strategic planning, creative problem-solving

• Claude Haiku: Simple repetitive tasks at 10x lower cost

And as always: Backend isn’t scary. Flask is approachable. SSE is simpler than it sounds. gunicorn just needs the right timeout settings. Deployment to Render took 10 minutes.

The Verdict

Setup Time – 8/10
Flask + Claude Code made the backend smooth. Gemini 3.0 generated a production-ready frontend in one session. The SSE debugging cost me an evening, but the architecture is solid.

Performance – 9/10
8-15 second generation feels instant compared to 180 seconds. Template-based generation is instantaneous. asyncio parallelization hides network latency beautifully.

Reliability – 7/10
Core pipeline works perfectly. Template coverage at 85-95%. Still need proper error handling for API failures and better fallbacks when templates are missing.

Wow Factor – 10/10
When you input “Build an AI travel planner” and get back a complete 7-phase roadmap with 50+ copy-pastable prompts in 12 seconds — that moment of “it actually understood my idea” hits different. Real-time progress updates make it feel alive.

Reuse Potential – 9/10
This architecture (keyword routing + template-first generation + asyncio parallelization) would work for any AI-powered planning tool. The patterns are transferable.

Final Verdict: Worth it if you want to learn full-stack optimization while building something actually useful. 9/10 concept, 7/10 completeness (needs auth, error handling, and deployment monitoring).

The Meta Takeaway

We’re shifting from “use AI for everything” to “use the right AI for the right problem.”

The systems that survive won’t just call LLMs blindly. They’ll know when to use templates, when to use heuristics, when to parallelize, and when to actually invoke the expensive model.

My AI Architect isn’t the future, but it’s a prototype of one possible future. And it all started with decision paralysis, 47 open tabs, $200 in forgotten subscriptions, and the realization that AI tool selection is a search problem, not a decision-making problem.

Got an AI workflow you want me to over-engineer next? Send it my way.

Check out my work here:

GitHub URL: https://github.com/codebyellalesperance/ai-architect

Actual Site: https://ai-architect-ynxa.onrender.com/

DM me here! <3

You know that feeling when you’re standing in your kitchen at 6pm, staring into the abyss of your pantry, having absolutely no idea what food you actually own?

“Do I have tomatoes?” → Opens three cabinets, checks the fridge twice, finds expired tomato paste from 2023.

“What can I make for dinner?” → At work, spam calling roommates about who bought what, and when. Just to be followed up by ordering takeout.

Household inventory management is where good intentions go to die. So I built a Pantry App, a React Native solution that makes “what’s in my kitchen?” as easy as typing a search query.

No more expired mystery containers. No more buying duplicate pasta. Just: open app, search “tomato,” see exactly what you have and where it’s stored.

The Promise vs. The Reality

The concept of “intelligent pantry management” is sexy(?): Open an app, see your complete household inventory, add items with smart autocomplete, maybe even come up with recipe suggestions based on what you actually own. Never wonder if you need milk again.

That’s the vision.

The reality? Twelve (or more) TypeScript refactors, one Supabase Row Level Security meltdown, a three-tier product architecture that felt over-engineered until it wasn’t, and several moments of questioning why I didn’t just write things down on paper like a normal person.

But here’s the thing: it works. And when you type “tomat” and it suggests “tomato sauce (2 cans, pantry)” while also offering “Did you mean tomatoes?” — it feels like the future of not-forgetting-what-you-own.

The Claim vs. The Setup

Build a household inventory app that makes pantry management frictionless without the coordination overhead of shared grocery lists that nobody updates.

Requirements:

• Smart product search with typo tolerance (”tomatoe” → “tomato”)

• Three-tier product system (official catalog + community + custom)

• Category organization with collapsible sections

• Offline-first architecture with cloud sync

• Mobile-native feel (haptic feedback, smooth animations)

Non-Requirements (none of which I got to):

• Recipe recommendations (phase 2)

• Price tracking (phase 2)

• Barcode scanning (would be nice)

• Web version (mobile-first household tool)

The Tech Stack

I wanted this to be fast to build, data-rich, and maintainable. No “just write it in Notes app” compromises. No reinventing search algorithms poorly.

Here’s what I landed on:

Core Technologies

• React Native + Expo SDK for cross-platform mobile without the iOS/Android split

• TypeScript for type safety = fewer “undefined is not a function” crashes

• Supabase (PostgreSQL) for cloud database with real-time sync and Row Level Security

• Three-tier product architecture for balancing curation with user flexibility

• Levenshtein distance algorithm for fuzzy search that handles typos gracefully

• AsyncStorage for offline persistence and recent searches

Dev Tools

• Claude for architecture planning, database schema design, algorithm selection

• Cursor IDE for debugging React Native quirks and TypeScript gymnastics

• Expo Go for instant device testing without builds

Why These Choices?

Expo over bare React Native: Expo provides instant hot reload, managed workflow, and handles native modules without ejecting. For rapid prototyping with complex data flows, it’s unbeatable. You can always eject later if you need custom native integrations.

Three-tier product system: The magic sauce. Instead of one big messy product table, I built:

1. Official catalog (100 curated grocery items)

2. Community contributions (users add products everyone can use)

3. Custom household items (”Mom’s special sauce”)

This balances data quality with user flexibility — and prevents the Wikipedia problem where anyone can corrupt core data.

PostgreSQL + RLS: Supabase gives you real-time subscriptions, user authentication, and Row Level Security policies out of the box. No rolling your own user management or websocket infrastructure.

The Build Log: What Worked, What Failed, and What Got Weird

The Good

React Native + Expo delivered on the promise. I went from empty project to working prototype in about a week of evening coding, and the hot reload feedback loop felt instant. No Xcode compilation delays, no Android Gradle mysteries.

The three-tier search architecture held up beautifully. Users can find anything:

• Search “pasta” → Shows official catalog items + community additions + your custom “gluten-free pasta from that fancy store”

• Type “tomatoe” → Levenshtein distance catches the typo and suggests “tomato”

• Recent searches persist locally, so “pasta” becomes one tap

Here’s the search flow that actually works

// Multi-source fuzzy search with score boosting
const searchResults = await Promise.all([
  searchCatalogProducts(query),       // Official curated items  
  searchUserContributedProducts(query), // Community catalog
  searchCustomProducts(query)         // Household-specific
]);

// Apply source boosting: custom > community > catalog
const boostedResults = results.map(result => ({
  ...result,
  score: result.score * getSourceBoost(result.source)
}));

Fuzzy search was the killer feature I didn’t expect. The Levenshtein distance algorithm catches common typos and makes the app feel psychic. When you type “tomatoe” and it suggests tomato products, users assume you’re doing machine learning. Nope — just good old-fashioned edit distance math.

Mobile UX details mattered more than I thought. 48px minimum touch targets, haptic feedback on autocomplete selection, and keyboard navigation (arrow keys work!) transformed the experience from “functional” to “feels native.”

The Weird

Row Level Security nearly broke everything.

I spent 4 hours debugging this error:

new row violates row-level security policy for table “catalog_products”
Error code: 42501

The upload script was using an anonymous key to insert catalog data, but RLS policies only allowed service role access. The fix was simple (temporarily disable RLS during upload), but the debugging was painful.

Lesson: Test your database permissions with the actual keys you’ll use in production.

SwipeListView has opinions about null returns.

My collapsible categories were removing items entirely instead of hiding them. Turns out SwipeListView doesn’t handle conditional rendering (return null) well — it treats missing items as deleted items.

Fixed by filtering data instead of rendering conditionally:

// Broken: Returns null for collapsed categories
renderItem={({ item }) => {
  if (!expanded) return null; // SwipeListView gets confused
  return <ItemRow item={item} />;
}}

// Working: Filter data before rendering
data={expanded ? categoryItems : []}
extraData={expandedCategories} // Force re-render

The autocomplete became accidentally delightful.

I added recent searches as an afterthought — just store the last 5 queries in AsyncStorage. But during testing, friends kept commenting on how “smart” it felt to see their previous searches appear instantly. Sometimes the simplest features have the biggest UX impact.

The Broken

Authentication is a placeholder everywhere. Every time a user creates a custom product, I’m using temp_user_id instead of real authentication. Supabase Auth is sitting there, waiting to be integrated, but I prioritized the core inventory loop first.

// TODO: Replace this everywhere
const userId = ‘temp_user_id’; // 😅

The missing RPC function haunts my logs. I reference increment_user_contributed_usage in the code to track popular community products, but never actually created the database function. So every time someone selects a community item, there’s a failed SQL call.

Category collapse animation is still janky. When you tap to collapse a category, items disappear instantly instead of smoothly animating out. React Native’s LayoutAnimation should handle this, but SwipeListView fights with it. Sometimes you ship the behavior first, polish later.

What Worked (and Why It Mattered)

The biggest win came from building the search experience first, with mock data. Once I had fuzzy search working with instant results, everything else became data plumbing instead of UX uncertainty.

But the deeper insight was architectural: household inventory is a multi-user, multi-device problem disguised as a simple list app. You’re not just tracking items — you’re coordinating family members, handling different input patterns (voice, barcode, manual), and dealing with the social dynamics of “who forgot to update the app when they used the last milk?”

Claude sketched the three-tier product architecture and database schema; Cursor kept the build moving by catching SwipeListView edge cases and TypeScript prop mismatches before I hit them. The pairing created an unexpected rhythm — strategic thinking meets tactical debugging, both learning the domain as we went.

Lesson: Most of what we call “good product design” is actually friction removal and invisible complexity management done right.

What I Learned (and Would Do Differently)

Mock data first isn’t just about speed: it’s about truth. You can’t fake search behavior in Figma. Build the interaction, then optimize the algorithm.

Three-tier architecture was worth the complexity. I almost built one giant “products” table. The curated catalog + community contributions + household custom items separation creates better data quality and user mental models.

TypeScript caught the navigation bugs before users did. React Navigation’s type safety for screen params alone justified the setup cost:

navigation.navigate(’AddItem’, { productName: undefined }); // ❌ TypeScript error
navigation.navigate(’AddItem’, { productName: ‘tomatoes’ }); // ✅ Passes type check

AI pair-building changes the development rhythm. Claude for architecture and algorithm selection, Cursor for debugging and React Native patterns. It’s collaborative, not automated. The AI suggests, I decide, we both learn the domain.

(Quick note on using Claude in this way — try not to let the model ‘summarize’ and continue to iterate too many times after. Open a new tab to minimize ‘over-contexting’ the model.)

And as always: Database permissions first, fuzzy search second, authentication eventually.

The Verdict

Setup Time – 7/10
Expo + Supabase makes the happy path very smooth. The Row Level Security debugging cost me an evening, but that’s on me for not reading the docs.

Performance – 8/10
Fuzzy search with 300ms debouncing feels instant. LRU cache prevents redundant database calls. SwipeListView occasionally stutters on category collapse, but the core interaction is smooth.

Reliability – 7/10
Search works perfectly, authentication is mocked, RPC functions are missing. It’s a prototype that knows what it wants to be when it grows up.

Wow Factor – 9/10
When you type “tomatoe” and it corrects to “tomato sauce (2 cans, pantry)” — that moment of “it understood me” hits different. Fuzzy search feels like magic until you implement it.

Reuse Potential – 9/10
This architecture (three-tier products + fuzzy search + RLS) would work for any inventory/catalog app. The patterns are transferable.

Final Verdict: Worth it if you enjoy solving coordination problems with code instead of spreadsheets. 8/10 concept, 6/10 completeness (needs real auth).

The Meta Takeaway

We’re shifting from “remember to update the list” to “the list updates itself.” The future of household management isn’t better organization — it’s invisible coordination.

The systems that survive won’t just track inventory; they’ll predict needs, handle multiple input methods (voice, scan, type), and coordinate family members without requiring everyone to be diligent list-maintainers.

My Pantry app isn’t the future, but it cold be a prototype of one. And it all started with expired tomato paste, a frustrated “what do we even have?” moment, and the realization that inventory management is a search problem, not a memory problem.

Next up: Integrating actual authentication, building the missing RPC function, and maybe finally tackling that barcode scanner. Because typing “organic whole wheat pasta” gets old fast. And (maybe) getting it into the app store so my roommates can see what I’ve been typing at for the last two weeks:)

Got a household coordination problem you want me to over-engineer next week? Send it my way.

DM me here! <3

You know that feeling when you’re bored on a Saturday afternoon, willing to grab coffee or go for a run, but coordinating with friends feels like solving a Rubik’s cube blindfolded?

“Anyone free?” → 12 unread messages, 3 maybes, 0 confirmed plans.

Group chats are where spontaneity goes to die. So I built Whim — a React Native app that makes last-minute hangouts as easy as posting an Instagram story.

No polls. No “what works for everyone?” threads. Just: “I’m getting coffee in 20 minutes. Who’s in?”

The Promise vs. The Reality

The concept of “spontaneous social coordination” is seductive: Open an app, see what friends are doing right now, tap once to join them. No group chat negotiations, no “what works for everyone?” threads that die in async hell.

That’s the vision.

The reality? Twelve TypeScript errors, three navigation refactors, one NativeWind configuration meltdown, and several moments of questioning why I didn’t just stick with group chats.

But here’s the thing: it works. And when your friend posts “coffee run in 15 mins” and you join with one tap, it feels like the future of hanging out.

The Claim vs. The Setup

Build a social activity app that makes last-minute hangouts frictionless—without the coordination overhead of group chats.

Requirements:

• Post spontaneous activities (”Coffee now” / “Dinner at 7pm”)

• Discover what friends are doing nearby

• Join or decline with one tap

• Privacy controls (public vs friends vs close friends)

• Location-based filtering with configurable radius

• Native mobile feel (smooth animations, intuitive navigation)

Non-Requirements:

• Complex scheduling algorithms

• Built-in messaging (keep it simple)

• Web version (mobile-first)

• Monetization (yet)

The Tech Stack

I wanted this to be fast to build, cross-platform, and maintainable. No native iOS/Android split. No compromise on UX.

Here’s what I landed on:

Core Technologies

• React Native + Expo SDK forCross-platform mobile (iOS + Android) without ejecting

• TypeScript for type safety = fewer runtime crashes, better DX

• React Navigation v6 for Native navigation with stack + bottom tab navigators

• NativeWind v4 for Tailwind CSS for React Native (utility-first styling)

• shadcn/ui patterns for Reusable component library (Button, Card, etc.)

Dev Tools

• Claude for architecture planning, component design, debugging patterns

• Cursor IDE for inline AI assistance for React Native quirks and TypeScript errors

• Expo Go for instant device testing without builds

• React DevTools for Component tree debugging

Why These Choices?

Expo over bare React Native:
Expo provides instant hot reload, easy deployment, and handles native modules without ejecting. For rapid prototyping, it’s unbeatable. You can always eject later if you need custom native code.

TypeScript:
React Navigation’s type safety alone justifies this. Autocomplete for screen names and params prevents 90% of navigation bugs.

The Build Log: What Worked, What Failed, and What Got Weird

The Good

React Native + Expo delivered on the promise. I went from empty project to working prototype in 12 hours, and the hot reload feedback loop felt instant.

The navigation architecture held up beautifully. TypeScript caught navigation prop mismatches before runtime:

navigation.navigate(’NonExistentScreen’); // ❌ TypeScript error
navigation.navigate(’Home’); // ✅ Passes type check

That saved me from the classic React Navigation bug: pushing to a screen that doesn’t exist and only discovering it when a user taps a button.

The UX flow worked intuitively. I tested with friends (using mock data) and they immediately got it:

• Open app → See activities nearby

• Tap one → Full details modal

• Join button → You’re in

No tutorials needed. No confusion about “Now” vs “Soon” buckets. The Instagram-style feed pattern translated perfectly to spontaneous hangouts.

NativeWind styling was shockingly fast. Compare:

// Old way (StyleSheet)

const styles = StyleSheet.create({

   container: {

    flex: 1,

    backgroundColor: ‘#ffffff’,

    paddingHorizontal: 16,

    paddingTop: 48,

  },

  title: {

    fontSize: 24,

    fontWeight: ‘bold’,

    marginBottom: 16,

  },

});

// New way (NativeWind)

<View className=”flex-1 bg-white px-4 pt-12”>

  <Text className=”text-2xl font-bold mb-4”>What’s Happening</Text>

</View>

I styled the entire app in ~2 hours. With StyleSheet, that would’ve taken a full day.

The Weird

Expo’s “managed workflow” occasionally feels too magic.

I tried to add native iOS haptic feedback:

import * as Haptics from ‘expo-haptics’;

// Trigger haptic on button press
Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Medium);

It worked instantly. No Xcode. No bridging code. No gradle files. Just... worked.

That feels great until you hit a limitation and realize you don’t understand the abstraction layer. It’s like driving an automatic car—smooth until you need to pop the hood.

The “Close Friends” tier sparked unexpected product questions.

I added three friend categories:

• Friends (general connections)

• Close Friends (inner circle)

• Requests (pending)

During testing, a friend asked: “How do I know if I’m someone’s close friend?”

Great question. No idea. Should the app show this? Is it private? Does it create awkward situations if someone sees they’re not a close friend?

Instagram Stories solves this by making it private (you never know if you’re on someone’s close friends list). But for spontaneous hangouts, that asymmetry might feel worse.

UI decision I’m still questioning: Should declined activities disappear or remain visible?

Right now, if you tap “Decline,” the activity stays in your feed (because someone else might join). But does that feel naggy? Should it hide for 24 hours? Or move to a separate “Passed” tab?

I don’t know yet. Need real users.

The Broken

The map is a placeholder box. That gray rectangle where the map should be? It may or may not haunt me. Without real location visualization, the “zone” concept feels abstract. I know the radius is 5 miles, but show me.

I didn’t implement react-native-maps because it requires separate API keys for iOS and Android, custom marker components, clustering logic for performance, and permission handling that goes beyond Expo’s managed workflow. That’s easily a full weekend. For a 12-hour prototype validating UX patterns, I chose to ship the interaction model first. The map can wait, for now at least.

Push notifications are the killer feature, that are not currently implemented (whoops!). The magic should be: Friend posts → You get notified → Tap → Join. Without that, Whim is just Instagram for hangouts. The coordination tool is missing its coordination.

Expo’s push notification setup requires server-side token management, notification permissions handling, deep linking configuration, and testing on physical devices (simulators don’t support push). Worse, the entire value prop depends on perfect notification delivery—flaky notifications kill trust. I’d rather ship a working feed first, then add the real-time layer once the core behavior is validated.

What Worked (and Why It Mattered)

The biggest win came from building UI-first with mock data. Once I had real interactions to validate, everything else became implementation details, not product questions.

But the deeper insight was architectural: mobile-first design changes how you think about spontaneity. Instead of “planning apps,” you build for impulse. The difference between “Let’s grab coffee sometime” and “Coffee in 15 mins” isn’t scheduling—it’s removing every friction point between intent and action.

Claude sketched the navigation architecture and component hierarchy; Cursor kept the build moving by catching TypeScript errors and suggesting React Native patterns before I hit them. The pairing created an unexpected rhythm—strategy meets execution, both adapting to my workflow as I went.

Lesson: Most of what we call “good UX” is actually psychological friction removal done right.

What I Learned (and Would Do Differently)

1. Mock data first isn’t just about speed—it’s about truth. You can’t fake user behavior in Figma. Build the interaction, then add infrastructure.

2. Fewer screens, deeper flows. I almost built a separate “activity history” tab. Glad I didn’t. Probably would’ve diluted the core loop.

3. Watch real humans tap things. My friend tried to swipe cards left/right to decline. Didn’t expect that. Now I’m considering it.

4. AI pair-building is real. Claude for architecture, Cursor for debugging. It’s a workflow that feels collaborative, not automated.

And as always: TypeScript first, native modules second.

The Verdict

Setup Time – 8/10
Expo makes this almost too easy. npx create-expo-app to working prototype in 12 hours. The NativeWind v4 config was the only real friction.

Performance – 8/10
Instant hot reload & smooth navigation. React Native has come a long way. No janky transitions, no dropped frames. (Although most of the backend still has a ways to come…)

Reliability – 7/10
Navigation works perfectly, but modal state management got weird without Context API. Spent 2 hours debugging prop drilling before refactoring.

Wow Factor – 8/10
That moment when a friend said “Wait, I’d actually use this” hit different. Validation > perfection.

Reuse Potential – 9/10
This codebase is a template for any location-based social app. The navigation structure, modal patterns, and NativeWind setup are all reusable.

Final Verdict: Worth it if you enjoy shipping fast and iterating faster. 9/10 concept, 7/10 completeness (needs backend).

The Meta Takeaway

It does feel like nowadays, in the age of async communication overload, social coordination shouldn’t require 47 messages and a Doodle poll. Things like context, proximity, and timing are valuable data and can make spontaneous hangouts feel effortless instead of exhausting.

We’re shifting from social planning apps to social impulse tools. The systems that survive won’t just organize—they’ll reduce friction, respect attention, and make “anyone free?” actually work.

Whim isn’t the future—but it’s a prototype of one. And it all started with a frustrating group chat, some coffee plans that never happened, and the realization that coordination is a UX problem, not a people problem.

See my work on GitHub (coming soon—need to clean up those commit messages first 😅)

Got a project idea you want me to build next week? Send it my way. My terminal is hungry.

DM me here! <3

Every conversation with ChatGPT feels like talking to a brilliant goldfish.
It dazzles you for thirty seconds, then forgets who you are. I wanted to change that cycle, and thus I decided to build a local “Second Brain”—a small memory system that lets AI actually remember me without shipping my thoughts to the cloud or binging OpenAI tokens.

The result? A semi-functional prototype that now knows I like sushi, am trying to nail down a consistent running routine, and have a have a bit of an obsession with following dachshunds in cute jackets on instagram. It also knows too much about my work habits, but that’s another story (and one I am not permitted to tell on here)…

The Claim vs. The Setup

The concept of “AI memory” is seductive:
Every assistant you use should start where you left off, fully caught up on your goals, patterns, and context, and grow alongside you over time.

That’s the claim.

The reality?
Fourteen browser tabs, two environment variables, and one emotional breakdown later, I had a working system that sometimes forgot its own encryption password.

Tech Stack

• Node 20, TypeScript

• SQLite for metadata, JSON for vector storage

• Local embeddings via @xenova/transformers

• Whisper for voice input

• AES-256 encryption

• Claude for high-level architecture and system planning

• Cursor IDE for coding, debugging, and live iteration (Cursor’s inline AI chat saved me hours)

Goal

Build a lightweight memory engine that plugs into Claude’s Model Context Protocol (MCP), runs locally, and supports adding and searching “memories” semantically—without cloud APIs.

The Build Log: What Worked, What Failed, and What Got Weird

The Good

Local embeddings worked better than expected.
I started by adding a few sample memories:

yarn cli add “I love spicy tuna rolls and prefer it without soy sauce”

yarn cli add “Remember that my favorite candy is Twizzlers”

yarn cli add “I tried a new Italian spot and had an amazing tiramisu last week”

Then I ran:

yarn cli search “what kind of desserts or foods do I like?”


Then output:

1. I tried a new Italian spot and had an amazing tiramisu last week

2. I love spicy tuna rolls and prefer it without soy sauce

3. Remember that my favorite candy is Twizzlers

It understood the meaning, not just the words.
That first moment of semantic recall felt more like a spooky ghost AI memory—messy, human, and a little scary. Think Baby Reindeer meets low budget Silicon Valley.

The Weird

Once integrated with Claude via MCP, things got uncanny.
When I asked, “What kind of food do I like?”, Claude replied:

“You enjoy sushi—specifically spicy tuna rolls without soy sauce—and recently raved about tiramisu at a new Italian restaurant. You also mentioned Twizzlers as your favorite candy.”

That came entirely from local memory—no API calls, no data sync.

Claude felt like an assistant that had actually been paying attention.

The Broken

Naturally, TypeScript had opinions.

• The compiler refused to build because of a missing rootDir.

• Async functions hung on exit.

• The embedding model occasionally stalled mid-load.

• Encryption worked too well—I locked myself out of my own data twice.

Cursor’s in-IDE debugger saved me here. Using its inline chat, I traced stack errors and refactored live. Claude handled system-level architecture while Cursor fixed the fires in real time. It felt like working with two coworkers—one calm strategist, one caffeine-fueled firefighter.

What Worked (and Why It Mattered)

The biggest win came from using local embeddings instead of cloud APIs.
Once cached, they cut query latency by roughly 60% and removed rate limits entirely.

But the deeper insight was architectural: local-first design changes how you think about memory.
Instead of AI “sessions,” you build an evolving knowledge base.

Claude sketched the high-level schema and encryption flow; Cursor kept the build moving by catching subtle type and logic errors before I did. The pairing created an unexpected rhythm—strategy meets execution, both learning me as they went.

Lesson: most of what we call “AI intelligence” is actually human scaffolding done right.

What I Learned (and Would Do Differently)

1. Local-first isn’t just about privacy—it’s about trust. You design for autonomy, not dependency.

2. Fewer memories, deeper meaning. Debug three examples before adding thirty.

3. Observe your vectors. Logging cosine similarity scores early saves endless guessing.

4. AI pair-building is real. Claude for architecture, Cursor for debugging—it’s a workflow that feels collaborative, not automated.

And as always: caffeine first, YAML second.

The Verdict

Setup Time – 5/10
More “hackathon” than “hello world.” Expect a few hours of dependency wrestling before you see a clean and compatible build.

Performance – 8/10
Once the embeddings cache locally, the whole thing flies. Searches feel instant, even with hundreds of entries.

Reliability – 6/10
Solid when it works, but every now and then the vector index forgets what reality is. A quick rebuild usually fixes it.

Wow Factor – 9/10
That first recall moment (when the AI references your past sushi order or candy preference) is borderline eerie in the best way.

Reuse Potential – 7/10
It’s a great backbone for future personal AI projects or as a component inside bigger local-first experiments.

Final Verdict:
Worth it if you enjoy debugging your own mind in TypeScript.
10/10 concept, 6/10 sanity.

The Meta Takeaway

It does feel a bit like nowadays in the age of information that every assistant you use should just be able to instantly come up to speed on you. Things like context, history, and growth is valuable data and can give any AI tool helpful or even necessary data on a user. Think tailoring responses to potentially avoid drastic impacts on well being or mental health, but I’ll let you go down that hole.

We’re shifting from AI as app to AI as adaptive runtime.
The systems that survive the test of time won’t just respond; they’ll remember, refine, automate and grow with you.

My local memory engine isn’t the future—but it’s a prototype of one.
And it all started with sushi, Twizzlers, and tiramisu.

See my work on GitHub:)

Got a tool or an idea you want me to break next week?
Send it my way. My error logs are hungry.

DM me here! <3

Subscribe now