DEV Community: Jakub

The boring stack behind 14 live products

Jakub — Thu, 07 May 2026 18:13:28 +0000

Running 14 products on the same stack sounds like a scaling nightmare. It's not. It's actually the only thing keeping me sane.

The stack

Every product at Inithouse runs on three layers:

Lovable for the frontend. React SPAs, component library, built-in Cloudflare Pages deployment. I don't write boilerplate. I describe what I want, iterate in real time, and hit Publish. A new product goes from idea to live URL in hours, not weeks.

Supabase for the backend. Postgres with Row Level Security, edge functions for anything custom, real-time subscriptions where needed. The SQL editor alone saves me from building admin panels for half the products.

Cloudflare Pages for hosting. Every Lovable publish pushes to CF automatically. I add a custom domain, set up _headers for cache control and content types, and that's it. Global CDN, no config.

Analytics: GA4 for traffic, Microsoft Clarity for session replays and heatmaps.

Why this works for solo building

The whole point is speed of iteration. When you're validating 14 MVPs, you don't need the perfect architecture. You need to ship, measure, and decide fast.

Magical Song went from concept to paying customers in a single weekend. Same stack as Be Recommended, which targets a completely different market (AI visibility for brands). The shared foundation means bug fixes in one product often improve another.

Supabase edge functions handle the weird stuff: AI song generation triggers, LLM API calls for visibility scoring, payment webhooks. All in TypeScript, deployed in seconds.

Where it breaks

No SSR. Lovable builds React SPAs. That means client-side rendering only. For SEO-heavy products, this hurts. I work around it with Cloudflare Workers for meta tags and pre-rendering, but it's a patch, not a solution.

Supabase edge functions have cold starts. Not terrible (200-500ms), but noticeable on first load for latency-sensitive features.

Shared patterns create coupling. When I update the blog system on one product, I'm tempted to update all 14. Sometimes that's efficient. Sometimes it introduces bugs in products I haven't touched in weeks.

Lovable's AI chat sometimes hallucinates component structures. When it works, it's magic. When it doesn't, you spend more time debugging generated code than you'd spend writing it from scratch.

The trade-off I made

The obvious alternative: Next.js + Vercel. Better SSR, better SEO out of the box, mature ecosystem.

I chose Lovable because iteration speed beats architectural purity when you're searching for product-market fit. Once a product finds traction, migrating the frontend is a known problem. Not finding PMF because you spent three months on infrastructure is a dead-end problem.

Fourteen products, three tools, zero regret about the boring parts.

Jakub, builder @ Inithouse

The useSEO hook pattern: why I dropped React Helmet across 14 projects

Jakub — Thu, 07 May 2026 06:10:29 +0000

React Helmet is great. It's also too much for a SPA with twelve dynamic blog routes. Here's what I shipped instead.

I run Inithouse, a portfolio of about 14 web products. All built as React SPAs. Every single one needs proper meta tags for SEO: title, description, Open Graph, Twitter cards, JSON-LD. The usual stuff.

I started with React Helmet. Worked fine for the first app. By app three, I was copy-pasting the same boilerplate helmet component across repos, fighting with nested helmet instances, and wondering why my bundle had an extra 12KB just to set a page title.

So I wrote a hook. About 20 lines. It replaced Helmet across every project.

The hook

import { useEffect } from 'react';

interface SEOProps {
  title: string;
  description?: string;
  image?: string;
  url?: string;
  type?: string;
  jsonLd?: Record<string, unknown>;
}

export function useSEO({ title, description, image, url, type = 'website', jsonLd }: SEOProps) {
  useEffect(() => {
    document.title = title;

    const setMeta = (name: string, content: string) => {
      if (!content) return;
      let el = document.querySelector(\`meta[name="\${name}"], meta[property="\${name}"]\`);
      if (!el) {
        el = document.createElement('meta');
        el.setAttribute(name.startsWith('og:') || name.startsWith('article:') ? 'property' : 'name', name);
        document.head.appendChild(el);
      }
      el.setAttribute('content', content);
    };

    if (description) {
      setMeta('description', description);
      setMeta('og:description', description);
      setMeta('twitter:description', description);
    }
    setMeta('og:title', title);
    setMeta('twitter:title', title);
    setMeta('og:type', type);
    if (image) {
      setMeta('og:image', image);
      setMeta('twitter:image', image);
      setMeta('twitter:card', 'summary_large_image');
    }
    if (url) {
      setMeta('og:url', url);
      const link = document.querySelector('link[rel="canonical"]') || document.createElement('link');
      link.setAttribute('rel', 'canonical');
      link.setAttribute('href', url);
      if (!link.parentNode) document.head.appendChild(link);
    }

    if (jsonLd) {
      let script = document.getElementById('json-ld-seo');
      if (!script) {
        script = document.createElement('script');
        script.id = 'json-ld-seo';
        script.type = 'application/ld+json';
        document.head.appendChild(script);
      }
      script.textContent = JSON.stringify(jsonLd);
    }

    return () => {
      document.getElementById('json-ld-seo')?.remove();
    };
  }, [title, description, image, url, type, jsonLd]);
}

That's it. No provider, no context, no side-channel for server rendering. Just a hook that touches the DOM.

How I use it

Every page or route component calls it at the top:

function BlogPost({ post }) {
  useSEO({
    title: \`\${post.title} | My App\`,
    description: post.excerpt,
    image: post.heroImage,
    url: \`https://myapp.com/blog/\${post.slug}\`,
    type: 'article',
    jsonLd: {
      '@context': 'https://schema.org',
      '@type': 'BlogPosting',
      headline: post.title,
      author: { '@type': 'Person', name: 'Jakub' },
      datePublished: post.publishedAt,
      image: post.heroImage,
    },
  });

  return <article>...</article>;
}

Blog index, product landing, about page, FAQ. Same pattern everywhere. The hook handles the meta tag creation, update, and JSON-LD injection in one call.

Why not React Helmet?

Couple of reasons that mattered for my setup:

Bundle size. React Helmet pulls in react-side-effect and handles nested instances with a priority queue. For a SPA where only one component sets meta at a time, that's dead code.

SSR complexity. Helmet has a whole server rendering story with Helmet.renderStatic(). If you're doing SSR, great. My apps are client-rendered SPAs deployed to static hosting. I don't need server extraction. Google crawls JavaScript fine for most content.

Mental model. Helmet feels like a component you render. The hook feels like a side effect you declare. For meta tags (which are side effects), the hook model clicks better with how React works now.

Edge cases I hit

Route changes. React Router triggers a re-render, the hook runs again, meta updates. Clean. But if you navigate from a page with JSON-LD to one without, the old script tag stays unless you clean up. The return cleanup in the useEffect handles this.

Multiple hooks on one page. If two components both call useSEO, the last one wins. That's usually fine. The page-level component should be the one setting meta. If you need nested overrides, you need Helmet. I never did.

Missing description. Some crawlers penalize pages without a meta description. The hook only sets it if you pass one. I added a lint rule: every route component must pass at least title + description.

Dynamic content. Blog posts loaded from an API. The hook runs on mount with empty strings, then re-runs when data arrives. Brief flash of wrong meta. Not great for social share previews if a bot hits it before data loads. I prerender critical pages with a simple build step for this.

JSON-LD per route

This was the real win. Each product in the portfolio has different structured data needs. Be Recommended needs SoftwareApplication schema. Magical Song needs Product + MusicComposition. Blog posts need BlogPosting.

With Helmet, I'd nest JSON-LD scripts inside JSX which felt wrong. With the hook, JSON-LD is just another parameter. Type-safe, cleaned up on unmount, one script tag in the head.

When you should NOT use this

If you need SSR meta extraction, use Helmet or a framework-level solution (Next.js Head, Remix meta). If you have deeply nested components that all want to contribute meta tags, use Helmet's priority system.

For client-rendered SPAs where one component per route owns the page meta? A hook is simpler, smaller, and easier to reason about.

The pattern scales

I've shipped this across Audit Vibe Coding, Watching Agents, Voice Tables, and about ten other projects. Copy the hook file, import it, done. No package to install, no version to track.

Sometimes the boring solution is the right one.

Building 14 products at Inithouse. Writing about what actually ships.

Content API Beats Clicking Publish: Why I Stopped Using the UI

Jakub — Wed, 06 May 2026 22:10:45 +0000

I haven't clicked Publish in three weeks. My blog has more posts than ever.

When you run one product, the editor workflow makes sense. Open dashboard, write, click Publish, done. Maybe five minutes of overhead. No big deal.

But I run 14 products. Each has its own blog on its own domain. Each blog needs fresh content for SEO, for AI visibility, for keeping the product alive in search results. Multiply that five-minute overhead by 14 and suddenly you're spending an hour just navigating dashboards before you've written a single word.

So I built a Content API instead.

The Problem With UI Publishing at Scale

Every blog platform has a slightly different editor. Different button placement, different preview behavior, different autosave quirks. When you're context-switching between 14 products in a day, that cognitive load adds up fast.

Here's what a typical morning used to look like:

Open project for Product A
Navigate to blog section
Write post in the rich text editor
Preview, fix formatting issues
Click Publish
Verify the sitemap updated
Submit to Google Search Console
Repeat for Product B, C, D...

By product number four, I'd already lost 20 minutes to just navigating UIs. The actual writing was maybe 30% of the time spent.

What a Content API Looks Like

The idea is dead simple. Instead of clicking through a UI, you POST a JSON payload to an endpoint and the blog post appears on your site.

curl -X POST https://yourproduct.com/api/blog/publish \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "How We Reduced Load Time by 40%",
    "slug": "reduced-load-time-40-percent",
    "content": "## The bottleneck was...",
    "author": "Jakub",
    "status": "published",
    "tags": ["performance", "optimization"],
    "meta_description": "A quick walkthrough of..."
  }'

That's it. No clicking, no waiting for autosave, no "are you sure?" modals. The post is live.

For my stack (Supabase + React), the API is an Edge Function that validates the payload, inserts into the blog_posts table, and returns the slug. The frontend already knows how to render posts from the database, so there's zero deployment step.

The Auth Part Nobody Talks About

Most tutorials show you the happy path. Here's what actually matters:

Token rotation. Don't hardcode a token that lives forever. I rotate mine weekly. A cron job generates a new one, stores it encrypted, and the old one expires.

Idempotency by slug. If you POST twice with the same slug, the second call should update, not duplicate. This saved me more times than I want to admit. Typo in the content? Just re-POST with the fix.

INSERT INTO blog_posts (slug, title, content, author, status)
VALUES ($1, $2, $3, $4, $5)
ON CONFLICT (slug)
DO UPDATE SET title = $2, content = $3, updated_at = now();

Rate limiting. Even on your own API. I hit my own endpoint 47 times in one session while debugging a script. Without rate limiting, that would've been 47 published posts.

The Script That Replaced My Morning Routine

I wrote a small bash wrapper that chains the whole publish flow:

#!/bin/bash
PRODUCT=$1
SLUG=$2
CONTENT_FILE=$3

# Publish
curl -s -X POST "https://$PRODUCT/api/blog/publish" \
  -H "Authorization: Bearer $(vault_token $PRODUCT)" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --arg t "$(head -1 $CONTENT_FILE)" \
            --arg s "$SLUG" \
            --arg c "$(tail -n +3 $CONTENT_FILE)" \
            '{title:$t, slug:$s, content:$c, status:"published"}')"

# Verify sitemap
sleep 5
curl -s "https://$PRODUCT/sitemap.xml" | grep -q "$SLUG" \
  && echo "Sitemap OK" || echo "WARN: slug not in sitemap"

# Request indexing (GSC API)
gsc_index "https://$PRODUCT/blog/$SLUG"

One command. Product name, slug, content file. Post goes live, sitemap verified, indexing requested. What used to take 10 minutes per product now takes 10 seconds.

When NOT to Use a Content API

Not everything should be API-published. Some posts need the UI:

Visual-heavy posts. If the post has custom layouts, embedded widgets, or interactive elements, the WYSIWYG editor is still faster than hand-coding HTML in a JSON payload.

First post on a new product. When you're still figuring out the blog's look and feel, clicking through the editor helps you see what the reader sees. Don't automate discovery.

Collaboration posts. If someone else needs to review before publishing, a shared editor with commenting beats a git-based review flow. At least at our scale.

The Unexpected Side Effect

Once publishing became a one-liner, I started publishing more. Not because I forced myself to, but because the friction disappeared. The mental cost of "I should write a post about this" dropped from "ugh, 20 minutes of UI" to "30 seconds, done."

In the last month, I published more blog posts across my products than in the previous three months combined. Not because I wrote more. Because I stopped losing energy to the publish step.

If you're running multiple products, especially on a stack like Supabase + a React frontend, building a Content API is maybe a weekend project. The ROI hits within the first week.

I'm building tools like Audit Vibe Coding for code quality and Be Recommended for AI visibility tracking. Both have blogs powered by this same API pattern. Same script, different domain, different content. That's the whole point.

Jakub, builder @ Inithouse

Building a Psychology-Framework Conflict Resolver

Jakub — Tue, 05 May 2026 20:42:21 +0000

Turns out psychology frameworks are basically prompts. Here's how I structured them for production.

I've been building Verdict Buddy - a tool where you describe a conflict, and it breaks it down from multiple angles, gives you a verdict, and suggests concrete next steps. The interesting part isn't the AI. It's the psychology layer sitting between the user's messy input and the model's structured output.

The problem with "just ask AI"

If you paste a relationship argument into ChatGPT and say "help me resolve this," you get generic advice. Be empathetic. Communicate better. Listen actively. Thanks, robot.

The output is useless because there's no framework guiding the analysis. A couples therapist doesn't wing it. They apply specific models. Gottman's Four Horsemen. Nonviolent Communication. Emotionally Focused Therapy. Each framework looks at the same conflict through a different lens and catches different things.

So I stopped trying to make AI "understand" conflicts and started making it apply frameworks.

Framework selection logic

Not every framework fits every situation. A workplace disagreement about project ownership doesn't need Gottman (that's couples territory). A recurring argument between partners doesn't need Harvard Negotiation tactics.

The selection works in two stages. First, classify the conflict type from the user's description: romantic, family, workplace, friendship, roommate, or group. Second, map that type to the frameworks most likely to produce useful output.

Romantic conflicts get Gottman + EFT (Emotionally Focused Therapy) + NVC. Workplace gets Harvard Negotiation Project + NVC + conflict resolution basics. Family disputes pull from Bowen Family Systems + NVC. Friendships and roommates get a lighter stack focused on boundaries and communication patterns.

The mapping isn't random. Each framework was designed for specific relationship dynamics. Using Gottman's repair attempts framework on a salary negotiation produces nonsense. Using interest-based negotiation on a couple arguing about emotional availability misses the point entirely.

Prompt architecture per framework

Each framework becomes a structured prompt template. Not a wall of text, but a focused analytical lens.

Take Gottman as an example. The prompt doesn't say "analyze this using Gottman." It says: scan for the Four Horsemen (criticism, contempt, stonewalling, defensiveness). Identify which partner is flooding. Check for failed repair attempts. Look for positive sentiment override or its absence.

These are specific, observable things. The model can actually find them in a conflict description because they map to concrete language patterns. "You always..." is criticism. "Whatever, I don't care" is stonewalling. "I tried to make a joke but she wasn't having it" is a failed repair attempt.

NVC gets a different template: separate observations from evaluations, identify the feelings behind positions, surface the unmet needs driving those feelings, generate request-form suggestions (not demands).

The key insight was that psychology frameworks are already structured analytical procedures. They were designed for human therapists to follow step by step. That makes them surprisingly good prompt templates, because they tell the model exactly what to look for and how to organize what it finds.

Output structuring

Raw framework analysis is interesting but not actionable. Nobody wants to read "Gottman analysis reveals presence of Horseman #2 (contempt) in Partner A's communication pattern." That's a textbook, not help.

The output pipeline runs in three stages:

Analysis runs each selected framework against the conflict description. This is the heavy lifting, usually 2-3 frameworks producing separate analyses.

Synthesis merges the framework outputs into a unified verdict. Where frameworks agree, confidence goes up. Where they disagree, that's actually useful information. A conflict that looks fine through NVC but terrible through Gottman tells you something specific: the surface communication is okay but the underlying relationship dynamics are damaged.

Action plan converts the synthesis into concrete next steps. Not "communicate better" but "when you notice yourself starting a sentence with 'you always,' stop and rephrase as 'I feel X when Y happens.'" Specific, behavioral, doable.

Where AI fails (and what to do about it)

The model hallucinates framework concepts. It'll invent a "Fifth Horseman" or attribute techniques to the wrong researcher. The fix: constrain the output space. Each framework prompt includes an explicit list of valid concepts. If the model references something not on the list, the validation layer catches it.

Severity calibration is another problem. AI tends to either catastrophize ("this relationship shows signs of serious dysfunction") or minimize ("this seems like a minor misunderstanding"). Both are dangerous in conflict resolution. The calibration comes from including severity anchors in the prompt: examples of mild, moderate, and serious conflicts with expected severity ratings. The model uses these as reference points.

The hardest failure mode is bias toward the narrator. In any conflict, you only hear one side. The model naturally sympathizes with the person telling the story. Every framework prompt includes an explicit instruction to steelman the absent party's likely perspective. It doesn't eliminate bias, but it reduces it enough to be useful.

What I learned

Psychology frameworks are underused in AI product design. Most builders treat AI as a general-purpose reasoning engine and hope good output emerges from vague instructions. But decades of clinical psychology have already solved the "how to analyze human problems" question. Those solutions are structured, validated, and ready to be turned into prompts.

The technical work isn't in the AI. It's in understanding which framework applies when, translating framework concepts into prompt constraints, and building validation layers that catch the model's predictable failure modes.

If you're building anything that touches human behavior (conflict resolution, coaching, feedback tools, team dynamics), look at the clinical literature before you look at prompt engineering blogs. The frameworks are already there. You just need to structure them for a different kind of practitioner.

Check out Verdict Buddy if you want to see this in action, or browse more of what we're building at Inithouse.

Jakub, builder @ Inithouse

Psychology frameworks are basically prompts — here's how I structured them for production

Jakub — Tue, 05 May 2026 20:40:44 +0000

Turns out the hardest part of building an AI conflict resolver wasn't the AI. It was figuring out which psychology framework to apply — and when.

I'm building VerdictBuddy, a tool that helps people navigate relationship conflicts using AI-powered analysis grounded in real psychological frameworks. Not generic "communicate better" advice — structured verdicts based on Gottman, NVC, attachment theory, and cognitive-behavioral models.

Here's the technical breakdown of how I got there.

The core insight: frameworks are prompt templates

Every established psychology framework follows a predictable structure. Gottman's Four Horsemen model, for example, identifies four destructive communication patterns (criticism, contempt, stonewalling, defensiveness) and maps each to a repair strategy.

That structure translates almost directly into a prompt template:

Input classification — which pattern is present in the user's conflict description
Framework logic — what does the theory say about this specific pattern
Output generation — concrete verdict + reasoning + actionable next steps

The same applies to Nonviolent Communication (NVC), which breaks every conflict into observations, feelings, needs, and requests. That four-part structure becomes a four-stage prompt pipeline.

Framework selection logic

Not every framework fits every conflict. A workplace disagreement about project ownership doesn't need attachment theory. A recurring argument with a partner probably doesn't need a pure CBT reframe.

I built a classification layer that analyzes the conflict description and selects the most appropriate framework based on three signals:

Relationship type — partner conflicts lean toward Gottman and attachment theory. Workplace conflicts map better to NVC and interest-based negotiation. Family dynamics often need a blend.

Conflict pattern — is this about communication style (Gottman), unmet needs (NVC), cognitive distortions (CBT), or deep-rooted attachment patterns? The pattern determines the lens.

Escalation level — high-escalation conflicts get de-escalation-first approaches. Low-stakes disagreements can jump straight to resolution frameworks.

This isn't a simple if-else tree. The classifier weighs multiple signals and sometimes combines frameworks. A partner conflict about household responsibilities might get Gottman for the communication breakdown analysis and NVC for the resolution path.

Prompt architecture per framework

Each framework has its own prompt template, but they share a common output structure. This was a deliberate design choice — users get consistent verdicts regardless of which framework runs under the hood.

The template structure looks like this:

Context injection — the user's conflict description, parsed into structured elements (who said what, what happened, what's the recurring pattern).

Framework application — the specific psychological model's lens applied to those elements. For Gottman, this means identifying which of the Four Horsemen are present. For NVC, it means extracting the unspoken needs behind each person's position.

Verdict generation — a clear assessment of what's happening, why it's happening, and what each person can do about it. Not "you're both right" — an actual analysis with reasoning.

Next steps — three to five specific, actionable things each person can try. Not vague advice like "communicate more." Concrete moves like "next time you notice yourself withdrawing from the conversation, say 'I need five minutes to collect my thoughts' instead of going silent."

Where AI fails — and how to catch it

The biggest quality issue isn't hallucination in the traditional sense. It's false confidence in framework application. The model will confidently apply Gottman's contempt pattern to something that's actually just frustration, because the surface-level language looks similar.

I built validation checks at three points:

Pre-generation — does the conflict description contain enough information to apply the selected framework? If someone writes "we argued about dinner," that's not enough signal. The system asks follow-up questions instead of guessing.

Post-generation — does the verdict actually use the framework correctly? I check for common misapplications: confusing criticism with contempt (Gottman), confusing observations with evaluations (NVC), or applying attachment labels without behavioral evidence.

User feedback loop — after each verdict, users can flag whether the analysis felt accurate. This doesn't retrain the model, but it feeds into my understanding of where each framework template needs refinement.

The hardest lesson: AI is surprisingly good at describing psychological concepts but mediocre at applying them to specific situations. The gap between "can explain Gottman" and "can correctly identify contempt in this specific conversation" is wider than you'd expect.

What I'd do differently

If I started over, I'd begin with fewer frameworks. I launched with five, and the interaction effects between them created edge cases I'm still sorting out. Start with one, nail the prompt template, validate the output quality, then add the next.

I'd also invest earlier in the classification layer. Getting the right framework matters more than perfecting any single framework's prompt. A mediocre NVC analysis of a situation that actually needs NVC beats a perfect Gottman analysis applied to the wrong conflict type.

This is part of what I'm building at Inithouse — a portfolio of AI-powered tools where each product tackles a specific problem domain. VerdictBuddy handles conflict resolution, Be Recommended tracks AI visibility for brands, and Here We Ask explores community-driven Q&A.

The psychology-to-prompt pipeline is the kind of problem that looks simple until you're three frameworks deep and your classifier is arguing with itself. But when it works — when someone gets a verdict that genuinely helps them understand their conflict — the architecture disappears and the output speaks for itself.

GA4 Custom Dimensions: The Events That Actually Matter for Micro-SaaS

Jakub — Tue, 05 May 2026 20:28:16 +0000

GA4 default events tell you traffic. Custom events tell you behavior. Here's the difference that matters when you're running a micro-SaaS.

The Problem With Default GA4

If you've launched a product — whether it's built with Lovable, Next.js, or anything else — GA4 gives you page_view, session_start, first_visit, and a handful of engagement events out of the box. That's fine for a blog. For a product trying to find product-market fit, it's almost useless.

Default events answer "how many people visited." They don't answer "how many people actually tried the core feature," "where do users drop off in the flow," or "which acquisition channel brings users who convert."

I run Inithouse, a portfolio of ~14 micro-SaaS products in various stages of finding PMF. Every single one of them needed custom events from day one. Here's what I've learned.

Which Custom Events Actually Matter

Forget tracking everything. Track the moments that tell you whether someone got value from your product.

Activation events — the user did the core thing your product exists for. For Be Recommended (an AI visibility tool), that's "ran first analysis." For a photo tool, it's "generated first image." For a challenge game, it's "completed first round." Name it something specific like core_action_completed and fire it exactly once per session.

Friction events — the user hit a wall. Form validation errors, failed API calls, empty states with no guidance. Track these as user_friction with a custom dimension for the friction type. You'll find patterns fast.

Conversion micro-steps — every step between landing and paying. Clicked pricing, opened signup modal, started checkout, completed payment. Each one is a separate event with a funnel_step dimension.

Feature discovery — did users find the features you built? Track feature_used with a dimension for which feature. If nobody finds your best feature, that's a product problem, not an analytics problem.

Implementation: gtag Basics and Gotchas

The basic pattern is straightforward:

gtag('event', 'core_action_completed', {
  action_type: 'analysis_run',
  result_count: 12,
  time_to_complete: 4500
});

But here are the gotchas that trip people up.

Custom dimensions need registration. Firing custom parameters in gtag does not automatically create dimensions in GA4. Go to Admin, then Custom definitions, then Create custom dimension. Register each parameter you want to filter on. Until you do, the data is collected but invisible in reports.

Event-scoped vs user-scoped. Event-scoped dimensions describe what happened (friction_type, feature_name). User-scoped dimensions describe who it happened to (plan_tier, signup_source). A user plan tier is user-scoped since it persists. A specific error code is event-scoped since it is per occurrence.

The 50-event limit. GA4 allows up to 50 custom events (500 for GA360). Plan your taxonomy upfront. Use generic event names with descriptive dimensions instead of unique event names for every action. feature_used with a feature_name dimension is better than used_search, used_filter, used_export as separate events.

Debug mode is essential. Use the DebugView in GA4 while developing. Enable debug mode in your config:

gtag('config', 'G-XXXXXXXX', { debug_mode: true });

Without this, you are flying blind. Events take 24-48 hours to show up in standard reports.

Setting Up Custom Dimensions Step by Step

Start by planning your taxonomy. List every meaningful user action. Group by category (activation, friction, conversion, discovery). Aim for 10-15 events max to start.

Then register in GA4: Admin, Custom definitions, Create custom dimension. Set the scope (event or user), map to the parameter name in your code.

Implement in code and fire events at the right moment. For SPAs, handle route changes since GA4 will not auto-track virtual pageviews unless configured.

Validate in DebugView. Open your app with debug mode on, trigger every event, confirm they appear with correct parameters.

Finally, build Explorations in GA4 using your custom dimensions. Funnel explorations are particularly useful for conversion micro-steps.

Reporting That Actually Helps

Once your custom events are flowing, build three reports:

Activation funnel — from first_visit through each micro-step to core_action_completed. This is your north star. At Inithouse we check this weekly for every active product. If activation rate drops, everything else is noise.

Feature adoption matrix — how many users discover each feature, and which features correlate with retention. Build this as a free-form exploration with feature_used events broken down by feature_name dimension.

Friction heatmap — which friction events fire most often, on which pages, for which user segments. Sort by frequency and fix top-down. This is the highest-ROI work you can do since reducing friction directly improves activation.

When Custom Events Beat Mixpanel

For a solo builder or small team, GA4 custom events often beat dedicated product analytics tools. Mixpanel, Amplitude, and PostHog are great, but they add another service to manage, another SDK to load, and another bill to pay. If you are in the zero-to-one phase validating whether anyone even wants your product, GA4 custom events give you 80% of the insight at 0% of the cost.

The exception: if you need cohort analysis, real-time funnels, or complex behavioral segmentation, dedicated tools earn their keep. But for most micro-SaaS at the PMF-hunting stage, gtag with well-planned custom dimensions is more than enough.

The Checklist

Before you ship your next feature, make sure you can answer these with your analytics:

Can you measure the activation rate? (percentage of visitors who complete the core action)

Do you know where users drop off? (friction events with page context)

Can you compare acquisition channels by activation, not just traffic? (UTM + custom events)

Do you know which features get used? (feature discovery tracking)

If the answer to any of those is no, your next task is not building a new feature. It is adding the right custom events.

I am Jakub, building Inithouse — a portfolio of micro-SaaS products where every week is an experiment in finding product-market fit. Tools like Watching Agents and Be Recommended are where I test these analytics patterns in practice.

GA4 Custom Dimensions — The Events That Actually Matter for Micro-SaaS

Jakub — Tue, 05 May 2026 20:27:24 +0000

GA4 default events tell you traffic. Custom events tell you behavior. Here's the difference that matters when you're running a micro-SaaS and every user action counts.

I run Inithouse, a portfolio of about a dozen small products — everything from AI photo tools to analytics platforms. Each product is an MVP testing product-market fit. GA4's built-in events (page_view, session_start, first_visit) tell me almost nothing useful about whether a product is working. Custom events changed that.

What GA4 Default Events Actually Miss

Out of the box, GA4 tracks surface-level interactions. You get page views, scroll depth (at 90%), outbound clicks, and file downloads. That's fine for a content site. For a SaaS product, it's nearly useless.

Here's what I actually need to know:

Did the user complete the core action? (generate a photo, run an audit, submit a form)
Where did they drop off in the funnel?
Which feature drove them to convert?
How many times did they return before paying?

None of that comes free. You have to build it.

Setting Up Custom Events — The Practical Way

The gtag API is straightforward. Here's the pattern I use across all Inithouse products:

// Core action completed
gtag('event', 'core_action_complete', {
  product: 'zivafotka',
  action_type: 'photo_generated',
  is_first_time: true
});

// Funnel step tracking
gtag('event', 'funnel_step', {
  step_name: 'upload_photo',
  step_number: 1,
  funnel_name: 'photo_generation'
});

// Feature engagement
gtag('event', 'feature_used', {
  feature_name: 'style_selector',
  context: 'homepage'
});

The key insight: name your events by what they mean to your business, not by what the UI element does. button_click tells you nothing in a report. core_action_complete tells you everything.

Custom Dimensions — Making Events Queryable

Events alone aren't enough. You need custom dimensions to slice the data. In GA4 Admin, go to Custom definitions and create custom dimensions:

Event-scoped dimensions I set up on every product:

product — which product in the portfolio (essential when sharing one GA4 property)
action_type — the specific action within the core flow
funnel_name + step_name — for funnel analysis
feature_name — which feature was used
traffic_source_detail — enriched beyond GA4's default attribution

User-scoped dimensions worth adding:

user_tier — free vs paid (set on login)
signup_date_cohort — weekly cohort for retention analysis
first_action — what they did first (predicts retention)

The Gotchas Nobody Warns You About

1. Register dimensions before sending events. If you fire custom events before creating the corresponding custom dimensions in GA4 Admin, the data is lost. GA4 doesn't retroactively apply dimension definitions. I learned this the hard way on Be Recommended — two weeks of event data with unregistered dimensions, gone.

2. The 50-event limit is real. GA4 allows 50 custom event names per property (500 for GA4 360). Plan your naming taxonomy before you start. I use a flat hierarchy: core_action_complete, funnel_step, feature_used, error_encountered, conversion_intent. Five event names, infinite granularity through parameters.

3. Event parameters vs. custom dimensions are different things. You can send any parameter with an event. But unless you register it as a custom dimension, you can't use it in reports, explorations, or segments. The parameter still exists in BigQuery export — but if you're not on BigQuery, it's invisible.

4. Debug View is your best friend. GA4 DebugView in Admin lets you watch events arrive in real time. Install the GA Debugger Chrome extension, enable debug mode, and verify every custom event before you consider it shipped.

5. The not set trap. If an event fires without a parameter that you've registered as a dimension, that row shows as (not set) in reports. This pollutes your data. Always set a default value:

gtag('event', 'feature_used', {
  feature_name: featureName || 'unknown',
  context: pageContext || 'direct'
});

Building Reports That Actually Help

Once your custom events and dimensions are flowing, build these three explorations:

1. Core Action Funnel
Free-form exploration with funnel steps as rows and completion rate as metric. This is your product's heartbeat. If completion rate drops, something broke.

2. Feature Adoption Matrix
feature_used events pivoted by user_tier. Shows which features free users engage with (upgrade triggers) and which paid users ignore (candidates for removal).

3. First-Session Behavior Cohort
Filter by first_visit event, group by first_action dimension. Users who generate a photo on first visit retain 3x better than users who browse the gallery. That kind of insight changes your entire onboarding flow.

When Custom Events Aren't Enough

GA4 custom events work for 80% of product analytics. For the remaining 20% — real-time cohort analysis, complex funnels with branching paths, revenue attribution across a product portfolio — you'll eventually need something more. But for an MVP testing product-market fit, GA4 custom events give you the signal you need without adding another SaaS bill.

The pattern is simple: decide what matters to your business, fire events when those things happen, register dimensions so you can query them, and verify everything in Debug View before calling it done.

Start with five event names. You can always add more. You can't get back the data you didn't track.

I'm Jakub, building Inithouse — a portfolio of MVPs finding product-market fit. I write about the tools and workflows that keep the machine running.

Supabase dual-DB gotcha — test vs live, and how I stopped shipping broken data

Jakub — Tue, 05 May 2026 20:13:14 +0000

I spent two hours debugging an empty production list. The data was in the test database the whole time.

If you're building with Lovable and Supabase, there's a gotcha that will bite you eventually — and when it does, you'll wonder why nobody warned you. Consider this your warning.

The setup nobody explains

When you spin up a Supabase project through Lovable, you get two database environments: test and live. This makes sense in theory — you don't want your AI-assisted edits touching production data while you're experimenting.

The problem? The boundary between these two is almost invisible.

When you use the AI chat in Lovable to insert data — say, seed some blog posts, add sample users, or populate a lookup table — that data goes into the test database. Your production app, the one your users actually visit, reads from the live database.

You insert ten records. You check the app. Zero records. You start debugging.

Where the confusion hits

Here's the typical debugging spiral:

You ask the AI to insert data. It confirms success.
You open your app. The list is empty.
You check your query. It looks correct.
You add console logs. The query runs fine, returns nothing.
You start questioning your RLS policies, your auth setup, your entire understanding of PostgreSQL.

The data is there. It's just in the wrong database.

The fix is one toggle

In Lovable's Supabase integration, there's a SQL Editor with a toggle to switch between test and live environments. When you need data in production, you switch to Live and run your inserts there.

Simple — once you know about it. Brutal when you don't.

My pre-deploy checklist

After getting burned on this across multiple projects at Inithouse (we run about a dozen MVPs built on Lovable + Supabase), I started using a quick checklist before every deploy:

1. Check which database you're targeting. Before any insert, look at the SQL Editor toggle. If it says "test" and you need production data, switch it.

2. Don't trust AI chat inserts for production. The AI chat is great for prototyping, but treat its database writes as test-only by default. For production data, use the SQL Editor switched to Live.

3. Verify after insert. After running your production inserts, open your deployed app and confirm the data shows up. Don't assume — check.

4. Document your seed data. Keep your production seed SQL in a file. When you inevitably need to re-run it (new environment, data reset, migration), you want it ready.

Why this matters for real products

This isn't just a development inconvenience. I've shipped Živá Fotka and HereWeAsk on the Lovable + Supabase stack. Both had moments where content was "missing" in production because someone inserted it through the AI chat.

For an MVP you're validating with real users, showing an empty page when there should be content is a conversion killer. Users don't debug — they leave.

The broader lesson

AI-assisted builders are incredible for speed. But they abstract away infrastructure in ways that create new categories of bugs. The test-vs-live database split is Supabase doing the right thing by protecting your production data. The gap is in making that split visible enough.

If you're building on Lovable + Supabase, bookmark this. You'll need it at 11 PM on a Sunday when your production page is empty and you can't figure out why.

I'm Jakub, building a portfolio of micro-products at Inithouse. Follow along for more war stories from the AI-assisted building trenches.

SEO Fixes for Lovable Apps — Sitemap, Meta Tags, Canonical URLs, and the Full Checklist

Jakub — Tue, 05 May 2026 19:34:59 +0000

Your Lovable app is fast and pretty. Google still can't find it.

I've shipped over a dozen MVPs with Lovable over the past year at Inithouse. The builder handles UI, routing, and deployment beautifully — but SEO is not part of the default stack. Every single app I launched needed manual fixes before Google would index it properly.

Here's the checklist I now run on every project before going live.

The Problem: SPAs Are Invisible by Default

Lovable apps are React single-page applications. That means the HTML Google receives on first request is mostly empty — a root div and some script tags. Without server-side rendering, crawlers see nothing.

This isn't unique to Lovable. Every SPA framework has this issue. But Lovable's target audience — solo builders shipping fast — often skips the SEO layer entirely. I did too, until I noticed zero organic traffic on projects that should have been ranking.

Fix 1: Generate a Real Sitemap

Lovable apps don't ship with a sitemap. If you have dynamic content (blog posts, listings, user profiles), you need one that updates automatically.

The approach I use: a Supabase Edge Function that queries the database and returns XML.

// supabase/functions/sitemap/index.ts
import { createClient } from "@supabase/supabase-js";

Deno.serve(async () => {
  const supabase = createClient(
    Deno.env.get("SUPABASE_URL")!,
    Deno.env.get("SUPABASE_ANON_KEY")!
  );

  const { data: posts } = await supabase
    .from("blog_posts")
    .select("slug, updated_at")
    .eq("published", true);

  const urls = (posts || []).map(
    (p) => `<url>
    <loc>https://yourdomain.com/blog/${p.slug}</loc>
    <lastmod>${new Date(p.updated_at).toISOString()}</lastmod>
  </url>`
  ).join("");

  const xml = `<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url><loc>https://yourdomain.com/</loc></url>
  ${urls}
</urlset>`;

  return new Response(xml, {
    headers: { "Content-Type": "application/xml" },
  });
});

Then submit the function URL to Google Search Console under Sitemaps. I do this for every project — including Ziva Fotka, which runs the same codebase across five country domains.

Key detail: After deploying new content, manually resubmit the sitemap in GSC. Google can go weeks without re-fetching it on its own.

Fix 2: Dynamic Meta Tags

React Helmet or a custom useSEO hook — pick one, but you need dynamic <title> and <meta name="description"> tags per page. The default Lovable setup gives you a single static title across the entire app.

// hooks/useSEO.ts
import { useEffect } from "react";

interface SEOProps {
  title: string;
  description: string;
  canonical?: string;
  ogImage?: string;
}

export function useSEO({ title, description, canonical, ogImage }: SEOProps) {
  useEffect(() => {
    document.title = title;

    const setMeta = (name: string, content: string) => {
      let el = document.querySelector(`meta[name="${name}"]`) 
        || document.querySelector(`meta[property="${name}"]`);
      if (!el) {
        el = document.createElement("meta");
        el.setAttribute(name.startsWith("og:") ? "property" : "name", name);
        document.head.appendChild(el);
      }
      el.setAttribute("content", content);
    };

    setMeta("description", description);
    setMeta("og:title", title);
    setMeta("og:description", description);
    if (ogImage) setMeta("og:image", ogImage);
    if (canonical) {
      let link = document.querySelector('link[rel="canonical"]');
      if (!link) {
        link = document.createElement("link");
        link.rel = "canonical";
        document.head.appendChild(link);
      }
      link.href = canonical;
    }
  }, [title, description, canonical, ogImage]);
}

Call it at the top of every page component:

useSEO({
  title: "How to Convert Live Photos to GIF",
  description: "Turn your iPhone Live Photos into shareable GIFs in seconds.",
  canonical: "https://yourdomain.com/blog/live-photo-to-gif",
});

This is client-side only, so it won't help with crawlers that don't execute JavaScript. But Googlebot does execute JS in most cases, and it's infinitely better than having the same generic title on every page.

Fix 3: Canonical URLs for Multi-Domain

If you run the same app on multiple domains (like I do with Ziva Fotka across .cz, .sk, .pl, .de, and .online), you need canonical tags pointing to the primary version. Without them, Google sees duplicate content and picks one arbitrarily — usually not the one you want.

Set the canonical based on the current domain:

const domain = window.location.hostname;
const canonicalBase = domain.endsWith(".sk") 
  ? "https://yourdomain.sk" 
  : domain.endsWith(".pl")
  ? "https://yourdomain.pl"
  : "https://yourdomain.com"; // default primary

useSEO({
  title: pageTitle,
  description: pageDesc,
  canonical: `${canonicalBase}${window.location.pathname}`,
});

Each domain should have its own GSC property. Submit sitemaps separately per domain.

Fix 4: JSON-LD Structured Data

Google uses structured data to generate rich snippets. For a SaaS landing page, SoftwareApplication schema works. For blog posts, use Article. For tools like Be Recommended (an AI visibility checker I built), WebApplication fits.

export function JsonLd({ data }: { data: Record<string, unknown> }) {
  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(data) }}
    />
  );
}

// Usage on a blog post page
<JsonLd data={{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": post.title,
  "author": { "@type": "Person", "name": "Jakub" },
  "datePublished": post.created_at,
  "dateModified": post.updated_at,
}} />

Fix 5: Pre-Render Critical Pages

For pages that absolutely must be indexed (landing page, pricing, key blog posts), consider pre-rendering. You can use a service like Prerender.io or build a simple Cloudflare Worker that serves a cached HTML snapshot to crawlers.

I haven't needed this for most Lovable apps — Googlebot handles client-side rendering reasonably well in 2026. But if you're seeing "Discovered — currently not indexed" in GSC for important pages, pre-rendering is the nuclear option.

The Pre-Launch SEO Checklist

Before every Lovable app goes live, I run through this:

Sitemap — Edge Function generating XML from DB, submitted to GSC
Meta tags — Dynamic title + description per page via useSEO hook
Canonical URLs — Set on every page, especially for multi-domain setups
JSON-LD — At minimum on the homepage and blog posts
robots.txt — Confirm it's not blocking anything important (Lovable default is fine)
Open Graph — og:title, og:description, og:image for social sharing
GSC verification — DNS TXT record, property confirmed, sitemap submitted
Manual index request — For the homepage and top 5 pages, use Request Indexing in GSC immediately after launch

This takes maybe 30 minutes per project. The difference between doing it and not doing it is the difference between organic traffic and zero organic traffic.

Wrapping Up

Lovable is great for shipping fast. SEO is the part you bolt on after. None of these fixes are complex — they're just not included out of the box, and if you don't know to look for them, your app stays invisible.

I've been building and measuring MVPs at Inithouse using this exact playbook. If you're shipping Lovable apps and wondering why Google isn't picking them up, start with the sitemap and meta tags. Those two alone will get you most of the way there.

Questions or your own Lovable SEO tricks? Drop them in the comments.

SEO fixes for Lovable apps — sitemap, meta, canonical, and the stuff Google actually needs

Jakub — Tue, 05 May 2026 19:34:50 +0000

Your Lovable app is fast and pretty. Google still can't find it. Here's the fix list.

I run Inithouse, a portfolio of about 14 micro-SaaS products — all built with Lovable. After shipping the first few, I noticed the same pattern: great product, zero organic traffic. The apps worked fine for users who had the link, but Google was basically ignoring them.

It took some digging to figure out why. Lovable gives you a solid React SPA out of the box, but SPAs and search engines have a complicated relationship. Here's everything I learned fixing SEO across projects like Živá Fotka (AI photo animation), Be Recommended (AI visibility tool), and Vibe Codéři (a Czech vibecoding portal).

The core problem: React SPAs are invisible by default

When Googlebot hits a Lovable app, it sees a mostly-empty HTML shell. The content loads via JavaScript, and while Google claims to render JS, the reality is inconsistent. Some pages get indexed, others don't, and you have no idea why.

The fix isn't one thing — it's a checklist of small wins that add up.

1. Generate a real sitemap from your database

Lovable apps typically store content in Supabase. Your blog posts, product pages, landing pages — they all live in the database, but there's no sitemap telling Google about them.

The fix: create a Supabase Edge Function (or a Lovable Cloud function) that queries your content tables and returns a proper XML sitemap.

The key parts:

Query all published pages/posts from your Supabase tables
Build XML with <url>, <loc>, <lastmod>, and <changefreq> tags
Set the response Content-Type to application/xml
Add the sitemap URL to your robots.txt

One gotcha I ran into: if you're using Supabase RLS (Row Level Security), make sure your Edge Function has the right permissions to read published content. I've had sitemaps return empty because the function was hitting RLS policies meant for authenticated users.

After deploying the sitemap, submit it in Google Search Console. Don't just wait for Google to discover it — go to Sitemaps in GSC and submit the full URL manually.

2. Dynamic meta tags with a useSEO hook

Out of the box, Lovable apps ship with a single set of meta tags in index.html. Every page has the same title, description, and OG image. Google sees that as thin content — dozens of URLs with identical metadata.

The fix: create a useSEO custom hook that updates document metadata per page.

What the hook should handle:

document.title — unique per page
Meta description — via document.querySelector('meta[name="description"]')
Open Graph tags (og:title, og:description, og:image, og:url)
Twitter card tags
Canonical URL (more on this below)

Call the hook at the top of every page component with page-specific values. For blog posts, pull the title and description from your Supabase data.

The important thing: these changes happen client-side, so they only help with Google's JS rendering. For social media previews (Twitter, LinkedIn, Slack), you need server-side rendering or a prerender service. I've had mixed luck with prerender.io — it works, but adds latency. For most MVPs, client-side meta tags plus a good default OG image is enough to start.

3. Canonical URLs for multi-domain setups

This one bit me hard. Živá Fotka runs on five domains (CZ, SK, PL, EN, DE) from a single codebase. Without canonical tags, Google was treating them as duplicate content and picking winners randomly.

The fix: set a <link rel="canonical"> tag that points to the primary URL for each piece of content.

Rules I follow:

Each domain's homepage canonical points to itself
Shared content (like the main app page) canonicals point to the primary domain
Blog posts canonical to whichever domain they were originally published on
Use absolute URLs, never relative

In the useSEO hook, I add canonical handling:

useEffect(() => {
  let link = document.querySelector('link[rel="canonical"]');
  if (!link) {
    link = document.createElement('link');
    link.setAttribute('rel', 'canonical');
    document.head.appendChild(link);
  }
  link.setAttribute('href', canonicalUrl);
}, [canonicalUrl]);

For multi-domain setups, also add hreflang tags pointing to each language version. This tells Google which version to show in which country.

4. JSON-LD structured data

Google loves structured data. For a micro-SaaS, the most useful schemas are:

WebApplication — for the main product page
Article or BlogPosting — for blog posts
FAQPage — if you have an FAQ section
Organization — for your company info

I inject JSON-LD in the same useSEO hook using a script tag with type="application/ld+json". The trick is to clean up old script tags when the component unmounts, otherwise you end up with duplicate structured data.

5. Pre-launch SEO checklist

Before submitting any Lovable app to Google Search Console, I run through this:

robots.txt exists and doesn't block important paths
Sitemap is generated, accessible, and submitted to GSC
Every page has a unique title and meta description
Canonical URLs are set on all pages
OG tags are present (test with opengraph.xyz)
JSON-LD validates (test with Google's Rich Results Test)
No broken internal links
Images have alt text
Page loads under 3 seconds on mobile (Lovable apps are usually fast here)
noindex isn't accidentally set anywhere

The results

After applying these fixes across our portfolio at Inithouse, the difference was measurable within weeks. Pages that were completely invisible started showing up in search. Here We Ask went from zero indexed pages to full coverage after the sitemap fix alone.

The reality is that Lovable handles the hard parts of building a product — UI, database, auth, hosting. But SEO is still something you need to wire up yourself. The good news: once you've done it for one project, the pattern is the same for every new one.

If you're building with Lovable and struggling with organic traffic, start with the sitemap and meta tags. Those two fixes alone will get you 80% of the way there.

I'm Jakub, building Inithouse — a portfolio of AI-powered micro-SaaS products, all shipped with Lovable. Follow along for more builder notes.

How We Built a Conflict Resolver That Uses Psychology Frameworks as Prompts

Jakub — Tue, 05 May 2026 10:15:36 +0000

We're building Verdict Buddy — an AI-powered conflict resolution tool that translates established psychology frameworks into structured prompts. Here's the technical story of how we got there and why prompt engineering for empathy turned out to be the hardest challenge we've tackled at Inithouse.

The Problem With "Just Talk It Out"

Most conflict resolution advice boils down to "communicate better." But when you're in the middle of a heated argument — whether it's with your partner about finances, your roommate about dishes, or your coworker about project scope — your brain isn't exactly in problem-solving mode.

We wanted to build something that could actually guide people through structured conflict resolution, the same way a therapist or mediator would. Not by replacing human connection, but by providing the framework when emotions are running high and you can't remember what your couples therapist said last Tuesday.

Four Frameworks, Three Modes

We studied four established approaches to conflict resolution and translated each into prompt architectures:

Gottman Method — focuses on "soft startups" and repair attempts. The prompt structure here emphasizes identifying the underlying need behind the complaint. Instead of "you never clean up," the AI guides toward "I need to feel like we're a team."

Emotionally Focused Therapy (EFT) — works with attachment patterns. We built prompts that identify whether someone is pursuing or withdrawing, then scaffold responses that address the attachment need rather than the surface issue.

Harvard Negotiation Project — separates positions from interests. The prompt chain here is almost algorithmic: identify stated positions, dig for underlying interests, generate options for mutual gain, apply objective criteria.

Nonviolent Communication (NVC) — observation, feeling, need, request. This was actually the easiest to implement as prompts because it's already quite structured, but the hardest to make sound natural rather than robotic.

Each framework maps to different conflict types. Gottman and EFT work best for intimate relationships. Harvard Negotiation is ideal for workplace or business disputes. NVC is the Swiss Army knife that works everywhere but requires the most prompt finessing to avoid sounding like a therapy textbook.

The Three Modes

Verdict Buddy operates in three distinct modes:

Solo Mode — you describe the conflict from your perspective. The AI asks clarifying questions using the selected framework, then provides insights about what might be driving the other person's behavior and suggests specific language for your next conversation.

Couple Mode — both parties describe their perspective through a shared link. The AI synthesizes both views, identifies where the real disconnect is (often it's not what either person thinks), and proposes a path forward that addresses both people's underlying needs.

Group Mode — for team conflicts, family disputes, or roommate situations with more than two parties. The prompt architecture here is significantly more complex because you're tracking multiple attachment styles, interests, and communication patterns simultaneously.

Why Empathy Is Harder Than Image Generation

Here's something that surprised us: getting an LLM to generate empathetic, framework-appropriate responses is significantly harder than most other prompt engineering tasks.

The failure modes are subtle. An image generator either produces something that looks right or doesn't. But a conflict resolution response can sound reasonable while actually being harmful — validating one person's perspective in a way that dismisses the other, or using NVC language in a way that comes across as passive-aggressive rather than connecting.

We spent weeks on what we call "empathy calibration" — making sure the AI doesn't:

Take sides while appearing neutral
Use therapeutic language that feels condescending
Suggest solutions before both parties feel heard
Default to compromise when the real issue is a boundary violation

The prompt engineering approach that finally worked was layering: the base prompt sets the framework constraints, a second layer adds the relational context (are these romantic partners? colleagues? family?), and a third layer handles tone calibration based on the emotional temperature of the conversation.

What We Learned About Prompt Architecture

Building this taught us something about AI product development that I haven't seen discussed much: the hardest prompt engineering problems aren't about getting accurate outputs — they're about getting emotionally appropriate ones.

You can't unit test empathy the way you test factual accuracy. We ended up building our own evaluation rubric based on therapy research about what makes interventions effective vs. harmful. Each response gets scored on: validation (does both parties feel heard?), reframing (does it shift from blame to understanding?), actionability (is there a clear next step?), and safety (does it avoid reinforcing harmful dynamics?).

Current State

Verdict Buddy is live and we're actively collecting feedback on how people use the different modes and frameworks. Early signals suggest that Solo Mode is the most-used feature — people want to understand their own conflicts better before engaging the other party.

If you're interested in the intersection of psychology and AI, or if you're building products that need emotionally intelligent outputs, I'd love to hear how you're approaching similar challenges.

I'm Jakub, building a portfolio of AI-powered products at Inithouse. Verdict Buddy is one of about a dozen MVPs we're running simultaneously to find product-market fit.

Whisper + Custom Prompts: Turning Messy Voice Into Structured Data

Jakub — Tue, 05 May 2026 04:11:29 +0000

The hardest part of voice-to-data isn't the transcription. It's making sense of someone thinking out loud.

I've been building Voice Tables — a tool that lets you speak naturally and get structured spreadsheet rows back. No forms, no typing, just talk. Under the hood, it's a two-stage pipeline: Whisper handles the transcription, then a custom prompt chain extracts structured fields from the raw text.

Here's how it actually works, and where things get tricky.

The Pipeline

The architecture is deceptively simple:

Voice recording → Whisper transcription → Prompt-based extraction → Structured row

Stage one (Whisper) is mostly a solved problem. Stage two — turning a messy human monologue into clean, column-mapped data — is where the real engineering lives.

Whisper Configuration

For Voice Tables, I run Whisper with these considerations:

// Whisper config essentials
const whisperConfig = {
  model: "whisper-1",
  language: null,            // auto-detect — users speak CZ, EN, DE...
  temperature: 0,            // deterministic output
  response_format: "text"    // plain text, no timestamps needed
};

A few things I learned the hard way:

Auto-detect language works surprisingly well. When you're running a product across multiple markets, hardcoding language: "en" breaks the moment a Czech user starts speaking. Let Whisper figure it out.

Temperature 0 matters more than you'd think. Even small variations in transcription can cascade into extraction errors downstream. "Twenty three" vs "23" vs "twenty-three" — each triggers different parsing paths.

Model size tradeoffs: The large model catches more edge cases (mumbling, background noise, accented speech) but adds latency. For a real-time-ish UX, the base model with a retry fallback to large works well.

The Extraction Prompt

This is where it gets interesting. Raw Whisper output looks like this:

"So I had a meeting with, uh, John from Acme Corp yesterday, 
it was about the Q2 renewal, they want to bump it up to 
fifty thousand annually, told him I'd get back by Friday"

And you need to extract:

Contact	Company	Topic	Amount	Deadline
John	Acme Corp	Q2 renewal	$50,000/yr	Friday

The prompt template is column-aware — it knows what fields exist in the user's table and adapts extraction accordingly:

function buildExtractionPrompt(columns, transcript) {
  const columnDefs = columns
    .map(c => `- ${c.name} (${c.type}): ${c.description || "no description"}`)
    .join("\n");

  return `Extract structured data from this voice transcript.

Target columns:
${columnDefs}

Rules:
1. Extract ONLY the columns listed above
2. If a value is ambiguous, use your best interpretation
3. If a value is missing from the transcript, use null
4. For dates, interpret relative references relative to today
5. For amounts, normalize to numbers ("fifty thousand" → 50000)
6. Return valid JSON array of objects

Transcript:
"${transcript}"

Respond with ONLY the JSON array.`;
}

The key insight: column descriptions are the secret weapon. When a user sets up their table with a "Company" column described as "the organization, not the person," extraction accuracy jumps dramatically. The prompt doesn't have to guess — it has context.

The Validation Layer

Garbage in, garbage out. Voice input is inherently messy, so the validation layer does heavy lifting:

function validateExtraction(extracted, columns) {
  return extracted.map(row => {
    const clean = {};

    for (const col of columns) {
      let value = row[col.name];

      // Type coercion
      if (col.type === "number" && typeof value === "string") {
        value = parseFloat(value.replace(/[^0-9.-]/g, ""));
        if (isNaN(value)) value = null;
      }

      // Date normalization
      if (col.type === "date" && value) {
        value = parseRelativeDate(value) || value;
      }

      // Flag missing required fields
      if (value === null && col.required) {
        clean._warnings = clean._warnings || [];
        clean._warnings.push(`Missing required: ${col.name}`);
      }

      clean[col.name] = value;
    }
    return clean;
  });
}

The _warnings array is surfaced in the UI so users can quickly spot and fix extractions that need human review. You don't want a tool that silently produces wrong data.

Edge Cases That Will Break You

After processing thousands of voice entries across Voice Tables, here are the edge cases that consumed the most debugging time:

Homophony. "Their" vs "there" vs "they're" — Whisper usually gets it right, but when it doesn't and you're extracting a company name, you get phantom entries. The fix: fuzzy matching against known entities when the column has existing data.

Partial sentences. People pause, restart, contradict themselves. "The price is... actually no, make it twelve hundred... wait, fifteen hundred." The prompt needs explicit instructions: "If the speaker corrects themselves, use the final stated value."

Number ambiguity. "I need to order one fifty." Is that 1.50? 150? One unit of item #50? Context from column type and description helps, but this is genuinely hard. We added a confirmation step for ambiguous numbers.

Multi-row entries. Sometimes one recording contains data for multiple rows. "I talked to John about project Alpha and then Maria about project Beta." The extraction prompt handles this — it returns an array — but users are often surprised when one voice note creates two rows.

What I'd Do Differently

If I were starting Voice Tables from scratch:

Start with constrained input. Let users define expected patterns ("I met [person] from [company] about [topic]") before going fully freeform. Constrained extraction is 10x more reliable.
Build the feedback loop earlier. Users correcting extractions is the best training signal. Every correction should tune the extraction prompt for that specific table.
Batch processing matters. The initial version processed one recording at a time. Batching multiple short recordings with shared context (same meeting, same project) dramatically improves extraction quality.

The Stack

For anyone building something similar, here's what powers this at Inithouse:

Whisper API (OpenAI) for transcription
GPT-4o for extraction (structured outputs mode)
React + Supabase frontend and storage (built with Lovable)
Edge functions for the processing pipeline

The whole thing runs surprisingly lean. Most of the complexity is in prompt engineering, not infrastructure.

Voice-to-structured-data is one of those problems that sounds simple until you actually build it. The transcription part is essentially commoditized. The real challenge is bridging the gap between how humans think out loud and how databases expect data to arrive.

If you're working on something similar, I'd love to hear what approaches you've tried. Drop a comment or find me on Dev.to.