Indie TM #12: One Founder, Ten Thousand Sources, Every Tender in Romania

What we learned at our twelfth meetup, where Mihai Negrea opened the books on DataDriven

The twelfth edition tried something new: instead of three or four pitches, the whole evening went deep on a single company. [Mihai Negrea](/people/mihai-negrea) is the founder, and the only employee, of [DataDriven](https://www.datadriven.ro), a platform that monitors public tenders across Romania. He walked the room through all of it, from the uncle whose SEAP misery seeded the idea, through a launch nobody noticed and a 3,000 EUR monthly cloud bill, to 300 paying firms, a self-hosted OCR pipeline running on a gaming GPU, and an MCP server his customers point Claude at. Very little was off the record, which is what made it one of the densest evenings we have had.

The arc is worth stating up front, because every section below hangs off it. Twelve years as a developer at Microsoft, two of them in the US on the Bing team. Burnout in 2021, resignation, and a deliberate decision to build the next thing completely alone. A company founded in 2023 with no prior entrepreneurial experience. A first client at 19 lei per month, a long trough of 40 tiny subscriptions, and then a compounding climb: roughly 1,500 EUR in MRR in September 2025, about 27,000 lei (around 5,000 EUR) today, growing 2 to 5 percent a month, profitable for the last three. The full first-person story is in [his journey](/journeys/mihai-datadriven); this recap focuses on what the room dug into.

![datadriven.ro homepage](/screenshots/datadriven.png)

## Twelve years at Microsoft, then a company of one

Mihai's founding constraint was not a market thesis, it was recovery. After the 2021 burnout he wanted, in his own words, to eliminate human contact from his working life and to build the application exactly the way he saw fit. No cofounders, no employees, no negotiated roadmap. The room has heard many origin stories by now, but rarely one where the org chart was a mental health decision, stated that plainly.

It matters because everything else about DataDriven follows from it. A company of one cannot brute-force problems with headcount, so every expensive process eventually gets automated, and every tool choice is audited by the question "can I maintain this alone at 2 a.m.?" What looks like an infrastructure story or a marketing story below is really the same story: one person substituting engineering for staff.

## An uncle, six menus, and a p7s file

The product idea came from watching his uncle, a real estate appraiser working public procurement contracts, spend hours every day inside SEAP, Romania's electronic procurement system. The interface offered six different menus where a tender relevant to his business might be filed, and the filing was inconsistent enough that he had to check all of them. Downloading the documentation meant receiving a .p7s signed file that Windows cannot open, at which point the standard industry workflow was to google "p7s open" and install whatever trialware appeared.

Mihai did what engineers do for family: wrote a script that watched for new tenders in his uncle's domain, crawled the data in Azure, and emailed whatever appeared. The script grew into a crawler with distinct stages, site discovery, processing, extraction from unstructured text, including sites that only render inside a browser. The ambition grew with it: not one domain but all tenders in Romania, using SEAP's APIs for the public data while capturing the large volumes of information never exposed in the HTML. Today that pipeline monitors more than 10,000 sources daily.

## $100,000 of credits and a quiet launch

The company got Azure credits worth up to $150,000 through a startup program, and Mihai burned around $100,000 of them on the AI scripts doing the crawling and processing. In February 2023 he launched, put up ads, and waited for the server to crash under the stampede. The stampede never came. The first paying client arrived in April 2023, at 19 lei per month, and for a long stretch the entire business was 40 clients at that price. He spent those years on the crawler and the data, and admits he did not seriously look at marketing until 2025.

The room noted the pattern, because it recurs across our meetups: the technical founder who builds for two years and markets for two months, then wonders why the curve is flat. What saved DataDriven was that the two years produced something structurally hard to copy, which is not always true of the things we spend two years on.

## Security firms, school sandwiches, and a market of 20,000

Two customer stories defined the product. A security services firm was finding tenders through a bookmark folder organized by county: every day an employee opened the town hall websites one by one to check for new listings. They became the first serious contract, at 2,000 lei per month, for complete coverage of the sites they cared about. And catering firms serving school meal programs, the old "cornul și laptele" that has since become "masă sănătoasă," turned out to be a natural segment: catering is logistically bound to a county, you cannot deliver school sandwiches two counties away, so each firm needs every town hall in its county watched and nothing else.

The addressable market, firms that actively participate in Romanian public tenders, is roughly 20,000 companies. That number shaped everything about go-to-market: it is far too small for consumer-style growth, and exactly the right size for a lead list assembled from public data.

## Reading the documents nobody reads

The technical heart of the talk was a decision most competitors have not made: DataDriven reads the actual tender documentation, the PDFs and the scans, rather than trusting titles and descriptions. The official CPV classification has around 10,000 subcategories and is misapplied constantly; Mihai has found food accessories filed under laptops. So he built his own taxonomy of about 180 categories, deliberately down-to-earth, modeled on how Romanian companies actually describe their work, and classifies from document content. That is what allows the platform to say "this caiet de sarcini asks for exactly these products" instead of the generic "medical equipment."

Reading every document requires industrial OCR, and this is where the solo-founder economics got interesting. The pipeline started on Azure Document Intelligence and now runs on Tesseract plus his own classifiers that validate output quality, executing on an RTX 3090 with 24GB of VRAM in his office at around 1,500 pages per hour. The office has solar panels that cover both the machine and its cooling, so marginal energy cost is effectively zero. The same GPU capacity rented in the cloud would be prohibitive at his volumes.

:::advice{slug="ocr-on-a-gaming-gpu" category="business" person="mihai-negrea" title="A gaming GPU on solar power can replace a cloud AI service"}
DataDriven needs industrial OCR, every tender document in Romania, scans included, and cloud pricing made that a luxury: Azure Document Intelligence billed per page, and GPU instances rent at rates designed for venture budgets. Mihai's replacement is a single RTX 3090 in his office running Tesseract plus his own quality-validation classifiers, processing about 1,500 pages per hour, powered by the solar panels on the roof, so the marginal cost per page is approximately zero. A consumer GPU is not a data center, but a solo founder's workload rarely needs one; it needs sustained, predictable throughput on a task that tolerates batch processing. When an AI API is your biggest variable cost, price out the unfashionable alternative of one good machine you own, because the payback period is often measured in weeks.
:::

## Ads for branding, cold email for customers

Google Ads was the first channel, and Mihai now files it under branding, not acquisition. The conversion problem was structural: someone searches for construction work, clicks the ad, lands on the platform, and turns out not to meet the eligibility requirements that public tenders impose, revenue thresholds, employee counts, certifications. No ad platform can target on "eligible to sell to the Romanian state." Facebook Ads came up in discussion, strong targeting, easy distribution through groups, deep penetration in Romania, but nobody in the room could vouch for it in B2B, and Mihai remains unconvinced.

:::advice{slug="ads-cant-qualify-an-eligibility-market" category="distribution" person="mihai-negrea" title="Paid ads fail when your buyer must meet requirements a click cannot check"}
Google Ads sent DataDriven a steady stream of visitors who could never become customers: they searched for construction tenders, clicked, and only then discovered that public procurement demands revenue thresholds, staff counts, and certifications they did not have. The ad platform had no way to target eligibility, so the budget bought branding at best and noise at worst. This failure mode generalizes to every market where the buyer must hold a license, a certification, or a track record: regulated industries, government suppliers, professional services. In those markets the qualifying attribute is invisible to ad targeting but often visible in public registries, which is where the marketing budget should go instead. Before spending on ads, ask whether a click can even in principle identify your qualified buyer; if not, the channel is structurally wrong regardless of how well you run it.
:::

What replaced ads is a cold email operation built on SEAP's own public data: who participates in tenders, who wins them, phone numbers, activity domains. A firm's procurement history is the qualification ads could not check. The sending infrastructure runs on Instantly.ai at about $150 per month, plus roughly $5 per address for Google Workspace: multiple addresses across several domains, automatically warmed up by the platform sending, opening, replying to, and clicking messages between its own accounts to train sender reputation. Throughput is limited by design, and open rates hold up. Attribution, he admitted, is a mess: people see the email, later google the product, and arrive through the ad, so no dashboard cleanly says which channel closed them.

:::advice{slug="warm-up-a-fleet-of-sending-domains" category="distribution" person="mihai-negrea" title="Cold email at scale is an infrastructure problem before it is a copywriting problem"}
Mihai's cold email machine is mostly plumbing: multiple sending addresses spread across several domains, each warmed up automatically by Instantly.ai, which has the accounts send, open, reply to, and click each other's messages until mailbox providers trust them. The whole fleet costs about $150 per month plus $5 per Google Workspace address, and throughput stays deliberately limited to protect deliverability. The insight indie hackers miss is the ordering: before subject lines and personalization matter at all, the message has to land in an inbox, and that is determined by sender reputation built over weeks. Blasting from your main domain both fails and burns the domain your business runs on. Treat cold email like infrastructure, warmed domains you can afford to lose, low volume, patience, and only then start optimizing the words.
:::

## Leaving Azure without burning the boats

When the sponsorship credits ran out, the bill landed at 2,500 to 3,000 EUR per month across Azure Search, Cosmos DB, OpenAI, and storage, against roughly 1,500 EUR of MRR at the time. The exit, told in full in [his journey](/journeys/mihai-datadriven), ran piece by piece: Cosmos DB to MongoDB in two or three days using a Claude-built query translation layer running in parallel until automated validation confirmed parity; Azure Search, about $500 per 16GB instance and two instances for availability, to self-hosted Elasticsearch; storage to Hetzner's S3-compatible object store after egress and ingress charges, including one 700 EUR ingress month, revealed what shuttling documentation in and out of Azure really cost. The target is three dedicated Hetzner servers, Elasticsearch, MongoDB, and web, plus temporary cloud instances on demand. Last month's Azure bill: $1,500 and falling.

What kept the room's attention was that the exit is not absolutist. When the office infrastructure has downtime, backend tasks overflow to Azure Batch Low Priority instances for a few hours at moderate hourly cost. For network resilience he is considering a Starlink fallback. The GPU sits in an office, not a data center, and he has engineered around that honestly rather than pretending it is one.

:::advice{slug="build-a-fallback-before-you-leave-the-cloud" category="business" person="mihai-negrea" title="Leave the cloud with a fallback, not a farewell"}
DataDriven's infrastructure now lives on Hetzner dedicated servers and an office GPU, but Mihai kept an escape hatch in the other direction: when his local hardware has downtime, backend tasks overflow to Azure Batch Low Priority instances for a few hours at modest cost, and a Starlink connection is under consideration as network fallback. That design is what makes self-hosting responsible instead of reckless for a company of one. The cloud's real product was never compute, it was the promise that failures are someone else's pager, and when you take that back you must replace it with something: an overflow path, a degraded mode, a documented recovery. Price the fallback into the migration math from the start, because the savings of leaving the cloud are only real if one hardware failure cannot take the product down for a week.
:::

## The numbers, and the invoice-first economy

Mihai shared the finances without hedging. Over 300 paying firms. MRR around 27,000 lei, approximately 5,000 EUR, up from roughly 1,500 EUR in September 2025. About 40,000 EUR in total revenue last year. Growth of 2 to 5 percent per month, which he described as slow and steady rather than apologizing for it. Profitable on paper for about three months, with minimal salaries for himself and his wife, and a Romanian accounting lesson attached: you cannot repay the money you personally lent your own company, or pay dividends, until the balance sheet turns positive. His own cash, locked until the books say otherwise.

Pricing is fully public, no "contact us," topping out at 290 lei per month on a plan that recently gained API access and an MCP server. That premium tier collected 3 or 4 subscribers in its first month, which at this scale he counts as a win. The harder conversation was churn, which is high and mostly transactional rather than product-driven: cards without funds, forgotten payments, subscriptions that lapse by accident. Romanian B2B customers want direct contact, want the fiscal invoice, and are wary of automatic card billing, even though the platform only invoices after explicit confirmation and payment. The cost of that culture is operational: reminders, follow-ups, and a certain amount of phone time that a pure SaaS playbook never budgets for.

:::advice{slug="invoice-first-is-a-market-reality" category="business" person="mihai-negrea" title="In invoice-first markets, churn is operational, not emotional"}
DataDriven's churn is high, and almost none of it means the product failed: cards run out of funds, payments get forgotten, and firms that fully intend to continue simply lapse. Romanian B2B buyers want the fiscal invoice before money moves, prefer direct human contact, and distrust automatic card billing on principle, so the frictionless self-serve subscription that SaaS playbooks assume does not exist here. Mihai's response is to treat payment recovery as a standing operational process, reminders, follow-up calls, re-onboarding, rather than reading every lapse as a verdict on the product. The lesson for anyone selling outside the Silicon Valley payment bubble is to learn how your market actually pays before designing the billing, and to budget real recurring effort for collection. A lapsed card in an invoice-first culture is a to-do item, not a goodbye.
:::

Success-fee pricing came up from the audience, pay a percentage when you win the tender. Mihai has thought about it and keeps refusing, because the money in question is public money, and a platform taking a percentage of public contract values is a position he does not want to occupy, legally or reputationally. What he might build instead is a subscription that includes a number of assisted tenders plus a fixed, non-percentage fee on success, outcome-based but not proportional. No commitment yet, and he was careful to say so.

:::advice{slug="refuse-the-percentage-of-public-money" category="business" person="mihai-negrea" title="Some revenue models are traps: know why you refuse a success fee"}
Customers keep offering Mihai a seductive model: charge nothing up front, take a percentage when the tender is won. He refuses, and his reasoning is worth copying. The contract values are public money, and a private platform skimming a percentage of state contracts invites legal scrutiny, reputational damage, and misaligned incentives to push clients toward the biggest tenders rather than the right ones. If he ever prices on outcomes it will be a fixed fee per successful assisted tender bundled into a subscription, never a percentage. The general discipline is to stress-test a revenue model against the source of the money and the behavior it rewards, not just against revenue potential, and to be able to articulate exactly why you turned down the model everyone suggests. A pricing structure is a position you have to defend for years.
:::

## Onboarding, trainings, and thirty interviews

The customer development story drew as many questions as the infrastructure. Mihai has scheduled around 30 customer interviews, of which 10 to 12 actually showed up, and his script avoids the question founders love: not "what features do you want?" but "what do you do? walk me through it, how long does it take, who is involved." Workflow, time, people. The feature list falls out of that on its own.

Onboarding asks for a minimum of 30 characters describing the tenders you care about; AI converts the text into monitoring criteria so the first login shows relevant tenders immediately. Behavior then tunes the filters, thumbs up and down, saves, navigation patterns, with changes reviewed to avoid surprises. Some users resist, "let me just see the app," and some expect to be phoned and configured, both of which he absorbs: two open training sessions per week, a free short setup meeting for anyone who wants one, and scheduled emails on days 1, 2, 5, and 10 with practical suggestions, instead of a first-time product tour he considers intrusive and skippable. He named the trade-off directly: his time goes into the product and these conversations, and the analytics stack sits mostly unconfigured, a choice, not an oversight.

:::advice{slug="interview-the-workflow-not-the-wishlist" category="mindset" person="mihai-negrea" title="Interview customers about their workflow, never their wishlist"}
Of the thirty or so customer interviews Mihai scheduled, ten to twelve happened, and in every one he refuses the founder's favorite question. He never asks what features people want; he asks what they do: walk me through the process, how many hours does it take, who on the team touches it. Feature requests are guesses filtered through what the customer imagines software can do, while workflow descriptions are facts, and the product opportunities sit visibly inside them, the daily bookmark-folder patrol, the hours lost to six SEAP menus. The show-up rate is also part of the lesson: schedule three times the interviews you need, because most will evaporate. Treat customer conversations as ethnography rather than requirements gathering, and the roadmap writes itself from the pain you observed instead of the wishlist you collected.
:::

## MCP packs and an agent that files the paperwork

The forward-looking section was the most technical of the night. Tender documentation, once OCRed, gets rebuilt into what Mihai serves through MCP, the Model Context Protocol that lets tools plug directly into Claude, ChatGPT, and other assistants: cleaned markdown versions of each document with semantic search and an explicit structure, table of contents, chapter and subchapter levels. He deliberately avoids leaning on embeddings alone; retrieval is guided through the document's own hierarchy first, table of contents navigation plus targeted lookups, an approach currently gaining ground in RAG circles. His customers already use Claude and GPT at work, so the MCP server means their assistant reads the tender the way a careful human would, at lower token cost and higher accuracy than dumping raw PDFs into a context window. Firms that would otherwise have to build OCR and retrieval in-house get it as a plan feature; he called it a no-brainer, and the first premium subscribers seem to agree.

:::advice{slug="guide-the-llm-through-the-table-of-contents" category="product" person="mihai-negrea" title="Give an LLM the table of contents before you give it embeddings"}
DataDriven serves tender documentation to AI assistants as structured markdown with an explicit table of contents and chapter hierarchy, and retrieval walks that structure first, using semantic search as a supplement rather than the foundation. Mihai distrusts embeddings-only RAG for long official documents, where a naive similarity search returns fragments stripped of the context that gives them legal meaning. Guided navigation, find the right chapter, then read it properly, mirrors how a careful human reads a contract, costs fewer tokens, and fails more predictably. The broader point for anyone building on LLMs is that documents already contain an information architecture, headings, sections, numbering, and throwing it away to chunk-and-embed is destroying signal you paid to OCR. Preserve structure, navigate it explicitly, and reserve embeddings for the queries structure cannot answer.
:::

Beyond MCP sits the real ambition: an end-to-end agent for tender participation. The user declares the tender they want, their products, certifications, and company data, and the agent prepares the complete submission documentation. And beyond that, a civic idea the room liked: the same dataset exposes patterns worth journalistic attention, firms that always finish second, pairs of companies bidding in tandem at the same authority, correlations across winners. A transparency tool for journalists is on the someday list.

## Copycats, Hermix, and Europe

The competitive map, as Mihai drew it: Romanian incumbents run 2010-era interfaces on top of the official CPV codes, inheriting every classification error. A European competitor, Hermix, reports 500 to 600 thousand EUR ARR with a team of 14 and a heavy sales focus; a "join forces" conversation went nowhere, because their center of gravity is sales and his is technology. And a wave of Romanian copycats now claims "AI agents for tenders," most of them, in his assessment, GPT wrappers with no data underneath. He is calm about all of it: the moat is the coverage, the crawler, the OCR pipeline, the taxonomy, the retrieval stack, and the fact that one person with that stack can move faster than a fourteen-person sales organization.

Europe is already underway: crawling runs on more than 60 procurement portals, state and private, with Germany alone fragmenting into per-land portals plus private ones. The current version translates titles and descriptions into Romanian and targets Romanian firms bidding abroad; full per-country expansion is an architectural project he is pacing deliberately, automation and maintainable scale before flags on the landing page.

:::advice{slug="let-copycats-chase-the-wrapper" category="mindset" person="mihai-negrea" title="Copycats clone your pitch, not your pipeline"}
When Romanian copycats started advertising "AI agents for public tenders," Mihai did not panic, because he could see what they actually shipped: a GPT wrapper over the same misclassified official data everyone can access. What they cannot clone from his landing page is the part that took years, a crawler covering ten thousand sources, an OCR pipeline reading every document, a hand-built taxonomy, and a retrieval stack that makes the data usable. Even the funded European competitor with fourteen people concentrates on sales rather than technology, which is precisely why he declined to join forces. The reassurance for any founder watching lookalikes appear is that marketing copy is the only layer that copies cheaply; if your advantage lives in accumulated data and infrastructure, every copycat validates the market while inheriting none of the moat. Fear the competitor who rebuilds your pipeline, not the one who rewrites your homepage.
:::

## Twelve editions in

The single-story format worked because the story had everything our meetups keep circling: the burnout that reset the ambition, the two years of building before anyone paid attention, the customer whose bookmark folder was the real spec, the cloud bill that nearly outran revenue, and the slow, compounding 2 to 5 percent months that never make it into launch threads. What made it land was the completeness. We usually see the demo; this time we saw the cost structure, the churn, the locked dividends, and the reasoning behind every refusal, of cofounders, of success fees, of the funded competitor's merger offer.

If there was one sentence to take home, it was the shape of the whole thing: find the workflow so painful that someone pays a hundred times your list price to be rid of it, read the source documents everyone else skims, own the expensive parts of your stack, and be patient enough to let three years of compounding do what a launch week cannot. See you at the thirteenth.


Indie TM #5: SEO Tactics That Actually Work

What we learned at our fifth meetup at Cowork Timisoara

Eleven people, one conference table, a Thursday evening in Timisoara. The format was simple: each person gets seven minutes to present what they have been working on, then the room roasts it. No polite nods, no "looks great." Tell me what's wrong.

## Raul goes first

![OG Pilot WordPress plugin](/screenshots/ogpilot-wordpress.png)

[Raul](/people/raul) pulled up [OG Pilot](https://ogpilot.com) on the big screen. He walked through the recent changes: a cleaner dashboard, a better template editor, and the thing he was most excited about, a brand-new [WordPress plugin](https://ogpilot.com/wordpress).

One click to install, and every post on a WordPress site gets a branded Open Graph image automatically. No design skills needed.

![Calm Companies Blog](/screenshots/calmcompanies-blog.png)

Then [Raul](/people/raul) switched tabs to the [Calm Companies Club blog](https://calmcompanies.club/blog) and showed how he was using [NanoBanana](https://nanobanana.com) to generate featured images for his posts. Instead of spending 20 minutes in Canva per article, he described the post topic, NanoBanana generated an image, and he was done. The blog looked polished without the manual effort.

The conversation shifted to content strategy more broadly. [Raul](/people/raul) had been experimenting with different formats beyond text-only blog posts, and shared what was actually moving the needle.

:::advice{slug="video-content-face-in-corner" category="product" title="Record videos with your face in the corner" person="raul"}
Use Loom or similar tools to record product walkthroughs with your face visible in the corner. People trust faces. These videos work as blog post embeds, YouTube content, and social proof simultaneously. Pages with face-in-corner walkthroughs consistently convert better than text-only pages.
:::

:::advice{slug="infographics-backlink-strategy" category="seo" title="Create infographics for blog posts and backlinks" person="raul"}
Infographics get shared and linked to far more than plain text. Create one per major blog post. Use Canva or Figma to visualize your key data points, then offer an embed code below the image so other bloggers can easily reuse it. This is one of the most reliable passive backlink strategies.
:::

:::advice{slug="content-platform-backlinks" category="distribution" title="Get backlinks from Blogger, Wikipedia, and YouTube" person="raul"}
Create profiles and content on high-authority platforms. Write a Blogger post linking to your product. Add your tool to relevant Wikipedia lists (following their guidelines). Create a YouTube video and include your link in the description. Each of these platforms passes significant domain authority through their backlinks.
:::

## Vlad showcases sisif.ai and getnanoclaw

![sisif.ai homepage](/screenshots/sisif-ai.png)

[Vlad](/people/vlad) was up next. He pulled up [sisif.ai](https://sisif.ai) and walked through the programmatic SEO pages he had been building: landing pages targeting specific platforms and locations, each with real content rather than just a swapped city name in a template.

:::advice{slug="nocode-platform-backlinks" category="distribution" title="Get listed on no-code platforms for free backlinks" person="vlad"}
Integrate with Zapier, Make.com, n8n, and other workflow tools. Each platform gives you a listing page with a backlink to your domain. The integration itself doesn't need to be complex: even a simple webhook trigger is enough to get listed. This is free, permanent, and builds domain authority over time.
:::

:::advice{slug="programmatic-local-pages" category="seo" title="Create localized landing pages at scale" person="vlad"}
Build pages targeting "[product/service] in [city/country]" and "[integration] in [city/country]" combinations. Automate the page structure but keep the content genuine. Each page should have real, location-specific information, not just a city name swapped in a template. This is how you capture long-tail local search traffic with almost no competition.
:::

### getnanoclaw gets roasted

![getnanoclaw homepage](/screenshots/getnanoclaw.png)

For his second product, [Vlad](/people/vlad) showed [getnanoclaw](https://getnanoclaw.com/), a personal AI assistant that runs on WhatsApp. The pitch: deploy a Claude-powered chatbot in under two minutes, no servers, no terminal. The room had questions. Lots of questions. Who is this for? Who are the actual users? Small businesses? But it requires an Anthropic API key, which is not something a small business owner knows how to get. The interface felt too programmatic, too developer-friendly for the audience it was trying to reach. If the target is non-technical people, the onboarding needs to meet them where they are, not where a developer would be comfortable.

It was the kind of honest feedback that only comes when people aren't being polite.

## Mircea demos Blahphone

![Blahphone homepage](/screenshots/blahphone.png)

[Mircea](/people/mircea) was next. He pulled up [Blahphone](https://blahphone.com), his browser-based international calling service, and gave the room a live demo. The product looked solid, and the programmatic SEO setup impressed the group: he had built out pages targeting specific calling routes and countries, each ranking well. The roasting focused on the same question that kept coming up all evening: who is actually using this? The group pushed [Mircea](/people/mircea) to get sharper on his user persona and figure out where those people already hang out.

![SingleFax homepage](/screenshots/singlefax.png)

Beyond Blahphone, [Mircea](/people/mircea) had been methodically building backlinks for both [Blahphone](https://blahphone.com) and [SingleFax](https://singlefax.com). His approach was almost comically systematic: list every high-authority platform that lets you create a profile with a link back to your site, then work through them one by one.

:::advice{slug="app-store-backlinks" category="distribution" title="Publish to app stores for authority backlinks" person="mircea"}
Even if your product is primarily web-based, publish a simple mobile wrapper to the App Store and Google Play. The backlinks from apple.com and google.com are extremely high authority. A basic WebView wrapper with push notifications takes a weekend to build and gives you two of the strongest backlinks on the internet.
:::

Someone pushed back on the app store wrapper idea, asking whether Google penalizes thin app listings. [Mircea](/people/mircea)'s answer: he had been doing it for over a year with no issues, and the domain authority lift was measurable.

:::advice{slug="internal-linking-seo" category="seo" title="Add internal links between every page" person="mircea"}
Every page on your site should link to at least 2-3 other relevant pages. Internal linking helps Google discover your content, distributes page authority, and keeps visitors engaged longer. Audit your site for orphan pages (pages with zero internal links pointing to them) and fix them. Use descriptive anchor text, not "click here."
:::

## Mihai shows OCRskill

![OCRskill homepage](/screenshots/ocrskill.png)

[Mihai](/people/mihai-balint) was up next with [OCRskill](https://ocrskill.com), his OCR API that extracts structured data from images in under 500ms. The room was impressed. The product was sharp, the demo clean, and the questions quickly turned technical: what models are you using, how do you handle edge cases, what's the latency under load? [Mihai](/people/mihai-balint) had clearly been paying attention to the SEO discussion all evening. He took notes on every piece of advice, then started asking follow-up questions: how to apply programmatic pages to an API product, whether FAQ schema makes sense for developer tools, how to structure trust pages when your customers are other developers.

## Petru brings the big-domain perspective

[Petru](/people/petru-popa) was next, and he brought a different kind of experience to the table. He works on [Kink.com](https://www.kink.com), one of the oldest domains on the web. The room was immediately curious about the SEO behind a site with that kind of domain age and authority. [Petru](/people/petru-popa) had the most SEO advice of the evening, walking through the structural work that compounds over time.

:::advice{slug="faq-schema-markup" category="seo" title="Add FAQ sections with FAQPage schema to every page" person="petru-popa"}
Write real, human-authored FAQ sections for every page on your site. Use FAQPage structured data so Google can surface your answers as rich results. The key is writing questions your users actually ask, not keyword-stuffed filler. Check Google Search Console for queries people already use to find you, then answer those directly on the page.
:::

:::advice{slug="trust-pages-careers-about" category="seo" title="Create Careers, About Us, and team pages to build trust" person="petru-popa"}
Google evaluates trust signals when ranking your site. A Careers page, an About Us page, Privacy Policy, Terms of Service, and content showcasing team building experiences all signal that there is a real organization behind the site. Include team photos, company culture, and hiring information even if you are not actively recruiting. These pages build trust with both search engines and visitors, and attract backlinks from directories that list companies with public hiring or legal pages.
:::

:::advice{slug="publish-one-article-per-day" category="seo" title="Publish one article per day instead of batching" person="petru-popa"}
Publishing one article per day is far more effective than dropping a batch of articles all at once. Search engines treat a sudden burst of content as suspicious, potentially flagging it as spam. A steady daily cadence signals consistent, genuine content production. It also gives each article time to get indexed and start ranking before the next one competes for attention.
:::

## Cristian on building slow and intentional

![Cozmoslabs homepage](/screenshots/cozmoslabs.png)

[Cristian](/people/cristian-antohe) closed the presentations. He brought [Cozmoslabs](https://www.cozmoslabs.com) and a portfolio of WordPress plugins: [TranslatePress](https://translatepress.com) for multilingual sites, [Profile Builder](https://www.cozmoslabs.com/wordpress-profile-builder/)

![TranslatePress](/screenshots/translatepress.png)

for custom user registration, and [Paid Member Subscriptions](https://www.cozmoslabs.com/wordpress-paid-member-subscriptions/) for membership sites. Over a decade of shipping, and a story that started long before any product existed.

In the early days, [Cristian](/people/cristian-antohe) was writing programming tutorials on the [Cozmoslabs blog](https://www.cozmoslabs.com/blog/). No product to sell, no grand strategy. Just useful content. That content became the foundation for their SEO, and it still drives traffic today. The products came later, born from what their clients kept asking for. Every plugin Cozmoslabs builds starts with a real problem that clients have, because they know it will take about a year to execute properly. So they are picky. They do not chase trends or build features on speculation.

The [full origin story](https://leveldo.com/finding-success-with-wordpress-interview-with-adrian-spiac-co-founder-of-cozmoslabs/) is worth reading: it is a case study in patience.

:::advice{slug="translate-pages-slugs" category="seo" title="Translate every page including the URL slugs" person="cristian-antohe"}
Full translation means translating the content AND the URL slugs. A page at /ro/servicii/ ranks better in Romanian search than /ro/services/. Use hreflang tags to tell Google which language version to show each user. Start with your highest-traffic pages and expand from there.
:::

:::advice{slug="content-before-product" category="seo" title="Write useful content before you have a product to sell" person="cristian-antohe"}
Cozmoslabs started by publishing programming tutorials with no product behind them. That content built domain authority, attracted an audience, and created the SEO foundation that still drives traffic years later. If you start writing only after you have something to sell, you are already behind. The best time to build your content foundation is before you need it.
:::

:::advice{slug="high-quality-low-volume-content" category="seo" title="Publish high-quality articles at low volume" person="cristian-antohe"}
Cozmoslabs still publishes articles, but they prioritize quality over quantity. Every piece is well-researched, genuinely useful, and built to last. High-quality, low-volume content builds trust with both readers and search engines. A single article that answers a real question thoroughly will outperform ten shallow posts competing for the same keywords.
:::

:::advice{slug="build-from-client-problems" category="product" title="Build products from real client problems, not speculation" person="cristian-antohe"}
Every Cozmoslabs product started with a problem their clients kept running into. They do not build on speculation or trends. When you know a product will take a year to execute, you need to be certain the problem is real. Spot the pattern in client requests, validate that the pain is genuine, and only then commit to building. Being picky about what you build is a feature, not a limitation.
:::

## Bogdan wraps up with Event Newsletter

![Event Newsletter homepage](/screenshots/event-newsletter.png)

[Bogdan](/people/bogdan-moldovean) closed the evening with [Event Newsletter](https://event-newsletter.com), his personalized weekly digest of local events. The room liked the retro design, and the niche felt right: event discovery is a real problem, and nobody is solving it well for smaller cities. [Bogdan](/people/bogdan-moldovean) had been the most active questioner all night, asking about every SEO tactic that came up. He is not doing any SEO yet but wants to start, and the group gave him a crash course throughout the evening. The feedback also touched on the AI models he is using to curate and summarize events for the newsletter, with suggestions on which ones might work better for his use case.

The conversation kept going past 9 PM. Someone suggested the next meetup should focus on pricing strategies, someone else wanted to talk about cold outreach. The usual problem: too many good topics, not enough evenings.

Cowork Timisoara - The Office, Timisoara

Vlad Mircea Raul Mihai Petru Cristian Bogdan


Indie TM #6: From ThemeForest Rejects to 70k/Month

What we learned at our sixth meetup at Cowork Timisoara

Ten people, a Friday evening in Timisoara, and a guest who flew in with a story worth hearing. [Zoltan](/people/zoltan) took the big screen for the main slot, walking through how [Bergside](https://bergside.com) went from a rejected ThemeForest template to 70k/month. [Vlad](/people/vlad) and [Mile](/people/mile-rosu) followed with lightning demos, and the room did what it does best: roast everything.

## Zoltan tells the Bergside story

![Bergside homepage](/screenshots/bergside.png)

[Zoltan](/people/zoltan) started from the beginning. He and his co-founder Robert came from outsourcing, building things for other people. They pivoted to templates, submitted their first one to ThemeForest, and got rejected. They kept going. Then came a Black Friday that changed everything: a Tailwind and Figma design system kit sold 3,000 euros in a single night.

That spike proved the market was real. They doubled down on Tailwind components, started building in public, and launched [Flowbite](https://flowbite.com).

![Flowbite homepage](/screenshots/flowbite.png)

[Flowbite](https://flowbite.com) is now an open-source UI component library with over 30 million npm downloads and 9,100+ GitHub stars. The library ships 600+ components, sections, and pages built with Tailwind CSS utility classes and designed in Figma. Two people, bootstrapped, no outside money. The business model: the open-source library is free, but pro components, full website sections, and framework integrations (React, Vue, Svelte) are paid. No subscriptions, just one-time purchases. That model gets them to 70k/month.

### How they decide what to build

The room asked the obvious question: with 600+ components, how do you decide what to build next? [Zoltan](/people/zoltan)'s answer was surprisingly simple. They use [Semrush](https://semrush.com) to check what people are actually searching for. When they saw demand for "avatar tailwind" or "datepicker tailwind," they built those components. Feature decisions driven by search volume, not guesswork.

:::advice{slug="keyword-demand-before-features" category="product" title="Use search demand to decide what features to build" person="zoltan"}
Before building a new feature or component, check what people are actually searching for. Use tools like Semrush to find keywords with real demand. When Flowbite saw search volume for "avatar tailwind" and "datepicker tailwind," they built those components and captured the traffic. Let search data guide your roadmap instead of guessing what users want.
:::

### Influencers over ads

[Zoltan](/people/zoltan) was blunt about paid advertising: skip it. If your product has any traction at all, spend on influencers instead. Put them on the hero section of your site. Pay 1,000 to 2,000 euros per influencer, and prefer American or Australian accents for credibility in the English-speaking developer market. Once one influencer posts about your product, others follow.

:::advice{slug="influencer-over-ads" category="distribution" title="Spend on influencers instead of ads" person="zoltan"}
If your product has any traction, skip paid ads and invest in influencer marketing instead. Pay 1,000 to 2,000 euros per influencer, feature them on your homepage hero section, and prefer American or Australian creators for the English-speaking market. One influencer creates social proof that attracts others. The ROI on a single well-placed creator video outperforms most ad campaigns for developer tools.
:::

### Never discount your prices

This was the most heated topic of the evening. [Zoltan](/people/zoltan) was firm: never compete on price, never offer discounts. Cheap pricing scares away serious clients. If you price like an Indian outsourcing shop, you attract clients who treat you like one. And once you start discounting, people will always wait for the next sale instead of buying now.

The room pushed back. What about Black Friday? [Zoltan](/people/zoltan) acknowledged they experimented with it early on, but the long-term lesson was clear: in the digital products space, maintaining premium pricing builds a better business.

:::advice{slug="never-discount-prices" category="business" title="Never discount your prices" person="zoltan"}
Resist the urge to compete on price or offer discounts. Low prices scare away serious clients who associate cost with quality. Once you start discounting, customers learn to wait for sales instead of buying at full price. In the digital products space, maintaining premium pricing attracts better customers and builds a more sustainable business. Flowbite never discounts, and it has not hurt growth.
:::

### Distribution that actually works

[Zoltan](/people/zoltan) spent the longest on distribution, walking through every channel that has moved the needle for [Flowbite](https://flowbite.com).

Product Hunt worked for initial visibility. Reddit worked, but only with story-driven posts. The key insight: on Reddit, never sell anything. Share the story of building the thing. On X/Twitter, talking about MRR numbers works. On Reddit, it gets you downvoted.

:::advice{slug="story-driven-reddit" category="distribution" title="Post stories on Reddit, not sales pitches" person="zoltan"}
Reddit rewards authenticity and punishes promotion. When Flowbite launched a new datepicker component, they posted the story of building it, not a sales pitch. Share the journey, the technical decisions, the problems you solved. On X/Twitter, sharing MRR numbers gets engagement. On Reddit, the same post gets buried. Each platform has its own language. Learn to speak it.
:::

For SEO content, [Zoltan](/people/zoltan) uses a canonical link strategy: write an article on [Medium](https://medium.com) or [dev.to](https://dev.to), then set the canonical URL pointing back to your own site. You get the platform's audience and distribution while keeping the SEO juice on your domain.

:::advice{slug="canonical-links-medium-devto" category="seo" title="Write on Medium and dev.to with canonical links to your site" person="zoltan"}
Publish articles on Medium and dev.to to reach their built-in audiences, but always set the canonical URL to point back to your own blog. This way you get distribution from the platform while search engines credit your domain as the original source. The content should genuinely help the reader, not be a thinly disguised ad. Spammy content gets flagged on both platforms.
:::

Beyond content, [Zoltan](/people/zoltan) emphasized that people are surprisingly open to partnerships. Reach out to other builders for backlink exchanges, guest articles, and cross-promotion. Discord communities, [src.club](https://src.club), and niche directories are all viable channels. The common thread: every piece of content should answer one question: how does this help the person reading it?

### TypeUI: the new bet

![TypeUI homepage](/screenshots/typeui.png)

Then [Zoltan](/people/zoltan) switched to [TypeUI](https://typeui.sh), the project he is most excited about right now. TypeUI is a CLI coding tool that applies a consistent, beautiful design layer on top of AI-generated code. You run it via npx, it generates components, handles formatting, licensing, and accessibility rules. Think of it as a design system that works natively with AI coding workflows (Cursor, Claude, Copilot) instead of fighting against them.

![TypeUI design skill files](/screenshots/typeui-design-skills.png)

The core concept is "design skills": curated style files that define a visual language. Paper, Bento, Neobrutalism, Bold, Clean, and seven others. Each skill is a complete design system you can pull into your project with one command. The CLI downloads the skill file, applies it to your AI-generated components, and the output looks like a designer touched it.

![TypeUI Paper design skill](/screenshots/typeui-paper.png)

![TypeUI Neobrutalism design skill](/screenshots/typeui-neobrutalism.png)

The product is early, building in public, pre-revenue. Open source under MIT license, with monetization being explored through one-time payments, subscriptions, and sponsorships.

The room discussed the tension between deterministic and AI-generated components. TypeUI is betting that as more code gets generated by AI, the need for a consistent design layer on top becomes critical. The question is whether developers will pay for that layer or expect it to be free.

### Analytics before you scale

The conversation shifted to measurement. [Zoltan](/people/zoltan) stressed that you should never scale traffic without analytics in place first. You need to see what users actually do on your site before you pour effort into bringing more of them.

:::advice{slug="analytics-before-scaling" category="product" title="Set up analytics before you start scaling traffic" person="zoltan"}
Do not invest in scaling traffic until you have analytics running. Use Microsoft Clarity (free) or Hotjar for heatmaps, rage click detection, and session replays. Watch your bounce rate and average time on site (one minute is a reasonable benchmark to start). If users leave immediately, more traffic just means more people leaving. Fix the experience first, then scale.
:::

One more thing [Zoltan](/people/zoltan) was clear about: cold outreach does not work. He tried it. The problem is that cold messages need a hook that genuinely helps the recipient, and most people cannot write one. If your outreach does not answer "what is in it for them" in the first sentence, it goes straight to the trash.

## Vlad demos Openable.dev

![Openable.dev homepage](/screenshots/openable.png)

[Vlad](/people/vlad) was up next with a lightning showcase of [Openable.dev](https://openable.dev), an open-source tool for deploying AI-generated apps without hassle. The idea: connect a GitHub repo, and Openable exports it to GitHub Pages or similar hosting. No terminal commands, no server configuration. Built for non-technical users who just need a shareable link to their project.

The demo was live, which meant the rough edges were on full display. The room spotted rendering issues, some bundling problems, and the branding was not finalized. Classic work-in-progress energy.

The feedback was constructive. Someone suggested Cloudflare Tunnel as a distribution channel. Others pushed on the target audience: if it is for non-technical founders, the onboarding needs to be radically simpler. Cursor integration came up as an interesting angle, with auto-commit and auto-push as a potential workflow that would make deployment invisible.

## Mile pitches the church management app

[Mile](/people/mile-rosu) closed the evening with a concept that caught the room off guard: a management app for churches. Congregation management, business operations, the full administrative stack that churches need but rarely have good software for.

The niche is real. Churches are transaction-heavy organizations with schedules, memberships, donations, and communications to manage. But the room immediately zeroed in on the hard part: distribution. Churches do not move fast. Buying cycles are long. Decision-makers are not hanging out on Product Hunt.

The tech stack is Laravel and Alpine.js, and the product is early enough that it is still a concept rather than a launched tool. The group pushed [Mile](/people/mile-rosu) on focus: instead of building a full management suite, find one specific pain point that churches have and solve that first. Billing? Scheduling? Member communication? Pick one and nail it.

The distribution advice was practical: find a friendly church contact and co-design the product with them. Use WhatsApp groups and local community channels for early feedback. Target church IT contacts or volunteers who already handle the tech side. The biggest risk is building something too generic for a niche that needs something very specific.

## The conversation keeps going

The evening ran past nine. [Zoltan](/people/zoltan)'s story sparked a longer discussion about pricing strategies for digital products, with [Cristian](/people/cristian-antohe) sharing how Cozmoslabs handles annual licensing for WordPress plugins. The contrast was instructive: Flowbite makes 70k/month without recurring revenue, while the WordPress ecosystem lives on yearly renewals. Different markets, different models, both working.

Someone suggested the next meetup should go deeper on pricing. Someone else wanted to talk about building for enterprise versus indie markets. The usual problem: too many good topics, too few Friday evenings.


Indie TM #7: News as a Traffic Locomotive

What we learned at our seventh meetup at Cowork Timisoara

A smaller Wednesday evening than usual, but a denser one. Four presenters: one SEO story with a surprise news-cycle twist, one early-stage AI hiring product looking for its wedge, one security founder pulling the room into a pricing debate, and one small-but-opinionated developer tool that the room quickly started projecting new use cases onto. [Raul](/people/raul) opened with a traffic spike he could not explain at first. [Flavius](/people/flavius) followed with a pitch that turned into a conversation about what "structured" even means in a hiring interview. [Fineas](/people/fineas-silaghi) brought the kind of question that only people shipping to enterprise customers ever get to ask out loud. [Vlad](/people/vlad) closed with a personal side project that doubled as an argument for building your own tools.

![Attendees around the conference table at Cowork Timisoara listening to a presentation during Indie TM #7](/images/events/indie-tm-7-room.jpeg)

## Raul unpacks ebaza.ro

![ebaza.ro homepage](/screenshots/ebaza.png)

[Raul](/people/raul) pulled up [ebaza.ro](https://ebaza.ro), a Romanian domain in the home insurance space. He bought it, along with a few other `.ro` domains, about four years ago and sat on them. Nothing happened for a long time. Then over the last few months the Domain Rating climbed, organic traffic followed, and he started seeing conversions.

The first thing he did once traffic arrived was internal linking: rewiring related pages so they point at each other with descriptive anchors. That alone moved the needle. But there was something else going on.

### The mystery spike

A recent week had an unusually large bump. [Raul](/people/raul) checked [Datafast](https://datafast.com) to confirm the traffic came from Google, not from a single referrer or a social post. Then [Mile](/people/mile-rosu) chimed in from across the room: a new law was about to take effect requiring some institution to inspect mandatory home insurance policies (PAD). The news had been making the rounds in Romanian outlets that same week.

The pieces fit. [Raul](/people/raul) opened [Google Trends](https://trends.google.com) and confirmed the spike: search volume for the relevant PAD terms had jumped in lockstep with the news cycle. His pages happened to be the ones answering the question the news stories were raising. Free traffic, delivered by the news.

:::advice{slug="news-driven-seo-spikes" category="seo" title="Ride news cycles for organic traffic spikes" person="raul"}
When a news story drives sudden search demand for a topic, pages that genuinely answer the underlying question capture a disproportionate share of the traffic. If you see an unexplained spike in analytics, open Google Trends and look for a matching jump in search volume on related terms, then confirm with recent news. Once you know a news cycle is driving the traffic, publish more supporting content while the cycle is still hot. News stories are locomotives: the trick is having something already on the tracks when one arrives.
:::

### The real SEO metric nobody measures

The conversation turned to rankings. [Raul](/people/raul) was skeptical of the usual SEO dashboards. The metric he actually cares about is simple: does the user click your result and find what they came for, or do they bounce back to Google and click the next one? The second behavior ("pogo-sticking") is, in his read, the strongest negative signal in modern search. The first is what you are actually optimizing for.

:::advice{slug="dont-let-users-return-to-search" category="seo" title="Optimize for users not returning to search" person="raul"}
The most important SEO signal in modern search is whether a user returns to the results page after clicking your link. If they do, Google reads it as "this page did not answer the query" and your ranking erodes. If they do not, it reads as "problem solved" and your ranking compounds. This reframes SEO from "rank for keywords" to "fully resolve the intent behind each query." Audit your top pages: does the reader actually get what they came for above the fold, or do they have to scroll through filler and ads? Fix the ones that force users back to search.
:::

### References and side notes

[Raul](/people/raul) mentioned he increasingly uses [ChatGPT](https://chatgpt.com) and [Perplexity](https://perplexity.ai) as research tools when writing content, both to map out the shape of a query and to find the references he should cite. The room also agreed that for apps, a backlink from a relevant marketplace listing is worth more than most content-based backlink tactics, since it comes from a domain whose whole purpose is to send qualified traffic to tools like yours.

## Flavius pitches Pace

![Pace hiring tool homepage](/screenshots/pace.gif)

[Flavius](/people/flavius) was up next with a background that stitched several disciplines together: computer science and psychology, then neuroscience and organizational behavior, then 5+ years hiring for teams across Europe. The through-line was a steadily growing frustration with how interviews actually get run. Earlier in 2026 he turned it into [Human Nature](https://humannature.earth), a company building ethical AI infrastructure for organizations. Its first product is [Pace](https://hirewithpace.com), an AI-native hiring platform that encodes a specific interviewing framework into the workflow instead of leaving every hiring manager to reinvent it.

His thesis sat on one uncomfortable observation. Structured interviews (same questions, same rubric, same scoring across every candidate) are the single most validated predictor of on-the-job performance in the hiring research literature. Almost nobody actually runs them. Not the agencies, not the startups, not the big tech companies when you scratch the surface. [Flavius](/people/flavius) admitted that even when he knew what a structured interview should look like, he struggled to run one consistently under time pressure.

:::advice{slug="product-build-for-known-gap" category="product" title="Build for a practice everyone agrees is right but nobody does" person="flavius"}
The richest product territory is the gap between "known best practice" and "what people actually do." Structured interviews are universally accepted as the strongest predictor of job performance, and almost nobody runs them. Double-entry bookkeeping, security key logins, automated tests, pre-commit hooks: same pattern. Look for a practice that experts in your industry agree is correct and operators skip because it is inconvenient, then build the tool that makes the right thing the easy thing. The onboarding pitch writes itself.
:::

### The framework Pace encodes

[Flavius](/people/flavius) walked through the framework [Pace](https://hirewithpace.com) is built around. It is a two-part model borrowed from organizational psychology: every hire is scored on interview performance and on job fit, as separate axes. A candidate who aces the technical questions but bombs the fit signal is a different decision from a candidate who does the opposite, and collapsing them into one score is where most hiring processes quietly fail.

Inside each axis, the emphasis is on problem-solving over domain-specific knowledge. [Flavius](/people/flavius) was explicit: a good candidate rarely knows the exact stack on day one, and the candidates who memorize trivia tend to underperform in real work. He also showed the two questions he reaches for every time, which he argues pull more signal per minute than any generic prompt:

- "What does a typical day look like in this role?" (to the hiring manager, before the interview is even scheduled; it forces the role definition to become concrete)
- "What separates a great hire from an average one?" (to the hiring manager; the answer usually rewrites the scorecard)

:::advice{slug="interview-specific-questions" category="mindset" title="Ask specific questions that reveal the real role" person="flavius"}
Generic interview questions ("tell me about yourself," "what are your weaknesses") produce rehearsed answers and almost no signal. Two questions that consistently produce the opposite are "What does a typical day look like in this role?" and "What separates a great hire from an average one?" The first forces the hiring manager to describe the real job instead of the job description. The second forces them to articulate the dimension on which people actually succeed or fail. Use the answers to design the rest of the interview. If a hiring manager cannot answer either clearly, the role is not ready to be filled.
:::

The interview itself runs as a panel with three components: a technical track, a sales or individual contributor track matched to the role family, and a behavioral pass. The scorecard pulls signal from all three and the job-fit layer on top, not from one hero interviewer's gut.

### The AI workflow

The AI-native part is less about a chatbot and more about removing the operational tax on the recruiter. [Pace](https://hirewithpace.com) runs alongside Google Meet via a Chrome extension with picture-in-picture, so the recruiter sees questions and scoring rails without leaving the call. Transcription happens in real time (similar to how [Granola](https://granola.ai) handles meeting notes), so by the end of the interview the scorecard is mostly pre-filled and the recruiter just edits and signs off.

The pitch to buyers is concrete on cost. Traditional recruiting is heavy on manual overhead: scheduling, note-taking, write-ups, scorecard alignment, resume parsing, pipeline updates. [Flavius](/people/flavius) ballparks the savings at 40 minutes per interview once transcription, auto-scorecards, and screening automation are in the loop. The room then helped him reframe the pitch: the right benchmark is not "how much does Pace cost per month" but "how much does one bad hire cost this year." At that comparison, the tool pays for itself the first time it prevents a false positive.

:::advice{slug="benchmark-against-cost-of-mistake" category="business" title="Price against the cost of the mistake, not your competitors" person="flavius"}
For tools that sit on top of high-stakes decisions (hiring, compliance, security, legal), the wrong benchmark is competitor pricing. The right benchmark is the cost of one bad outcome. Pace is built for hiring, where a single bad hire typically costs one to two times the annual salary once you factor in ramp, opportunity cost, severance, and team drag. A tool that prevents one bad hire a year is paying for itself many times over at almost any price. Teach your prospects to do that math in the first five minutes of the demo, and pricing objections mostly go away.
:::

### Where it could go next

Toward the end of the pitch, [Flavius](/people/flavius) sketched an adjacent bet: an automated code assessment layer that sits downstream of the interview. GitHub and repository integration, multi-language support (C++, JavaScript, React, and friends), dependency and vulnerability scanning, and AI-filtered results to cut the usual false positive avalanche from static analysis. In the long version, the same platform can run white-box and black-box assessments for internal security reviews, with an optional bug bounty tie-in. The foundation would be TypeScript, modular enough to self-host for enterprises that cannot let candidate code leave their network.

The room noted this is a second product hiding inside the first, and advised [Flavius](/people/flavius) to not ship it until Pace itself has paying customers. Classic indie trap: the adjacent product always looks more interesting than the one you need to close this quarter.

### Where the room pushed back

The demo had been live on the screen while [Flavius](/people/flavius) walked through the framework, which meant the room had plenty of time to inventory the rough edges.

The first complaint was the interface. Setting up a job description inside [Pace](https://hirewithpace.com) currently takes too many steps. Someone pointed out that the whole flow is exactly the kind of thing an LLM should collapse into a single input: paste the job ad, let the model extract the role, the panel structure, and a first-pass question set, then let the recruiter edit. Every extra click before the interview is a click the recruiter will have to repeat dozens of times.

The second was about focus during the interview itself. A good interviewer is listening closely, reading tone and hesitation, following up where the signal lives. Anything on screen that pulls attention away from the candidate (a busy scorecard, a dense rubric, notification badges, unnecessary buttons) is a direct hit on the quality of the signal. The room pushed [Flavius](/people/flavius) to design the live-call view as a minimum viable cockpit: a question, space for a short note, and as close to nothing else as possible. Everything administrative should happen before or after, never during.

The freestyle vs. structured debate came next and got heated. Some in the room preferred the looseness of a conversational interview, arguing that a rigid script misses the best candidates. [Flavius](/people/flavius) had the research on his side, but the consensus was that the research alone is not a marketing asset. [Pace](https://hirewithpace.com)'s homepage and onboarding need to explain, in plain language, why structured interviews outperform freestyle ones before the product can convincingly sell the how. Most hiring managers have never questioned the default; the product has to do that questioning for them.

Then came the persona question. Who is [Pace](https://hirewithpace.com) actually for? Internal HR managers, agency recruiters, hiring managers doing their own hiring, or the candidate side? Each of those buys differently and pays differently. Someone suggested going narrower still: instead of a generic interview tool, pick tech interviews specifically. A tech-first product would need different features (code tasks, system design prompts, engineering panels) but could be a far better alternative than a horizontal tool trying to serve every kind of role. Being the best product for one vertical beats being an acceptable product for all of them.

Pricing drew its own round of questions. How was the current price chosen? Was it anchored to competitors, to the cost-of-bad-hire benchmark [Flavius](/people/flavius) had argued for earlier, or to gut feel? Per-seat enterprise pricing has a reputation for long closing cycles, and a simpler usage-based model (per interview, per role) was floated as a faster way to land the first paying customers, even if it leaves money on the table at the top end.

The sharpest challenge came at the end, and it was not about the product at all. Someone asked the vertical-AI question: why build a SaaS tool that sells interviewing software to recruiters, instead of building a recruiting company whose whole operation is powered by custom AI tools you own? In the vertical version, [Flavius](/people/flavius) is not competing with Greenhouse; he is competing with recruiting agencies that charge 15 to 25 percent of first-year salary per placement, running circles around them on speed and consistency because his internal stack is purpose-built. The SaaS route monetizes the framework. The vertical route monetizes the outcome, which is where most of the margin lives. The room did not resolve it, but it reframed the decision [Flavius](/people/flavius) is actually making.

## Fineas brings the on-prem pricing question

![AISafe homepage](/screenshots/aisafe.gif)

[Fineas Silaghi](/people/fineas-silaghi), CEO of [AISafe Labs](https://aisafe.io), took the floor briefly with a question more than a pitch: how do you price on-prem deployments? [AISafe](https://aisafe.io) sells into environments where running as a SaaS is not an option. Corporations want the tool inside their own network, their own compliance boundary, their own audit trail. The product works. What the pricing page has not fully answered is what those deployments should cost.

The room converged on two answers.

The first was to price against the existing budget, not against competitors or gut feel. Corporations of a certain size already have a budget line for tools in your category: security, compliance, developer tooling, whatever the shelf is called internally. That budget exists, the procurement team is used to spending it, and your job is less "convince them to pay" and more "discover the number." Someone suggested that on discovery calls, you ask what the team already spends on adjacent tools, or what last year's budget for this category was. The literal price tag matters less than landing inside the familiar range so the buyer does not have to fight finance.

:::advice{slug="discover-the-enterprise-budget" category="business" title="Discover the enterprise budget instead of inventing a price" person="fineas-silaghi"}
Corporations of a certain size already run a budget line for your category: security, compliance, developer tooling, whatever the shelf is called internally. The money exists and procurement is used to spending it, so the pricing call is less "convince them to pay" and more "discover the number." On discovery, ask what the team already spends on adjacent tools or what last year's budget for the category was, and land inside the familiar range. The absolute number matters less than being in a bucket finance does not have to fight for. Founders who invent a price from scratch almost always land below the budget the buyer was ready to spend.
:::

The second was to factor the real cost of on-prem maintenance into the price before naming a number. Unlike SaaS, on-prem means limited access to the deployment: no live logs without a ticket, no hotfixes without the customer's change window, no telemetry unless you negotiated it into the contract. Support engineers will spend materially more time per customer on debugging, upgrades, and escalations than a pure SaaS model would ever model. The people in the room who had shipped enterprise software were blunt about this one: if you price on-prem like SaaS, the first production incident eats the margin on the account.

:::advice{slug="price-on-prem-for-support-cost" category="business" title="Price on-prem for the support reality, not the demo" person="fineas-silaghi"}
On-prem is not SaaS with a different installer. Once the software lives inside a customer network you lose live logs, hotfix freedom, and telemetry unless you explicitly negotiated for them. Support engineers spend materially more time per customer on debugging, upgrades, and escalations than any SaaS cost model captures, and that time has to be priced in before you name a number. If on-prem is priced like SaaS, the first production incident eats the margin on the account. The safe heuristic is to model a realistic support load per customer per year, multiply by a loaded engineering rate, and treat that number as the floor, not a contingency.
:::

[Fineas](/people/fineas-silaghi) took both in: the "discover the budget, do not invent it" side, and the "price for the support reality, not the demo" side. The short version for the rest of the room: on-prem pricing is a two-axis problem, and most founders solve only one of the two.

## Vlad shows off zag

![zag composable agent development environment](/screenshots/zag.png)

[Vlad](/people/vlad) wrapped the evening with a short demo of [zag](https://github.com/vtemian/zag), a composable agent development environment written in Zig that he has been building for himself. The framing was deliberately modest: not a startup, not a product, just a personal harness for agentic coding that he uses day to day. Everything above the primitives is a plugin, which means he can swap in new models, terminals, keymaps, and trajectory validators as the ecosystem keeps moving.

The pitch to the room was less about zag specifically and more about the observation behind it. Building a harness for an agentic workflow sounds like a huge project until you actually try it. Once you strip it down to the primitives (a loop, a model call, a tool interface, a trajectory log), the core is a couple of hundred lines. Owning that core gives you leverage everyone else rents from a vendor: you can change the prompt discipline, the validation rules, the editor integration, the telemetry, without waiting for a feature flag.

:::advice{slug="build-your-own-agent-harness" category="mindset" title="Build your own agent harness, even as a side project" person="vlad"}
Most developers assume an agent harness is something you buy or install. In practice, a working harness for your own workflow is a weekend project, not a quarter-long one. The payoff is that every future agentic feature you build sits on primitives you actually control: your own prompt format, your own tool interface, your own logging and trajectory replay. Even if you never ship it as a product, the harness compounds: it is the thing that makes every downstream experiment cheap. And as [Vlad](/people/vlad) put it at the end of his demo, it is genuinely fun to build, which is a signal in itself.
:::

### Where the room pointed it

The most interesting feedback had nothing to do with the code. Several people in the room noted that every visible agent harness today (Claude Code, Codex, Cursor, Aider, zag) is optimized for one workflow: generating, editing, and shipping code. The equivalent tooling for non-code workflows (complex business operations, back-office logic, compliance routines, support pipelines) barely exists. The gap is not the model; it is the harness. Someone building the zag equivalent for operations work, where the "trajectory" is a sequence of forms, approvals, and state changes rather than a diff against a repo, would be sitting on territory nobody else is contesting yet.

[Vlad](/people/vlad) took the note: zag itself will stay a personal coding tool, but the same primitives could anchor a very different product aimed at the non-technical end of the spectrum. The room filed it under "things to watch next."

## The evening wraps up

Four talks, a lot of cross-talk, and a running debate about whether SEO in 2026 is about keywords, intent, or just not annoying the reader. The consensus, for tonight at least, was "all three, and the third matters the most." The bigger thread connecting the evening was a quieter one: every talk, whether it was Raul's traffic spike, Flavius's interview framework, Fineas's on-prem pricing puzzle, or Vlad's agent harness, came back to the same question: what do you own, and what are you renting?


Indie TM #9: Six Demos and a BYOK Debate

What we learned at our ninth meetup at Cowork Timisoara

A Thursday evening built as a show and roast: six builders, each putting a live product on the screen and asking the room to break it. [Raul](/people/raul) bolted a car-insurance flow onto a domain we already knew. [Mircea](/people/mircea) turned tax anxiety into a landing page and then mined his own Search Console for content. [Doru](/people/doru-bota) brought a dental booking platform and walked into the one constraint that matters when you store medical data. [Valentin](/people/vali) showed a tool that tells you whether your email is reaching the inbox at all. [Petru](/people/petru-popa) showed photorealistic 3D property tours. [Ionut](/people/ionut) closed the demos with the most different project of the night, a synth he sells as a one-person studio. Then the room converged on the question every AI builder there had hit: should users bring their own key?

The thread running under all of it was quieter. The products that landed hardest were the ones selling relief from a specific, expensive pain, and almost every roast was a variation on one question: how much friction are you allowed to put between a user and that relief?

## Raul adds an RCA flow to ebaza.ro

![ebaza.ro homepage](/screenshots/ebaza.png)

[Raul](/people/raul) opened by going back to [ebaza.ro](https://ebaza.ro), the Romanian insurance domain he walked the room through last time. The story then was traffic. This time it was a product: he had built a full RCA quote flow into the site. RCA (Raspundere Civila Auto) is Romania's mandatory car-liability insurance, a renew-on-a-schedule purchase every driver in the country has to make, which makes it a steady, high-intent search market sitting right next to his existing pages.

The clever part was the onboarding. Instead of asking a driver to transcribe a dozen fields from their car registration and current policy, [Raul](/people/raul) lets them upload a photo. OCR reads the document and pre-fills the form. He had also leaned on [TypeUI](https://typeui.sh), the design-skill CLI [Zoltan](/people/zoltan) demoed back at the sixth meetup, to make the flow look finished, and he mentioned updating one of his AI skills to stop adding emojis to generated copy, because the stray emoji is the fastest tell that a page was written by a machine.

:::advice{slug="ocr-upload-cuts-onboarding-friction" category="product" title="Let users upload a photo instead of filling a form" person="raul"}
When your onboarding asks for data the user is already holding on a card or a document, do not make them transcribe it. Let them photograph it and run OCR to pre-fill the fields. Raul's RCA flow replaces a dozen manual inputs with a single photo of the car registration and the current policy, and every field removed before the user sees value is a measurable lift in completion. The pattern generalizes to anything printed: an invoice, an ID, a label, a receipt. The cost of an OCR pass is now low enough that asking the user to type what a camera could read is a friction you are choosing to keep.
:::

The sharpest roast was about the call to action. The button promised to "see the price," but clicking it did not show a price; it pushed the user one step deeper into the funnel. A CTA that says "see the price" and then does not show a price is a small dishonesty, and small dishonesties teach users not to trust the next button. The room's note was blunt: either show the price there, or label the button for what it actually does.

## Mircea turns ANAF anxiety into a product

![renzi.ro homepage](/screenshots/renzi.png)

[Mircea](/people/mircea) showed [renzi.ro](https://renzi.ro), a property-management SaaS for Romanian landlords. It centralizes the unglamorous parts of renting out apartments: rent and payment tracking, utility invoices, contracts, document storage. The feature that actually sells it is the tax one: Renzi pre-fills the Declaratia Unica, the unified annual tax declaration (Form 212), ready to submit in ANAF's online SPV portal.

The positioning is the lesson, and it is the opposite of a feature list. The homepage leads with a number: one ANAF fine costs as much as two years of Renzi. That framing does a lot of work, and it is worth being precise about why, because the literal statutory fine for an unregistered rental contract is small (50 to 500 lei). The real exposure is everything behind it: retroactive back-tax at the 10 percent flat rate on the rent you failed to declare (levied on 80 percent of gross, after the 20 percent standard deduction that replaced the old 40 percent one in 2023), plus daily interest and late penalties, plus ANAF's own and usually higher estimate of what you owe, plus the account garnishment that can follow. For 2026, ANAF has more visibility than ever, pulling signals from banks and from platforms like Airbnb and Revolut. Renzi sells relief from that whole stack of consequences and prices itself at a rounding error next to it, roughly 22 to 89 lei a month. [Mircea](/people/mircea) also credited an AI copywriting workflow for the site's copy, which is how a one-person marketing budget produces a page that reads like it had a copywriter.

:::advice{slug="anchor-price-on-the-pain" category="business" title="Anchor your price against the cost of the problem" person="mircea"}
When your product removes a specific, expensive risk, price it against that risk, not against competitors or hours saved. Renzi's homepage leads with "one ANAF fine costs as much as two years of the app." The honest version of that math is not the modest statutory fine but the full exposure it stands in for: retroactive tax on undeclared rent, daily interest and penalties, and the tax authority's own estimate of what you owe. Against a number that large, a subscription of a few tens of lei a month is a rounding error, and the pricing objection mostly disappears. Find the worst outcome your product prevents, do that math out loud on your landing page, and let it dwarf your price.
:::

Then the SEO half. [Mircea](/people/mircea) walked through a script he wrote against the Google Search Console API: pull every query and the page it landed on, dump it to CSV, and group the rows by their shared parent term to expose keyword gaps. The room recognized the move. The API returns far more than the dashboard does (up to 25,000 rows a call against the UI's thousand or so), which is what makes the gap analysis possible. He had also been chasing a high bounce rate and had started addressing it, which is the right reflex: there is no point pouring traffic into a page people leave immediately.

:::advice{slug="mine-search-console-for-content-gaps" category="seo" title="Mine your own Search Console data for content gaps" person="mircea"}
Your Google Search Console data already tells you what Google thinks you rank for, in your users' real words, for free. Pull the full query-and-page table from the Search Console API (it returns up to 25,000 rows per call against the dashboard's thousand or so), then look for two signals. First, striking-distance keywords: queries where you sit in positions four to twenty with plenty of impressions but a weak click-through rate. Google already considers you relevant, and nudging one of those pages from position twelve to position six can multiply its traffic. Second, content gaps: cluster the queries under their shared parent term, and any cluster with real impressions but no dedicated page is a pre-validated brief for an article you have not written yet. It is the cheapest, highest-signal SEO loop there is, and it needs no paid keyword tool.
:::

## Doru shows Dentor, and the room finds the real constraint

![dentor.ro homepage](/screenshots/dentor.png)

[Doru](/people/doru-bota) presented [Dentor](https://dentor.ro), an appointment-scheduling and practice-management platform for dental clinics. Patients book 24/7 through a personalized link, the system sends automated SMS and email reminders, and the practice gets centralized patient records and an auto-generated website. The pitch is operational: fewer phone calls, fewer no-shows, priced at 245 lei a month. He also mentioned a WordPress plugin as part of how clinics would adopt it.

The roast came in three layers, from cosmetic to existential.

The first was diacritics, an old Romanian-web argument. The practical answer the room landed on: keep diacritics in the content a human reads (body copy, headings, titles), because Google treats "programari" and "programări" as equivalent so there is no ranking penalty, and correct Romanian reads as more credible. Strip them from the things a machine parses: URL slugs, file names, image alt text, where encoding quietly breaks links and tooling. This is the dominant practitioner recommendation rather than settled science (you can find Romanian SEOs who argue the other way), but the split between reader-facing content and machine-facing identifiers is the safe default.

:::advice{slug="diacritics-in-content-not-urls" category="seo" title="Keep diacritics in your content, strip them from your URLs" person="doru-bota"}
On a Romanian site, the diacritics question has a practical answer. Google treats "programari" and "programări" as equivalent, so writing correct Romanian with diacritics in your body copy, headings, and titles carries no ranking penalty and reads as more credible to a human. Where diacritics genuinely cause trouble is in URL slugs, file names, and image alt text, where encoding breaks links and tooling. So the rule most Romanian practitioners settle on: diacritics in the content the reader sees, none in the identifiers the machine parses. The same logic applies to any language with accented characters.
:::

The second was the demo video. Dentor already has a roughly two-minute "see how it works" video; the note was about placement. Put the video above the fold next to the headline and the booking CTA, run it as click-to-play with a strong poster frame rather than sound-on autoplay (which browsers block and mute anyway, especially on mobile), keep it short, and never let the video push the primary CTA below the fold. The video supports the booking button; it should never displace it.

The third was the existential one. The moment Dentor stores diagnoses, treatments, and dental imaging, it is processing special-category health data under Article 9 of the GDPR. That is prohibited by default and permitted only on a specific lawful basis, typically the provision of health care or the patient's explicit consent, and it carries a higher bar of safeguards than ordinary personal data. Someone in the room pointed at [universulfiscal.ro](https://universulfiscal.ro) as a local example of surfacing explicit processing consent at the point of data entry, the kind of pattern a health-data product needs front and center rather than buried in a policy page.

:::advice{slug="health-data-compliance-is-engineering" category="product" title="For health data, compliance is an engineering posture, not a badge" person="doru-bota"}
The moment your product stores diagnoses, treatments, or medical images, you are processing special-category health data under Article 9 of the GDPR, which is prohibited by default and allowed only on a specific lawful basis such as the provision of health care or explicit consent. That triggers a higher bar than ordinary personal data: a data protection impact assessment, encryption and pseudonymization, access limited to staff bound by confidentiality, and a signed data-processing agreement that makes you the processor to each clinic's controller. A "GDPR Compliant" badge on the landing page is marketing; for health data it has to be a documented engineering and legal reality. When you build a vertical SaaS that touches a regulated data class, the binding constraint is not your feature set, it is the data class, and you should design for it from the first table you create.
:::

## Valentin checks whether your email actually lands

![doesmyemail.work homepage](/screenshots/doesmyemail.png)

[Valentin](/people/vali) showed [doesmyemail.work](https://doesmyemail.work), a free, no-signup tool that answers a plain question: does my email reach the inbox or the spam folder? You hand it a domain and it scans your SPF, DKIM, DMARC, and MX records, then explains in plain English what is broken (SPF as "does your domain say yes, I sent this," DKIM as "are your emails signed," DMARC as "do you have rules for handling fakes"). It then offers a second, active check: send a real test email to a seed address to confirm mail actually flows end to end.

He was candid that the tool is the top of a funnel, not the business. The plan is lead generation, a WordPress plugin, and a first launch post on LinkedIn. That sequence is well worn for a reason: the whole email-deliverability category gives away the check because running it is itself an admission of a problem the same vendor sells the cure for.

:::advice{slug="free-tool-as-top-of-funnel" category="distribution" title="Ship a free tool as the top of your funnel" person="vali"}
A narrow, free, no-signup tool that solves one frequently-Googled problem is not charity, it is a lead magnet. The whole email-deliverability category (mail-tester, GlockApps, Warmy) gives away the check because running it is itself an admission of a problem the same vendor sells the fix for: it self-qualifies warm prospects and ranks for high-intent queries like "does my email go to spam." The indie sequence is to ship the magnet first, let it accumulate search traffic and word of mouth, and only then bolt on the paid layer (monitoring, a plugin, a done-for-you fix). The catch the room raised: a magnet only works if activation is effortless, so the single most important screen is the one where the user gets their answer.
:::

That last point became the roast. The active-check step is where the tool gets brittle on a phone: it shows a seed address with a "Copy" button and asks you to switch to your mail app and send a message to it, and the hand-off from a browser tab to a native mail client is exactly where mobile users lose the thread. The room's fix was concrete: replace the copy-and-switch dance with a single "send test email" action, a mailto link that pre-fills the recipient and ideally the subject and body, collapsing two taps and a paste into one tap. The activation moment is the one screen you cannot afford to make fiddly.

## Petru shows off Oria

![realoria.com homepage](/screenshots/realoria.png)

[Petru](/people/petru-popa) showed [realoria.com](https://realoria.com), branded Oria: photorealistic 3D property tours that it pitches as Google Street View quality but for interiors, built on Gaussian Splatting, the rendering technique that has been quietly taking over real-estate walkthroughs. The tours run in any browser at over 100 frames per second with no app to install, and turnaround from filming to a delivered tour is 48 to 72 hours. The studio service starts at 350 euros per property, with a self-serve version (film it on your own phone) slated for later in the year.

## Ionut ships a synth, and a one-person studio around it

![Lost Synapse running its Laura polysynth](/screenshots/lostsynapse.png)

[Ionut](/people/ionut) closed the demos with the most different project of the night: [Laura](https://lostsynapse.store), a software synthesizer he builds in C and C++ on top of [JUCE](https://juce.com) and sells under his one-person studio, Lost Synapse. For anyone outside audio software, JUCE is the de facto standard C++ framework for building audio plugins, the effects and instruments that load inside a digital audio workstation like Ableton Live, Logic Pro, or FL Studio. You write the processing code once and JUCE exports the same codebase to every major plugin format across desktop and mobile, which is precisely the cross-platform, cross-format plumbing that would otherwise eat a solo developer's entire timeline. Laura ships as an AU, VST3, and standalone instrument for macOS and Windows.

The commercial shape is as much the lesson as the DSP. Laura is pitched at sound designers "who'd rather not learn another ecosystem": four oscillator engines under one signal path, a mod matrix, and a button that rolls the dice when inspiration is late. It sells for 69 dollars, one time, with lifetime updates and no telemetry, direct from the site or through Gumroad. That is the whole indie-audio thesis on one product page: a single technical founder, one well-scoped instrument, a perpetual license, and a promise ("one purchase, lifetime updates, every new build free, forever") that a subscription tool structurally cannot make.

:::advice{slug="niche-audio-plugin-as-a-product" category="product" title="A niche audio plugin is a textbook solo product" person="ionut"}
Audio plugins are an underrated indie category. A single technical builder can ship one well-scoped effect or instrument on a standard framework like JUCE, which handles the brutal cross-format, cross-platform plumbing (VST3, AU, AAX across Windows, macOS, and Linux) so you can focus on the sound. The economics fit one person: you sell perpetual licenses for 30 to 100 dollars directly to producers, the distribution channels already exist (KVR Audio, Plugin Boutique, YouTube and producer communities), and a perpetual framework license covers six figures of revenue before it costs you recurring money. The moat is not raw engineering, it is taste and DSP craft: a recognizable sound and a brand producers trust. Small, focused, and durable, which is exactly the kind of product that outlasts trends.
:::

## The night ends on the key question

With the demos done, the conversation converged on a problem several people in the room were living: BYOK, bring your own key. The idea is that instead of holding one central API key and billing users for the model usage, you ask each user to supply their own provider key (OpenAI, Anthropic, OpenRouter), store it, and make calls on their behalf, so they pay the model provider directly. Founders reach for it for one reason: it removes the unbounded inference bill that can bankrupt a thin AI wrapper the moment it scales.

The room's two complaints were the two halves of the BYOK problem. First, people are reluctant to hand over a key at all: pasting a long-lived secret into someone else's app raises the obvious questions of where it goes, whether it can be leaked, and whether someone can run up charges on it. Second, the setup is too heavy. Since OpenAI stopped handing out free credits in mid-2025, telling a new user to "go make an API key" now silently means "go add a credit card," which is a much bigger ask than it sounds and stalls signups before anyone sees value.

The resolution was about sequencing and audience, not a yes or no. Lead with a managed free tier on your own key so a new user reaches the aha moment with zero setup, then introduce BYOK as the upgrade for heavy users once the value, and the real cost, are obvious. If you must ask early, kill both frictions deliberately: replace copy-and-paste with a one-click OAuth flow (OpenRouter's authorization flow hands your app a user-scoped key without the user ever touching a raw secret), and be explicit about where the key lives, because "we never see it, it stays in your browser" is a genuine selling point when it is actually true. And the inversion worth remembering: the same key request that repels a consumer signup is, for an enterprise buyer, a litmus test for being enterprise-ready, because it means data sovereignty and their own negotiated provider pricing. Consumer and enterprise want opposite things from the same screen.

Which looped back to the thread under the whole evening. The products that landed hardest were the ones selling relief from a specific, expensive pain: a tax fine, a spam folder, a missed appointment. And nearly every roast was the same question asked six ways: how much friction are you allowed to put between a user and that relief? The answer, for tonight at least, was always less than you think.

Raul
Mircea
Doru
Valentin Bora
Petru
Ionut F.


Bogdan

Dabbler

Worked for Microsoft, started a small business, headed the engineering team for a high growth startup. Had varied levels of success. Now works as a consultant, raises 2 kids and builds small stuff sometimes. The Event Newsletter is one of those things. It's an app that delivers weekly local event newsletters based on the user's preferences, using AI to find and curate events.


Camil

Turning my own problems into products

Full-stack engineer with 8 years of experience, just started indie products on the side. Builder of SoundScrub, a desktop app that removes any sound you can describe (a barking dog, people talking, copyrighted music) from a video, or keeps only that sound, or just turns it down. It runs on Meta's open-source SAM Audio model inside an Electron shell with a Python backend on RunPod, and the video never leaves your machine: the app uploads only the extracted audio for processing. Started as a terminal script for cleaning up his own holiday footage and grew into a pay-per-use product aimed at travel vloggers and videographers. I also launched jobAIssistant, a product that tracks job applications: paste a job URL and it extracts the details, forward a recruiter email and it updates the application details and interview schedule. I also work on PermaMusic, a free tool that finds deleted songs and duplicates across your YouTube playlists.


Cristian

WordPress product builder at Cozmoslabs

Founder of Cozmoslabs, building WordPress plugins for membership and community management. Over a decade of shipping products in the WordPress ecosystem serving 500,000+ brands with 6+ million plugin downloads.


Doru

Building scheduling software for dental clinics

Builder behind Dentor, an appointment-scheduling and practice-management platform for Romanian dental clinics. Dentor gives each practice a 24/7 online booking link, automated SMS and email reminders, centralized patient records, and an auto-generated website, so a clinic runs on software instead of a receptionist's notebook. Building a vertical SaaS in one of the most heavily regulated data classes there is: patient health data under GDPR.


Fineas Silaghi

Security researcher and CTF player running AISafe Labs

Dives headfirst into the most challenging subjects and uncovers ways to exploit them. Security researcher and CTF player from Romania, now CEO of AISafe Labs, where he ships a security product into environments where SaaS is not an option: corporate networks, regulated industries, air-gapped deployments.


Flavius D.

Builds systems that make hiring decisions better

Studied computer science and psychology, then went deeper into neuroscience and organizational behavior. Spent 5+ years hiring for teams across Europe before founding Human Nature in 2026, a company building ethical AI infrastructure for organizations. First product is Pace, a structured interview copilot that runs beside interviewers rather than replacing them. Structured interviews have the highest predictive validity in hiring research and the highest variability in practice; Pace exists to close that implementation gap.


Greg

Bootstrapped CX and NPS SaaS founder at Retently

Founder of Retently, a bootstrapped customer feedback platform (NPS, CSAT, CES, reviews, and insights) for Ecommerce stores and B2B SaaS. More than a decade of building it profitably and independently, with a focus on durability, customer trust, and a product that compounds over time.