DEV Community: Jakub

What 14 Products Reveal That One Can't: Cross-Portfolio Analytics as a Cheat Code

Jakub — Sun, 19 Apr 2026 06:40:57 +0000

Running a single product, you get a steady line of charts: traffic, signups, conversion. You tune each dial and hope the curve bends. Running a portfolio of fourteen products, a different picture emerges. The patterns that were invisible in one product stand out like blinking lights once you can compare them against each other.

This is a building-in-public note about the unfair advantage that comes from measuring many products side by side, with shared GA4 + Clarity instrumentation and one place to look at the data.

The setup

We run a portfolio at Inithouse: roughly fourteen small products at different lifecycle stages. Some are days old, others have months of real traffic. All of them ship the same analytics baseline:

GA4 on every domain, with the same event schema
Microsoft Clarity on every domain, with the same session triggers
A shared Looker Studio workspace where every property is a drop-down away

The payoff is not faster dashboards. The payoff is being able to ask one question across the whole portfolio and see how the answer changes with product age, category, and traffic source.

Pattern 1: the "first 48 hours" scroll signal

One of the cleanest cross-portfolio patterns we see is on new products. For every product we launch, Clarity's scroll-depth distribution in the first 48 hours is weirdly predictive of what that product's bounce rate will look like three months later.

Products where the 75th percentile scrolled past the first CTA on day one (our Czech vibe-coding community Vibe Codéři was a textbook case) tend to keep a healthy return-visit cohort. Products where the 75th percentile bailed before the fold (early iterations of Pet Imagination) needed a rebuild of the hero section before anything else moved.

A single-product founder gets this data too. But they see one number. Without peer products to anchor against, "60% scroll past fold" is just a number. With a portfolio, that same 60% is either a red flag (our stable baseline is 78%) or a green light (our new-product baseline is 45%).

Pattern 2: event mapping drift

Here's one that only shows up when you audit many properties at once: event names drift.

We standardized an event set early: cta_click, form_submit, generator_run, pricing_view. When one developer ships, they use the canon. When another ships, they sometimes improvise: cta_clicked, form_submitted, run_generator. In a single GA4 property you notice nothing. The chart still goes up. In a portfolio view, one property is suddenly missing from a funnel comparison and the cause is almost always event drift.

We now run a weekly job that lists the top 10 events per property and flags anything that doesn't match the canon. It takes 30 seconds of attention per week and has saved us at least two incidents where a product looked dead in analytics and was actually converting fine, just under a renamed event.

If you're building a portfolio, put the canonical event list in a YAML file next to your deploy config. Future you will send a thank-you note.

Pattern 3: the Clarity "rage-click" correlation that wasn't

We had a belief for months that rage-clicks correlated with churn. Clarity surfaces them on every session recording, and it's intuitive: angry user, bad product, user leaves. We even had a threshold in our head.

Running the same analysis across the portfolio broke the belief. On Audit Vibe Coding, high rage-click rate correlated with higher engagement, because the product is interactive and users were spamming the "re-run" button on purpose. On Magical Song, rage-clicks meant exactly what we thought. On a third product, the rage-click signal was dominated by a single broken element in the nav.

The same metric meant three different things across three products. A single-product founder would have picked one interpretation and been either dangerously right or confidently wrong. The portfolio forces you to unlearn the metric as a universal signal and treat it as something that needs per-product context.

Pattern 4: traffic source tells you which product you actually have

One of the most humbling cross-portfolio insights: the traffic source mix tells you what kind of product you built, regardless of what you thought you were building.

We have products we pitched as "tools for professionals" that turn out to get most of their traffic from casual search intent. We have products we launched as "casual consumer apps" that quietly rank for long-tail professional queries and have a tiny, high-intent conversion cohort. Watching Agents is a live example: launched as a general-audience prediction platform, but the organic traffic that actually sticks is coming from research and analyst queries.

If you run one product, you optimize toward whichever audience you originally imagined. If you run a portfolio, you learn early that audience is discovered, not chosen, and you start following the analytics instead of leading them.

What I would tell a portfolio-curious founder

Three things, based on a year of watching this data roll in:

One: standardize your analytics baseline before you have anything to measure. Same GA4 property setup, same event names, same Clarity config. The cost when the portfolio is small is invisible. The cost when the portfolio grows and you have to retroactively unify eight different schemas is painful.

Two: look at the same dashboard view across every product every week, even the dead ones. The patterns you need to see live in the differences between products, not in any one chart.

Three: treat your weakest-performing product as a control, not a failure. It tells you what "normal bad" looks like, which is the baseline you need to recognize when something on a stronger product quietly goes wrong.

A portfolio is not just a hedge against one product failing. It's a continuous calibration instrument for every other product you run. Once you get used to reading it that way, going back to single-product tunnel vision feels like flying with one eye closed.

Building Inithouse in public: 14 products, one analytics stack, one weekly review. More portfolio notes to come.

The Compounding Effect of Domains: Why We Buy URLs Before Writing Code

Jakub — Wed, 15 Apr 2026 11:09:36 +0000

We have a rule at our studio: buy the domain first, build later. It sounds backwards. But after launching 14 products in under a year, I can tell you it changes how you think about every project.

The domain is the land grab

When I started Inithouse, the first thing I did for each product idea wasn't writing a spec or prototyping. It was opening a registrar and checking if the .com was available.

Why? Because a domain is the one thing that gets harder to acquire over time. Code can be rewritten. Designs can be iterated. But a clean, memorable .com that matches your product name? Those disappear. And once they're gone, you're stuck with hyphens, weird TLDs, or paying $5k on the aftermarket.

For VoiceTables (a voice-first workspace builder), the domain was available and it perfectly described what the product does. Same with WatchingAgents, our AI prediction platform. Both names were registered months before we wrote a single line of code.

Some domains start working before the product exists

This is the part most people don't expect. A few of our domains started ranking in Google before we had anything live.

VerdictBuddy is a good example. The domain itself signals what the product does. Google started indexing the holding page, and by the time we launched the actual product, we already had some search visibility. No ads, no backlinks. Just a domain name that matched what people were searching for.

Same story with AuditVibeCoding. "Vibe coding" started trending as a term, and having "audit" + "vibe coding" in the domain gave us a head start when people started searching for tools to review AI-generated code.

The .com tax is worth it

I know there's a whole debate about whether .com still matters. For us, it absolutely does. Here's why:

People type .com by default. When someone hears "Pet Imagination" and wants to check it out, they'll type petimagination.com without thinking. If we had petimagination.app or petimagination.io, we'd lose a chunk of direct traffic to whoever owns the .com.

The one exception we make is for local markets. VibeCoderi.cz targets Czech developers, so .cz makes sense there. And for ZivaFotka, our AI photo animation tool, we went with .cz for the Czech market but also grabbed alivephoto.online for international, zywafotka.pl for Poland, and lebendigfoto.de for Germany. Multiple domains, same codebase.

Our decision framework

Not every domain purchase makes sense. Here's roughly how we think about it:

Buy immediately if the .com is available and under $15/year. The yearly cost is basically nothing compared to the optionality you get. We grabbed MagicalSong, PartyChallenges, ScaryChallenges, NaughtyChallenges, HereWeAsk, BeRecommended, and WithoutHuman all this way. Each one cost less than a coffee subscription for the year.

Think twice if it's a premium domain ($500+). At that point, you need conviction that the product will actually ship.

Skip if you're forcing a name to fit a domain. The name should come naturally. If you need to add "app" or "hq" or "get" as a prefix, the name probably isn't right.

The portfolio effect

Here's where it gets interesting. When you have 14 products, domains start reinforcing each other. A blog post on WithoutHuman can mention WatchingAgents. A solutions page on VoiceTables can reference BeRecommended. Each domain becomes a node in a network, and links between them carry SEO value.

This isn't something you plan from day one. It emerges naturally when you have a portfolio of real products on real domains. And it compounds. Every new product you add creates linking opportunities with all existing ones.

The cost math

Let's do some quick numbers. We own roughly 20 domains across our portfolio (including localized variants). At $10-15/year each, that's about $200-300/year total. For context, a single Google Ads click in most of our niches costs $1-3.

One domain that ranks organically for its target keyword pays for the entire portfolio's registration costs many times over. It's not even close.

What I'd tell someone starting out

If you're building side projects or launching a startup, here's the practical version: spend 20 minutes checking domain availability before you commit to a product name. If the .com is taken, reconsider the name. Not because .com is magic, but because naming constraints often lead to better, more distinctive names anyway.

PetImagination is a better name than "AI Pet Portrait Generator Pro." MagicalSong beats "AI Music Creator Tool." The domain forces clarity.

And once you buy it, point it somewhere immediately. Even a single landing page with your email. Let Google know the domain is alive. Time is your friend here. The longer a domain has been active, the more authority it builds.

That compounding never stops working.

Building a Voice-First Workspace: What We Learned Shipping VoiceTables

Jakub — Tue, 14 Apr 2026 07:39:08 +0000

Most developer tools start with a UI mockup. Ours started with a microphone.

We just launched VoiceTables -- a workspace where you describe what you need and the AI builds it. Say "I need a client tracker with status and revenue" and you get a structured table with the right columns, sample data, and connected docs. No forms, no drag-and-drop, no 20 minutes of manual setup.

Here's what we learned building it.

The core problem: voice is messy, tables are not

The hardest part wasn't the speech-to-text. That's basically a solved problem in 2026. The real challenge was turning fuzzy human language into clean, structured data.

When someone says "track my invoices," they don't specify column types, data formats, or relationships. They just... say it. And they expect the result to make sense.

So the actual engineering challenge is the middle layer: understanding intent, inferring schema, generating realistic sample data, and presenting it all in under 60 seconds.

How the pipeline works

At a high level:

Voice capture -- browser-native Web Speech API for real-time transcription. We tried a few third-party APIs early on but the latency was killing the experience. Native browser speech recognition is faster and good enough for workspace commands.
Intent parsing -- the transcribed text goes through an LLM layer that extracts the workspace type, expected fields, and data relationships. This is where most of the prompt engineering lives. We tested dozens of system prompts before landing on one that reliably generates sensible schemas from vague descriptions.
Schema generation -- the parsed intent becomes a typed schema (column names, types, constraints). We generate sample data that actually looks real, not "lorem ipsum" rows but things like "Acme Design, $2,400, Paid."
Real-time rendering -- the table appears progressively as the AI generates it. No loading spinner. You see the columns form, then the rows fill in. It feels like someone is building it in front of you.

Conversational refinement was the surprise hit

We built the initial "voice to table" flow and thought that was the product. But during testing, people kept talking to it. "Add a priority column." "Filter by overdue items." "Summarize my revenue."

So we leaned into it. VoiceTables now supports ongoing conversation with your workspace. You can restructure, filter, add docs, ask questions about your data, all without touching a menu.

The technical bit here: we maintain a conversation context that includes the current schema state. Each new command is interpreted relative to what already exists. It's basically a stateful agent loop where the workspace IS the memory.

Three-in-one was intentional

We ship tables, docs, and AI chat in one workspace. Not because "more features = better" but because in practice, data and context always live together.

When a freelancer tracks invoices, they also need a note about payment terms. When a team lead sets up a sprint board, they need a doc for the retrospective. Forcing people into three separate tools (Notion for docs, Airtable for tables, ChatGPT for questions) is a workflow tax nobody wants to pay.

What's next

We're in beta right now. Free tier, $19/mo Plus plan, custom Enterprise. No credit card needed to start.

The honest truth: we don't know yet which use cases will stick. Freelancers tracking clients? Small teams running projects? Field workers logging inventory by voice? We built it broad on purpose and we're watching what people actually do with it.

If you want to try it: voicetables.com

I'm Jakub, building VoiceTables and a portfolio of AI products at Inithouse. Other things we've shipped recently: Be Recommended (check if AI chatbots recommend your brand), Audit Vibecoding (security audit for AI-generated code), and Watching Agents (AI prediction platform). Follow along for more build logs.

11 Landing Pages for 11 Niches: How We're Testing Who Actually Wants VoiceTables

Jakub — Sun, 12 Apr 2026 11:42:41 +0000

Most founders pick a niche and go all-in. We did the opposite. We built 11 landing pages for 11 different professions and shipped them all at once.

Here's why, and what we're learning from it.

The problem with "pick one niche"

When we started building VoiceTables (a voice-first AI workspace where you talk instead of type), we had the classic early-stage dilemma. The product works for a lot of different people. Freelancers tracking invoices. Sales reps logging calls from the car. Craftsmen on job sites with dirty hands.

But which one actually wants it enough to pay?

The lean startup playbook says: pick one, validate, iterate. That's solid advice. But when your product is horizontal (like a database or a spreadsheet), picking one niche too early means you might be optimizing for the wrong audience for months.

So we built 11 solution pages instead

Each page targets a different profession with tailored copy, specific voice command examples, and use cases that speak directly to their daily pain points. Here's the full list:

Craftsmen & Tradespeople -- "Add a job: kitchen rewiring, 4 hours, 340 euros"
Sales Reps & Field Agents -- "Update Acme deal: met with Sarah, follow up Friday"
Real Estate Agents -- "The Johnsons loved the backyard, follow up Thursday"
Freelancers & Solopreneurs -- "Add project: rebrand for Olive Studio, 3500 euros"
Small Business Owners -- "Received shipment: 50 candle sets, invoice 4821"
Event Planners -- "Add vendor: Bloom Florals, delivering at 2pm, budget 1200"
Coaches & Personal Trainers -- "Log Jake: bench press 80kg, 4 sets, felt strong"
Consultants & Agencies -- "Log 3 hours on DataFlow strategy, competitor analysis"
Students & Researchers -- "Add source: Smith 2024, relevant to chapter 3"
Content Creators -- "New brand deal: FitGear, 3 posts, budget 2000"

Each page lives under voicetables.com/solutions. Same product, same features, completely different framing.

The thinking behind it

This isn't random. We grouped the niches into three buckets:

In the Field -- people whose hands are literally too busy to type. Craftsmen, sales reps, real estate agents. Their phone is in their pocket, they need to capture data between appointments or while standing in someone's kitchen.

Running a Business -- solopreneurs and small teams wearing every hat. Freelancers, small business owners, event planners. They don't have time for complex tools. They need something that just works when they talk to it.

Knowledge Work -- people drowning in information. Coaches tracking client progress, consultants juggling multiple projects, students collecting research sources, creators managing brand deals.

The hypothesis: the "in the field" group probably has the strongest pull because typing is genuinely painful for them. But we don't know yet. That's the whole point.

What we're actually measuring

For each solution page, we're watching:

Traffic and bounce rate -- does the page title and meta description attract the right clicks from search?
Time on page -- does the copy resonate or do people leave after 5 seconds?
CTA clicks -- does anyone actually click "Try it free"?
Signup-to-activation -- the real metric. Did they create their first table by voice?

We're using Google Search Console for indexation tracking and GA4 for behavior data. It's early days, but we already see differences in how each page performs.

The portfolio scout mindset

This approach comes from something we practice at Inithouse more broadly. We run a portfolio of products, each testing a different market. Ziva Fotka animates old photos. Magical Song generates custom songs with real vocals. Be Recommended checks if AI chatbots recommend your business. Audit Vibe Coding audits AI-generated codebases.

Same philosophy: ship fast, measure everything, double down on what works. Kill what doesn't.

With VoiceTables, we're applying that same mindset within a single product. Instead of launching 11 separate products for 11 niches, we built one product with 11 entry points. Each solution page is basically a micro-experiment.

Early observations

We're only a couple weeks in, so take this with a grain of salt. But a few things are already becoming visible:

The "hands-busy" niches (craftsmen, sales reps) generate the most intuitive copy. When the value prop is "your hands are full, just talk," people get it immediately. There's no explaining needed.

Knowledge worker niches need more convincing. A consultant already has Notion and Airtable. Why switch? The answer ("because you can just say what you need instead of building a schema") is compelling, but it takes more words to land.

Students are a wild card. Low willingness to pay, but high engagement when they try it. Could be a growth lever, could be a distraction.

What's next

Over the next few weeks, we'll start seeing real SEO data come in. Which pages rank, which keywords drive clicks, which niches have enough search demand to justify further investment.

Then comes the hard part: picking 2-3 winners and going deep. Custom features, tailored onboarding, maybe even niche-specific pricing.

But for now, 11 pages are out there, collecting data. And that beats guessing.

If you're building a horizontal product and struggling with niche selection, try this approach. Ship multiple landing pages, each framed for a different audience. Let the data tell you who your real users are.

VoiceTables is free to try, no credit card needed. And if you want to see all 11 solution pages: voicetables.com/solutions.

We also recently launched Watching Agents, a prediction platform where AI agents track questions about the future, and Party Challenges / Here We Ask, two card games testing the social games market. Different products, same experiment-first philosophy.

Would love to hear if anyone else is running multi-niche landing page tests. What worked, what didn't?

Our Portfolio Runs on One-Time Payments. Here's the Stripe Setup.

Jakub — Fri, 10 Apr 2026 07:44:19 +0000

Every SaaS playbook says the same thing: build recurring revenue. MRR is king. Subscriptions scale.

I went the other way. Our portfolio of 14 products runs entirely on one-time payments. No monthly fees, no annual plans, no "cancel anytime" copy. You pay once, you get your thing, done.

Here's why, and how we set it up with Stripe.

The subscription fatigue problem

People are tired. The average consumer now manages 12+ active subscriptions. Every new tool wants $9/month, $29/month, $99/month. And for products people use once or twice? That math just doesn't work for either side.

We build AI-powered tools. Most of our users come in, do one thing, and leave happy. An animated photo. A custom song. A code audit report. Charging $9/month for something someone uses once a quarter felt dishonest.

So we asked: what if we just... didn't?

What our payment model looks like

Three products, three simple prices:

Magical Song - AI-generated custom songs with real vocals. $6 per song. No account needed.
Audit Vibecoding - Professional audit of AI-generated code. $4-9 per report. 47 checks across security, SEO, performance, accessibility.
Ziva Fotka - AI photo animation. One-time payment per animation. Serves 5 markets (CZ, SK, PL, EN, DE) from a single codebase.

No free trials that convert to paid. No credit card upfront. No dark patterns. You see the price, you pay, you get value. Immediately.

The Stripe implementation

Setting up one-time payments with Stripe is surprisingly simple. Here's the architecture we use across all products:

User clicks "Buy" > Stripe Checkout Session (server-side) > Payment > Webhook > Deliver value

The key piece is Stripe Checkout in payment mode (not subscription):

const session = await stripe.checkout.sessions.create({
  mode: 'payment',
  line_items: [{
    price_data: {
      currency: 'usd',
      product_data: {
        name: 'Custom AI Song',
        description: 'Studio-quality song with real vocals',
      },
      unit_amount: 600, // $6.00
    },
    quantity: 1,
  }],
  success_url: YOUR_DOMAIN + '/success?session_id={CHECKOUT_SESSION_ID}',
  cancel_url: YOUR_DOMAIN + '/cancel',
});

Then handle the webhook:

// Listen for checkout.session.completed
app.post('/webhook', async (req, res) => {
  const event = stripe.webhooks.constructEvent(
    req.body,
    req.headers['stripe-signature'],
    webhookSecret
  );

  if (event.type === 'checkout.session.completed') {
    const session = event.data.object;
    // Trigger value delivery (generate song, run audit, etc.)
    await deliverProduct(session.metadata.productType, session);
  }

  res.json({ received: true });
});

That's it. No subscription logic, no billing cycles, no failed payment retry flows, no churn tracking infrastructure. The simplicity is the point.

What we learned

Conversion rates are higher than we expected. When someone sees "$6, one time" vs "$9/month", the barrier drops significantly. People don't need to calculate annual cost or worry about forgetting to cancel.

Support load dropped. No "how do I cancel?" emails. No "I was charged again" disputes. No proration questions. Our support inbox is mostly "cool product, thanks."

The economics work differently. Yes, we don't get monthly compounding. But we also don't have churn. Every dollar earned is earned. No MRR anxiety, no cohort decay charts to stare at.

Multi-currency is free complexity. Stripe handles it. We set prices in USD and Stripe converts automatically based on the buyer's card. For Ziva Fotka, which runs across 5 countries, this was a huge win.

When one-time payments DON'T work

I'm not saying subscriptions are bad. They make sense when:

Your product delivers ongoing value (project management, communication)
Users come back daily or weekly
You need to fund continuous infrastructure costs per user

But if your product is transactional, if users come for a specific output, one-time payments align incentives better. You only get paid when you deliver value. There's something clean about that.

The tech stack

All our products run on React + Supabase + Stripe, deployed through Lovable. The payment flow is identical across products, just with different prices and delivery logic. We built it once and reuse it everywhere.

If you're building something where users want a result, not a relationship, consider skipping the subscription. Your Stripe integration will be simpler, your users will be happier, and you might be surprised by the conversion numbers.

Building 14 products in public at inithouse.com. Follow the journey.

We Query ChatGPT, Claude, and Perplexity About Your Brand. Here's the Architecture

Jakub — Thu, 09 Apr 2026 12:43:14 +0000

A few months ago I had a question that didn't let me sleep. When people ask ChatGPT "what's the best tool for X", which brands actually get mentioned? And more importantly: does my brand get mentioned?

Turns out this is a surprisingly hard thing to measure. So we built a product for it. It's called Be Recommended, and under the hood it's a system that parallel-queries ChatGPT, Claude, Perplexity, and Gemini, then scores how visible a brand is inside their answers.

This post is about the architecture. And about the data we found, which frankly shocked us.

The problem in one line

Traditional SEO tells you how you rank on Google. But when someone opens ChatGPT and asks "what's the best CRM for a solo consultant", Google isn't in the room. The LLM answers directly, from its training data plus whatever live retrieval it does. If your brand isn't in that answer, you lose the customer before you even know they existed.

The Gartner forecast everyone quotes says roughly a quarter of search volume moves to AI assistants by 2026. Our own data, which I'll get to, suggests the shift is faster than that in some verticals.

Why this is harder than it looks

The naive version is easy: open ChatGPT, type a prompt, see if your brand is mentioned. Done.

The real version is not.

Problem one is prompt variance. "Best CRM for solo consultant" and "what CRM should a one person agency use" return different answers. Any scoring that hits a single prompt is basically noise. You need a prompt set per vertical, seeded with realistic intent, and you need to rotate through it.

Problem two is model variance. ChatGPT and Claude don't even agree on what decade it is, let alone which SaaS product is the market leader. Averaging them hides the signal. We report per-engine scores separately and then a blended composite.

Problem three is response variance. The same prompt to the same model on two different days will surface different brands. You need to sample, not snapshot.

Problem four, and this is the one that took us the longest, is parsing. LLMs don't return JSON when you ask "what CRM should I use". They return prose with brand names sprinkled inside sentences, sometimes with typos, sometimes with "CRM Hub" instead of "HubSpot CRM", sometimes with a brand mentioned in a dismissive footnote. You can't just grep.

The architecture, top to bottom

Here is how a single "analyze my brand" request flows through the system.

Step one: intent expansion. The user gives us a brand name and a URL. We pull the landing page, classify the vertical, and generate a set of 20 to 40 representative buyer intents. "Best X for Y", "alternatives to Z", "is brand A worth it", "what's the cheapest way to do W". The prompts are not random. They are templated against real search intents we've scraped from Quora, Reddit, and Google's People Also Ask.

Step two: parallel fanout. Each prompt is dispatched to every engine in parallel. Four engines, up to forty prompts, that's one hundred and sixty concurrent inference calls per scan. We don't wait serially. If you do, a single scan takes twenty minutes and the user bounces.

Step three: rate limiting. This is where it got real. OpenAI's TPM limits on the standard tier make a naive fanout impossible. We implemented a token-bucket limiter per engine, per model, with exponential backoff and jittered retries. When one engine is saturated we spill to another to keep the user's scan moving. Responses get deduplicated against a short-lived cache so two prompts with near-identical semantics don't double-bill.

Step four: response normalization. This is the parsing layer. Each response gets run through a second, cheaper LLM call whose only job is to extract mentioned entities and classify the sentiment of each mention. Positive mention, neutral mention, negative mention, dismissive footnote. We also track position: was your brand first, third, or buried at the end of a list of ten? Position matters because users don't read past the top three.

Step five: scoring. The scoring algorithm is where the opinion lives. We weight by engine reach (ChatGPT dominates), by mention sentiment, by position, and by the share of prompts that mentioned the brand at all. The output is a 0 to 100 score, the AI Visibility Score. The math is tuned so that a brand mentioned positively in the top three of most prompts on most engines lands around 80. That's the "top performer" band.

Step six: reporting. We don't dump raw data on users. The final report shows the composite score, a per-engine breakdown, the exact prompts where you were mentioned and where you weren't, the top competitors that showed up in your place, and a prioritized list of fixes. The fixes come from a rules engine that pattern-matches on the gaps. Missing G2 listing, thin landing page, no schema markup, no authoritative third-party mention, and so on.

What the data showed us

We ran the system against a few hundred brands across SaaS, e-commerce, agencies, and consumer apps. A few findings that genuinely surprised me.

The average AI Visibility Score is 31. Out of 100. That means for most companies, most of the time, the major LLMs either don't mention them or mention them in a throwaway sentence. Think about that for a second. A whole industry is optimizing for Google while the actual decision-making conversation has already moved somewhere they're not even present.

Brand recognition and AI visibility are barely correlated. We scanned some household SaaS names and found scores in the 40s. We scanned smaller tools with great documentation and active third-party review coverage and found scores in the 70s. Training data eats marketing budgets for breakfast. What the internet wrote about you five years ago matters more than what your ad agency shipped last quarter.

The engines disagree a lot. It's common to see a 30-point spread between ChatGPT and Perplexity for the same brand. Perplexity leans heavily on fresh retrieval, so it rewards recent coverage. ChatGPT leans on training snapshots, so it rewards longevity and repeat mentions in tech press. Claude sits in the middle. Gemini is the wildcard.

Position bias is brutal. Being mentioned fifth in a list of ten is almost the same as not being mentioned at all. Users read the first two or three answers and stop. If the LLM puts you in sixth place, you're invisible.

What we learned building it

Two things I'd tell anyone trying to build something similar.

First: the parsing layer is where your product lives or dies. Getting prompts right is easy. Calling the APIs is easy. Extracting clean, structured mentions from messy LLM prose is the whole game. We rewrote ours three times before it was usable.

Second: this space is moving fast enough that any snapshot is a guess at the current weather. We rescan on a schedule because the same brand can swing 20 points in a month when a big review lands or a model version ships. A one-shot audit is entertainment. A tracked score over time is actually useful.

Try it

If you're curious what the three big LLMs say about your own brand, Be Recommended runs a scan for $4. You get a full report with the prompts, the engines, the competitors, and the fixes. We built it because we were running this for ourselves every week and decided it was silly not to let other people use it.

Would love to hear what score you get. Drop it in the comments.

AI Style Transfer That Doesn't Lose the Dog

Jakub — Wed, 08 Apr 2026 08:41:55 +0000

Style transfer sounds simple in theory. You take an image, apply an artistic style, done. Except when your input is a photo of someone's actual pet, "done" is the beginning of the problem.

I've been building Pet Imagination, an AI pet art generator with 9 artistic styles. The pitch is straightforward: upload a photo of your dog, cat, bird, whatever, pick a style like Watercolor or Renaissance, and get back a portrait that actually looks like your pet. Not a generic cute animal wearing a costume.

Turns out that last part is really, really hard.

The Identity Problem

Most style transfer approaches treat the content image as a loose suggestion. You feed in a photo of a French Bulldog with a distinctive underbite and brindle pattern, and out comes... a vaguely dog-shaped blob in the target style. The "artistic interpretation" ate everything that made the dog recognizable.

This is fine for landscapes. Nobody cares if the mountains shift a bit. But pet owners notice everything. The ear shape is wrong? They'll tell you. The markings switched sides? Absolutely not. The expression changed from "skeptical" to "happy"? That's not their dog anymore.

We went through dozens of iterations trying to solve this. Early versions were basically unusable. The AI would latch onto the style so hard that breed-specific features just vanished. A Dalmatian without spots. A Husky with floppy ears. A Siamese cat that came out tabby.

Why Renaissance Works Better Than Anime

Here's something I didn't expect: some art styles are inherently better at preserving identity than others.

Renaissance style turned out to be one of the most reliable. It makes sense when you think about it. Renaissance portraiture was obsessed with capturing the exact likeness of the subject. The style itself demands accurate proportions, realistic fur textures, and faithful color reproduction. The AI just needs to add dramatic lighting, a dark background, and maybe a lace collar. The subject stays intact.

Anime, on the other hand, was a nightmare. The anime aesthetic actively fights against individual features. It wants to simplify. Round the eyes, smooth the fur, standardize the proportions. Every cat wants to become the same cat. We had to significantly constrain the style influence to keep breed characteristics visible, and even then it's the style most likely to drift.

Watercolor sits in a nice middle ground. The loose brushwork actually helps because it doesn't need pixel-perfect accuracy, but the composition stays true to the original. Sketch works similarly. The abstraction is in the rendering technique, not in the subject's features.

The costume styles (Sheriff, Wizard, Astronaut) introduced a completely different challenge. You're adding elements that don't exist in the source photo. A sheriff hat, a wizard robe, a space helmet. The AI has to figure out where the pet ends and the costume begins, and it has to do that without obscuring the face. We found that any costume element overlapping with the pet's face would tank recognition. So the generation pipeline specifically protects the facial region.

The 4K Upscale Problem

Generation at base resolution is one thing. Pushing to 4K for print-quality output is another game entirely.

The naive approach is generate-then-upscale. Run the style transfer at a manageable resolution, then use a super-resolution model to blow it up to 4K. Problem: super-resolution models are trained on photos, not art. They try to "fix" the artistic style by sharpening brushstrokes into photo-realistic textures. Your watercolor portrait suddenly has crispy fur detail that breaks the whole aesthetic.

We ended up needing style-aware upscaling that respects the artistic treatment. Watercolor gets soft upscaling that preserves the bleed edges. Sketch keeps the pencil texture without adding phantom detail. Renaissance gets the most aggressive sharpening because it wants that level of detail.

Processing time was another constraint. Pet owners aren't patient. They uploaded a photo for fun, probably on their phone, probably with three other tabs open. If it takes more than 60 seconds, they're gone. Getting 4K output within that window required some aggressive optimization on the pipeline side.

What Actually Ships

The live product at petimagination.com does 9 styles: Watercolor, Renaissance, Anime, Sketch, Sheriff, Wizard, Astronaut, Final Boss, and Blocky. Each one was individually tuned. There's no universal "style strength" slider because the right balance is different for every style.

It accepts any pet species. Dogs and cats are the majority of uploads, obviously, but we've had birds, rabbits, reptiles, hamsters. The identity preservation challenge scales with how distinctive the animal looks. A golden retriever is harder than a parrot because golden retrievers look more similar to each other than parrots do.

No account required. No watermarks. Print-ready output with optional 4K upscale. The whole thing runs in the browser, upload to download in under 60 seconds.

Lessons for Anyone Doing Style Transfer

If you're working on something similar, a few things I'd pass along:

Test with breed pairs, not random images. Get two photos of different dogs of the same breed and verify the output looks different. If your style transfer makes two different Golden Retrievers look identical, your identity preservation is broken.

Protect the face region explicitly. Whatever else you do with style strength, dial it back around the eyes and muzzle. That's where recognition lives.

Different styles need different pipelines. A single model with a style parameter will always compromise. Renaissance and Anime are so fundamentally different in what they preserve vs. abstract that treating them the same way guarantees mediocre results for both.

Upscaling is not an afterthought. If you're promising print quality, your upscaling strategy needs to be style-aware from day one. Bolting it on later creates artifacts that are obvious at print size.

This is one of ~14 products I'm building at Inithouse. We're a small team running lean experiments across different niches. Some of our other projects: Magical Song for AI-generated custom songs, Be Recommended for checking your AI visibility score, and Watching Agents, a prediction platform where AI agents track questions about the future.

If you're building something with generative AI and hitting similar identity-preservation challenges, I'd love to hear how you're solving it.

Same Components, Different Worlds: Two Card Games from One Codebase

Jakub — Tue, 07 Apr 2026 09:39:00 +0000

When I started building Party Challenges, I didn't plan to ship a second product from the same code. But about two weeks in, I noticed something. The card component, the deck selector, the game loop, the PWA setup... none of it cared what was on the card. A dare and a deep question look exactly the same to a React component.

So I built Here We Ask on top of the same foundation. Same card flip animation, same deck navigation, same offline-first architecture. Completely different product.

Here's what I learned shipping two products from one codebase, and why I think more indie builders should try this.

The shared layer

Both products are React SPAs built with Lovable (a vibe-coding tool I use for rapid prototyping). They share roughly 70% of their component tree:

Card component with flip animation and swipe gestures
Deck selector with category filtering
Game modes (Hot Seat, Timed, Classic)
PWA service worker for offline play
Daily content rotation logic
Premium gate and payment flow ($1.99/mo on both)

The key insight: if you build your components around behavior rather than content, reuse becomes trivial. A <GameCard> doesn't need to know if it's holding "I dare you to sing your last text out loud" or "What's a belief you held strongly five years ago that you've since changed?" It just renders text, handles swipe, tracks progress.

Where they diverge

The interesting part isn't the shared code. It's where the products have to be different.

Party Challenges is loud. Bright colors, bold typography, animations that feel like confetti. The "Date Night" deck here means flirty dares and physical challenges. The copy says things like "no boring moments." The whole vibe is Friday night energy.

Here We Ask is calm. Softer palette, more whitespace, slower transitions. The "Date Night" deck here means vulnerability prompts and relationship check-ins. The copy talks about "meaningful connections." Sunday morning energy.

Same component renders both. The theming layer does all the heavy lifting. I use a config object per product that controls:

// Simplified example
const productConfig = {
  theme: 'party' | 'calm',
  cardAnimation: 'bounce' | 'fade',
  deckOrder: [...],
  premiumDecks: [...],
  dailyContentPool: 'challenges' | 'questions',
  copyVariant: 'energetic' | 'reflective'
}

One config swap, entirely different product feel.

What "Date Night" taught me about product positioning

This is my favorite example. Both products have a deck called "Date Night." In Party Challenges, it's cards like "feed each other blindfolded" and "recreate your first date but everything goes wrong on purpose." In Here We Ask, it's "what's something you've never told me but always wanted to?" and "where do you see us in five years, honestly?"

Same feature name. Same UI. Completely different emotional register.

When I show both to people, they often don't realize it's the same codebase. That's the goal. The tech should be invisible. Users don't care about your architecture. They care about whether the product fits their moment.

The portfolio math

Here's where it gets practical. Building the second product took maybe 30% of the effort of the first one. Most of that was content creation (writing 1,000+ questions vs. 1,000+ challenges) and the theming/copy work. The infrastructure, deployment, PWA setup, analytics, SEO patterns... all reused.

I run a portfolio of products at Inithouse. The idea is simple: build small, focused tools and see what sticks. Some of them are AI-powered, like Magical Song (personalized AI songs) or Pet Imagination (AI pet portraits). Others are content-driven, like Vibe Coderi (a Czech vibecoding portal). Each one is an experiment.

The card games taught me that portfolio building isn't just about launching separate products. It's about finding the shared bones across them. Every component you build well once is a component you never build again.

Practical takeaways for builders

Start with behavior, not content. If your component tree is organized around what happens (flip, swipe, filter, gate) rather than what says (dare, question, quote), you can reskin faster than you think.

Theme configs beat feature flags. I tried feature flags first. It got messy fast. A dedicated config object per product is cleaner and easier to reason about. You always know which product you're looking at in the code.

Content is the real work. The tech took weeks. The content took months. Writing 1,000 good party dares is a different skill than writing 1,000 good conversation starters. Don't underestimate this part.

Ship the second product before perfecting the first. I could have spent another month polishing Party Challenges. Instead I shipped Here We Ask while the architecture was fresh in my head. Both products improved faster because fixes in one often applied to both.

What's next

I'm looking at whether this pattern extends beyond card games. Verdict Buddy (AI conflict resolution) and Watching Agents (AI prediction platform) use completely different architectures, but some lower-level patterns (SEO hooks, analytics setup, PWA configs) keep showing up. There might be a shared toolkit hiding in there.

If you're building multiple products, or even thinking about it, I'd love to hear how you handle code reuse across them. Drop a comment or find me on Dev.to.

I'm Jakub, founder of Inithouse. We build a portfolio of small AI and web products, testing ideas fast and seeing what resonates. Party Challenges and Here We Ask are two of about a dozen experiments currently running.

Voice-to-Schema: Turning "Track My Invoices" Into a Real Table

Jakub — Sun, 05 Apr 2026 07:08:16 +0000

We rebuilt our NLP pipeline three times before it actually worked. Here's what went wrong each time and what we learned about the gap between what people say and what they mean.

The Problem Nobody Talks About

When we started building VoiceTables, we had a simple hypothesis: let people describe what they need, and generate a structured table from that description. User says "I need to track my invoices," system creates an invoices table with sensible columns. Easy, right?

Turns out spoken language and structured data are almost completely different things. The first version took about two weeks to build and maybe 20 minutes to realize it was broken.

Attempt 1: Naive Prompt Engineering

The first pipeline was embarrassingly simple. Take the transcript, send it to an LLM with a system prompt like "extract a table schema from this description," parse the JSON response.

It worked perfectly for clean inputs. "Create a table with columns: client name, invoice amount, due date, status" produced exactly what you'd expect.

Nobody talks like that.

Real inputs looked like this:

"uh, I need something for... like tracking stuff, you know, for my clients"
"make me a table, invoice things, the usual"
"so I've got these freelance gigs and I keep losing track of who paid me"

The third one is actually the most useful input. It tells you what the user needs (payment tracking), who they're working with (freelance clients), and what the pain point is (losing track of payments). But our v1 pipeline couldn't extract any of that. It would either hallucinate random columns or return a generic two-column table that helped nobody.

Attempt 2: Two-Stage Extraction

For the second version, we split the pipeline into two steps:

Intent extraction: figure out what domain the user is working in (invoicing, project management, inventory, etc.) and what they actually want to track
Schema generation: given the intent, generate an appropriate table structure

This was better. The intent layer caught things like "freelance gigs" mapping to freelancer invoicing, which gave the schema generator much better context.

But we hit a new problem: ambiguity in spoken language vs. typed input.

When someone types "client name," they mean a text column called "Client Name." When someone says "client name," they might mean:

The name of their client (text column)
A reference to an existing clients table (foreign key)
"the client" as filler while they think about what to say next

Spoken language has pauses, restarts, filler words, self-corrections. "I need a table for... no wait... like, a list of my clients and their... the projects, and how much each one... you know, the budget for each project."

That sentence contains at least three potential columns (client, project, budget) and a relationship (clients have projects). Our v2 would sometimes generate six columns because it treated "no wait" and "you know" as potential data points.

Attempt 3: What Actually Works

The third rewrite introduced something we should have done from the start: a confidence-scored extraction with a clarification loop.

The pipeline now works like this:

Transcript cleanup: strip filler words, normalize speech patterns, handle self-corrections ("no wait" means "ignore what I just said")
Entity extraction with confidence: each potential column gets a confidence score. "Budget" from the sentence above gets 0.9. "Projects" gets 0.85. "The" gets filtered out entirely.
Schema proposal: generate the table structure, but only include columns above a confidence threshold
Gap detection: identify what's probably missing. If someone mentions invoices but no date column, that's a gap worth asking about.

The key insight was that we don't need to get it perfect on the first pass. We just need to get it good enough that the user can see what we understood and correct us quickly. "I see you want to track invoices for freelance clients. I've set up columns for Client Name, Project, Amount, and Status. Want me to add anything else?"

That conversational correction loop is way more natural than trying to parse everything perfectly from a single voice input.

Failure Modes We Still Deal With

It's not all solved. Some recurring edge cases:

Language mixing. We have users who switch between languages mid-sentence. Our pipeline handles Czech and English separately, but code-switching mid-sentence still trips it up sometimes.

Implicit schemas. "Make it like a CRM" assumes shared knowledge about what a CRM table looks like. We built a library of common schema templates (CRM, invoice tracker, project board, inventory) that the intent layer can match against. It covers maybe 70% of cases.

Overspecification. Some users describe every single column in detail, including data types and validation rules, all in one breath. The pipeline gets confused because it's optimized for the messy, underspecified case. We're still tuning the balance.

Numbers

After the third rewrite:

First-pass schema accuracy went from ~40% (v1) to ~78% (v3) measured by "did the user accept the generated schema without modifications"
Average time from voice input to usable table dropped from asking 3+ clarification questions to usually 0-1
The cleanup step alone (stripping fillers, handling corrections) improved extraction accuracy by about 15 percentage points

What I'd Do Differently

If I were starting from scratch, I'd skip the "parse everything from one input" approach entirely. Start with the clarification loop from day one. People are surprisingly patient with "let me make sure I understood you" if the follow-up question is smart.

Also, collect real voice inputs as early as possible. We spent two weeks optimizing for typed test inputs that looked nothing like actual speech. The gap between "create a table with columns name, email, phone" and "uh yeah so I need like a contacts thing" is massive, and you won't close it without real data.

I'm building VoiceTables as part of the Inithouse portfolio, where we ship AI-powered tools across different verticals. Some of our other projects include Be Recommended (check if AI chatbots recommend your brand), Watching Agents (AI prediction platform), and Audit Vibecoding (automated audits for AI-generated code). If you're building voice-first interfaces or have war stories about NLP pipelines, I'd love to hear about it in the comments.

We Shipped an AI Song Generator. The Hardest Part Wasn't the AI.

Jakub — Sat, 04 Apr 2026 19:07:59 +0000

We launched Magical Song a few weeks ago. It's an AI song generator where you describe a story, pick a genre, and get a studio-quality track with real vocals in under two minutes.

The AI generation part? That was the easy part. Seriously.

The part that nearly broke us was everything around it. The UX flow, the payment model, and a fundamental misunderstanding about who our user actually is.

Three steps sounds simple. It wasn't.

Our flow is: describe your story > pick genre and mood > get your song. Three screens. Should be straightforward, right?

The first version had a long form. Name of the person, occasion, details, inside jokes, mood preference, tempo, vocal style. We thought more input = better output. Users thought "this is homework" and bounced.

We cut it down to the bare minimum. One text area for the story. A grid of genre cards. A generate button. Conversion went up immediately.

The lesson wasn't new but it hit different when you see it in your own data: every extra field is a decision, and every decision is a chance to leave.

Stripe one-time payment was a deliberate bet

Most AI tools go subscription. We went with a single payment of $6 per song. No account needed.

Here's why: our users aren't repeat customers in the traditional sense. Someone ordering a birthday song for their mom isn't coming back next week. They might come back in a year for another occasion, or never. A subscription would feel like a trap for something they need once.

Stripe Checkout made this dead simple. We create a session, redirect, handle the webhook, unlock the download. No user accounts, no password resets, no subscription management UI. The entire payment flow is maybe 200 lines of code.

One unexpected side effect: zero refund requests so far. When people pay once for something specific, they know exactly what they're getting. No "I forgot to cancel" frustration.

The gift economy thing we didn't expect

We built Magical Song thinking people would make songs for themselves. Playlists, fun experiments, maybe content creators needing custom jingles.

Wrong.

Almost every song is a gift. Birthday songs, anniversary tracks, wedding surprises. And then the one that really caught us off guard: our first paying customer ordered a memorial song. Someone used it to create a tribute for a person who passed away.

This completely changed how we think about the product. We're not building a "fun AI toy." We're building something people use for moments that actually matter to them. That raises the bar on everything: the quality of the output, the reliability of the service, the tone of the landing page.

When your user is buying a gift, the UX pressure is different. They're not browsing. They're on a mission. They have a deadline (the birthday is tomorrow). They need confidence that the result will be good enough to share. Every friction point isn't just annoying, it's a risk that the gift falls through.

What I'd do differently

If I were starting over, I'd user-test the payment moment earlier. We spent weeks tuning the AI prompt engineering and almost no time watching people go through checkout. Turns out the moment someone decides to pay $6 for an AI-generated song is fragile. They need social proof right there, not on the landing page.

I'd also build the sharing flow first. Right now we generate a shareable link, but it's an afterthought. For a gift product, the "unwrapping" experience should be the hero feature. That's next on our list.

The stack, briefly

We built this with Lovable (React + Supabase), Stripe for payments, and a third-party AI music API for generation. The whole thing runs serverless. Total development time from idea to first paying customer was about two weeks.

If you're building something similar, the boring advice is the right advice: keep the flow short, make the payment invisible, and watch real people use it before you optimize anything else.

We're part of Inithouse, where we run ~14 MVPs simultaneously trying to find product-market fit. Each one teaches us something. Magical Song taught us that sometimes your users aren't who you think they are, and that's actually a good thing.

If you want to try it: magicalsong.com. And if you're curious about auditing your own vibecoded project, we also built Audit Vibe Coding for exactly that.

Running 5 International Domains from One Codebase (React SPA + Lovable)

Jakub — Fri, 03 Apr 2026 05:30:25 +0000

We run an AI photo animation product across 5 country domains, all from a single React codebase. No monorepo, no microservices, no framework gymnastics. Just one Lovable project serving zivafotka.cz, zivafotka.sk, zywafotka.pl, alivephoto.online, and lebendigfoto.de.

Here's how it works and what we learned making it happen.

The problem

We built Ziva Fotka as a Czech product. Upload a photo, AI animates it into a short video with natural movement. Simple concept, works well. Then we wanted to go international.

The naive approach would be one codebase per country. Five repos, five deploys, five sets of bugs to fix. That's a maintenance nightmare for a small team. We needed one codebase that adapts to whichever domain it's running on.

Domain-based locale detection

The key insight: the domain IS the locale selector. No language dropdown, no cookies, no URL prefixes like /en/ or /de/. If you're on zivafotka.cz, you get Czech. If you're on lebendigfoto.de, you get German. Clean and obvious.

// Simplified locale detection
function getLocale(): Locale {
  const hostname = window.location.hostname;

  if (hostname.includes('zivafotka.cz')) return 'cs';
  if (hostname.includes('zivafotka.sk')) return 'sk';
  if (hostname.includes('zywafotka.pl')) return 'pl';
  if (hostname.includes('lebendigfoto.de')) return 'de';
  return 'en'; // alivephoto.online and fallback
}

This runs once on app init and feeds into a React context that every component can consume. No runtime overhead, no flicker, no hydration mismatch.

Routing: same paths, different languages

Each domain has its own URL structure that makes sense in that language:

CZ: /srovnani/ziva-fotka-vs-myheritage
SK: /porovnanie/ziva-fotka-vs-myheritage
PL: /porownanie/zywa-fotka-vs-myheritage
DE: /vergleich/lebendiges-foto-vs-myheritage
EN: /comparison/alive-photo-vs-myheritage

Routes are defined per locale in a central config. The React Router setup maps locale-specific paths to shared page components. The component receives locale as a prop and renders the right content.

// Route config per locale
const routes = {
  cs: { comparison: '/srovnani', pricing: '/cenik' },
  sk: { comparison: '/porovnanie', pricing: '/cennik' },
  pl: { comparison: '/porownanie', pricing: '/cennik' },
  de: { comparison: '/vergleich', pricing: '/preise' },
  en: { comparison: '/comparison', pricing: '/pricing' },
};

Sitemaps: one per domain

This was the trickiest SEO piece. Each domain needs its own sitemap with its own URLs. We generate five separate sitemap files:

sitemap-cz.xml for zivafotka.cz
sitemap-sk.xml for zivafotka.sk
sitemap-pl.xml for zywafotka.pl
sitemap-en.xml for alivephoto.online
sitemap-de.xml for lebendigfoto.de

Each sitemap only contains URLs for that specific domain. A sitemap.xml index file references all five. The robots.txt points to the index sitemap.

Critical detail: every URL in every sitemap includes hreflang annotations pointing to the equivalent page on all other domains. This tells Google "these five pages are the same content in different languages."

<url>
  <loc>https://zivafotka.cz/srovnani/ziva-fotka-vs-myheritage</loc>
  <xhtml:link rel="alternate" hreflang="cs"
    href="https://zivafotka.cz/srovnani/ziva-fotka-vs-myheritage"/>
  <xhtml:link rel="alternate" hreflang="sk"
    href="https://zivafotka.sk/porovnanie/ziva-fotka-vs-myheritage"/>
  <xhtml:link rel="alternate" hreflang="pl"
    href="https://zywafotka.pl/porownanie/zywa-fotka-vs-myheritage"/>
  <xhtml:link rel="alternate" hreflang="de"
    href="https://lebendigfoto.de/vergleich/lebendiges-foto-vs-myheritage"/>
  <xhtml:link rel="alternate" hreflang="en"
    href="https://alivephoto.online/comparison/alive-photo-vs-myheritage"/>
</url>

SEO: dynamic meta per domain

Every page uses a custom useSEO hook that sets the right meta tags based on the current locale and domain:

Title and description in the local language
Canonical URL pointing to the current domain (not a "master" domain)
Open Graph tags with locale-specific content
JSON-LD schema with the correct publisher for each domain

This is where a lot of multi-domain setups go wrong. If your canonical tags all point to the .com domain, Google ignores your country-specific pages. Each domain must be treated as authoritative for its locale.

What we got wrong (and fixed)

Wrong brand name per locale. We initially used "Ziva Fotka" everywhere. But the Polish site is "Zywa Fotka" and the German one is "Lebendiges Foto." Every reference to the product name needs to be locale-aware, not just the UI copy.

Forgetting footers. Comparison page links in the footer were hardcoded to Czech paths. On the Polish domain they led to 404s. Footer navigation has to be locale-routed like everything else.

Sitemap submission per property. Each domain is a separate property in Google Search Console. You need to submit the domain-specific sitemap to each property individually. We missed alivephoto.online for weeks.

The numbers

Running five domains instead of one has a real impact on discoverability. Czech users searching "ozivit fotku" land on zivafotka.cz. Polish users searching "ozywic zdjecie" land on zywafotka.pl. Same product, but each market finds it through natural search in their own language.

Our CTR in Google Ads runs 13-16% across CZ and SK domains, significantly above typical display benchmarks. The domain matching the user's language builds immediate trust.

Why Lovable makes this work

We built everything in Lovable, which gives us a React SPA with Supabase backend. The single-project architecture means one deploy covers all five domains. DNS and domain routing handles the rest.

If you're building with Lovable and considering multiple markets, this pattern scales well. The key principles: detect locale from domain (not URL), generate per-domain sitemaps with hreflang cross-references, and make every piece of content locale-aware, including things you'd never think of like footer links and schema markup.

The codebase for all five domains of Ziva Fotka / Alive Photo lives in a single Lovable project. Check out the live sites to see it in action.

We're building more products at Inithouse, each with its own scaling challenges. Be Recommended checks if AI assistants recommend your business. Watching Agents runs AI prediction agents. Different problems, same build-fast philosophy.

Who Audits the AI-Generated Code? We Built an AI to Do It

Jakub — Thu, 02 Apr 2026 19:51:05 +0000

Vibe coding is everywhere. Cursor, Lovable, Bolt, v0, Replit Agent... the tools keep shipping and the code keeps flowing. But here's the thing nobody wants to talk about: most of that code has never been reviewed by anyone.

Not by a human. Not by a linter. Not by anything.

We found out the hard way. After shipping a dozen products built almost entirely with AI tools, we started noticing patterns. Security headers missing. Lighthouse scores in the 40s. Meta tags that made zero sense. Accessibility? Forget about it.

So we asked ourselves: if AI can write the code, can another AI catch what the first one missed?

The Meta Problem

There's something almost funny about it. You prompt an AI to build your app. It generates thousands of lines of code in minutes. You deploy it because it works in the preview. And then you wonder why Google isn't indexing it, why your Core Web Vitals are red, and why someone on Reddit found an open API endpoint.

The AI that wrote the code optimized for one thing: making it work. It didn't think about your robots.txt. It didn't check if your images have alt text. It didn't verify that your authentication flow actually prevents session hijacking.

This is the gap we set out to close with Audit Vibecoding.

What We Actually Check

The audit runs dozens of automated checks across five categories:

Security - Headers, CSP policies, exposed endpoints, authentication patterns, dependency vulnerabilities. The stuff that keeps you up at night (or should).

SEO - Meta tags, canonical URLs, structured data, sitemap validity, robots.txt, Open Graph tags. Most AI-generated sites ship with generic or completely broken SEO.

Performance - Core Web Vitals, bundle size, image optimization, lazy loading, render-blocking resources. AI loves to import entire libraries when you need one function.

Accessibility - ARIA labels, color contrast, keyboard navigation, screen reader compatibility, heading hierarchy. This is where AI-generated code fails the hardest. Almost every project we've audited scores below 50% on accessibility.

Code Quality - TypeScript strictness, error handling, unused imports, console.logs left in production, hardcoded values. The kind of stuff a senior dev would catch in code review but your AI pair programmer doesn't care about.

Each check produces a pass/fail/warning result with a specific recommendation. You get an overall Audit Score from 0 to 100. The average across all projects we've audited? 31. Production-ready is 80+.

Let that sink in. The average vibecoded project scores 31 out of 100.

The Pipeline

You give us a URL. That's it. No account, no setup, no GitHub integration needed.

Behind the scenes, the audit crawls your deployed site and analyzes what it finds. It's looking at your actual production output, not your source code. This matters because a lot of problems only show up after build and deploy. Your local dev server might work fine while your production site is leaking environment variables.

Within 24 hours you get a full report: every check with its result, a prioritized action plan (what to fix first), and an overall score. The whole thing costs between $4 and $9. Less than a coffee and a sandwich.

Why Not Just Use Lighthouse?

Lighthouse is great. We use it ourselves. But it only covers performance and some accessibility. It doesn't check your security headers. It doesn't validate your structured data. It doesn't tell you that your sitemap returns a 404 or that your canonical URL points to localhost.

We built this because we needed something that covers the full surface area of a shipped product, not just the parts that Chrome DevTools can see.

What We've Learned From Auditing Real Projects

After running audits on projects built with Lovable, Cursor, Bolt, and others, a few patterns keep showing up:

Security is always the worst category. AI-generated code almost never includes proper security headers. Content-Security-Policy? Missing. X-Frame-Options? Missing. Rate limiting? What's that?

SEO is broken in predictable ways. Missing meta descriptions, duplicate title tags across pages, no sitemap, robots.txt blocking everything. The AI generates working pages but doesn't think about discoverability.

Accessibility gets ignored entirely. This is the one that bothers me most. Screen reader support, keyboard navigation, ARIA labels... AI tools just don't prioritize this unless you explicitly ask. And even then, the implementation is often wrong.

Performance problems come from over-engineering. AI loves to add dependencies. A simple landing page ends up importing React, three animation libraries, a state management solution, and a CSS-in-JS framework. The result loads in 8 seconds on mobile.

The Uncomfortable Question

"Quis custodiet ipsos custodes?" Who watches the watchmen?

If AI writes the code and AI audits the code, where does the human fit in? Honestly, the human fits in the same place they always did: making decisions. The audit gives you a prioritized list of what's broken. You decide what to fix, when, and how much it matters for your specific use case.

A personal blog with a security score of 40? Probably fine. A SaaS handling payment data with that same score? Fix it now.

The point isn't to replace human judgment. The point is to give you the information you need to make good decisions, especially when the code was written by something that doesn't understand the context of your business.

Try It

If you've shipped anything built with AI tools, run an audit. Not because I'm selling you something (though yes, auditvibecoding.com is the product). But because you should know what you shipped.

The average score is 31. Yours might be better. It might be worse. Either way, you should know.

I'm Jakub, founder of Inithouse. We build AI-powered products and occasionally write about what we learn along the way. This is one of those learnings: ship fast, but know what you shipped.