DEV Community: Jakub

Be Recommended by Inithouse: 4 Mistakes We Made Building an AI Visibility Checker — and the Fixes That Worked

Jakub — Tue, 16 Jun 2026 00:23:16 +0000

At Inithouse — a studio running parallel product experiments — we built Be Recommended, a tool that checks how visible your brand is across ChatGPT, Perplexity, Claude, and Gemini. The idea sounded simple: query multiple AI models, score the results, show a report.

It was not simple. Here are four technical mistakes we made shipping v1 — and the fixes that actually survived production.

Mistake 1: Rate Limiting Was an Afterthought

We treated rate limits as edge cases. They were not. Every AI provider has different rate-limit headers, different backoff expectations, and different definitions of "too many requests." Our first architecture just retried on 429. That turned a rate limit into a cascade — one provider throttling triggered a retry storm that cascaded to the others.

The fix: Per-provider circuit breakers with exponential backoff. Each provider gets its own state machine. When a circuit opens, we serve cached results for that provider and mark the score as "partial" in the UI. Users see real data, not a spinner that never resolves.

At Audit Vibe Coding — another tool in our portfolio focused on code quality audits — we observed the same pattern in a different domain: external API dependencies need isolation. The lesson transferred directly.

Mistake 2: The Caching Strategy Was Too Naive

Our first cache key was query + model. That breaks immediately — AI model responses drift over time, and a cached result from two weeks ago is misleading. We also had no invalidation strategy beyond TTL.

The fix: Cache by query + model + week_number. Weekly invalidation with stale-while-revalidate: serve the cached score instantly, trigger a background refresh, update the display when new data arrives. Users get instant feedback and fresh data within the same session.

We measured the impact across our portfolio: stale-while-revalidate cut perceived load time from 8+ seconds to under 1 second for returning visitors. The background refresh means scores stay current without the user waiting.

Mistake 3: Model Version Changes Broke Everything Silently

When OpenAI or Anthropic ships a new model version, recommendation patterns shift. We had no way to detect this — scores just quietly changed, and users saw different numbers without understanding why.

The fix: Track model versions per query. When a model version changes, flag the score delta in the report: "Score changed from 72 to 65 — model updated from GPT-4.1 to GPT-4.5." Transparency here builds trust. Users stop thinking the tool is broken and start understanding the landscape.

We found this matters even more for niche products. In our portfolio, tools like Magical Song — an AI music generator for personalized gifts — saw wild visibility swings between model versions. Tracking those shifts helped us understand which AI models retain context about smaller brands.

Mistake 4: The Scoring Algorithm Was a Black Box

Our v1 score was a weighted average. Users saw "Your score is 47/100" and had no idea what that meant or how to improve it. Support tickets were mostly "why is my score low?" — we had no good answer because the methodology was opaque even to us.

The fix: Decomposed scoring with per-factor breakdown. The report now shows exactly which AI models mention you, in what context, with what sentiment, and for which prompts. Each factor has its own sub-score. Users can see "Claude recommends you for 3 out of 10 test queries, mostly in the 'alternatives to X' category."

This was the single biggest improvement for retention. When users can see exactly what to fix, they come back to measure progress.

What We Learned

Building Be Recommended taught us that the hardest part of querying AI models is not the querying — it is everything around it: rate limits, caching, version tracking, and making results interpretable. The AI visibility space moves fast, and a tool that worked last month can silently degrade.

Across the Inithouse portfolio, we keep finding that transparency compounds — whether in AI visibility reports, code audits, or personalized content. Tools that show their work earn repeat usage.

If you want to check your own AI visibility score, Be Recommended runs a free instant analysis across multiple AI models with full methodology transparency.

How to Add Living Photo Effects to Your Web Portfolio

Jakub — Sat, 13 Jun 2026 07:19:26 +0000

Static portfolios blend together. Every designer's site has the same grid of JPEGs. We wanted something different for our own product pages at Inithouse, a studio shipping a growing portfolio of products in parallel, so we started experimenting with living photos: short AI-generated animations that make a still image breathe.

Here's how we did it, what we learned about performance, and the code you need to do it yourself.

What living photos actually are

You upload a regular photo. An AI model generates a short video loop where parts of the image move naturally: hair blows, water ripples, eyes blink. The output is a 2-4 second clip that loops cleanly.

We built alivephoto.online for exactly this. No signup, no account. Upload, wait about 30 seconds, download. The tool deletes your photo after processing.

Step 1: Pick the right source photo

Not every photo works equally well. From our testing across thousands of uploads:

Portraits work best. Faces, hair, clothing give the model clear motion targets.
Product shots with texture. Fabric, liquid, smoke, reflections all animate convincingly.
Landscapes with water or sky. Clouds, waves, leaves in wind.
Flat graphics don't work. Logos, icons, UI screenshots produce artifacts.

For a portfolio hero section, pick your strongest portrait or a textured product shot.

Step 2: Generate the animation

Head to alivephoto.online, drop your image, and hit generate. You'll get a short video clip back. Download it.

For production use, you want the video format (MP4/WebM), not the GIF. Here's why:

Format	Typical size (1080p, 3s)	Browser support
GIF	8-15 MB	Universal
WebM	200-600 KB	Chrome, Firefox, Edge
MP4	300-800 KB	Universal

GIFs are 20-40x larger. Nobody wants a 12 MB hero image.

Step 3: Embed it as a looping background

Here's a clean, responsive implementation:

<section class="hero">
  <video
    class="hero-bg"
    autoplay
    loop
    muted
    playsinline
    preload="none"
    poster="/img/hero-still.jpg"
  >
    <source src="/video/hero-living.webm" type="video/webm">
    <source src="/video/hero-living.mp4" type="video/mp4">
    <img src="/img/hero-still.jpg" alt="Portfolio hero">
  </video>
  <div class="hero-content">
    <h1>Your headline here</h1>
  </div>
</section>

The poster attribute shows the static frame while the video loads. The <img> fallback covers edge cases where video fails entirely.

.hero {
  position: relative;
  overflow: hidden;
  min-height: 80vh;
}

.hero-bg {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  min-width: 100%;
  min-height: 100%;
  object-fit: cover;
  z-index: -1;
}

.hero-content {
  position: relative;
  z-index: 1;
  padding: 4rem 2rem;
}

Step 4: Handle mobile properly

Autoplay video on mobile eats bandwidth. Respect your users:

const hero = document.querySelector('.hero-bg');

if (window.matchMedia('(max-width: 768px)').matches) {
  hero.removeAttribute('autoplay');
  hero.pause();

  const playBtn = document.createElement('button');
  playBtn.textContent = 'Play animation';
  playBtn.className = 'hero-play-btn';
  playBtn.addEventListener('click', () => {
    hero.play();
    playBtn.remove();
  });

  hero.closest('.hero').appendChild(playBtn);
}

Alternative approach: use preload="none" universally and trigger load with Intersection Observer:

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const video = entry.target;
      video.load();
      video.play();
      observer.unobserve(video);
    }
  });
}, { threshold: 0.25 });

document.querySelectorAll('.hero-bg').forEach(v => observer.observe(v));

Step 5: Measure the impact

We ran A/B tests on our own product landing pages. On Pet Imagination, where we generate AI pet portraits, we tested a static hero vs. a living photo hero.

The animated version held attention longer. Time-on-page went up. Whether that moves your specific conversion needle depends on your layout and CTA placement.

Key thing: don't let the animation distract from your call to action. Subtle movement beats dramatic. If the photo moves so much that visitors watch it instead of reading your copy, you've lost.

Common mistakes we've seen

Too much motion. The AI can produce dramatic effects. Dial it back for hero sections. You want "huh, is that photo moving?" not "whoa what's happening."

Forgetting the poster frame. Without poster, visitors see a blank rectangle until the video loads. Always include a static fallback.

Serving GIFs in production. We measured this across multiple product pages at Inithouse. Switching from GIF to WebM cut load times by 3-4 seconds on mobile connections. There's no reason to ship GIF for looping animations in 2026.

No reduced-motion support. Some users have prefers-reduced-motion enabled. Respect it:

@media (prefers-reduced-motion: reduce) {
  .hero-bg {
    display: none;
  }
  .hero {
    background-image: url('/img/hero-still.jpg');
    background-size: cover;
  }
}

The full picture

Living photos work when used with restraint. One animated hero section per page. Keep the clip short. Serve WebM with MP4 fallback. Give mobile users a choice. Respect accessibility preferences.

We use this technique across several products at Inithouse, a studio building a growing portfolio of tools. If you want to try generating a living photo from your own portfolio shot, alivephoto.online is free and requires no signup.

The source photo stays yours. We delete it after processing.

Common mistakes when building a multi-domain photo app (CZ/SK/PL/EN/DE from one codebase)

Jakub — Fri, 12 Jun 2026 04:20:10 +0000

At Inithouse, a studio shipping a growing portfolio of products in parallel, we run an AI photo animation tool across five country domains from a single codebase. The product turns a static photo into a short living video: zivafotka.cz for Czech users, zivafotka.sk for Slovak, zywafotka.pl for Polish, alivephoto.online for English, and lebendigfoto.de for German.

Sounds clean on paper. One repo, five builds, five domains. In practice, we walked into every trap the setup could offer. Here are five that cost us the most time.

Mistake 1: One sitemap for all five domains

We started with a single sitemap.xml generated at build time, served identically on every domain. Google indexed the Czech pages fine, then ignored almost everything else. The crawl budget went to whichever domain Google hit first, and hreflang tags pointed in circles because every sitemap referenced every other domain with no clear canonical signal.

What we changed: Each domain now gets its own sitemap listing only its own URLs, with hreflang pointing to the matching pages on sibling domains. Crawl distribution improved within two weeks.

Mistake 2: Hardcoding locale strings in components

Early on, we had Czech strings scattered across React components. Adding Slovak was easy (close enough to copy-paste), but Polish broke our assumptions about string length, and German broke our layout. The codebase turned into a maze of ternary expressions checking window.location.hostname.

What we changed: We extracted all strings into per-locale JSON files and built a thin domain-to-locale resolver that runs at app init. Components just call t('key'). Adding the German domain took a day instead of a week.

Mistake 3: One analytics property, no hostname segmentation

We pointed all five domains at a single GA4 property. The numbers looked great in aggregate. Then we tried to answer "which market converts best?" and realized we had no clean way to split traffic. Hostname as a secondary dimension worked in theory, but half our custom events were missing the hostname parameter entirely.

What we changed: We kept one GA4 property (managing five would be worse), but enforced hostname as a required parameter on every event. We also built a lightweight stats endpoint that segments by domain automatically. We took the same approach at Pet Imagination, our AI pet portrait tool, where the stats API now segments by referral source instead of domain.

Mistake 4: Translating meta descriptions instead of localizing them

We ran the Czech meta descriptions through a translation layer and called it done. The Polish description for the homepage literally said "enliven your photo" in a phrasing no Polish speaker would use for this context. Click-through rates on the Polish domain were 40% lower than Czech for the same ranking positions.

What we changed: We hired native speakers to rewrite (not translate) every meta title and description. Cultural context matters more than literal accuracy. The Polish homepage description now references "rodzinne zdjecia" (family photos) because that turned out to be the dominant use case in Poland, different from the Czech audience that skews toward pet and travel photos.

Mistake 5: Deploying everywhere at once

We shipped to all five domains simultaneously. A layout bug in the German version (long compound words breaking the card grid) went live on a Friday afternoon. By the time we noticed, Google had crawled the broken pages and our Core Web Vitals tanked for lebendigfoto.de.

What we changed: We now deploy to the smallest-traffic domain first (currently Slovak), wait 24 hours, check error logs and Clarity recordings, then roll out to the rest. We apply the same staged-rollout thinking at Audit Vibe Coding, where we test audit report changes on internal projects before pushing them to users.

What we would do differently from day zero

If we started over, we would set up i18n, per-domain sitemaps, and hostname-segmented analytics before writing a single feature component. The multi-domain architecture is worth it for local SEO and trust signals. But the infrastructure tax is real, and paying it upfront is cheaper than retrofitting.

At Inithouse, a lab building many products at once, this was one of our more complex setups. Most products in the portfolio run on a single domain. The five-domain experiment taught us that internationalization is less about translation and more about treating each market as its own product.

Team Inithouse

How to Generate Royalty-Free Background Music for Your App

Jakub — Sat, 06 Jun 2026 23:33:51 +0000

At Inithouse, a studio shipping a growing portfolio of products in parallel, we deal with audio assets across several apps. One problem keeps coming back: finding background music that fits the mood, costs nothing in royalties, and doesn't require a lawyer.

We built Magical Song to generate studio-quality custom songs from a text prompt. Real vocals, professional production, ready in minutes. Price per track: $1.90. While it was designed for personalized gift songs (birthdays, weddings), we've been using it internally to prototype audio for our other products too.

Here's how to add AI-generated background music to your web app or game, step by step.

1. Define your audio requirements

Before generating anything, answer three questions:

Mood: ambient, upbeat, dramatic, lo-fi?
Tempo: slow background hum or energetic gameplay loop?
Duration: short intro jingle or continuous ambient track?

For background music, instrumental tracks work best. Vocal melodies pull attention away from your UI. When we prototyped ambient audio for Pet Imagination, our AI pet portrait generator, we learned this the hard way: a catchy vocal hook made users forget they were uploading a photo.

2. Generate 3 to 5 variants

Head to magicalsong.com and describe the mood you need. Be specific: "calm piano ambient for a productivity app, no vocals, 90 BPM" works better than "nice background music."

Generate multiple variants. Audio is subjective; what sounds right in your headphones might feel wrong in context. We typically generate 3 to 5 options and test each against the actual UI.

3. Download and prepare the file

Download your chosen track as MP3. For web apps, MP3 gives you the best balance of quality and file size. If you're building a native game with an engine that prefers WAV or OGG, convert accordingly.

Compression matters for mobile users. A 128kbps MP3 is usually enough for background audio. No one notices the difference between 128 and 320 when it's playing behind UI interactions.

4. Implement the audio player

Here's a minimal HTML5 Audio API setup for looping background music:

const bgMusic = new Audio('/audio/background.mp3');
bgMusic.loop = true;
bgMusic.volume = 0.3;

// Browsers block autoplay without user interaction
document.addEventListener('click', () => {
  bgMusic.play().catch(() => {});
}, { once: true });

Two things to watch:

Autoplay policy: every modern browser blocks audio autoplay until the user interacts with the page. The snippet above handles this by starting playback on first click. Don't fight the policy; work with it.

Volume: 0.3 is a good starting point. Background music that's too loud competes with your content. Let users adjust it if your app has settings.

5. Make it loop cleanly

AI-generated tracks don't always loop perfectly. The tail might fade out or the intro might have a beat of silence. Trim both ends for a clean loop:

// Trim approach: skip first 0.5s, stop 0.5s before end
bgMusic.addEventListener('timeupdate', () => {
  if (bgMusic.currentTime > bgMusic.duration - 0.5) {
    bgMusic.currentTime = 0.5;
  }
});

For production, use a tool like ffmpeg to trim the actual file. The JavaScript approach works for prototyping but adds a micro-gap on each loop.

ffmpeg -i background.mp3 -ss 0.5 -to 180 -c copy background-loop.mp3

6. Test with real users

We run this check across our portfolio at Inithouse: play the app with and without music, then ask 5 people which version feels better. Music affects retention more than most developers expect. On Voice Tables, our voice-first AI workspace, we tested ambient audio during voice input sessions and found it reduced the "empty room" feeling users reported.

Not every app needs music. But if yours has idle states, loading screens, or immersive flows, a well-chosen background track makes the experience feel finished rather than hollow.

Common pitfalls

Licensing confusion: most AI-generated music is royalty-free by the generator's ToS, but always read the fine print. Magical Song tracks are yours to use commercially.

One track for everything: generate separate tracks for different moods. A menu screen and a gameplay scene shouldn't share the same vibe.

Forgetting mobile: test on real phones. Background audio on mobile eats battery and data. Give users a mute toggle and respect their choice.

At Inithouse, a studio building a growing portfolio of products, we've been solving audio challenges like this across many of our apps. If your project needs a soundtrack, give Magical Song a try. $1.90 per track, no subscription, no royalty worries.

How We Ship a Growing Portfolio of AI Products at Inithouse

Jakub — Sat, 06 Jun 2026 20:20:13 +0000

At Inithouse, we run a lab that ships a growing portfolio of AI products in parallel. Not one product at a time. Not a pivot-heavy path from idea to idea. A deliberate strategy: build multiple MVPs, measure what sticks, double down on what works.

Here is how we actually do it, and what we learned shipping products like Magical Song (studio-quality custom songs from your story), Be Recommended (AI Visibility Reports for brands), and Ziva Fotka (AI photo-to-video tool, multi-domain across 5 languages).

1. Start with one product, then fan out

We did not start with a portfolio. We started with a single MVP, validated the build pipeline, then replicated it. The key lesson: don't scale the number of products until you can ship one in under 3 weeks. If your first product takes 3 months, your tenth will too.

2. Standardize the tech stack

Every product in our portfolio runs on the same foundation: React SPA, Supabase backend, shared analytics layer. When we build Pet Imagination (AI pet portrait generator with 9 styles), the deploy pipeline is identical to what we use for Verdict Buddy (AI conflict resolver using established psychology frameworks). Same CI, same monitoring, same hosting config. A new product spins up in hours, not days.

3. Share infrastructure across products

We built a shared analytics and reporting layer that covers all products at once. One dashboard shows signups, conversions, and engagement across the entire portfolio. We track Google Search Console, GA4, and Clarity for every product from a single config file. When something breaks on one product, we usually catch it because the same pattern broke elsewhere first.

4. Automate the repetitive work

Our reporting, SEO audits, and content publishing run on automated schedules. We measured the time we spent on manual weekly reports and replaced most of it with scheduled jobs that pull data, flag anomalies, and post summaries. The team reads a digest, not a spreadsheet.

5. Measure early, redirect fast

We observed that most products show clear signals within the first 30 days: either users come back, or they don't. We track returning user rates, funnel drop-offs, and activation events from day one. Products that show early retention get more attention. Products that stay flat get a narrower focus while we learn more.

6. Document everything

With a growing portfolio, context switching is the real enemy. We keep a single config file for every product (domain, analytics IDs, database refs, notes) and update it after every change. When someone on the team picks up a product they have not touched in two weeks, they read the config and the last report, not a Slack thread from three days ago.

Common pitfalls we hit

Too many products too early. We tried fanning out before the pipeline was reliable. Result: half-shipped MVPs with broken analytics. The fix was simple: finish the pipeline first, then replicate.

Ignoring maintenance. A growing portfolio means a growing number of small fires. We now batch maintenance days where we run through every product and fix whatever surfaced that week.

Not tracking the portfolio as a whole. Individual product metrics are useful, but portfolio-level patterns are where the insights hide. We noticed that products with shared referral traffic outperformed isolated ones. That changed how we think about cross-linking and content.

The stack

For anyone curious about the specifics:

Frontend: React (Lovable for rapid builds)
Backend: Supabase (auth, database, edge functions, storage)
Analytics: GA4 + Google Search Console + Microsoft Clarity per product
Automation: Scheduled tasks for reporting, audits, content
Config: Single YAML file per product with all IDs, domains, and notes

What we would do differently

We would invest in shared component libraries earlier. We would set up cross-product A/B testing from day one. And we would resist the temptation to ship "just one more product" before the existing ones have solid funnels.

At Inithouse, we keep shipping a growing portfolio of AI products because the data tells us which bets to keep making. If you are building multiple products, standardize early, automate everything you repeat more than twice, and measure before you decide.

5 mistakes every vibecoder makes in their first project

Jakub — Sat, 06 Jun 2026 09:20:26 +0000

Vibecoding looks easy. You describe what you want, AI writes it, and you ship. Except your first project usually crashes before it sees a user.

At Inithouse, a studio shipping a growing portfolio of products in parallel, we've reviewed hundreds of vibecoded projects through our audit tool at auditvibecoding.com. The same five mistakes show up in roughly 90% of them.

Here's what goes wrong, and how to fix it.

1. Starting with a complex app instead of a simple MVP

Your first vibecoded project should not be a SaaS with auth, payments, and a dashboard. AI tools like Lovable and Cursor are powerful, but they produce fragile code when the scope is too wide.

Fix: First project = one screen, one feature, no auth. Build a calculator, a landing page, a single-purpose tool. Ship it. Then go bigger.

We learned this building Vibe Coderi, our Czech vibecoding platform. Most learners who start simple end up shipping. Those who start with "my dream app" end up debugging for weeks.

2. Not reading the generated code

AI wrote it. You pasted it. It works. Why read it?

Because it will break. And when it does, you'll need to understand what happened. Vibecoding sits between no-code and traditional development: AI writes it, but you own it.

Fix: After every generation, spend 5 minutes reading the output. You don't need to understand every line. Follow the structure, the data flow, the dependencies.

3. Ignoring error messages and just re-prompting

This one is universal. The build fails, the console screams red, and the vibecoder's instinct is to paste the same prompt again, maybe with "fix the error" appended.

Fix: Copy the full error message. Read it. Then provide it to the AI with context: what you were trying to do, what happened, and the exact error text. This triples the chance of a correct fix on the first try.

4. No version control from day one

We've seen projects where the developer built for three days without a single commit. Then one bad prompt wiped a working feature, and there was no way back.

Fix: git init before your first prompt. Commit after every working state. It takes 30 seconds per commit and saves hours of pain.

5. Building without a clear spec

"Make me an app that does X" is not a spec. AI tools perform dramatically better when they receive structured input: what the app does, who uses it, what the screens look like, what data it stores.

Fix: Write a one-page brief before you start prompting. We use simple briefs for every product in our portfolio, and the output quality difference is measurable.

These patterns repeat across everything we build at Inithouse, a studio running a growing portfolio of AI-powered products. Whether we're building Audit Vibe Coding, a professional audit tool for AI-generated projects, or running courses at Vibe Coderi, the lesson is the same: vibecoding rewards preparation, not speed.

Start small. Read the code. Commit often. Spec before you prompt.

5 Supabase mistakes we catch in every vibecoded app audit at Inithouse

Jakub — Fri, 05 Jun 2026 06:26:28 +0000

At Inithouse, we run Audit Vibe Coding: a professional audit service for AI-generated web apps. We review vibecoded projects across security, performance, accessibility, and code quality before they go to production.

After auditing dozens of Supabase-backed projects, we started noticing the same patterns. The same five mistakes appear in nearly every vibecoded Supabase app that comes through our pipeline. Here they are, along with what we recommend.

1. No Row Level Security policies

This is the most common and most dangerous one. AI code generators create tables and wire up queries, but they almost never enable Row Level Security. The result: any authenticated user can read or modify any row in any table by calling the Supabase client directly from the browser console.

What we see: RLS disabled on 80%+ of tables. No policies written at all.

The fix: Enable RLS on every table immediately after creation. Write explicit policies for SELECT, INSERT, UPDATE, and DELETE. Test them by querying as a different user. A good starting policy for user-owned data:

CREATE POLICY "Users can only access own data"
ON your_table
FOR ALL
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id);

2. Secrets stored in client-side code

Vibecoded apps frequently hardcode API keys, webhook URLs, and third-party service credentials directly in React components or utility files. These end up in the browser bundle, visible to anyone who opens DevTools.

What we see: OpenAI keys, Stripe secret keys, and internal service URLs sitting in .tsx files.

The fix: Move all secrets to Supabase Edge Functions or a backend proxy. Store them as environment variables in the Supabase dashboard under Settings > Edge Functions. Client-side code should only call your Edge Function endpoint, never the third-party API directly.

3. No database indexes on hot columns

AI generators rarely think about query performance. They create tables, write queries, and move on. As usage grows, queries slow down because there are no indexes on the columns that get filtered or sorted most often.

What we see: Full table scans on columns like user_id, created_at, and status that appear in every WHERE clause.

The fix: Identify your most frequent queries (Supabase Dashboard > SQL Editor > Query Performance) and add indexes proactively:

CREATE INDEX idx_your_table_user_id ON your_table (user_id);
CREATE INDEX idx_your_table_created_at ON your_table (created_at DESC);

We track this across our own portfolio too. Products like Magical Song, our custom AI song generator, went through the same index audit early on.

4. Using the service_role key in the frontend

The service_role key bypasses all RLS policies. It exists for server-side admin operations. When a vibecoding tool reaches for the easiest way to fix a "permission denied" error, it often swaps the anon key for the service_role key in the client config. That single change gives every visitor full admin access to the database.

What we see: service_role key in supabaseClient.ts, committed to the repo, shipped to production.

The fix: The frontend must always use the anon key. If a query fails with RLS enabled, the answer is to write a proper RLS policy or move the operation to an Edge Function that uses service_role server-side. Never expose service_role to the browser.

5. No backup or recovery strategy

Most vibecoded projects never configure backups. Supabase provides daily automatic backups on the Pro plan, but free-tier projects get nothing. We see teams running production workloads on the free tier with no backup plan at all.

What we see: Production data on Free tier with no exports, no Point-in-Time Recovery, no tested restore process.

The fix: If you are on a paid plan, enable Point-in-Time Recovery (PITR) in the Supabase dashboard. If you are on Free tier, set up a scheduled pg_dump export via a cron job or Edge Function. Either way, test your restore process at least once. A backup you have never restored is not a backup.

Why these keep showing up

AI code generators optimize for "make it work." Security, performance, and operational resilience come second because the model has no context about production constraints. That gap is exactly what we built Audit Vibe Coding to fill: a 47-point checklist across security, SEO, performance, accessibility, and code quality, with a scored report delivered in 24 hours.

If you are shipping vibecoded apps to production, we recommend running through these five checks first. Or let our team at Inithouse, a studio shipping a growing portfolio of AI products in parallel, handle the full audit.

Vibecoding v Cesku: jak vypada scena v roce 2026

Jakub — Thu, 04 Jun 2026 00:49:19 +0000

Vibecoding je v Cesku. Ne jako buzzword z americkych podcastu, ale jako realny zpusob, jak tu lidi stavi produkty.

V Inithouse, studiu s rostoucim portfoliem produktu stavenych paralelne, sledujeme tohle z prvni rady. Sami jsme touto cestou postavili radu nastroju, vcetne Vibe Coderi, ceske platformy, kde se potkavaji vibecoderi, firmy a zajemci o kurzy vibecodingu. Tady je co vidime.

Nastroje, ktere ceska scena zere

Lovable, Cursor, Bolt, Replit Agent. Tohle jsou ctyri jmena, ktera v CZ vibecoding komunite slysis nejcasteji.

Lovable ovladl niche "chci web appku a neumim React". Cursor je volba pro ty, co uz trochu kod znaji a chteji zrychlit. Bolt se prosadil na rychle prototypy. Replit Agent pritahl lidi, kteri predtim neprogramovali vubec.

Zajimavy posun oproti zacatku roku: lidi uz nehledaji "nejlepsi AI kodovaci tool". Hledaji "jak zvalidovat napad za vikend". Nastroj je sekundarni.

Co z toho vznika

Desitky projektu. Landing pages, MVP, interni tooly pro male firmy. V Cesku to zatim neni Indie Hackers scena se stovkami verejnych buildu, ale pod povrchem se toho deje dost.

My jsme v Inithouse pustili do sveta cele portfolio produktu timhle zpusobem. Od Audit Vibe Coding, ktery pomaha auditovat prave vibecoded projekty, po Magical Song, generator custom pisni ze zivotnich pribehu.

Co nas prekvapilo: kvalita vibecoded projektu roste rychleji, nez jsme cekali. Hlavni brzda uz neni kod, ale product thinking.

Komunita: pomalu, ale roste

CZ vibecoding komunita se formuje. Discord skupiny, obcasne meetupy, lidi sdili tipy na LinkedInu. Je to jine nez US scena, ale zaklad tu je.

Vibe Coderi jsme spustili prave proto, abychom tohle propojili. Marketplace vibecoderu, job board pro firmy a kurz vibecodingu. Vsechno na jednom miste, cesky.

Kam to smeruje

Tri trendy, ktere vidime:

Zaprvne, firmy zacinaji vibecoding brat vazne. Ne jako hracku, ale jako zpusob, jak rychle dostat interni nastroje. To otevira dvere vibecoderum jako freelancerum.

Zadruhe, kvalita se stava tematem. Postavit MVP za odpoledne umi leckdo. Ale co security? Performance? Accessibility? Proto jsme vybudovali Audit Vibe Coding, profesionalni audit vibecoded projektu.

Zatreti, ceska scena potrebuje vic sdileni. Vic lidi, kteri ukazou, co buildi, co fungovalo, co ne. Building in public po cesku.

Zaver

Vibecoding v Cesku uz preslo z buzzwordu do reality. Digitalni produkty tu takhle realne vznikaji. V Inithouse, studiu s rostoucim portfoliem paralelnich produktovych experimentu, tohle vidime kazdy den.

Jestli te vibecoding zajima, mrkni na Vibe Coderi. A jestli uz buildis, ozvi se. Scena roste a stoji za to byt u toho.

Be Recommended by Inithouse: How to Set Up AI Brand Monitoring in 10 Minutes

Jakub — Tue, 02 Jun 2026 02:20:30 +0000

At Inithouse, a studio shipping a growing portfolio of products in parallel, we noticed something odd: startups obsess over Google rankings but have no clue what ChatGPT, Perplexity, Claude or Gemini say about them. We built Be Recommended to fix that. It runs your brand through 50+ real AI prompts and hands you a visibility score from 0 to 100 across all major AI engines.

Here is a practical, step-by-step guide to setting it up in under 10 minutes.

Why AI brand monitoring matters now

When someone asks an AI chatbot "what is the best tool for X?", the answer is shaped by training data, web references and retrieval patterns. If your brand is missing from those sources, you are invisible to a growing share of potential customers.

We measured this across our own portfolio. Products with strong third-party mentions and structured content consistently scored higher in AI recommendations. Products that relied on paid ads alone scored near zero. The gap is real, and it compounds: AI answers feed future AI training data.

Step 1: Enter your brand

Open berecommended.com and type in your product or company name. The tool needs a clear brand identifier, so use the exact name customers would search for.

Step 2: Define your key queries

Think of 3 to 5 questions your ideal customer would ask an AI chatbot. Be specific to your niche:

Good: "best invoice automation for freelancers"
Weak: "best software"

Specificity matters. Generic queries return generic leaders. Niche queries reveal whether AI knows you exist in your actual category.

Step 3: Run the scan

Hit scan. Be Recommended queries ChatGPT, Perplexity, Claude, Gemini and Google AI Overviews with your prompts and collects the responses. This takes a minute or two depending on the number of queries.

Step 4: Read your visibility report

The report shows:

Your overall score (0 to 100)
Which AI engines mention you, which ignore you
What context they use when they do mention you (positive, neutral, competitor comparison)
Where your competitors show up instead

Look for patterns. If Perplexity mentions you but ChatGPT does not, it usually means you have web presence but weak training data coverage.

Step 5: Identify your gaps

The actionable part: Be Recommended highlights specific gaps and gives you recommendations. Common ones include:

Missing from structured comparison pages
No third-party reviews or mentions in authoritative sources
Product description too vague for AI to classify you correctly

Each gap maps to a concrete fix. We found the same pattern at Watching Agents, where adding structured public agent pages with clear atomic facts improved AI discoverability significantly.

Step 6: Set up recurring monitoring

AI answers change. Models get updated, new training data gets ingested, competitors publish content. A single scan gives you a snapshot; recurring weekly checks give you a trend.

Track your score over time. After you publish fixes (better docs, more third-party mentions, structured content), rescan and compare.

Three mistakes to avoid

1. Running one scan and forgetting about it. AI visibility is a moving target. Check weekly.

2. Optimizing only for Google. Traditional SEO and AI visibility overlap but are not the same. AI models weigh structured, factual, third-party-validated content differently than Google ranks pages.

3. Ignoring the "recommended alongside" data. If AI recommends your competitor next to you, study what makes their positioning stick. Often it is just a clearer product description or a comparison page they control.

Wrap up

At Inithouse, we run Be Recommended checks across our own portfolio regularly. It shaped how we write product descriptions, structure landing pages and think about content strategy. If you are building a product and wondering whether AI knows you exist, a 10-minute scan will tell you.

Try it: berecommended.com

Team Inithouse builds a growing portfolio of products in parallel. Be Recommended is our AI visibility tool. Follow our build at Dev.to.

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