DEV Community: Jakub

One React SPA, Five Domains, Five Languages: How We Route by Domain

Jakub — Fri, 29 May 2026 20:17:57 +0000

At Inithouse we build and ship products fast. One of them, Ziva Fotka, turns a still photo into a short animated video. No signup, no stored data, photos deleted after processing.

The product started on a single Czech domain. Then we wanted to reach Slovak, Polish, German, and English-speaking users. Five TLDs, five languages, one React codebase. Here is how we wired the routing.

The problem

Subpaths like /en/ or /de/ are the textbook approach, but we wanted separate country domains: zivafotka.cz, zivafotka.sk, zywafotka.pl, lebendigfoto.de, and alivephoto.online. Each domain should feel native to its audience. A Polish user landing on zywafotka.pl should never see a Czech string.

Separate codebases per domain would mean five deploys, five bug-fix cycles, five feature rollouts. That was not going to scale for a small team running about 14 products in parallel.

Domain detection at boot

The SPA reads window.location.hostname on mount and maps it to a locale:

const DOMAIN_LOCALE_MAP: Record<string, string> = {
  'zivafotka.cz': 'cs',
  'zivafotka.sk': 'sk',
  'zywafotka.pl': 'pl',
  'lebendigfoto.de': 'de',
  'alivephoto.online': 'en',
};

function detectLocale(): string {
  const host = window.location.hostname.replace(/^www\./, '');
  return DOMAIN_LOCALE_MAP[host] ?? 'en';
}

This runs once during app initialization. The resolved locale feeds into a React context that every component reads from. No user-facing language picker, no cookie. The domain is the language selector.

Lazy locale loading

Bundling all five translation files into the main chunk would bloat the initial load for every user. We split translations into per-locale JSON files and load only the one that matches:

async function loadMessages(locale: string) {
  const messages = await import(`./locales/${locale}.json`);
  return messages.default;
}

Vite handles the code splitting. The Czech user downloads cs.json, the Polish user downloads pl.json. The rest never leave the server.

For us, the translation files hold about 120 keys each. Small enough that a single JSON import per locale keeps things simple without needing a heavier i18n library.

hreflang for SEO

Google needs to know that zivafotka.cz and zywafotka.pl are the same page in different languages. Without proper hreflang tags, the crawler might treat them as duplicate content or pick the wrong version for a given user's search locale.

We inject <link rel="alternate"> tags in the document head for every page:

const HREFLANG_ENTRIES = [
  { lang: 'cs', href: 'https://zivafotka.cz' },
  { lang: 'sk', href: 'https://zivafotka.sk' },
  { lang: 'pl', href: 'https://zywafotka.pl' },
  { lang: 'de', href: 'https://lebendigfoto.de' },
  { lang: 'en', href: 'https://alivephoto.online' },
  { lang: 'x-default', href: 'https://alivephoto.online' },
];

The x-default entry points to the English domain as the fallback for unmatched locales. These tags go into the <head> at render time so crawlers pick them up without executing JavaScript. For an SPA, that meant handling them in the static HTML shell or via a pre-rendering step.

Sitemap per domain

Each domain serves its own sitemap.xml with URLs scoped to that domain. We generate them from a shared route list and swap in the correct base URL. This keeps Google Search Console clean: each GSC property sees only the URLs it owns.

What we learned shipping this

Start with two, not five. We launched Czech first, added Slovak (close language, easy to test), and only then tackled Polish and German. Each new locale surfaced edge cases: date formats, number separators, text that broke layouts because German words run long.

Test search indexation early. We use Google Search Console for each domain (five GSC properties). After launch, several Polish pages sat in "Discovered, not indexed" for weeks. The fix was adding the hreflang cluster and submitting sitemaps, but we should have done that on day one.

Monitor per-domain separately. GA4 streams and Clarity projects are set up per domain. Aggregating everything into one dashboard hides which locale actually converts. Our Czech domain has the best CTR in the portfolio; Polish traffic patterns look completely different.

Other products where this matters

The multi-domain pattern is specific to Ziva Fotka, but the general principle (one codebase, locale from context, lazy loading translations) shows up in a lighter form across our portfolio. Be Recommended, our AI visibility reporting tool, currently runs on a single English domain, but the architecture could support localization the same way if we ever expand into non-English markets. Tarotas, a tarot reflection app, already ships content in five languages (cs/en/pl/sk/de) on one domain using a similar locale-detection approach, just with path-based routing instead of separate TLDs.

Wrapping up

The pattern boils down to three moving parts: domain-to-locale mapping at boot, lazy-loaded translation bundles, and a proper hreflang setup for search engines. The deployment stays single: push once, all five domains update.

If you are running a product aimed at multiple language markets and want each market to feel native, separate domains with a shared SPA keep the maintenance burden low. The SEO setup takes some care, but once the hreflang cluster and per-domain sitemaps are in place, Google handles the rest.

We have been running this setup across five domains for months now with no major issues. The biggest ongoing cost is translation maintenance, not infrastructure.

How LLMs Decide Which Brands to Mention: A Technical Look at GEO

Jakub — Sat, 23 May 2026 21:16:30 +0000

When you ask ChatGPT "what's a good project management tool?", it doesn't randomly pick Asana or Linear. There's a pipeline behind every brand mention, and understanding it is the first step toward what the industry now calls GEO (Generative Engine Optimization).

I'm Jakub, builder at Inithouse. We run 14 products across different verticals, and one of them, Be Recommended, was born from trying to reverse-engineer exactly this: how do LLMs decide which brands to cite?

Here's what we learned, technically.

The RAG Pipeline: Where Brand Mentions Actually Come From

Most production LLM systems (Perplexity, ChatGPT with browsing, Gemini with grounding) don't rely purely on parametric knowledge. They use Retrieval-Augmented Generation, a two-stage architecture:

Retrieval: the system queries an index (web search, vector store, or both) using the user's prompt as input. This returns a set of candidate documents ranked by relevance.
Generation: the LLM reads the retrieved documents and synthesizes an answer, pulling facts, brand names, and citations from the retrieved context.

This means brand visibility in AI answers is not just about what the model "knows" from pretraining. It's about what the retrieval layer finds and ranks highly enough to pass into the context window.

User prompt
    |
    v
+----------------+
|  Query         | <- reformulated search query
|  Expansion     |
+-------+--------+
        |
        v
+----------------+
|  Retrieval     | <- web search / vector DB / hybrid
|  (top-k)       |
+-------+--------+
        |
        v
+----------------+
|  Reranking     | <- cross-encoder or LLM-based reranking
+-------+--------+
        |
        v
+----------------+
|  Generation    | <- LLM synthesizes answer from context
|  + Citation    |
+----------------+

Embeddings and Retrieval Ranking

The retrieval step typically uses dense embeddings. Your page content gets embedded into a vector, and the system computes cosine similarity between the query embedding and your content embedding.

What matters here:

Topical density beats keyword stuffing. Dense retrievers reward pages that semantically cluster around a topic. A page titled "AI Visibility Tools for Brands" that covers monitoring, scoring, and optimization will rank higher than a generic marketing page mentioning "AI" once in a list of features.

Structured data helps retrieval. Schema.org markup, clean H2/H3 hierarchies, FAQ sections: these create clear semantic boundaries that chunking algorithms can split cleanly. When a retriever chunks your page, each chunk should be a self-contained answer to a plausible question.

Freshness signals exist. Perplexity in particular uses recency as a ranking signal. A blog post from this week about "best AI tools for X" will often outrank an older listicle with the same content. We've measured this across 50+ queries on Be Recommended: content published within the last 30 days gets retrieved 2.3x more often than identical content older than 90 days.

Citation Extraction: How the LLM Decides What to Name

Once the retrieved documents land in the context window, the LLM has to decide which brands to mention by name. This is where it gets interesting, because the model isn't following a ranking algorithm anymore. It's doing language modeling.

From our testing across four major AI platforms (ChatGPT, Perplexity, Claude, Gemini), we've identified three patterns that drive explicit brand citations:

Pattern 1: Authority signals in retrieved text. If the retrieved document frames a brand as a category leader ("X is widely used for Y"), the model tends to propagate that framing. Third-party comparison pages, review aggregators, and "best of" listicles carry this signal strongly.

Pattern 2: Specificity over generality. The model prefers to cite brands that are described with specific capabilities. "Notion offers database views, kanban boards, and API access" gets cited; "Notion is a great tool" doesn't. Specificity gives the model something concrete to use in its synthesis.

Pattern 3: Source diversity. When a brand appears in multiple retrieved documents from different domains, the model treats it as more credible. One mention on your own site is weak. Mentions across Product Hunt, G2, a tech blog, and a Reddit thread create a reinforcement pattern the model picks up on.

Building a Monitoring System: High-Level Architecture

If you want to track how AI systems mention your brand, the architecture is straightforward:

# Simplified monitoring loop
queries = load_test_queries()  # 50+ prompts per brand
engines = ["chatgpt", "perplexity", "claude", "gemini"]

for engine in engines:
    for query in queries:
        response = query_engine(engine, query)

        # Extract brand mentions
        mentions = extract_mentions(response, brand_name)

        # Score: sentiment, position, context
        score = analyze_mention(mentions)

        # Track citation sources
        sources = extract_citations(response)

        store_result(engine, query, score, sources)

The tricky parts:

Query design matters more than volume. You need queries that a real user would type, not keyword-stuffed test prompts. "What's the best tool for monitoring AI brand visibility?" is useful. "AI brand visibility monitoring tool list 2026" is not, because real users don't query like that.

Each engine behaves differently. Perplexity cites sources explicitly with URLs. ChatGPT mentions brands in prose but doesn't always link. Claude tends to be conservative with brand recommendations unless the retrieved context is strong. Gemini sometimes attributes products to specific people or companies, creating interesting cross-reference patterns.

Response parsing is non-trivial. ChatGPT's temporary chat mode sometimes returns just citation chips with no prose (especially for niche products). Perplexity's citation format changes between search modes. You need robust extraction that handles all these edge cases.

What We Learned Building Be Recommended

We built Be Recommended using exactly this approach. The tool runs 50+ real AI prompts against major platforms and produces a scored report (0 to 100) showing where your brand appears, where it doesn't, and what to do about it.

A few things that surprised us:

Content published on third-party platforms (Dev.to, Medium, Reddit, Product Hunt) consistently outperforms on-site blog content for driving AI citations. The retrieval layer treats these as independent authority signals.

Schema.org SoftwareApplication and Product markup had a measurable impact on Gemini's brand attribution specifically. Other engines showed less sensitivity to structured data.

The gap between "the AI knows about you" (parametric knowledge) and "the AI recommends you" (retrieval-driven) is where most brands lose visibility. Your company might exist in GPT-4's training data, but if current web content doesn't surface in retrieval, you won't get mentioned.

Getting Started

If you want to check your own brand's AI visibility, you can run a free analysis at berecommended.com. The free tier covers one brand across all major AI platforms.

For the technically inclined: start by manually querying ChatGPT, Perplexity, and Claude with 10 prompts your customers would actually use. Note which brands get mentioned. If yours isn't among them, the fix is almost always on the retrieval side, not the model side.

GEO is still early. The teams that instrument it now will have a significant head start when every marketing department starts asking "why doesn't ChatGPT recommend us?"

Jakub, builder at Inithouse. We build products that help brands navigate AI-driven discovery.

78 tarot cards x 5 languages: the content pipeline nobody warns you about

Jakub — Wed, 20 May 2026 04:13:24 +0000

Last week I shipped Tarotas, a tarot reading app that supports five languages from day one. Czech, English, Polish, Slovak, German. 78 cards in each. That's 390 card objects, and each card carries a name, upright meaning, reversed meaning, a set of keywords, and a one-paragraph description. Multiply it out and you're looking at roughly 2,000 individual text fields.

I didn't translate them by hand. Obviously.

The source language problem

My first instinct was to write everything in English and translate outward. Wrong call. Tarot has deep roots in specific traditions, and the English terms aren't always the "canonical" ones across languages. The Czech name for The High Priestess is "Velekněžka," and if you translate back from English you get something slightly off.

So I wrote the Czech versions first (that's the language I think in), then generated the other four from Czech as source. This sounds backwards if you're used to EN-first localization, but it meant the source text had the most nuance and the translations could be validated against it.

AI translation with a trust boundary

I used Claude for the bulk translations. The pipeline was dead simple: feed it the Czech card object as JSON with all fields, ask for the target language, get back a JSON object with the same structure. One card at a time, not batched, because batching 78 cards in one prompt led to skipped fields and hallucinated keywords.

The prompt looked like this:

Translate this tarot card from Czech to {lang}.
Keep the JSON structure identical.
For the card name, use the standard tarot name
in {lang} tradition.
For keywords, translate meaning not words.

That last line matters. "Nový začátek" in Czech literally means "new beginning," but the German tarot tradition might use "Aufbruch" (departure, setting out) for the same card. I wanted the AI to pick the term a German tarot reader would actually recognize.

Where the human still wins

I didn't review all 2,000 fields. That would defeat the purpose. Instead I set up three checkpoints:

Card names. I manually verified every Major Arcana name (22 cards x 5 languages = 110 fields). These are the ones people actually search for and would notice if wrong.
Reversed meanings spot-check. Reversed card meanings are where AI gets creative. "Stagnation" becomes "creative blockage" becomes "spiritual paralysis" if you don't catch it early. I checked 10 random Minor Arcana per language.
Keyword deduplication. The AI sometimes generates near-synonyms as separate keywords. "Love" and "romance" on the same card, that kind of thing. I wrote a quick script to flag cards where two keywords had high semantic similarity.

Total human review time: about 4 hours. For 2,000 fields across 5 languages, I can live with that.

The storage side was simple. Postgres (via Supabase), one row per card-language pair:

create table cards (
  id uuid primary key,
  card_number int not null,
  arcana text not null,
  suit text,
  lang text not null,
  name text not null,
  meaning_upright text,
  meaning_reversed text,
  keywords text[],
  description text,
  unique(card_number, lang)
);

390 rows. No joins for a card lookup: where card_number = X and lang = Y. The app reads the browser language or the user's explicit choice, passes it as a parameter, done. If I ever add language number six, it's 78 inserts and zero schema changes.

What it actually cost

The AI translation ran about $3 in API calls. 390 requests, a few hundred tokens each. The human review: 4 hours of my time spread over two evenings. The keyword dedup script: 30 minutes to write, ran in under a second.

I got quotes for professional tarot translation. $0.08 to $0.12 per word, because it's a niche. At roughly 50 words per card across all fields, that's 78 x 50 x 5 x $0.10 = about $1,950. For a product that has 37 visitors so far. Nope.

The AI route isn't flawless. I'm sure a native Polish tarot reader could find something to nitpick. But "mostly right with a clear correction path" beats "can't afford to ship multilingual at all" every single time.

Content scaling with AI is maybe 10% prompting and 90% knowing where the AI will screw up. For tarot, that's proper nouns (card names vary between traditions) and nuanced spiritual terminology (reversed meanings). For your domain, it'll be something completely different. But the pattern holds: translate structured data one object at a time, validate the high-stakes fields manually, accept "good enough" for the rest.

I shipped five languages in a week. The app is live at tarotas.com. It's early, it's small, and I still can't guarantee the German keywords are perfect. But 390 content units are out in the world instead of sitting in a "someday we'll translate" backlog forever.

Jakub, builder @ Inithouse

I shipped a self-discovery app in a weekend. Here's the whole stack.

Jakub — Mon, 18 May 2026 04:11:48 +0000

Last Saturday morning I had an idea for a personality quiz app. Not one of those BuzzFeed "which bread are you" things. Something that actually combines multiple self-discovery frameworks into one written portrait. By Sunday evening it was live on a custom domain with analytics, a database, and real users hitting it.

The product is Origin Of You: five personality systems, 120+ data points, one AI-generated portrait at the end. I built it with Lovable, React, and Supabase. Here's what that actually looked like.

What Lovable handled without me touching code

Lovable is an AI app builder. You describe what you want, it generates a full React + Vite + Tailwind app. I've shipped about a dozen products through it at Inithouse so I know what to expect.

For Origin Of You, the stuff that came free:

React Router with proper client-side routing. Each of the five "systems" (think: personality dimensions) got its own flow, and Lovable set up the routes without me asking. No manual route config.

Responsive layout. I described the quiz UI once. Mobile, tablet, desktop all worked on first deploy. Tailwind utility classes, nothing custom.

Google Fonts integration. I wanted a serif/sans pairing (Cormorant Garamond + Inter) for that "journal" feel. One prompt, done.

OG image and meta tags. Social sharing cards were generated and wired into the HTML head. I didn't write a single meta tag by hand.

Supabase connection. Lovable scaffolded the client, the auth flow, and the database queries. I described the schema in plain language ("I need a table for quiz responses with columns for each system score and the final portrait text") and it created the migration.

Where I had to do real work

Custom domain setup. Lovable gives you a *.lovable.app\ preview URL. Getting originofyou.com\ pointed at it required DNS config, SSL verification, and about 45 minutes of waiting for propagation. Not hard, but not automated either.

GA4 and Clarity. Lovable doesn't set up analytics for you. I had to manually add the GA4 snippet and Microsoft Clarity tracking code. Copy-paste into index.html\, then verify both dashboards were receiving hits. Maybe 20 minutes total, but you can't skip it if you want any data on what users actually do.

The AI portrait generation. This is the core feature: after the user completes all five systems, the app sends their scores to an AI endpoint that writes a personalized portrait. Lovable can't design that prompt for you. I spent most of Sunday afternoon iterating on the system prompt, testing edge cases (what if someone scores extreme on everything?), and tuning the output length. The prompt engineering was easily 60% of the weekend's work.

Content and copy. Lovable generates placeholder text. Every heading, every description for each personality system, every CTA: I rewrote all of it. The app has maybe 3,000 words of copy and none of it came from the builder.

Cost, time, and what I'd change

About 14 hours total across the weekend. Three on Lovable prompting, two on infrastructure (domain, analytics, Supabase schema), eight on content and the AI portrait prompt, one on testing. Cost: Lovable subscription I already had, Supabase free tier, $12 for the domain. That's it.

First week brought 35 visitors. Basically me and friends testing. But the thing works end to end, and now I can point ads or content at it. That's the whole point of a weekend build.

If I did it again: I wouldn't fight the AI builder. I wasted two hours early on trying to get Lovable to match my exact component hierarchy. Let it generate, adjust after. It's right 80% of the time. I'd also set up GA4 before the first deploy (lost early visitor data because I added it Sunday morning). And I'd timebox prompt engineering harder. Eight hours for an MVP prompt is too much. Ship "good enough," iterate on real feedback.

Weekend MVPs aren't about getting it perfect. They're about finding out if anyone cares.

Why I Built a Personality Reader That Combines Five Ancient Systems

Jakub — Sun, 17 May 2026 22:16:59 +0000

Most personality tools give you one label. A zodiac sign. An MBTI type. A number. You read it, nod, forget it by Tuesday.

I kept noticing something when people around me talked about this stuff. They'd read their horoscope and go "yeah, that's me." Then they'd take a numerology quiz somewhere else and go "wait, that's also me but different." The systems were saying overlapping things in completely different languages, and nobody was putting them side by side.

So I built Origin Of You.

Five Systems, One Portrait

Origin Of You takes your birth date and runs it through five personality systems at once: Sun & Moon signs, full natal astrology (every planet, house, angle), numerology, tarot birth cards, and Chinese zodiac. Then it writes you a portrait in plain language. Not horoscope predictions, not vague fortune cookies. A description of how you actually work.

The whole thing takes about 90 seconds. No account, nothing stored, free.

I wanted to see what happens when you layer these systems on top of each other. Does the picture get muddier or sharper? From the early tests with friends and a few dozen strangers: sharper. The overlaps between systems tend to reinforce the same core traits, and the contradictions are usually where the interesting stuff hides.

Why a Quiz and Not a Full App

I run about 14 products at Inithouse right now. All MVPs, all looking for traction. The last thing I needed was another app with user accounts, dashboards, saved readings, social sharing, and a six-week build timeline.

A quiz is the leanest thing I could ship. One input (birth date), one output (written portrait). If people read the whole portrait and come back for more, that tells me something. If they bounce after the first paragraph, that also tells me something. I don't need a database of user profiles to figure out whether this idea has legs.

Built it over a weekend with Lovable (React + Supabase under the hood). Custom domain, basic analytics, done. Total cost: a few hours and some coffee.

What I'm Watching For

The honest answer is I don't know if this will work. Personality content is massive online but also crowded. The bet is that combining systems into one readable portrait is different enough to hold attention.

Here's what I'm measuring in the first few weeks: how far people scroll through their reading (do they actually read the whole thing or bail early?), return visits (does anyone come back to try a different date, maybe a partner's?), and organic shares. I didn't build any share buttons on purpose. If people share it, they'll paste the link themselves, and that signal is worth more than a like-count widget.

35 visitors in the first couple of days, no ads, no launch campaign. Just the URL sitting there. If it gets to a few hundred organics in the next month without me pushing it, I'll know there's something worth expanding.

If you're curious, try it: originofyou.com. Takes 90 seconds, costs nothing. I'd love to hear what people think of the multi-system approach.

Jakub, builder @ Inithouse

Why Distribution Belongs Inside Your MVP, Not After It

Jakub — Sun, 10 May 2026 19:11:06 +0000

I spent a year building fourteen products. Most of them are good. Some of them solve real problems. Almost none of them have users.

The reason is embarrassingly simple: I treated distribution as a post-launch task. Something to figure out after the code works, after the design is polished, after the landing page is just right.

That was wrong.

The build trap

Here's what happened. I'd validate a niche, build an MVP in a few days, ship it, post it somewhere, and wait. The product worked. The landing page converted okay. Nobody came.

Four of my products had solid problem-solution fit. Users who found them liked them. But "users who found them" was doing a lot of heavy lifting in that sentence, because almost nobody found them.

What actually moved the needle

After months of near-zero traction across the portfolio, three things started working:

SEO comparison pages. Instead of trying to rank for head terms, I built pages comparing my products to established competitors. These pages rank faster because the query intent is specific and the competition is lower. One product (BeRecommended) went from invisible to getting organic clicks within weeks.

Building in public cross-posting. Writing about what I'm doing across Dev.to, Medium, Hashnode, and a few other platforms. Each post is a small distribution event. The compounding effect is slow but real.

Niche communities over broadcast channels. Posting in specific groups where my target users hang out beats shouting into the void on Twitter. IndieHackers threads, relevant subreddits, Quora answers with genuine context.

What did not work

Product Hunt without a community. Zero pre-launch audience means zero launch momentum. The algorithm rewards early velocity, and I had none.

Twitter without followers. Posting into an echo chamber of zero. Building an audience there takes months of consistent engagement before distribution pays off.

Paid ads without PMF signal. Running Google Ads before knowing if people even want the thing is burning money to learn what organic feedback would tell you for free.

The shift

I now treat distribution as a core feature of the MVP itself. The question isn't "how do I get users after launch" but "how does this product reach people as part of its design."

That means building comparison pages before the launch. It means writing the first building-in-public post the same week I ship. It means choosing niches where distribution channels already exist.

The product is not done when it works. The product is done when people can find it.

I'm Jakub, building Inithouse, a portfolio of small products looking for traction. If you're in the same boat, I'd love to hear what distribution channels work for you.

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

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.