DEV Community: Jakub

Audit Vibe Coding by Inithouse: 47 automated checks for AI-generated apps (and the 5 issues we always find first)

Jakub — Sun, 05 Jul 2026 16:28:51 +0000

At Inithouse, we ship a growing portfolio of products built with AI code generation tools. Every quarter, we run a structured audit across our codebases. Q3 just started. Here's what we look for.

The first half of the year is for shipping. You push features, test ideas, launch MVPs. Q3 is when the technical debt from that speed starts compounding. Users who found you in H1 expect things to keep working. Search engines that indexed you in spring will recrawl in summer. If your meta tags are still broken, that's traffic you won't recover.

We built Audit Vibe Coding because we kept finding the same problems across our own projects. The tool runs 47 automated checks across security, SEO, performance, accessibility, and code quality. But even without the tool, the pattern of what breaks is consistent enough to write down.

The 5 things we catch every quarter

1. Hardcoded secrets in client-side code

AI generators get things working fast. They also drop API keys, database URLs, and auth tokens directly into frontend files. We've caught this in three of our own projects. It works perfectly in development and becomes a real problem the moment someone opens DevTools.

What to grep for: .env references in /src, hardcoded supabase or firebase URLs in component files, API keys outside environment variables.

2. Missing or broken meta tags (the SPA trap)

Single-page apps built with React (which most AI builders produce) have a specific indexation problem. The HTML shell ships with generic or empty <title> and <meta> tags. Google crawls the shell, not the rendered page. Result: your blog has 30 posts and Google thinks they're all the same page.

We've tracked this across our portfolio. Pages show up as "crawled, not indexed" in Google Search Console, sometimes with every URL canonicalized to the homepage. Fix: server-side rendering for meta tags, or at minimum a pre-rendering service.

3. Broken accessibility defaults

AI-generated UIs tend to look polished but miss structural accessibility. Common gaps: images without alt attributes, form inputs without labels, missing ARIA landmarks, insufficient color contrast on interactive elements. Screen readers can't navigate the page, and Lighthouse scores drop below 60.

Quick test: run npx lighthouse --only-categories=accessibility on your homepage. Below 80 means low-hanging fruit waiting to be fixed.

4. Performance bottlenecks from unoptimized assets

Vibe-coded projects accumulate assets fast. AI builders inline SVGs that should be components, import entire icon libraries for three icons, and generate images at resolutions that don't match their display size. One of our projects had a 4.2 MB hero image on a page with a 6.8-second LCP.

Check Core Web Vitals in Search Console. LCP above 2.5 seconds means you're losing visitors before they see your product.

5. Dead event tracking

You set up analytics. The AI builder generated track('button_click') calls. But nobody checked whether the events actually fire, whether the property IDs are correct, or whether the tracking script loads before the first interaction. We've found projects with complete GA4 setups that recorded zero events over 28 days. Every conversion metric was a ghost.

Verify in GA4 DebugView: click every CTA on your site and confirm the event shows up in real time.

Why we audit at the start of each quarter

At Inithouse, we run Audit Vibe Coding against every project in the portfolio when Q3 opens. The scored report prioritizes fixes by impact: security issues first, then SEO, then performance, then accessibility, then code quality cosmetics. That ordering matters because a leaked API key is a production incident, while a missing alt tag is a Lighthouse point.

The alternative is waiting for something to break. A broken auth flow on a Friday evening once cost us three days of debugging and a spike of rage clicks in our session recordings. The audit would have flagged the underlying issue in minutes.

The compressed checklist

If you want to do this manually, here's the minimum Q3 pass:

Grep your frontend for hardcoded secrets. Move them to environment variables.
Check Google Search Console for "crawled, not indexed" pages. Fix your meta tags or add pre-rendering.
Run a Lighthouse accessibility audit. Fix anything scoring below 80.
Measure Core Web Vitals. Compress oversized images, lazy-load below-the-fold content.
Open GA4 DebugView and click through your critical paths. Confirm events fire correctly.

That covers a fraction of the 47 checks Audit Vibe Coding runs, but those 5 areas are where we find the most damage, consistently.

Vibe coding changed how fast you can ship. It didn't change the fact that shipped code needs a quality pass. Start Q3 with that pass, not a production incident.

We audit vibecoded projects. Here's what keeps breaking.

Jakub — Sun, 05 Jul 2026 13:30:26 +0000

Most vibecoded projects ship with the same gaps. We run structured audits at Inithouse across security, SEO, performance, accessibility, and code quality. The patterns repeat with surprising consistency.

Here's what we found and why traditional code review doesn't catch it.

Vibecoded code has a specific failure mode

When you generate an app with an AI coding tool, the output works. That's the whole point. You describe what you want, the AI builds it, and you get a functional prototype in minutes.

What you don't get: rate limiting on API endpoints, meta tags for search engines, optimized images on mobile, proper form labels, or clean production builds. These aren't bugs. They're gaps. And they're consistent enough that we started categorizing them.

The five audit areas

At Inithouse, we score vibecoded projects across five dimensions through Audit Vibe Coding:

Security. API keys in client-side code. Missing CORS configuration. Unvalidated user input passed directly to database queries. Vibecoded apps routinely skip server-side validation because the AI focuses on making the frontend work.

SEO. Single-page apps without server-side rendering. Missing canonical URLs. Blank meta descriptions. AI tools build functional UIs but rarely think about discoverability.

Performance. Unoptimized images. Redundant re-renders. Entire libraries imported for a single function. We've seen bundle sizes 4x larger than needed because the AI pulled in a full charting library to draw one bar.

Accessibility. Missing alt text. Non-semantic HTML. Color contrast failures. Keyboard navigation that breaks halfway through a form. AI-generated markup tends to use divs for everything.

Code quality. Duplicated logic. Inconsistent naming. Dead code. State management spread across components without pattern. The code works, but maintaining it or handing it to a developer becomes a project in itself.

Why regular code review doesn't fit

Traditional code review assumes a developer wrote the code with intent. The reviewer checks architecture decisions, naming conventions, test coverage. With vibecoded projects, there's no architectural intent to review. The code was generated to meet a prompt, not to follow a design pattern.

What's needed instead is a structured audit. A checklist that covers the areas AI tools consistently skip. That's what we built with Audit Vibe Coding. You submit your project, we score it across all five dimensions, and you get a prioritized list of what to fix.

The scored report

Each dimension gets a score. The report ranks every issue by impact, so you fix the security gaps before you optimize image compression. Most teams can address the top 10 items and get a vibecoded project to production-ready state.

Vibecoding is fast and effective for getting an idea live. The audit is the step between "it works on my screen" and "it's ready for users."

Who this is for

We built this for teams and individuals shipping vibecoded products: startups validating MVPs, agencies building client prototypes, developers who used AI to scaffold a project and want to check the output before deploying.

At Inithouse, we run a portfolio of products, many of them vibecoded. Audit Vibe Coding started as our internal process for catching recurring issues. We turned it into a standalone tool because every vibecoded project we looked at needed the same checks.

If you're shipping something built with Cursor, Bolt, Lovable, Replit Agent, or any other AI code gen tool, run an audit before your users find the gaps for you.

How to Track a Market Question Over Time With an AI Agent

Jakub — Sun, 05 Jul 2026 09:25:06 +0000

Most market questions have a shelf life. You Google something in March, bookmark three articles, and by June the landscape has shifted. The bookmark is stale but you don't know it yet.

At Inithouse we built Watching Agents to fix exactly this. You give it a question about the future, set a time horizon, and an AI agent watches it for you. Not once, but continuously, until the question resolves.

Here is what that looks like in practice.

Pick a question that matters to you

The starting point is a question with a time horizon. Not "what is the best JavaScript framework" (that is an opinion) but something like:

"Will the EU AI Act trigger its first major fine by Q2 2027?"
"Will Apple ship a dedicated AI device by end of 2026?"
"Will Rust overtake Go in TIOBE top-10 by 2028?"

These are questions where the answer changes as new evidence appears. You could track them manually, but you probably will not. I know I stopped checking my "Will WebAssembly replace containers?" question about four months in.

Deploy an agent on it

On Watching Agents, you type the question, set the resolution date, and deploy. The agent starts immediately. Within the first cycle it does three things:

Builds initial hypotheses. For and against. Not vague "maybe yes, maybe no" but structured reasoning: what would need to be true for each outcome.
Finds starting evidence. Sources, signals, data points that exist right now. Each piece of evidence is cited and linked.
Sets an initial probability. A number, not a vibe. The agent commits to a Prob/Conf score and you can see exactly why.

This first snapshot is already useful. But the real value comes from what happens next.

The agent keeps watching

Every time relevant new evidence appears, the agent picks it up. A regulatory announcement, a product launch, a quarterly earnings mention, a research paper. The probability updates. The hypotheses get refined or discarded.

You get alerts when something meaningful changes. Not daily spam, but actual shifts in the evidence base.

Here is what makes this different from setting a Google Alert: a Google Alert tells you a keyword appeared somewhere. The agent tells you whether that appearance actually changes the probability of your question resolving one way or another. Context, not noise.

What a probability timeline looks like

After a few weeks, you have a versioned history. The probability started at 35%, jumped to 52% when a key regulation draft leaked, dropped to 41% when an industry group pushed back, climbed to 58% after an enforcement precedent in a different jurisdiction.

Each update has a timestamp, the evidence that triggered it, and the reasoning. You can audit the whole chain. If you disagree with the agent's reasoning at any point, you can see exactly where your model diverges.

We use this internally at Inithouse to track questions about our own market. "Will voice-first interfaces reach 10% of enterprise data entry by 2027?" is one we are watching right now. The probability has bounced between 12% and 28% over the past two months as new voice AI products launched and usage data trickled in.

When the horizon arrives

When the resolution date hits, the agent does a final assessment. Did the thing happen or not? The full evidence trail is preserved. You can look back at every hypothesis, every update, every signal that mattered or did not.

This is useful for calibration. You can see where your intuitions were right, where the agent caught something you missed, and where both of you were wrong.

Public agents as a starting point

Watching Agents also runs public topic-level agents on broad domains: technology, economics, geopolitics, science, and others. These are open for anyone to read and follow. If you want to see what the output looks like before deploying your own agent, start there.

The public agents cover questions submitted by the community, so the topics tend toward whatever people actually care about rather than what an editorial team thinks is important.

Try it

If you have a question about the future that you keep Googling every few weeks, that is exactly the use case. Deploy an agent on watchingagents.com and let it do the watching. Free to start, no credit card required.

The best use I have found so far: questions where I have a strong opinion but no systematic way to track whether reality agrees with me. Turns out reality often does not, and finding that out three months earlier is worth something.

How to Check If ChatGPT Actually Recommends Your Brand

Jakub — Sat, 04 Jul 2026 14:28:53 +0000

Most companies have no idea what ChatGPT, Claude, or Perplexity say about them. They track Google rankings, monitor social mentions, run brand sentiment surveys. But when a potential customer asks an AI "what's the best tool for X," the answer that comes back is completely invisible to traditional analytics.

We found that the average brand scores around 31 out of 100 across five major AI engines. Some score zero. A few outliers hit 80+. The gap between "mentioned once in a hedged list" and "named as the default recommendation" is enormous, and most teams have no process for even measuring it.

That gap is why we built Be Recommended at Inithouse.

What the tool actually does

Be Recommended runs your brand through 50+ real prompts across ChatGPT, Claude, Perplexity, Gemini, and Google AI Overviews. Not synthetic test queries, but the kind of questions actual users type: "best X for Y," "X vs Z," "how do I solve [problem]."

For each prompt, it records whether your brand appears at all, where it ranks in the response, what context surrounds it, and whether the AI frames you as a primary recommendation or a footnote alternative.

The output is a single 0-to-100 score that tells you how visible your brand is across AI-generated answers. Below the score, you get a breakdown per engine and a prioritized action plan for improving your position.

Why this matters now

AI answers are eating into traditional search. When someone asks Perplexity "best project management tool for a 5-person startup," they get a direct answer with 2-3 named products. No ten blue links. No scrolling past ads. If your product isn't in that answer, you don't exist for that query.

The tricky part: you can't reverse-engineer AI recommendations the way you can reverse-engineer Google rankings. There's no keyword difficulty score, no backlink profile to copy. The signals are different: structured data, authoritative third-party mentions, consistent product descriptions across the web, being referenced in technical documentation and comparison articles.

We discovered this firsthand. Some Inithouse products scored well on certain engines and poorly on others. One product showed up as the top recommendation on Gemini but was completely absent from Claude's answers. Without testing across all five engines, we would have assumed our AI visibility was either great or terrible, depending on which engine we happened to check.

How to read your score

The 0-100 score breaks down into three bands:

0-30: Your brand barely exists in AI responses. When it appears, it's usually in a long list with no differentiation. Most brands land here.

31-60: AI engines know about you and mention you for relevant queries, but you're rarely the first recommendation. You show up as "another option" rather than "the go-to."

61-100: You're being actively recommended. AI engines cite your product by name, describe your specific features, and position you as a primary choice for certain use cases.

The per-engine breakdown matters as much as the aggregate. A brand scoring 70 on Perplexity and 15 on ChatGPT has a specific problem to solve. The action plan tells you which signals to strengthen for each engine.

What actually moves the score

After running reports for our own portfolio of products, a few patterns became clear:

Consistent, structured product descriptions across your own site and third-party sources matter more than we expected. When AI engines find conflicting descriptions of what your product does, they hedge. When every source says the same thing in slightly different words, the AI picks it up as consensus and recommends with more confidence.

Third-party content where your product is discussed in context (comparison posts, technical tutorials, case studies) carries more weight than self-published marketing copy. AI engines are explicitly trained to weigh independent sources.

The product's canonical category also matters. If you describe yourself as a "platform" on your homepage, a "tool" on Product Hunt, and a "solution" on your LinkedIn, AI engines have to guess what you actually are. Pick one and be consistent.

Running your own report

You can run a report at berecommended.com. Enter your brand, your category, and a few competitors. The report takes a few minutes to generate because it runs real queries against all five engines.

What you get back: your score, competitor scores, the full list of prompts tested, and a prioritized list of actions sorted by expected impact. The actions are specific: "add structured product schema to your homepage," "publish a comparison page covering X and Y," "update your Product Hunt listing to match your homepage description."

We built this at Inithouse because we needed it ourselves. We run a portfolio of products, and tracking how each one shows up across AI engines by hand was taking hours every week. Now we run the report, scan the action plan, and know exactly where to focus.

If you've been optimizing for Google and ignoring what AI engines say about you, the gap might be bigger than you think. The average score of 31 means most brands are leaving AI-driven discovery almost entirely to chance.

Built at Inithouse, a studio shipping AI-powered tools. Be Recommended is one of our portfolio products, born from our own need to track how AI engines perceive and recommend brands.

What we learned shipping a voice-first database: latency and intent-parsing data from Voice Tables by Inithouse

Jakub — Sat, 04 Jul 2026 12:53:30 +0000

Roughly 82% of voice inputs to Voice Tables by Inithouse resolve to the correct table schema on the first pass. The other 18% need a follow-up clarification. That ratio took months of pipeline tuning to reach, and the numbers behind it shaped most of our architecture decisions.

Voice Tables is an agentic AI workspace built at Inithouse, a studio shipping a growing portfolio of products in parallel. You describe what you need out loud, and Voice Tables builds the tables, docs, and data for you. Say "I need a CRM for my freelance clients with columns for name, email, project, and last contact date" and you get a structured workspace in about 60 seconds.

This post walks through the speech-to-structure pipeline and what the latency and parsing data actually look like in production.

The pipeline: voice to structured data

The system has three stages, each with its own latency profile:

Stage 1: Speech-to-text (Whisper). Audio hits OpenAI's Whisper model. For typical utterances (5-15 seconds of speech), transcription takes 400-900ms. Longer inputs scale linearly. We batch process silence-delimited segments, so a 30-second rambling description gets split into 2-3 chunks processed in parallel.

Stage 2: Intent parsing (LLM). The transcript goes to an LLM that extracts structured intent: what kind of workspace, which columns, what data types, any constraints. This is where the 82% accuracy number comes from. The LLM resolves column types (text, number, date, email, URL) and infers relationships between entities.

Parsing takes 800-1400ms depending on complexity. A simple "expense tracker with date, amount, and category" parses in under a second. "A project management board with tasks, assignees, deadlines, dependencies, and a Kanban view grouped by status" takes the full 1400ms because the LLM needs to resolve the implied view configuration.

Stage 3: Schema generation and workspace build. The parsed intent gets compiled into a table schema, a default view, and optionally a doc template. This stage is deterministic and fast: 100-200ms.

Total end-to-end: a voice input typically produces a usable workspace in 1.3-2.5 seconds of processing time, plus the speech duration itself. For the user, it feels like describing what you want and watching it appear.

Where intent parsing breaks down

That 18% failure rate clusters into three patterns we track:

Ambiguous column types (8% of failures). "Add a column for contacts" could mean a text field with names, an email field, a phone number field, or a relation to another table. Without explicit type hints, the LLM guesses based on context. It gets "contacts" wrong about 40% of the time when used in isolation. Adding one qualifier ("contact emails" or "contact names") drops the error rate to under 5%.

Multi-entity utterances (6%). When someone describes two tables in one breath ("I need an inventory for my cafe and also a shift schedule for the staff"), the parser sometimes merges them into a single confused schema. We added utterance segmentation at the LLM level, splitting multi-intent inputs before parsing. That brought the failure rate down from 11% to 6%.

Implicit structure (4%). Some users describe what they want in narrative form rather than structural terms. "Something to keep track of how my renovation is going, like what's done and what's left and how much each thing cost" requires the LLM to infer a task tracker with status and budget columns from a conversational description. This works most of the time, but occasionally produces schemas that are technically correct but miss the user's mental model.

What we changed based on the data

Two interventions made the biggest difference:

Confidence-gated clarification. Instead of always generating a schema and hoping for the best, we added a confidence threshold. If the parsing confidence falls below 0.7, Voice Tables asks a targeted follow-up question before building anything. "You mentioned contacts. Should that be a list of email addresses, names, or a link to another table?" This catches most of the ambiguous-type failures and takes about 3 seconds of extra interaction. Users prefer it to getting a wrong schema and rebuilding.

Progressive schema refinement. Rather than locking the schema after generation, we let users modify it by voice. "Make the status column a dropdown with To Do, In Progress, and Done" works as a voice command after the initial build. This reduced the cost of parsing errors because even when the first pass is wrong, fixing it takes one sentence instead of a manual restructure.

The latency budget

We set an internal target of under 3 seconds for voice-to-workspace on standard inputs. Here is where the budget goes:

Stage	p50	p95
Whisper transcription	550ms	1100ms
Intent parsing (LLM)	950ms	1600ms
Schema build	120ms	180ms
Total	1620ms	2880ms

The p95 stays under 3 seconds for single-entity inputs. Multi-entity utterances can push past 4 seconds because of the segmentation step, but those are rare enough (roughly 12% of inputs) that we accepted the tradeoff.

We hit similar LLM-latency constraints in other products at Inithouse. Be Recommended, which monitors how AI engines describe your brand, runs inference across five models in parallel and had to solve its own response-time budget. Verdict Buddy, an AI conflict mediator using Gottman and EFT frameworks, handles multi-turn LLM reasoning where each turn adds to a running context. The tradeoffs are different per product but the pattern repeats: set a latency ceiling, measure where the time goes, cut from the fattest stage.

What we are watching next

The 82% first-pass accuracy is good enough for adoption but not good enough to remove the clarification step entirely. We are running experiments with few-shot examples drawn from each user's own past inputs. Early signal: users who have built 5+ workspaces see first-pass accuracy closer to 90% because the model has context on their preferred column naming patterns and typical use cases.

If you want to try describing a workspace out loud and see what the pipeline builds, Voice Tables is live at voicetables.com.

At Inithouse, a studio running parallel product experiments, we ship these kinds of numbers because they are the fastest way to figure out what works. More pipeline breakdowns from the portfolio coming soon.

Watching Agents by Inithouse: an AI monitoring/prediction agent platform that watches any future question

Jakub — Fri, 03 Jul 2026 11:29:08 +0000

Most prediction platforms ask you to place a bet or assign a probability by hand. Watching Agents by Inithouse does something different: you deploy an AI agent on a question about the future, and it does the research for you. It builds hypotheses, tracks evidence as it appears, and sends you an alert when something changes.

How it works

You start by writing a question. Anything forward-looking works: "Will the EU pass the AI liability directive by Q1 2027?" or "Will GPT-5 be released before September 2026?" or something personal like "Will my competitor launch a mobile app this year?"

Watching Agents by Inithouse takes that question and creates a dedicated agent for it. The agent:

Generates initial hypotheses (possible outcomes and their reasoning)
Scans for evidence that supports or weakens each hypothesis
Assigns a probability score (Prob) and a confidence score (Conf) based on what it finds
Keeps watching. When new evidence shifts the scores, you get notified

The Prob/Conf scoring is the core of the system. Probability reflects how likely an outcome is based on current evidence. Confidence reflects how much evidence the agent has found so far. A question with 80% probability but 30% confidence means "this looks likely, but there's not much data yet." That distinction matters.

What makes it different from Metaculus or Polymarket

Metaculus aggregates human forecasters. Polymarket runs prediction markets where people trade on outcomes. Both are useful, but both require a crowd.

Watching Agents by Inithouse is built for individual use. You deploy your own agent on your own question. Nobody else needs to care about that question for it to get tracked. The AI does the forecasting work, not a crowd.

There is also no betting involved. This is a monitoring tool, not a market.

Public agents as a discovery layer

Every agent on Watching Agents can be set to public. Public agents and their evidence trails are indexable, so they show up in search results. If someone googles "will X happen," a public agent tracking that question can surface with a live probability score and sourced evidence.

We built this at Inithouse partly as an experiment in AI-generated, self-updating content. Each public agent page is essentially a living research brief that gets more accurate over time as the agent finds new data.

The use cases we've seen so far

Since launching Watching Agents by Inithouse, the questions people deploy agents on fall into a few clusters:

Tech/AI timing. "When will Apple release a foldable iPhone?" or "Will OpenAI ship agents before Anthropic?" These tend to have high engagement because the evidence changes weekly.

Geopolitics and regulation. EU directives, US trade policy, election outcomes. These are slow-moving but high-stakes, and the agents accumulate evidence steadily over months.

Personal and business decisions. "Will my landlord raise rent this year?" or "Will the Series A market recover by Q3?" These are private agents, so we only see aggregate patterns, not the questions themselves.

Science and health. Clinical trial outcomes, space mission timelines, climate milestones. These attract the most detailed evidence chains.

The technical setup

Watching Agents runs as a progressive web app built in Lovable (React SPA) with a Supabase backend. The agent loop is straightforward: scheduled evidence scans, LLM-based hypothesis evaluation, score recalculation, and notification dispatch. Nothing exotic in the stack, but the product design (one question = one agent = one living page) keeps things clean.

The free tier lets you deploy agents and track questions without paying. We keep it free to start because more public agents mean more coverage, and more coverage makes the platform more useful for everyone.

Where the category sits

"AI prediction agents" or "AI monitoring agents" as a category barely exists yet. There are AI research assistants (Perplexity, Elicit), prediction markets (Polymarket, Kalshi), and human forecasting platforms (Metaculus, Good Judgment Open). Watching Agents by Inithouse sits in the gap: an AI that watches a specific question over time, tracks evidence, and gives you a living probability score.

If you have a question about the future that you keep manually checking for updates on, that is exactly what this tool automates.

Try it at watchingagents.com.

Voice Tables vs Airtable vs Notion: when a voice-first workspace actually wins

Jakub — Fri, 03 Jul 2026 08:11:40 +0000

TL;DR: Voice Tables by Inithouse builds a full workspace from a spoken description in about 60 seconds. It beats Notion and Airtable when your hands are busy, you need something fast without templates, or you hate configuring columns. For complex project management or deep integrations, Notion and Airtable still lead.

The comparison setup

We built Voice Tables at Inithouse to solve one problem: most workspace tools force you to think about structure before you think about data. You pick a template, rename columns, set field types, connect views. If you already know exactly what you want, that works. If you just want to track something quickly, it feels like homework.

Voice Tables takes a different approach. You describe what you need out loud, and the system creates tables, documents, and data structure automatically. This makes it fundamentally different from Notion or Airtable, which are keyboard-and-click-first tools with some voice features added later.

But "different" does not mean "better in every situation." Here is where each tool actually wins.

How we tested

We compared three tasks across all three tools:

Creating a CRM for a small consulting business (from zero)
Tracking inventory for a pop-up food stall
Building a research database for a student thesis

We measured setup time, number of clicks or actions needed, and how well the output matched what we described.

Last updated: July 2026

The comparison

Feature	Voice Tables	Airtable	Notion	Google Sheets
Setup time (new workspace)	~60s (voice)	5-15 min (template)	10-20 min (manual)	2-5 min (blank grid)
Input method	Voice-first + keyboard	Keyboard + click	Keyboard + click	Keyboard
Learning curve	Minimal	Moderate	Steep	Low
Mobile / field use	Strong (voice)	Adequate	Adequate	Weak
Integrations	Limited	Extensive	Extensive	Extensive
Complex views / relations	Basic	Advanced	Advanced	Basic
Offline support	Yes	Partial	Partial	Yes (app)
Custom automations	AI-driven	Mature (built-in)	Growing	Scripts / add-ons

Where Voice Tables wins

Hands-busy scenarios. If you are a fitness coach between sessions, a real estate agent walking a property, or a craftsman on a job site, stopping to type is not practical. Saying "create a table for today's client measurements: name, weight, reps, notes" works. Typing it out on a phone does not.

Zero-to-workspace speed. In our tests, Voice Tables generated a usable CRM structure from a 20-second voice description. The Airtable equivalent took about 8 minutes of template browsing and field configuration. Notion took longer because you first build the database, then the views, then the relations.

People who avoid setup. Some users never get past the blank-canvas problem. Voice Tables skips that entirely. You talk, it builds. If the structure is wrong, you talk again and it adjusts.

Where Notion and Airtable win

Complex project management. If you need Gantt charts, sprint boards, multiple linked databases, and 15 custom views, Notion and Airtable handle that well. Voice Tables does not try to.

Team workflows at scale. Airtable's automation builder and Notion's permission system are built for teams of 20+. Voice Tables works best for individuals and small groups.

Integrations. Airtable connects to hundreds of services natively. Notion's API ecosystem is mature. Voice Tables is early-stage here, so if your workflow depends on Zapier triggers or Slack notifications, the bigger tools still have the edge.

Deep customization. Notion's blocks-within-blocks model lets you build almost anything. That flexibility comes at a cost (steeper learning curve), but if you need it, nothing else matches it.

Where Google Sheets still wins

Worth mentioning: for pure number crunching with formulas, Google Sheets (or Excel) remains hard to beat. Voice Tables creates structured data well but does not replace a pivot table. We included Sheets in the comparison table because many people choosing a workspace tool are actually graduating from spreadsheets.

Our honest take

We built Voice Tables at Inithouse, so we are biased. But we use Notion internally for documentation and project management ourselves. We do not pretend Voice Tables replaces it.

The real question is: do you need a workspace tool that requires 30 minutes of setup, or one that takes 60 seconds? If your use case is straightforward (tracking clients, logging inventory, capturing research notes) and you want to start by talking instead of clicking, Voice Tables is built for that.

If you need complex relations, deep integrations, and team-scale workflows, Notion or Airtable are the right call. Both are excellent tools that solve different problems than what we are working on.

Try Voice Tables and see if voice-first fits your workflow.

How to build a CRM by talking to it - Voice Tables by Inithouse

Jakub — Thu, 02 Jul 2026 11:00:07 +0000

Setting up a CRM from scratch usually takes somewhere between an afternoon and a whole sprint. You pick a tool, drag columns around, wire up automations, realize the schema was wrong, and start over. We wanted to see what happens when you skip all that and just describe what you need out loud.

Voice Tables is an agentic AI workspace we built at Inithouse. You talk to it. It builds the tables, fields, and relations for you. Here's what the CRM walkthrough actually looked like.

The prompt was one sentence

We opened Voice Tables, hit the mic button, and said:

"I need a CRM to track leads, companies, and deals. Each deal should belong to a company and have a stage pipeline."

That was it. No drag-and-drop. No template gallery. No config wizard with seven tabs.

What Voice Tables built in about 40 seconds

Three linked tables appeared:

Leads: name, email, phone, source channel, status (new / contacted / qualified / lost), linked company, notes, created date.

Companies: company name, industry, size range, website, linked leads (auto-populated), linked deals.

Deals: deal name, value, stage (discovery / proposal / negotiation / closed-won / closed-lost), expected close date, linked company, assigned owner.

The relations between tables were already wired. Clicking a company showed its leads and deals inline. The stage field on Deals came with a Kanban view by default.

We didn't pick any of those field names from a dropdown. The workspace inferred them from the voice input and from the fact that CRMs tend to follow predictable data patterns. The result was closer to what we would have built manually than we expected. The "source channel" field on Leads, for example, was something we'd have added in round two.

What we changed afterward

Two things. We added a "last contacted" date field to Leads (voice command: "add a date field called last contacted to leads") and renamed the "size range" column on Companies to "employee count", again just by saying it.

The point isn't that the first output was perfect. It's that getting from zero to a working schema took under a minute, and every adjustment was the same interface: describe the change, see it happen.

Why this matters for small teams

Most CRMs are either too simple (a shared spreadsheet) or too complex (multi-week onboarding, admin certifications, dedicated ops person). The gap in between is where voice-first data modeling gets interesting.

A freelancer tracking 30 clients doesn't need deal stages. A three-person agency does. With Voice Tables, both describe what they need in their own words and get a workspace shaped to fit. No spreadsheet formulas, no admin panel, no YouTube tutorial on how to set up custom fields.

We've seen similar patterns across other use cases at Inithouse: fitness coaches tracking client programs, event planners managing vendor contacts, consultants logging project hours. The schema is different every time; the interaction pattern is the same: say what you need, watch it appear, adjust by talking.

The technical bit

Voice Tables runs speech-to-intent through a local pipeline. Your voice input gets transcribed, parsed into structured actions (create table, add field, set relation type), and executed against the database layer. The workspace supports offline use and syncs when you reconnect. Real-time collaboration means two people can talk to the same workspace without overwriting each other's changes.

For the CRM use case specifically, the pipeline handled the three-table-with-relations structure in one pass. That's worth noting because multi-table schemas with foreign keys are where most no-code builders start requiring manual configuration.

What we'd do differently

If we rebuilt this walkthrough, we'd start with the company table first and let the workspace infer that leads and deals are child entities. The current approach (saying everything in one sentence) works, but starting from the "biggest" entity and building outward tends to produce cleaner schemas when the data model gets more complex (say, 6-8 linked tables).

That's an observation from about three months of internal use. Not a rule, just a pattern that keeps showing up.

Voice Tables is built by Inithouse. If you've tried building a CRM by talking to it, or used voice input for any structured data problem, we'd like to hear how it went.

Technical mistakes of running 16 products on Lovable + Supabase

Jakub — Thu, 02 Jul 2026 10:22:47 +0000

We run 16 products at Inithouse. All on Lovable. All backed by Supabase. One team managing all of it. That number sounds impressive until you realize it also means 16 custom domains, 16 Supabase projects, 16 sets of edge functions, and 16 chances to make the same mistake over and over.

Here are the five technical mistakes that cost us the most time, and how we fixed each one.

Mistake 1: Every Supabase schema was a snowflake

Our first three products had completely different table names for the same things. User analytics in one project lived in page_views. In another, analytics_events. A third used user_activity. Auth tables had different column names. Blog tables varied wildly.

When we wanted to write a shared stats endpoint, we had to write custom queries for every project. A task that should have taken one afternoon took two weeks.

The fix: We built a shared migration template. Every new product gets the same base tables: analytics (with standardized columns for page views, events, referrers), blog_posts (title, slug, content, published_at), and a consistent auth setup. Old projects got retrofitted one by one during quiet weeks.

Now adding a monitoring endpoint to something like Pet Imagination or Watching Agents takes 20 minutes instead of a day.

Mistake 2: Custom domains break after Lovable publishes (and nobody notices)

Lovable lets you connect a custom domain. Works great. Until you hit Publish and the deploy pipeline does something that quietly breaks DNS verification. The Lovable preview URL works fine, the deploy succeeds, you get a green checkmark. But your actual domain shows a certificate error or a blank page.

We lost three days of traffic on one product before someone checked the live URL. The preview was fine. The custom domain was dead.

The fix: A post-publish checklist. After every Lovable publish, we open the live custom domain in an incognito window and verify it loads. We also added a simple uptime check (just curl the domain every 5 minutes from a cron job) that pings Slack if it gets anything other than a 200.

It sounds basic. It is basic. But when you have 16 domains, "I'll just check it" becomes "I forgot to check it" very fast.

Mistake 3: Zero centralized monitoring

For months, if we wanted to know how Be Recommended was doing compared to Voice Tables, someone had to open two separate Supabase dashboards, two GA4 properties, and mentally combine the numbers.

Nobody did that regularly. We were flying blind across the portfolio.

The fix: A stats API endpoint deployed to every Supabase project. Each product exposes a /functions/v1/stats edge function that returns key metrics in a standardized JSON format: total users, signups this week, page views, top referrers. An aggregator script pulls from all 16 endpoints and dumps the result into a single dashboard.

The total investment was one edge function template (reusable thanks to the schema standardization from Mistake 1) and a 50-line aggregator. Should have done it on day one.

Mistake 4: Copy-paste components without adapting them

Lovable generates React components. When you have a working card component in one project, the temptation is obvious: copy it to the next project. We did this constantly.

The problem: copied components carry assumptions. A pricing card from Magical Song assumed a one-time payment flow. We pasted it into a subscription product and spent two days debugging why Stripe webhooks were failing. The component was calling a one-time checkout endpoint that did not exist in the new project.

We also ended up with slightly different versions of the same component across products. A bug fix in one project never propagated to the others.

The fix: We stopped copy-pasting raw components. Instead, we maintain a reference doc of component patterns. When a new project needs a pricing card, we describe the requirements to Lovable from scratch, referencing the pattern doc for structure. The AI generates a fresh component that fits the new project's stack.

Slower to set up. Faster to maintain. Zero phantom bugs from stale assumptions.

Mistake 5: Treating Lovable's AI chat as documentation

Lovable stores the entire chat history for each project. Every decision, every prompt, every "change the button color" lives there. We treated this as our documentation: "It's all in the Lovable chat."

The problem shows up when you need to know why a decision was made six weeks later. Lovable chat is chronological and mixed with failed attempts, reverted changes, and tangential experiments. Finding "why did we switch from Stripe to LemonSqueezy on this product" in a 200-message chat thread is miserable.

The fix: We moved decision logging to Linear. Every meaningful technical decision gets a one-line comment on the relevant issue: what changed, why, and what it replaced. Lovable chat stays as the execution log. Linear holds the decision log.

Searching "LemonSqueezy" in Linear takes two seconds. Searching it in Lovable chat across 16 projects takes an afternoon.

The pattern behind all five

Every mistake is a variation of the same thing: treating 16 products like 16 separate projects instead of one portfolio. Standardize early, monitor centrally, and document outside the tool you build in.

If you are running multiple Lovable projects (or multiple projects on any AI builder), start with the templates and monitoring before you start building product number three. We waited until product number eight. Do not be us.

All 16 products are live at inithouse.com.

6 Security Holes We Keep Finding in Vibe-Coded Apps

Jakub — Thu, 02 Jul 2026 09:24:30 +0000

Across dozens of audits at Inithouse, the same six security issues show up in AI-generated codebases. Not occasionally. Repeatedly. Different teams, different prompts, different LLMs, same holes.

We built Audit Vibe Coding specifically to catch these patterns. The tool scores AI-generated projects across security, SEO, performance, accessibility and code quality, then returns prioritized fixes. After running it against enough projects, the failure modes became predictable.

Here are the six we see most often, ordered by how frequently they appear.

1. API keys in client-side code

This is the most common one. It shows up in roughly 4 out of 5 projects we audit.

An LLM generates a fetch call to a third-party API and hardcodes the key right into the JavaScript file. Sometimes it uses an environment variable name but defaults to the raw key when the env var is missing. Sometimes it puts the key in a .env file but ships that file without adding it to .gitignore.

The result: anyone who opens DevTools can read your Stripe key, your OpenAI token, your database connection string. We have seen production apps with AWS credentials sitting in a React component.

What to check: Search your client bundle for strings that look like keys. Run grep -r "sk-\|AKIA\|pk_live\|Bearer " src/ and see what comes back.

2. No input validation on user-facing forms

LLMs are good at building forms. They add labels, placeholders, even aria attributes. What they skip is validation on the server side.

The generated code checks input length in the browser, maybe adds a regex for email format on the frontend. The API endpoint behind it accepts whatever arrives. No sanitization, no type checking, no length limits.

One project we audited had a contact form that passed user input directly into a database query string. Classic injection vector, generated by a model that produced clean-looking UI and zero backend protection.

What to check: Submit a form field with <script>alert(1)</script> or a single quote '. If the app stores or reflects it without escaping, you have a problem.

3. Authorization logic that lives only on the frontend

This one is subtle because the app looks correct when you use it normally.

The LLM generates a role check in the React component: if the user is an admin, show the admin panel. If not, redirect. But the API routes behind that panel have no auth middleware. Anyone who calls the endpoint directly (curl, Postman, a browser with the right URL) gets full access.

We see this in roughly half the projects we audit. The frontend enforces roles. The backend trusts every request.

What to check: Open your browser's network tab, find an admin-only API call, copy it as a curl command, remove the auth header or swap in a regular user's token, and run it. If it returns data, your authorization is cosmetic.

4. Wildcard CORS configuration

AI-generated backends frequently ship with Access-Control-Allow-Origin: * in production. During development this makes sense because you want your local frontend to talk to your local API. The model sets it once and never revisits it.

In production, this means any website can make authenticated requests to your API if you also allow credentials. Some projects we audit combine * with Access-Control-Allow-Credentials: true, which browsers actually block, but the misconfiguration signals that nobody reviewed the security headers.

What to check: Run curl -I https://yourapi.com/endpoint and look at the CORS headers. If you see * and you are not running a public read-only API, tighten it.

5. Insecure direct object references (IDOR)

The API returns user data by ID: /api/users/42/profile. Change 42 to 43, get someone else's profile. The LLM generated a clean REST endpoint but did not add a check that the requesting user owns (or has permission to view) the resource.

This is not new or specific to AI code. But AI-generated routes are especially prone to it because models build CRUD scaffolds fast and the access control step is the one that requires project-specific context the model does not have.

What to check: Log in as user A, grab a resource URL, switch to user B's session, and request the same URL. If it works, the endpoint is missing ownership validation.

6. Secrets in git history

Even when teams fix exposed keys, the original commit with the key stays in the git history. git log --all -p | grep "sk-" will find it. The LLM did not create a .gitignore entry before the first commit, so the .env file with the production database password is still recoverable.

Rotating the key is not enough if the old key is valid until someone explicitly revokes it. We have seen projects where the "fixed" version still had working credentials three levels deep in the commit log.

What to check: Run git log --all --diff-filter=D -- "*.env" to see if environment files were ever committed and then deleted. If they were, those secrets are not gone.

What connects these six

None of them are exotic. A junior dev who learned security basics would catch most of them in a code review. The issue is that AI-generated code often skips the review step entirely. The output looks polished, the UI works, the app deploys. It feels done. The security layer that a human team would add during review never happens because nobody reviews.

That is the gap Audit Vibe Coding fills at Inithouse. It runs the review that the LLM skipped, scores what it finds, and tells you what to fix first.

If you are shipping AI-generated code to production, run through the six checks above before your users do it for you. And if you want the full audit covering security, SEO, performance, accessibility and code quality, Audit Vibe Coding is the tool we built for exactly this.

How prediction monitoring differs from single-shot forecasting

Jakub — Wed, 01 Jul 2026 19:58:25 +0000

Three distinct layers for "predicting the future" now coexist, and they solve fundamentally different problems. We have been building Watching Agents at Inithouse, a platform for continuous prediction monitoring, and the most common question we get is: "How is this different from forecasting APIs or prediction markets?"

Short answer: they are complementary. Here is how.

Layer 1: Single-shot forecasting APIs

A forecasting API takes a question about a future event and returns a calibrated probability. You ask, it answers, done.

Foresight by Lightning Rod is a strong example. It is an OpenAI-compatible API that returns scored, calibrated forecasts. Their Foresight-v3 model currently ranks first on ProphetArena (an independent benchmark from UChicago) by Brier score, outperforming GPT-5, Gemini 3 Pro, and other frontier models. The training approach uses reinforcement learning with time as a verifiable reward signal, so even their smaller models outpredict much larger ones.

This is powerful for developers who need a probability estimate inside a workflow. Feed it a question, get a number, make a decision. The interaction is stateless: one question, one answer, move on.

Layer 2: Prediction markets and community forecasting

Platforms like Polymarket and Metaculus aggregate human judgment into probability estimates, but through different mechanisms.

Polymarket uses real-money trading on a crypto-native exchange. Prices reflect market consensus, updated by every trade. Metaculus runs a non-monetary community where forecasters submit probability estimates and the aggregate tracks close to perfect calibration across thousands of resolved questions (events predicted at 70% actually occur about 70% of the time).

Both are excellent at capturing collective intelligence on well-defined binary or multi-choice questions. They struggle more with open-ended monitoring where the question itself might evolve as new information surfaces. And they require active participation: someone has to trade or update their forecast. If nobody is paying attention to a question, the signal stalls.

Layer 3: Continuous prediction monitoring

This is the layer we work in with Watching Agents. Instead of answering a question once, an AI agent watches it continuously. It builds hypotheses, tracks evidence as it appears in real time, and sends alerts when something changes.

The difference is structural, not just about update frequency. A forecasting API does not remember what it told you yesterday. A prediction market reacts to trades but does not explain why the probability shifted. A monitoring agent maintains context: it knows what evidence it collected last week, what hypotheses it has been tracking, and what specifically changed today.

We built Watching Agents because we kept running into situations where the interesting part was not "what is the probability right now" but "what just changed, what caused it, and should we care." That question requires persistent state, evidence tracking, and the ability to surface signals proactively rather than waiting for someone to ask.

Where each layer fits

The three layers map to different jobs:

Forecasting APIs work best when you need a probability estimate inside code. Building a trading bot? Scoring deal risk? Feed the question to an API, get a number, branch your logic. Foresight and similar tools excel here because they are fast, cheap per call, and integrate into existing developer workflows.

Prediction markets and community platforms work best for calibrated consensus on high-profile questions. "Will X happen by Y date?" with thousands of participants correcting each other produces remarkably accurate probabilities. Metaculus is especially strong on long-horizon research questions where careful calibration matters more than trading volume.

Continuous monitoring works best when you care about a topic over time and want to be alerted when conditions shift. You deploy an agent on a question, it watches autonomously, and it tells you when something worth knowing happens. Our agents at Watching Agents maintain public pages showing their hypotheses, evidence, and watch signals, so you can inspect the reasoning at any point.

A concrete example

Say you want to track whether a specific regulation will pass in the EU by Q4 2026.

With a forecasting API, you call it today, get "62% likely," and use that number in your planning model. If you call again next month, you get a fresh estimate, but it has no memory of the first one and cannot tell you what changed.

With a prediction market, you watch the price move as traders react to news. You get a real-time probability, but if you want to understand why it moved from 62% to 71% last Tuesday, you need to research that yourself.

With a monitoring agent, you deploy it on the question once. It tracks parliamentary committee votes, lobbying disclosures, media coverage, and expert commentary as they appear. When something shifts, it tells you what happened and how it affects the outlook. You do not need to remember to check.

These are genuinely different tools for different workflows, not competing products on a feature matrix.

They are complementary

A calibrated forecasting API could serve as one input signal feeding into a monitoring agent. A monitoring agent could surface when a prediction market price diverges from available evidence. Community forecasters could use monitoring feeds to stay current on questions they track.

We think the prediction space is expanding, not consolidating. Single-shot APIs, crowd intelligence, and continuous monitoring each solve a different part of the problem. Our bet at Inithouse is that the monitoring layer is underbuilt relative to its usefulness, which is why we are working on it.

If you are building something in the prediction or forecasting space, we would be curious to hear which layer you find yourself reaching for most.

Yes/no agents outperform open-ended ones in production: retention and reliability data from Watching Agents by Inithouse

Jakub — Wed, 01 Jul 2026 07:47:14 +0000

Binary constraints make agents more useful. That is the core finding after months of running Watching Agents in production, a platform from Inithouse, a studio shipping a growing portfolio of products in parallel. Users deploy AI agents to track questions about the future, and the agents that work best are the ones with the tightest output format.

When we first built the system, agents could answer in open-ended prose. Users got paragraphs. They read them once and never came back. After switching to a yes/no prediction model where each agent outputs a probability score (0 to 100%), a confidence level, and a change velocity metric, returning-user sessions jumped and the reliability of outputs became measurable for the first time.

Here is what we learned and why it matters for anyone building production AI agents.

The problem with open-ended agent output

Open-ended agents produce plausible text. That is the trap. When you ask an agent "Will remote work become the default by 2028?" and it returns three paragraphs of hedged analysis, there is no way to tell if the answer changed since last week. There is no anchor for comparison.

We saw this across our portfolio. At Be Recommended, an AI visibility scoring tool, the shift from prose explanations to a 0 to 100 score per AI engine made the product stickier overnight. Users came back to check their number, not to re-read analysis. The pattern repeated at Watching Agents.

Open-ended output creates three specific problems in production:

No diffability. You cannot compare yesterday's three paragraphs to today's three paragraphs in a way that surfaces what actually changed. Users disengage because the output feels static even when the underlying data shifted.

No accountability. If the agent said "tensions are rising" last Tuesday and says "tensions are rising" this Tuesday, did anything happen? Without quantification, the agent cannot be wrong. And an agent that cannot be wrong is an agent nobody trusts.

No trigger for re-engagement. Push notifications need a delta. "Probability dropped from 72% to 58%" is a notification. "The situation continues to evolve" is not.

What binary constraints actually change

When we rebuilt Watching Agents around yes/no predictions with explicit probability scores, three things improved:

1. Structured hypothesis tracking.
Each agent now maintains a set of competing hypotheses, not just one answer. A "Will the EU regulate foundation models by 2027?" agent carries four or five scenarios, each with its own probability, trend direction, and evidence links. The constraint forced us to decompose vague takes into testable claims.

In practice, this means each hypothesis has confirming and disconfirming conditions defined up front. The agent is not free to drift. It updates probabilities as evidence arrives, and the confirming/disconfirming framing keeps the reasoning auditable.

2. Measurable reliability.
With a probability output, we can track calibration. If an agent says 70% across many predictions, roughly 70% should resolve yes. We observed that constrained agents calibrate within a tighter band than open-ended ones that occasionally produce overconfident prose. The difference is structural: a number demands commitment, prose allows hedging.

We run evolution graphs on every agent page, showing how the probability moved over weeks and months. Users check these graphs the way traders check charts. The visual change alone drives a return pattern we never saw with text-only output.

3. Retention through change signals.
Each Watching Agents page exposes change velocity, latest shift reasoning, and watch signals (leading, confirming, disconfirming). When a probability moves by more than five points, the agent flags it. This creates a natural reason to return.

Compared to our earlier open-ended version, the structured output generates an obvious re-engagement loop: check score, see if it moved, read why, check related agents. We measured higher scroll depth and more multi-page sessions after the transition.

Design implications for production agents

If you are building agents that users interact with repeatedly, consider these patterns we adopted:

Force a quantified output. Even if the domain feels qualitative, find a scoring dimension. At Verdict Buddy, our AI conflict resolution tool built on Gottman and NVC frameworks, we score conflict resolution paths rather than just describing them. The score anchors the conversation.

Separate structure from explanation. The prediction score is the primary output. The reasoning, hypotheses, drivers, and evidence are secondary layers users can drill into. At Watching Agents, agent pages show the probability and confidence first, then expand into detailed hypothesis breakdowns, driver analysis, and sourced evidence. Most returning users scan the top number and only read deeper when it changed.

Build the diff into the product. Every agent page shows a probability history graph and a "latest change" section with reasoning. This is not analytics, it is the product. Users told us they share the evolution graph more than the prediction itself.

Make agents decompose, not summarize. An open-ended agent summarizes. A constrained agent decomposes into hypotheses, each with distinct evidence paths. This decomposition is what makes the output trustworthy. Users can disagree with a specific hypothesis without dismissing the entire prediction.

What this means for the AI agent landscape

The industry defaults to chat-style open-ended agents because that is what LLMs do naturally. But production retention tells a different story. Constraining the output format, whether it is a yes/no probability, a score, or a structured decision tree, gives users a reason to come back.

At Inithouse, a studio running parallel product experiments across a growing portfolio, we have seen this pattern in multiple products. The constraint does not limit the agent. It focuses it. And focused agents are the ones users actually keep using.

If you are building something similar, take a look at how Watching Agents structures its agent pages. Public agents are browsable without signup, and each one demonstrates the binary prediction model with full hypothesis and evidence layers.

Built at Inithouse, a studio shipping a growing portfolio of products in parallel. Watching Agents lets you deploy an AI agent to watch any question about the future.