Event Newsletter: A Side Project Built in the Margins

Why I scoped a personalized weekly local-events digest small enough to run alongside two kids and a consulting career

I have worked at Microsoft, started a small business, and led the engineering team at a high-growth startup. These days I work as a consultant, raise two kids, and build small things when I find the time. I call myself a dabbler, and I mean it. [Event Newsletter](https://event-newsletter.com) is one of those small things: an app that delivers a personalized weekly digest of local events based on what each person actually cares about, with AI doing the work of finding, curating, and summarizing.

![Event Newsletter homepage with a retro design](/screenshots/event-newsletter.png)

I brought it to Indie TM #5 in Timisoara, the meetup where each person gets seven minutes and then the room roasts what they built. I went last. The room liked the retro design and agreed the niche felt right: event discovery is a real problem, and nobody is solving it well for smaller cities. That was enough encouragement to keep going, and honest enough that I left with a long list of things to fix.

## The product had to fit the life I already have

I did not set out to build a startup. I set out to build something I could run in the margins of a life that is already full. That constraint shaped everything. A personalized weekly events digest is small on purpose: it has a narrow job, a predictable rhythm, and no expectation that I babysit it every day. If I had picked something that needed constant attention, it would have died the first busy week, and every week is a busy week.

:::advice{slug="build-in-the-margins-of-a-busy-life" category="mindset" person="bogdan-moldovean" title="Scope a side project to fit the life you already have"}
Bogdan has a consulting career and two kids, so he deliberately scoped Event Newsletter to something he could run in the gaps rather than something that demands his full attention. The trick is to choose the product around your real available time, not around an imagined version of yourself with empty evenings. A tightly-scoped tool with a narrow job survives the busy weeks that would kill a more ambitious build. For a dabbler, the right size of project is the one that still gets shipped when life gets loud.
:::

## AI turns a firehose of events into one personal digest

The reason this is even possible solo is AI. There is a firehose of events happening in any city, scattered across listings, pages, and posts that no human side-project owner could read every week. So I let AI do the reading. It finds the events, curates them against each person's stated preferences, and summarizes them into something short and readable. The newsletter that lands in your inbox is the small, personal end of a very large, very messy pipe.

:::advice{slug="let-ai-curate-the-event-firehose" category="product" person="bogdan-moldovean" title="Let AI curate and summarize the firehose into something personal"}
Event Newsletter works because AI handles the part a solo builder cannot: reading the constant flood of local events and turning it into a short, personal digest. Bogdan uses AI to find, curate, and summarize, matching events against each user's preferences so the output feels hand-picked rather than dumped. The leverage is not the AI by itself, it is pointing it at a firehose of information that a human could never process at the cadence the product needs. At Indie TM #5 the room also weighed in on which models might suit this job better, which is the kind of input he went looking for.
:::

## The niche is the cities everyone else skips

The honest insight here is small and specific. The big aggregators do event discovery acceptably for major cities and ignore everyone else. Smaller cities get thin, stale, or nonexistent coverage. That gap is the whole opportunity. I am not trying to out-aggregate the giants in places they already serve. I am trying to serve well the places they do not bother with, where someone genuinely cannot find out what is happening near them. The retro design is part of this too: it gives the product a bit of personality, which is cheap differentiation when you cannot compete on scale.

:::advice{slug="serve-the-smaller-cities-aggregators-skip" category="product" person="bogdan-moldovean" title="Serve the smaller cities the big aggregators ignore"}
Big event aggregators cover major cities and leave smaller ones thin or empty, and that ignored geography is the niche Bogdan is aiming Event Newsletter at. Picking the segment the incumbents skip means you are not fighting them where they are strong, you are serving people they have written off. The room at Indie TM #5 agreed this was the right wedge: a real problem that nobody handles well for smaller places. He also leans on the retro design as a cheap form of differentiation, since personality costs little and stands out when you cannot win on scale.
:::

## A weekly newsletter is a forgiving format

The newsletter format itself is a design decision, not just a delivery channel. Weekly means I am not promising real-time. It sets an honest expectation and gives the system a calm, predictable cadence to run on. Email also meets people where they already are instead of asking them to remember to open yet another app. For a side project that has to survive in the margins, a once-a-week digest is about as low-maintenance as a real product gets.

:::advice{slug="weekly-newsletter-as-low-maintenance-format" category="distribution" person="bogdan-moldovean" title="Use a weekly newsletter as a low-maintenance product format"}
Bogdan chose a weekly newsletter for Event Newsletter partly because the format itself is forgiving: a once-a-week cadence sets honest expectations and removes the pressure of anything real-time. Email reaches people in a place they already check rather than competing for attention as one more app to open. For a project run in the margins, the delivery format can do real work to keep maintenance low. The cadence you promise is a product decision, so pick one your life can actually sustain.
:::

## Being the loudest learner paid off

I was the most active questioner at the meetup, by a wide margin. Every time SEO came up, and it came up constantly, I asked about it, because I am not doing any SEO yet and I want to start. By the end of the night the room had effectively given me a crash course, just from me refusing to stay quiet. I have no SEO results to report, because there is nothing to report yet. What I have is a notebook full of tactics I did not know that morning, collected simply by being the person willing to keep asking.

:::advice{slug="be-the-loudest-learner-in-the-room" category="mindset" person="bogdan-moldovean" title="Be the loudest learner in the room"}
Bogdan was the most active questioner at Indie TM #5, and being the loudest learner is exactly how he walked out with a crash course in the SEO he had not started yet. A room full of builders is a free education, but only for the person willing to keep asking instead of nodding along to protect their ego. He has no SEO results to show, only a list of things to try, and that is the honest output of an evening spent learning out loud. When you are early and behind on something, the fastest way to catch up is to stop pretending you already know it.
:::

Scope a side project small enough to run in the gaps of a busy life

Let AI curate and summarize a firehose of events into one personal digest

A weekly newsletter is a low-maintenance product format

Be the loudest learner in the room and the room will teach you


SoundScrub: From a Terminal Script to a Product

How a tool for cleaning up holiday footage became a focused app that beats the big editors at one job

[SoundScrub](https://soundscrub.video) does one thing: you describe a sound in plain words, and it removes that sound from your video, keeps only that sound, or just turns it down. It did not start as a product. It started as a script I ran from the terminal to rescue my own footage.

![soundscrub.video homepage](/screenshots/soundscrub.png)

## From a personal fix to a product

I had come back from a holiday with a lot of footage I wanted to show my parents, and a lot of it was ruined by background noise. So I wrote a script to strip the noise out. It solved my problem, and then I hit the question every tinkerer eventually hits: this fixes my problem, but is it a product? The answer turned out to be yes, because the noise problem is not mine alone, it belongs to every traveler and videographer who films in the real world.

:::advice{slug="from-personal-fix-to-product" category="product" person="camil" title="A personal fix becomes a product when others share the pain"}
SoundScrub began as a script Camil wrote to clean the background noise out of his own holiday footage. The leap to a product came from one question: do enough other people have this exact pain? Scratching your own itch is a great way to start, but it only becomes a business when you confirm the itch is widely shared and worth paying to scratch. Build the thing that solves your problem first, because you understand it deeply, then go check that travelers and videographers are loudly describing the same problem before you commit to productizing it.
:::

## Build the app for the people who fear the terminal

The script worked, but only for someone comfortable in a terminal. The product is the desktop app I built for the much larger group of people who would never open one. That is the whole gap between a useful script and a sellable product: the same capability, wrapped so a non-technical person can use it without thinking about Python or command lines.

:::advice{slug="wrap-your-script-in-an-app" category="product" person="camil" title="Wrap your script in an app for the people who fear the terminal"}
Camil's noise-removal script already worked; the product was wrapping it in a desktop app for everyone who would never touch a terminal. The market for a command-line tool is other developers; the market for the same capability behind a clean interface is everyone. If you have a script that genuinely solves a problem, the productizing work is mostly removing the technical barriers around it, not adding features. A good interface over a working script reaches an audience an order of magnitude larger than the script ever could.
:::

## Stand on an open model

I did not train the audio model myself. SoundScrub runs on Meta's open-source SAM Audio, wrapped in an Electron shell with a Python backend that runs the model on RunPod GPUs. The hard research problem is solved by the open model; my job is the experience around it. Standing on open-source foundations is what let one person ship something this capable.

:::advice{slug="build-on-open-models" category="mindset" person="camil" title="Stand on an open model and build the experience around it"}
SoundScrub's audio separation is powered by Meta's open-source SAM Audio, not a model Camil trained. The leverage for a solo builder in 2026 is enormous: the hardest research is published and free, so your job is the product around it (the interface, the workflow, the trust). Do not try to out-research a frontier lab. Find the capable open model that does the hard part, and compete on the experience, the focus, and the polish that the raw model will never have on its own.
:::

## Let the architecture give you a feature

A nice property fell out of how SoundScrub is built. The video never leaves your machine; only the extracted audio is uploaded for processing, and it is deleted right after. I did not design that as a privacy feature, it was just how the pipeline worked, but it is a genuine selling point for anyone nervous about uploading personal footage. Sometimes the architecture hands you a promise you can make to users.

:::advice{slug="turn-architecture-into-a-promise" category="product" person="camil" title="Let your architecture hand you a feature worth selling"}
SoundScrub uploads only the extracted audio, never the video, and deletes it right after, so users get a real privacy guarantee that fell out of the technical design rather than a marketing decision. When a property of your architecture happens to answer a fear your users have (privacy, speed, offline use), name it and put it on the page. The most credible selling points are the ones that are simply true because of how the thing is built. Look at your own stack for promises you can already make and are not yet making.
:::

## Be honest about the limits

I was upfront with the room about where SoundScrub falls short. The prompt can describe what a sound is (a dog barking, people talking) but not where it sits in the frame, and the longest clip I had run through it was about twenty minutes. Saying that plainly did not weaken the pitch, it strengthened it, because the one comparison that made people sit up (it isolates a specific sound far more cleanly than DaVinci Resolve's built-in tools) was clearly coming from someone who knew exactly what his tool could and could not do.

:::advice{slug="name-your-tools-limits" category="mindset" person="camil" title="Be honest about the limits of your tool"}
Camil told the room exactly where SoundScrub breaks down (no spatial selection, a practical clip-length limit) and it made his strong claim, that it beats DaVinci Resolve at isolating a named sound, more believable, not less. Naming your limits signals that you understand your own product and are not overselling, which is precisely what makes your genuine advantages credible. Buyers trust a founder who volunteers the edges. Hiding the limits only means the user discovers them later, at the worst possible moment, and stops trusting everything else you said.
:::

A personal fix can become a product once others share the pain

Wrap your script in an app for everyone who fears the terminal

Stand on an open model and add the experience around it


A Decade of WordPress Plugins, Built One Slow Year at a Time

Why Cozmoslabs says no to most ideas, lives on yearly renewals, and treats patience as a strategy

I run [Cozmoslabs](https://www.cozmoslabs.com), and we build WordPress plugins. [TranslatePress](https://translatepress.com) makes sites multilingual, Profile Builder handles custom user registration, and Paid Member Subscriptions powers membership sites. Over the years that portfolio has reached more than 500,000 brands, with over 6 million plugin downloads behind it. When I closed the presentations at Indie TM #5, I did not talk about a growth hack. I talked about the opposite: how slow, deliberate building turned into a business that has lasted more than a decade.

![Cozmoslabs homepage showing its WordPress plugin portfolio](/screenshots/cozmoslabs.png)

## It started with content and no product

In the early days there was no product to sell. I was writing programming tutorials on the Cozmoslabs blog because they were useful, not because they fed a funnel. That content became the SEO foundation that still drives traffic today. The products came later, each one born from a problem clients kept asking me about. I have talked elsewhere about writing content before you have something to sell. The part I want to dwell on here is everything that happened after: the pace, the model, and why we keep saying no.

## A year per product means one product per year

Every plugin we ship takes about a year to execute properly. That is not a complaint, it is a budget. A year is the most expensive thing I have, and a real product spends all of it, which means I get very few of these decisions in a lifetime. So most of what we could build, we do not. The constraint is not whether an idea is good. Plenty of good ideas show up. The constraint is that saying yes to one is saying no to everything else for twelve months, and that math makes me ruthless about what earns a slot.

:::advice{slug="one-product-per-year-forces-no" category="mindset" person="cristian-antohe" title="A one-product-per-year cadence forces you to say no to almost everything"}
Every Cozmoslabs plugin takes about a year to ship properly, which means Cristian gets very few product decisions in a working lifetime. He treats that scarcity as the real filter: the question is never whether an idea is good, because plenty of good ideas appear, it is whether this one is worth giving up a whole year of everything else. That opportunity cost makes saying no the default and saying yes a rare, deliberate act. When each commitment costs a year, the discipline is not picking winners, it is refusing the merely-good in favor of the truly worth it.
:::

## The WordPress economy runs on renewals

At Indie TM #6 the room got into pricing, and I shared how we handle it. The contrast was sharp. Some products in that room make great money on one-time purchases. The WordPress plugin ecosystem works differently: it lives on yearly licensing and renewals. A customer buys an annual license, gets a year of updates and support, and renews to keep them. That recurring base is what lets us afford a year per product in the first place. Different market, different model, and ours rewards durability over a launch spike.

:::advice{slug="annual-licensing-is-a-durable-model" category="business" person="cristian-antohe" title="Annual licensing and renewals fund the long game"}
Cozmoslabs runs on the WordPress ecosystem's standard model: customers buy an annual license and renew it for ongoing updates and support. At Indie TM #6 Cristian contrasted this with one-time pricing, noting that the WordPress economy lives on yearly renewals rather than launch-day spikes. The recurring base is exactly what makes a year-long build cycle affordable, because the business is not betting everything on a single sale. When your model rewards the steady renewal instead of the one-off purchase, you can afford to build slowly and think in decades.
:::

## Standing on a platform, not beside it

We never tried to build standalone software. We built on top of WordPress, and that choice shapes everything. The platform already has the users, the install base, and the distribution. Our job is to solve a problem inside an ecosystem people already use, not to convince them to adopt a brand-new tool from zero. When a client needs multilingual support or custom registration, they are already on WordPress, and the plugin meets them exactly where they are.

:::advice{slug="build-on-an-existing-platform-ecosystem" category="distribution" person="cristian-antohe" title="Build inside an existing platform ecosystem, not standalone"}
Cozmoslabs builds plugins on top of WordPress rather than launching standalone software, and that decision is itself a distribution strategy. The platform already carries the users, the install base, and the demand, so a plugin meets people inside a tool they have already chosen instead of asking them to adopt something new. Cristian's products solve specific problems for an audience that is already present, which removes the hardest part of distribution. When a large ecosystem already holds your buyers, building inside it can beat building beside it.
:::

## One brand, several products

Cozmoslabs is not one plugin, it is a portfolio under a single name. TranslatePress, Profile Builder, and Paid Member Subscriptions each solve a different problem for a different need, yet they share the brand, the audience, and the content foundation. A customer who trusts us for one plugin is far easier to reach for the next. The blog that built authority years ago now lifts every product we attach to it. Each new plugin does not start from zero on trust, it inherits a decade of it.

:::advice{slug="one-brand-many-plugins" category="business" person="cristian-antohe" title="Run a multi-product portfolio under one trusted brand"}
Cozmoslabs ships several distinct plugins (TranslatePress, Profile Builder, Paid Member Subscriptions) under one brand rather than spinning up a separate identity for each. The shared brand, audience, and content foundation mean a new product inherits the trust and SEO authority the earlier ones built, instead of starting from zero. A customer who already relies on one Cozmoslabs plugin is a warm prospect for the next. When your products serve the same broad audience, keeping them under one roof compounds every audience and trust asset you have already earned.
:::

## A decade is the moat

What actually defends Cozmoslabs is not any single clever feature. It is that we are still here. More than ten years of shipping, supporting, and renewing builds a kind of durability that a competitor cannot copy by launching a flashier version next month. The content has aged into authority, the plugins have aged into reliability, and the brand has aged into trust. Being picky and slow looks like a handicap in a fast market. Over a decade, it is exactly what made us hard to displace.

:::advice{slug="decade-of-shipping-is-the-moat" category="mindset" person="cristian-antohe" title="Longevity across a decade is the real moat"}
After more than ten years of shipping, the thing that defends Cozmoslabs is not a single feature but its sheer durability. Content has aged into authority, plugins have aged into reliability, and the brand has aged into trust, and none of that can be cloned by a competitor launching something flashier next month. Cristian's pickiness and slow pace look like handicaps in a market obsessed with speed, yet across a decade they are precisely what made the business hard to displace. Longevity is not a byproduct of the strategy, it is the moat the strategy was built to create.
:::

Annual licensing and renewals are a durable business model

Build on top of an existing platform ecosystem, not standalone


Building Dentor in the Most Regulated Data Class There Is

How a dental booking platform turned a GDPR constraint into a moat, and learned to sell in person

[Dentor](https://dentor.ro) looks, on the surface, like a simple product: a 24/7 online booking link for a dental clinic, automated SMS and email reminders, centralized patient records, and an auto-generated website. The clinic runs on software instead of a receptionist's notebook, for 245 lei a month. Underneath that simplicity is the hardest constraint I have ever built around.

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

## The data class is the product spec

The moment Dentor stores a diagnosis, a treatment, or a dental image, it is processing special-category health data under Article 9 of the GDPR. That is prohibited by default and allowed only on a specific lawful basis, with a higher bar than ordinary personal data: a data protection impact assessment, encryption and pseudonymization, access restricted to staff bound by confidentiality, and a signed data-processing agreement that makes me the processor to each clinic's controller. When I first presented Dentor, the room walked me straight into this, and they were right. The binding constraint on a product like this is not the feature set, it is the data class.

:::advice{slug="design-for-the-data-class-from-day-one" category="product" person="doru-bota" title="In a regulated vertical, the data class is the product spec"}
When Dentor stores diagnoses and dental images, it is handling special-category health data under Article 9 of the GDPR, which is prohibited by default and allowed only under strict conditions. For a vertical SaaS in a regulated space, that data class dictates the architecture before a single feature does: encryption, pseudonymization, access control, a DPIA, and a processor agreement are not add-ons, they are the schema. Find out which regulated data class you are touching before you design the first table, and let it shape the product from day one. Retrofitting compliance onto a finished app is far more expensive than building for it from the start.
:::

## Sell the relief, not the features

A dental clinic does not want "centralized patient records." It wants fewer phone calls interrupting treatments, fewer no-shows eating the schedule, and a website it never had to commission. Every time I led with features, eyes glazed over. When I led with the relief (the receptionist stops fielding booking calls, the no-show rate drops because the system reminds patients automatically) the owner leaned in.

:::advice{slug="sell-the-relief-not-the-feature-list" category="product" person="doru-bota" title="Sell the operational relief, not the feature list"}
Dentor's feature list (booking link, reminders, patient records, auto-generated site) means nothing to a dentist until it is translated into relief: fewer interrupting phone calls and fewer empty chairs from no-shows. Buyers do not purchase capabilities, they purchase the removal of a daily pain. Lead with the specific operational misery your product ends, in the buyer's own words, and keep the feature list for the spec page. The clinic owner does not care how it works; they care that Monday stops being chaos.
:::

## Cold email died, in-person sold

The expensive lesson came on the sales side. I polished the brand, tightened the copy, and ran the obvious first move: a cold email campaign. It produced nothing. What worked was the least scalable thing imaginable: walking into small and individual dental clinics and pitching the owner face to face. A dentist does not live in their inbox and will not trust a stranger's link, but they will trust a person standing in their waiting room who clearly understands their day.

:::advice{slug="match-the-channel-to-the-buyer" category="distribution" person="doru-bota" title="Match the channel to the buyer, even when it does not scale"}
Doru's cold email campaign for Dentor produced nothing; walking into clinics and pitching owners in person produced customers. Cold email is the default because it scales from a laptop, but it assumes a buyer who reads cold email and trusts links from strangers. A local, high-trust, offline buyer like a dentist is the opposite of that. The channel has to match where the buyer's trust actually lives, not your preference for staying behind a screen. Early on, the unscalable channel is often the only one that converts, so do it until you have proof and a reference list.
:::

## Compliance is a reason to buy

The interesting inversion is that the same GDPR burden that makes Dentor hard to build is something clinics are afraid of themselves. A clinic owner knows, vaguely, that mishandling patient data is dangerous, and most have no idea whether their current spreadsheet-and-WhatsApp setup is exposing them. A product that has visibly done the compliance work is not just safer, it is more attractive. The constraint became part of the pitch.

:::advice{slug="turn-compliance-into-a-selling-point" category="business" person="doru-bota" title="Turn compliance from a burden into a selling point"}
The Article 9 requirements that make Dentor expensive to build are the same requirements clinics are quietly anxious about for their own data handling. Done properly and shown honestly (not a "GDPR Compliant" badge, but a real, explained posture on consent and data protection), compliance becomes a reason to choose you over the informal setup a clinic uses today. In a regulated market, the burden everyone else avoids is the differentiator. Do the hard work, then let prospects see that you did it, because their fear of getting it wrong is part of why they will pay you.
:::

## The hard niche is the moat

The in-person grind is slow, but everything that makes Dentor hard (health-data compliance, slow offline buyers, an unscalable sales motion) is also what keeps casual competitors out. A market that punishes shortcuts and rewards patience is a market where a committed builder can win and then defend the position. The difficulty is not a reason to avoid the niche, it is the reason the niche is worth owning.

:::advice{slug="a-regulated-niche-is-a-moat" category="mindset" person="doru-bota" title="A hard-to-serve, regulated niche is a moat"}
Everything that makes Dentor hard (health-data compliance, slow offline buyers, in-person selling) is also what keeps casual competitors out. A market that punishes shortcuts and rewards patience is one where a committed builder can win and then defend the position. The difficulty is not a reason to avoid the niche, it is the reason the niche is worth owning. When you find a vertical where the barriers are real (regulation, trust, an unglamorous sales motion), the same walls that slow you down will keep the next person out once you are inside.
:::

In a regulated vertical, the data class is the real product spec


Selling Security Where SaaS Cannot Follow

Why AISafe ships into corporate networks and air-gapped deployments, and what that choice does to the company

I spent years as a security researcher and CTF player, which is a polite way of saying I spent years diving headfirst into the hardest subjects to find ways to exploit them. These days I run AISafe Labs and ship [AISafe](https://aisafe.io), a security product. The part that shapes everything is where we sell it: not as a SaaS anyone can sign up for, but into corporate networks, regulated industries, and air-gapped deployments, the places where running someone else's cloud service is simply not an option.

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

When I took the floor at Indie TM #7 in Timisoara, I did not bring a pitch. I brought a question: how do you price an on-prem deployment? The product works. What I had not figured out was what it should cost to put it inside a customer's own network, behind their own compliance boundary, with their own audit trail. The room had concrete answers on the pricing math, but the more interesting conversation, for me, was everything around that question: why this market, why this background, and what selling into it does to the company you build.

## The constraint is the moat

Most security tools today run as SaaS, because it is cheaper and faster to build. That model works beautifully right up until your customer is a corporation that wants the tool inside its own four walls: its own network, its own compliance boundary, its own audit trail. For a SaaS competitor, that requirement is a wall they cannot climb without rebuilding their whole company. For us, it is the front door. We sell into the market where running as a SaaS is not an option, and the exact constraint that makes the work harder is the same constraint that keeps the easy competitors out.

:::advice{slug="the-constraint-is-the-moat" category="business" person="fineas-silaghi" title="Choose the market where SaaS competitors cannot follow"}
AISafe sells into corporate networks, regulated industries, and air-gapped deployments, environments where running as a SaaS is simply not an option. Most security competitors are SaaS-only because it is cheaper and faster to build, which means they physically cannot serve a buyer who needs the tool inside their own network and compliance boundary. Fineas treats that requirement not as a limitation to apologize for but as the moat itself: the constraint that makes the product harder to ship is the same constraint that locks the convenient competitors out. When a market punishes the lazy approach everyone else takes, being the one who does the hard version is the whole advantage.
:::

## Building security from an attacker's eye

I did not arrive at security through theory. I arrived through years of breaking things, of diving headfirst into the hardest subjects specifically to find how they could be exploited. That offensive instinct, the CTF habit of asking "where does this fall apart," is not a detour from building a security product, it is the foundation of it. When you have spent your career attacking systems, you know exactly which assumptions a defender quietly makes and which ones an attacker will walk straight through. That background shapes AISafe far more than any feature checklist could, because the product is built by someone who has spent years on the other side of it.

:::advice{slug="build-security-from-an-attackers-eye" category="product" person="fineas-silaghi" title="Build the security product from an attacker's eye"}
Fineas came to AISafe from offensive security: a researcher and CTF player whose habit was to dive into hard systems and find ways to exploit them. Building a security product on top of that background is an advantage, because the person designing it already knows which assumptions break under a real attack and which ones an attacker walks straight through. Founders who only ever read the documentation tend to protect against the threats they can imagine; founders who spent years attacking understand the threats that actually get used. If your edge is knowing how to break something, the strongest product you can build is the one shaped by that exact knowledge.
:::

## You are selling to procurement, not just the engineer

In a SaaS world the buyer and the user are often the same person clicking "start free trial." Selling into corporations is not like that, and the room made it concrete when the pricing conversation turned to budgets. A corporation of a certain size already has a budget line for tools in our category and a procurement team that is used to spending it. The people who decide are not only the engineers who would run AISafe; they are the procurement and compliance functions that care the tool stays inside their own network, respects their compliance boundary, and leaves a clean audit trail. They speak the language of risk, budget, and control rather than features, and learning to sell to them is a completely different skill from impressing the person who will actually use the software.

:::advice{slug="the-buyer-is-procurement-and-compliance" category="distribution" person="fineas-silaghi" title="Sell to procurement and compliance, not just the end user"}
For AISafe, the people who decide are not only the engineers who would run the tool; they are the procurement and compliance functions that sign off on it. The room made the point concrete on pricing: a corporation of a certain size already has a budget line for your category and a procurement team used to spending it, and those gatekeepers care that the software stays inside their network, respects their compliance boundary, and produces a clean audit trail. Fineas treats them as the actual customer, which means the pitch has to satisfy people who never touch the product but control whether it ships. When you sell into the enterprise, design the demo for the user and the paperwork for procurement, because both have to say yes.
:::

## The support reality reshapes the whole company

Here is the part that surprised me most, and the thing that turned a pricing question into a company-design question. Once your software lives inside a customer's network, you lose almost everything you take for granted in SaaS. No live logs without a ticket. No quiet hotfix without their change window. No telemetry at all unless you negotiated it into the contract. That changes far more than a price tag. It changes how you staff support, how you write the software so it can be debugged blind, how you ship updates, and how patient your whole engineering culture has to be. The on-prem support reality is not a line item you bolt on at the end, it is a force that quietly redesigns the company around it.

:::advice{slug="let-on-prem-support-reshape-the-company" category="business" person="fineas-silaghi" title="Let the on-prem support reality reshape the whole company"}
When AISafe runs inside a customer network, Fineas loses live logs, the freedom to hotfix, and any telemetry he did not contractually negotiate. Beyond what that does to the price, it reshapes how the company is built: support has to be staffed for blind debugging, the software has to be written to be diagnosable without a live connection, and the whole engineering culture has to absorb slower, more deliberate releases. Founders selling on-prem should treat the support model as an architectural and organizational decision, not only a pricing input. The way you will have to support the product after the sale should influence how you build the product and the team long before the first contract is signed.
:::

## Bring the question, not the pitch

I want to be honest about how that evening actually went, because it is the real lesson. I did not stand up with a deck and a closing line. I stood up with the one thing I genuinely had not solved: how to price an on-prem deployment when the product already works. Putting that unfinished question in front of a room of people who had shipped to enterprise customers got me two sharp answers that I would have circled for weeks on my own. The instinct to only present what is polished is exactly backwards. The polished parts do not need the room. The unsolved one does.

:::advice{slug="bring-your-hardest-question-to-the-room" category="mindset" person="fineas-silaghi" title="Bring your hardest unanswered question, not a polished pitch"}
At Indie TM #7, Fineas took the floor with a question rather than a pitch: how do you price an on-prem deployment when the product already works? Because he led with the thing he had genuinely not solved, the room full of people who had shipped enterprise software handed him two concrete answers instead of polite applause for a demo. The reflex to present only the finished, impressive parts wastes the room, because the finished parts do not need help. Walk in with the single hardest open question you have, and let the people who have already been where you are going do the part you cannot do alone.
:::

## What the pricing question was really about

I left the meetup with the pricing math I came for, but the bigger takeaway was that none of these threads are separate. Choosing the market where SaaS cannot follow, building from an attacker's background, selling to compliance, and designing the company around blind support are all the same decision seen from different angles. The on-prem price tag I still had to finish working out is just the most visible edge of a company shaped, top to bottom, by selling security exactly where the easy competitors are not allowed to go.

Choose the market where SaaS competitors physically cannot follow you

A security product built from an attacker's eye knows where defenses break

The buyer is procurement and compliance, not just the engineer who runs it

An on-prem support reality reshapes the company, not just the price

Bring your hardest unanswered question to the room, not a polished pitch


Pace: Building the Tool That Makes the Right Interview the Easy One

Why structured interviews win in the research and lose in practice, and how Pace closes the gap

I came to hiring sideways: computer science and psychology first, then neuroscience and organizational behavior, then five years actually hiring for teams across Europe. The whole time, one thing nagged at me. We know what a good interview looks like, and almost nobody runs one. [Pace](https://hirewithpace.com), the first product from [Human Nature](https://humannature.earth), is my attempt to fix that.

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

## The gap between known and done

Structured interviews (the same questions, the same rubric, the same scoring across every candidate) are the single most validated predictor of on-the-job performance in the entire hiring research literature. And almost nobody runs them: not the agencies, not the startups, not big tech when you scratch the surface. I could not reliably run one myself under time pressure, even knowing exactly what it should look like. That gap, between the practice everyone agrees is right and the thing people actually do, is the product.

:::advice{slug="make-the-right-thing-the-default" category="product" person="flavius" title="Encode the best practice so the right path is the easy one"}
Everyone agrees structured interviews work, and almost nobody runs them, because doing it right is inconvenient under pressure. Pace closes that gap by building the framework into the workflow, so the structured interview becomes the path of least resistance instead of a discipline you have to summon. The richest product territory is any practice that experts endorse and operators skip because it is annoying: automated tests, double-entry bookkeeping, security keys, structured interviews. Build the tool that makes the correct thing the easy thing, and the onboarding pitch writes itself.
:::

## Automate the tax, not the judgment

The AI part of Pace is not a chatbot that decides who to hire. It runs beside the interviewer (a Chrome extension alongside Google Meet, with picture-in-picture and real-time transcription) so that by the end of the call the scorecard is mostly pre-filled and the recruiter just edits and signs off. I estimate it saves about 40 minutes per interview: scheduling, note-taking, write-ups, scorecard alignment. The human still makes the call. The machine removes the operational tax around it.

:::advice{slug="automate-the-tax-keep-the-judgment" category="product" person="flavius" title="Automate the operational tax, not the human judgment"}
Pace does not decide who gets hired; it removes the 40 minutes of note-taking, write-ups, and scorecard wrangling around each interview so the human can focus on judgment. For tools that sit on high-stakes human decisions, that line matters: automate the busywork that surrounds the decision, and leave the decision to the person. Buyers trust a tool that makes them faster far more than one that tries to replace their judgment, and the busywork is where the real time is lost anyway. Find the operational tax around the decision and kill it, but keep your hands off the decision itself.
:::

## Two axes, not one number

The framework Pace encodes is a two-part model from organizational psychology: every candidate 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 fundamentally different decision from one who does the opposite, and collapsing them into a single score is where most hiring processes quietly fail. Inside each axis, the emphasis is on problem-solving over memorized domain knowledge, because the people who win on trivia tend to underperform in the actual work.

:::advice{slug="separate-performance-from-fit" category="mindset" person="flavius" title="Score interview performance and job fit as separate axes"}
Pace scores every candidate on two independent axes: how they performed in the interview, and how well they fit the role. A strong performer who is a poor fit and a weak performer who is a great fit are different decisions, and averaging them into one number erases exactly the information you need. Whenever you are evaluating something multi-dimensional (a hire, a feature, a deal), resist the single composite score. Keep the axes separate so you can see the trade-off you are actually making instead of hiding it inside an average.
:::

## The adjacent product is a trap

While I was demoing Pace, I sketched a second idea: an automated code-assessment layer downstream of the interview, with repository integration, vulnerability scanning, AI-filtered results. The room's response was immediate and correct: do not ship it until Pace has paying customers. The adjacent product always looks more interesting than the one you actually need to close this quarter. That is precisely why it is dangerous.

:::advice{slug="finish-product-one-first" category="product" person="flavius" title="Finish the first product before chasing the adjacent one"}
Mid-demo, Flavius floated an exciting second product (automated code assessment) and the room told him to bury it until Pace has paying customers. The adjacent idea always looks more appealing than the one in front of you, because it is unspoiled by the boring work of actually closing customers. That appeal is the trap: every hour on product two is an hour product one does not get, and product one is the one that has to pay the bills. Write the second idea down, then go back to making the first one sell.
:::

## Be the best for one vertical

The sharpest challenge was about focus. Who is Pace for: internal HR, agency recruiters, hiring managers doing their own hiring? The room pushed me to go narrower still: be the best possible tool for technical interviews specifically (code tasks, system-design prompts, engineering panels) rather than an acceptable horizontal tool for every kind of role. Being the best product for one vertical beats being a tolerable product for all of them.

:::advice{slug="win-one-vertical-not-all-roles" category="business" person="flavius" title="Be the best tool for one vertical, not an acceptable one for all"}
Pace could try to serve every kind of hiring, or it could be the unmistakably best tool for technical interviews and own that vertical completely. A horizontal tool that is acceptable everywhere loses to a vertical tool that is excellent in one place, because the buyer in that place feels it was built for them. Narrowing the target sharpens the features, the copy, and the demo all at once. Pick the one vertical where you can be the obvious best choice, win it, and expand from a position of strength rather than spreading thin from the start.
:::

Encode the best practice so the correct path is the easy path

Automate the operational tax, never the human judgment


Building Retently to Last, Not to Spike

How a bootstrapped customer-feedback SaaS treats longevity, customer trust, and independence as the real strategy

I run [Retently](https://www.retently.com), a customer feedback platform. It measures NPS, CSAT, and CES, collects reviews, and turns the raw responses into insights for Ecommerce stores and B2B SaaS teams. It is bootstrapped, profitable, and has been running for more than a decade. I have never raised money and never chased a launch-week spike. The thing I am most proud of is unglamorous: it is still here, customers still trust it with their feedback program, and it keeps getting better.

Retently was not where I started. I built and sold a previous company, Noction, and afterward went looking for the next thing. The customer success category was just taking off then, with companies like Gainsight and Totango defining it, and I wanted in. I chose to enter through the piece I could do exceptionally well rather than the whole sprawling suite: measuring how customers actually feel. Retently began as an NPS tool and grew into a full feedback platform spanning NPS, CSAT, and CES, focused squarely on Ecommerce and B2B SaaS rather than trying to become another all-in-one customer success platform.

## Win a focused lane, not the whole suite

Entering a category that funded incumbents were racing to define, the instinct is to match them feature for feature. I went the other way. Instead of building a sprawling customer success suite I could never out-resource, I went deep on the part every one of those teams needs and few do really well: the measurement layer. NPS first, then CSAT and CES, done properly for Ecommerce and B2B SaaS. A focused product that nails one job beats a broad one that does ten jobs adequately, and that edge is sharpest when you are bootstrapped and the people across the table have raised serious money.

:::advice{slug="win-a-focused-lane" category="product" person="grigore-raileanu" title="Win a focused lane instead of matching funded incumbents feature for feature"}
When Greg entered the customer success category, well-funded incumbents were racing to define it, and the obvious move was to match them feature for feature. He did the opposite: rather than build a sprawling suite he could never out-resource, he went deep on the one layer every team in that category needs and few do really well, customer feedback measurement (NPS, then CSAT and CES). A focused product that nails a single job beats a broad one that does ten jobs adequately, and that edge is sharpest when you are bootstrapped and your competitors have raised serious money. Pick the wedge you can be the best in the world at, and let the incumbents carry the cost of trying to be everything to everyone.
:::

## Longevity is the strategy, not the byproduct

Most SaaS advice optimizes for the first eighteen months: the launch, the growth curve, the round. I optimized for year ten. A product that is still standing after a decade has something a new competitor cannot clone by shipping a flashier version next month: it has aged into reliability. Customers have integrated it, trusted it with their feedback data, and built workflows on top of it. That accumulated durability is the asset, and everything else is in service of keeping it strong.

:::advice{slug="outlasting-beats-outlaunching" category="mindset" person="grigore-raileanu" title="Outlasting the category beats out-launching it"}
Greg built Retently to be standing in year ten, not to win launch week. A product that has run profitably for more than a decade earns something a faster competitor cannot copy on demand: it has aged into reliability and trust, customers have integrated it and built workflows on top of it, and that accumulated durability becomes the real moat. Optimizing for longevity instead of the early growth curve looks slow in a market obsessed with spikes, but the company that is still there after ten years, still trusted by its customers, is the one that compounded. Build for the decade, and durability stops being luck and becomes the strategy.
:::

## Independence is a feature customers can feel

Retently is bootstrapped and profitable, which means the people it answers to are its customers, not a board chasing a quota or an investor who wants an exit on a schedule. That independence keeps the product stable and present for the long run. There is no pressure to pivot away from the people who rely on it, and no risk of it being sold out from under them and shut down. A team trusts a feedback platform far more when they know it will still be there next year, run by the people who built it. Owning the business outright is what lets me optimize for the customer's decade instead of an investor's quarter.

:::advice{slug="bootstrapped-answers-to-customers" category="business" person="grigore-raileanu" title="Bootstrapped and profitable means your roadmap answers to customers, not investors"}
Retently is bootstrapped and profitable, so the people it answers to are its customers rather than a board or an investor with an exit timeline. Greg treats that independence as a feature customers can feel: the product stays stable and present, there is no pressure to pivot away from the people who depend on it, and there is no risk of it being sold off and shut down. Teams trust a feedback platform more when they know it will still be there next year, run by the people who built it. Owning the business outright is what lets a founder optimize for the customer's decade instead of an investor's quarter.
:::

## Be the safe place to land when a tool shuts down

When Delighted announced it was winding down, thousands of teams suddenly needed a new home for their NPS and feedback programs. The right response is not to treat that as a windfall to harvest, it is to be genuinely ready to receive those teams: a clean migration path, clear positioning, and the least possible friction for someone who already knows exactly what they need and just lost the tool that did it. Helping a displaced team move without losing their history earns trust that a cold pitch never will. When an incumbent in your category exits, the work is making the switch safe and easy, and the customers follow.

:::advice{slug="help-teams-migrate-safely" category="distribution" person="grigore-raileanu" title="Be ready to help teams migrate safely when a tool they relied on shuts down"}
When Delighted wound down, thousands of teams needed a new home for their feedback programs overnight, and Greg's read is that the right move is to be the safe place to land rather than to gloat over a windfall. A clean migration path, clear positioning, and the least possible friction for a buyer who already knows what they need can move more revenue than any cold-acquisition push, and helping a team migrate without losing their history earns trust a pitch cannot. Watch the incumbents in your category and be ready to receive their customers the moment one exits. Make the switch safe and easy, and the customers follow.
:::

## Value that compounds with use

The longer a customer runs Retently, the more it is worth to them. Years of NPS and CSAT history to trend against, integrations wired into their stack, and workflows their team relies on day to day. I built around the idea that the real value of a feedback platform is not any single screen, it is everything that accumulates on top of it over time. That compounding is good for the customer, because their data gets richer and more useful, and it is what makes the product something teams genuinely stay with for years rather than something they shop around every renewal.

:::advice{slug="value-compounds-with-data" category="product" person="grigore-raileanu" title="A feedback platform's value compounds with the data and integrations built on it"}
The longer a customer runs Retently, the more it is worth to them: years of NPS and CSAT history to trend against, integrations wired into their stack, and workflows the team relies on. Greg built around the idea that the real value of a feedback platform is not any single screen but everything that accumulates on top of it over time. That compounding is good for the customer, whose data only gets richer and more useful, and it is what turns a tool into something teams stay with for years instead of reshopping every renewal. Build for the value that deepens with use, not just the feature that demos well on day one.
:::


Laura: A One-Person Studio Selling a Synth Forever

Why a niche audio plugin is a textbook solo product, and a perpetual license is a promise subscriptions cannot make

I build audio plugins as a one-person studio called [Lost Synapse](https://lostsynapse.store). The first release is Laura, a software synthesizer written in C and C++ on top of JUCE. It is the most different kind of indie product you will see at a meetup full of SaaS founders, and the economics fit one person almost perfectly.

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

## Let the framework do the plumbing

JUCE is the de facto standard C++ framework for audio plugins, the instruments and effects 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. Laura ships as an AU, VST3, and standalone instrument for macOS and Windows, and I did not write that cross-format, cross-platform plumbing myself. That is precisely the work that would otherwise eat a solo developer's entire timeline.

:::advice{slug="let-the-framework-do-the-plumbing" category="product" person="ionut" title="Let the standard framework handle the cross-platform plumbing"}
Laura ships in every major plugin format on macOS and Windows because JUCE, the standard audio framework, handles the brutal cross-format, cross-platform export. Ionut writes the sound once and lets the framework do the part that would otherwise consume a solo developer's whole timeline. In any domain with a mature standard framework, the leverage is to stand on it for the undifferentiated plumbing and spend your scarce time on the part that is actually yours. Do not hand-roll what a battle-tested framework already solves for everyone.
:::

## A promise a subscription cannot make

Laura sells for 69 dollars, one time, with lifetime updates and no telemetry, direct from the site or through Gumroad. That perpetual license is not just a price, it is a promise: one purchase, every new build free, forever. A subscription tool structurally cannot say that. In a market of producers who are tired of renting their tools, "you own this and the updates never stop" is a real differentiator, not a discount.

:::advice{slug="sell-a-promise-subscriptions-cant-make" category="business" person="ionut" title="A perpetual license is a promise no subscription can match"}
Laura is a one-time 69 dollar purchase with lifetime updates and no telemetry, and that perpetual license is itself the pitch: own it once, every future build is free, forever. A subscription product cannot structurally make that promise, which means it is a differentiator you get for free by choosing the model. When your audience is tired of renting (creative tools, developer tools, anything with subscription fatigue), perpetual ownership is not money left on the table, it is a competitive weapon. Sometimes the pricing model is the marketing.
:::

## The moat is taste, not engineering

It would be easy to assume the hard part of a synth is the engineering. It is not, or not only. The moat in audio software is taste and DSP craft: a recognizable sound and a brand that producers trust. Anyone can wire up oscillators; very few can make them sound like something people want to reach for. That is where the durable advantage lives, and it is the part no framework and no competitor can copy.

:::advice{slug="compete-on-taste-not-tech" category="mindset" person="ionut" title="In a craft market, the moat is taste, not engineering"}
The defensible part of Laura is not the code, it is the sound: a recognizable character and the trust producers place in the Lost Synapse name. In creative tools, taste and craft are the moat, because the underlying engineering is increasingly available to everyone. If you compete in a market where the output is judged by feel (audio, design, writing tools), invest in developing a recognizable point of view, not just shipping features. The taste is the part that compounds and the part nobody can fork.
:::

## Scope one instrument well

Laura is pitched at sound designers who would 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. That is a deliberately bounded instrument, not a do-everything synth. One well-scoped product that a specific kind of user reaches for beats a sprawling one that tries to be every synth at once.

:::advice{slug="scope-one-well-made-thing" category="product" person="ionut" title="Scope one well-made instrument, not a do-everything synth"}
Laura is four oscillator engines, one signal path, a mod matrix, and one delightful "roll the dice" feature, aimed at a specific kind of sound designer. It is deliberately not a synth that tries to do everything. A single, well-scoped product that one type of user reaches for instinctively beats a feature-maximal one that serves no one in particular. Decide exactly who the tool is for and what the one delightful thing is, then resist the urge to add everything. Focus is what makes a solo product feel finished instead of thin.
:::

## The channels already exist

I do not have to build an audience from scratch. The distribution channels for audio plugins already exist: marketplaces like KVR Audio and Plugin Boutique, plus YouTube and the producer communities where people discover and demo instruments every day. My job is to show up where producers already gather, not to invent a new place for them to find me.

:::advice{slug="use-the-channels-that-already-exist" category="distribution" person="ionut" title="Use the distribution channels that already exist"}
Ionut does not need to build an audience for Laura from zero, because the audio-plugin world already has its gathering places: KVR Audio, Plugin Boutique, YouTube demos, and active producer communities. The distribution work is showing up where the buyers already are, not manufacturing a new channel. Before you assume you have to grow your own audience the slow way, check whether your niche already has established marketplaces and communities. Plugging into existing demand is far faster than creating it, and most mature niches have more of it than newcomers expect.
:::


DataDriven: Reading Every Public Tender in Romania, Alone

How an ex-Microsoft engineer turned burnout into a solo company that crawls 10,000 sources, OCRs tender documents on a gaming GPU, and gets 300 firms to pay for the result

I spent twelve years as a developer at Microsoft, two of them in the US on the Bing team. In 2021 I burned out and quit. In 2023, with zero experience as an entrepreneur, I founded a company and launched [DataDriven](https://www.datadriven.ro), a platform that monitors public tenders across Romania. Today it crawls more than 10,000 sources daily, reads the actual tender documentation with an OCR pipeline I run on a gaming GPU in my office, and serves over 300 paying firms at around 27,000 lei in monthly recurring revenue. I still work alone, and that is not an accident.

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

## An uncle lost in SEAP

The idea came from watching my uncle, a real estate appraiser who worked on public procurement contracts. He would spend hours inside SEAP, Romania's electronic public procurement system, because the interface gave him six different menus where a tender relevant to his business might be classified. For him there was one primary category where his work obviously belonged, but the authorities filing the tenders did not always agree. So he searched all six, every day.

It got worse after the search. To download a tender's documentation you receive a .p7s file, a cryptographically signed wrapper that Windows does not open. The standard move, for him and for everyone else in the industry, was to google "p7s open" and land on some piece of trialware. This is the daily reality of the people who sell to the Romanian state.

I did the obvious engineer thing: I wrote a script that watched for new tenders in his domain, crawled the data in Azure, and emailed him whatever appeared. That script was the seed of the company.

## A company of one, on purpose

When I decided to build a business, I decided to build it alone. After the burnout I wanted to eliminate human contact from my working life, bluntly put. No cofounders, no meetings about meetings, nobody to negotiate the roadmap with. I wanted to build the application exactly the way I saw fit.

:::advice{slug="solo-founder-by-design" category="mindset" person="mihai-negrea" title="Design the company around the life you need, even if that means no cofounders"}
Mihai came out of a burnout at Microsoft with a hard constraint: he needed to remove obligatory human contact from his working life for a while. So he designed the company around that constraint, no cofounders, no employees, full control over every product decision. The standard advice says find a cofounder, split the load, hire early, but standard advice optimizes for growth, not for the founder staying functional. A company shaped around your actual capacity is one you can run for years; a company shaped around a template is one you abandon. Constraints like health, energy, and tolerance for people are real inputs to company design, not weaknesses to overcome. Decide what you need to stay in the game, then build the business that fits inside it.
:::

## Launching into silence

I founded the company in 2023 and got into a startup program with Azure cloud credits worth up to $150,000. I burned through about $100,000 of it on the AI scripts that crawled and processed everything. In February 2023 I launched, put up some ads, and waited for the server to crash under the load of eager customers.

The server was fine. Nobody converted. The first paying client arrived in April 2023, two months after launch, at 19 lei per month, roughly four euros. For a long time the business was 40 clients at 19 lei each, which is not a business, it is a hobby with invoices. Until 2025 I barely looked at marketing at all; I was heads-down on the crawler, the data pipeline, and the frontend.

## The customers taught me the product

The shape of the real product came from two kinds of customers.

The first was a security services firm. Their tender-finding process was a browser bookmark folder organized by county, and every day someone opened the town hall websites one by one to check whether a new tender had appeared. That was a salaried human being clicking through bookmarks daily. They became my first serious contract at 2,000 lei per month for complete coverage of the sites they cared about.

The second group was catering firms, the companies behind school meal programs like the old "cornul și laptele" (now "masă sănătoasă"), where town halls receive budgets for sandwiches and related products. Catering is logistically bound to a county: you cannot deliver school meals two counties over. So each firm needs to watch every town hall in its county, and only those. That constraint made the product's value concrete: complete local coverage, zero noise from the rest of the country.

:::advice{slug="replace-the-bookmark-folder-workflow" category="business" person="mihai-negrea" title="Price against the manual workflow you replace, not the software you wrote"}
Mihai's first serious customer was a security firm whose tender discovery process was a bookmark folder organized by county and an employee who opened town hall websites every single day. They happily paid 2,000 lei per month for complete automated coverage, a hundred times his 19 lei list price at the time, because the alternative was a salary. The lesson is that software is not priced against its build cost or against other software, it is priced against the manual grind it replaces. Find the customer who is already paying a human to do the thing badly, and the budget already exists; you are not creating a line item, you are shrinking one. Before setting a price, ask what the current workflow costs in hours and salaries, and anchor there.
:::

## Read the documents, not the labels

The deeper I got into tender data, the clearer one thing became: you cannot trust what the authorities write on the tin. The official CPV classification system has around 10,000 subcategories, and misclassification is routine. I have seen food accessories filed under laptops. Titles and descriptions are frequently vague, misleading, or simply wrong.

So DataDriven reads the actual documentation, the PDFs and scans behind each tender, and classifies from the content. I built my own taxonomy of about 180 categories, deliberately down-to-earth, meant to mirror how Romanian companies actually describe their work rather than how a European classification committee does. That is what lets the platform recommend exactly the products requested in a caiet de sarcini instead of shrugging out something generic like "medical equipment."

:::advice{slug="read-the-documents-not-the-labels" category="product" person="mihai-negrea" title="Read the source documents, because official classifications lie"}
Public tenders in Romania carry official CPV codes, a taxonomy of roughly 10,000 subcategories, and Mihai found the labels wrong often enough to be dangerous, including food accessories classified under laptops. So DataDriven ignores the metadata and reads the actual tender documentation, OCRing PDFs and scans, then classifies everything against a hand-built taxonomy of about 180 categories that mirrors how companies really describe their work. That is the product's core advantage: competitors who filter on the official codes inherit the errors, and their users miss winnable contracts. Whenever your product sits on top of someone else's data, ask whether the labels are trustworthy or just convenient. Going to the primary source is expensive, which is exactly why doing it becomes a moat.
:::

## The marketing that finally worked

Google Ads was my first channel, and it mostly bought me branding. Conversion was terrible for a structural reason: people searched for construction work, clicked the ad, and landed on a platform full of tenders they were not eligible for. Public procurement has revenue thresholds, employee counts, and certification requirements, and an ad click cannot check any of them.

Cold email became the channel that actually worked, and the raw material was public data. SEAP exposes who has participated in tenders, who has won them, phone numbers, and activity domains. That is a pre-qualified lead list: these firms already sell to the state, they just find tenders badly. The market is roughly 20,000 firms, so I use Instantly.ai at about $150 per month, plus Google Workspace accounts at around $5 per address, to run multiple sending addresses across several domains with automated warm-up, keeping deliverability healthy at a deliberately limited throughput.

:::advice{slug="cold-email-runs-on-public-data" category="distribution" person="mihai-negrea" title="In a niche B2B market, public data plus cold email beats paid ads"}
Google Ads sent Mihai visitors who could never buy: public tenders have eligibility requirements around revenue, staff, and certifications that an ad click cannot filter for. Cold email inverted the problem, because Romania's procurement system publishes exactly who participates in tenders, who wins them, and how to reach them. A firm that already bids on public contracts is pre-qualified by its own history, so the public record becomes the lead list. With a market of roughly 20,000 firms, a modest cold email setup beats an ad budget: the targeting information ads cannot access is sitting in the open data. Before paying platforms to guess at your buyer, check whether a public registry, license list, or procurement record already names every one of them.
:::

## Escaping the cloud bill

When the Azure sponsorship expired, reality arrived: 2,500 to 3,000 EUR per month across Azure Search, Cosmos DB, OpenAI, and storage. For a business then doing about 1,500 EUR in MRR, that is not a cost structure, it is a countdown.

The migration happened in pieces. Azure Search, at about $500 per 16GB instance and two instances for availability, became self-hosted Elasticsearch. The web backend moved to Hetzner. Storage moved to Hetzner's S3-compatible object storage, after I discovered what egress and ingress really cost: my pipeline downloads documentation from SEAP, OCRs it, re-uploads it to storage, and serves it to processing jobs and users, and all that shuttling produced surprises like a 700 EUR ingress line item in a single month. For overflow, when my local infrastructure has downtime, I spin up Azure Batch Low Priority instances for a few hours at a moderate hourly cost. The target architecture is three dedicated Hetzner servers, one each for Elasticsearch, MongoDB, and the web stack, plus temporary cloud instances when needed.

The move I expected to dread, Cosmos DB to MongoDB, took two to three days. I had Claude build a query translation layer, then ran Cosmos and the new Mongo layer in parallel with automated validation comparing results until they reached parity. Only then did I cut over.

:::advice{slug="use-ai-to-derisk-a-database-migration" category="product" person="mihai-negrea" title="An AI translation layer can shrink a database migration from months to days"}
Migrating from Cosmos DB to MongoDB is the kind of project that haunts a solo founder, so Mihai turned it into a verification problem instead of a rewrite. He had Claude build a translation layer for his queries, then ran the old Cosmos path and the new Mongo path in parallel, with automated validation comparing outputs until the two systems agreed on everything. Once parity held, the cutover was boring, and the whole thing took two to three days. The pattern generalizes beyond databases: when replacing a load-bearing component, do not aim for a heroic big-bang rewrite, aim for a shim that lets old and new run side by side while machines check the diff. AI assistants are unusually good at generating exactly this kind of mechanical translation code that nobody wants to write by hand.
:::

The other half of the cost story is OCR. Azure Document Intelligence became Tesseract plus my own classifiers that validate output quality, running on an RTX 3090 with 24GB of VRAM sitting in my office, chewing through about 1,500 pages per hour. The office has solar panels that cover both the machine and its cooling, so the marginal energy cost is roughly zero, while the same GPU capacity in the cloud would be prohibitive. Last month the entire Azure bill was down to $1,500, and it keeps falling.

:::advice{slug="watch-the-egress-not-the-compute" category="business" person="mihai-negrea" title="Cloud egress, not compute, is what eats a data-heavy product's margin"}
Mihai's Azure bill was not dominated by the compute he had planned for, but by data movement he had never priced: documents flowing from the procurement system into processing, into storage, back out to jobs and users, culminating in a 700 EUR ingress charge in a single month. Hyperscaler pricing makes exactly this traffic expensive while keeping headline compute prices attractive, which is why his migration to Hetzner dedicated servers and S3-compatible storage, plus a self-hosted OCR pipeline on a local GPU, cut a 2,500 to 3,000 EUR monthly burn to a fraction. If your product's core loop is moving files around, model the traffic before choosing infrastructure, because the cloud's convenience premium applies to every gigabyte, every direction, forever. Data-heavy products are precisely the ones where owning the pipes pays.
:::

## Thirty characters and a running start

The eligibility mismatch that killed my ad conversion also shaped onboarding. At signup I ask for a minimum of 30 characters describing the tenders you care about. The AI turns that free text into monitoring criteria, so your first login already shows relevant tenders instead of an empty dashboard. From there the system watches behavior, thumbs up and down, what you save, where you navigate, and adjusts the filtering, with changes reviewed so nobody gets surprised.

Some users push back on even 30 characters, they want to "just see the app." But without that input the recommendation quality craters on day one, and day one is when they decide whether to stay. I run two open training sessions every week, offer a short personalized setup meeting for free, and send scheduled emails on days 1, 2, 5, and 10 with practical suggestions instead of forcing a first-time tutorial nobody reads.

:::advice{slug="ask-for-thirty-characters-then-do-the-setup" category="product" person="mihai-negrea" title="Ask for thirty characters at signup and do the setup for the user"}
DataDriven's onboarding asks one thing: at least 30 characters describing the tenders you care about. AI converts that sentence into monitoring criteria, so the first login shows relevant results instead of an empty dashboard and a configuration wizard. Behavior then tunes the filters automatically, thumbs up and down, saves, navigation. Some users resist even that single question and want to see the app first, but Mihai holds the line, because without the sentence the first session shows noise, and the first session is where churn is decided. The general principle: do not make users configure your product, make them describe their problem in their own words, then configure it for them. One honest question plus AI setup beats a five-step wizard that gets skipped.
:::

## The numbers

Today DataDriven is at over 300 paying firms and about 27,000 lei in MRR, roughly 5,000 EUR, up from about 1,500 EUR in September 2025. Total revenue last year was around 40,000 EUR. Growth is a steady, unglamorous 2 to 5 percent per month. The company has been profitable on paper for about three months, with minimal salaries for me and my wife, and Romania had a lesson waiting for me there: you cannot repay money you personally lent the company, or pay dividends, until the balance sheet turns positive. It was my own money, and I still could not touch it.

Pricing is public, no "contact us for a quote," which in this market is itself a differentiator. The top plan is 290 lei per month and recently gained API access and an MCP server that customers can point Claude or ChatGPT at. The premium tier picked up its first 3 or 4 subscribers within a month of launching, which at this scale is a signal worth respecting.

:::advice{slug="publish-prices-in-a-contact-us-market" category="business" person="mihai-negrea" title="Publish your prices in a market that hides behind contact forms"}
Every plan on DataDriven has a public price, topping out at 290 lei per month, in a category where the incumbent reflex is "contact us for pricing." For small firms deciding whether to try a tool, the hidden price is a wall: it signals enterprise sales calls, negotiation, and wasted time, exactly what a two-person catering company will not endure. Transparent pricing lets the product sell itself to the long tail the incumbents ignore, and it filters out nobody who was actually going to pay. Mihai treats it as strategy, not cosmetics: his revenue is built from hundreds of small subscriptions rather than a handful of negotiated contracts, and that model only works when the price is on the page. If your competitors hide their prices, publishing yours is free positioning.
:::

What is next is more of the same compounding: an MCP server that turns tender documentation into clean, navigable markdown for the AI assistants my customers already use, an end-to-end agent that prepares complete tender submissions, and a slow expansion across more than 60 European procurement portals, with titles translated to Romanian for Romanian firms first. All of it still a company of one, which is how I designed it, and how I intend to keep it for as long as it keeps working.


Why I Built a Specialized OCR Engine in the Age of ChatGPT

How OCRskill beats general LLMs on the only two numbers that matter: price per call and error rate

Every time I describe [OCRskill](https://ocrskill.com), someone asks the same question: why build OCR at all when you could just hand the image to ChatGPT? It is a fair question, and the answer is the whole reason the business works.

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

## The specialist still beats the generalist

OCRskill turns a document image into clean markdown and pulls structured records out of sources like SEAP, Romania's public procurement portal. For that specific job (reading a document and returning structured data) a purpose-built pipeline is both cheaper to run and, in my own head-to-head testing, more accurate than any general model, including the frontier ones. Reading a scanned form is exactly the bounded, repetitive problem a dedicated OCR engine was built for. A general model is paying, on every call, for a universe of capabilities the task never uses.

:::advice{slug="the-boring-niche-is-the-moat" category="mindset" person="mihai-balint" title="The boring, narrow niche is the moat"}
OCRskill extracts structured data from procurement documents. It is not glamorous, and that is exactly why it is defensible. A narrow, unsexy, high-volume job is one most founders skip while looking for something more exciting, which leaves the field open to whoever is willing to go deep on it. Mihai out-specializes general LLMs on document extraction precisely because he only does that one thing. Boring problems with real, repeated demand are where a solo builder can build something a frontier lab will never bother to beat.
:::

## The economics live in the hardware

The part people miss is where it runs. OCRskill runs on bare metal in an air-conditioned room, not on rented per-call GPUs. That single decision is what lets the unit economics survive at volume. When you rent GPU time by the call, your cost scales linearly with usage forever, and a high-volume API quietly bleeds margin. Owning the machines turns that variable cost into a fixed one you control.

:::advice{slug="own-your-compute-for-margin" category="business" person="mihai-balint" title="Own your compute to keep a high-volume API profitable"}
OCRskill runs on owned bare-metal hardware instead of rented per-call GPUs, and that is the reason the margins hold at volume. Per-call cloud inference is convenient at the start and brutal at scale: your cost grows in lockstep with every request, forever. For a product whose whole job is to be cheap per call and run constantly, owning the compute converts an unbounded variable cost into a fixed one. If your product's economics depend on doing one expensive operation millions of times, model the bare-metal version before you assume the cloud is cheaper.
:::

## The schema is the API

OCRskill's API does not ask you to write a prompt. You describe the fields you want (first name, last name, whatever the schema calls for) and the service returns a typed object that matches. Under the hood, PydanticAI runs an agent loop that keeps talking to the model until the output validates against the schema, so the caller gets structured data instead of a paragraph to parse and pray over. The integration experience is the product. A developer does not want a model; they want clean data showing up in the shape they asked for.

:::advice{slug="developer-experience-is-the-product" category="product" person="mihai-balint" title="For a developer tool, the integration is the product"}
OCRskill's customers are developers, and what they buy is not the OCR model, it is never having to write brittle string parsing again. The API takes a schema and returns a typed object that matches it. For a developer tool, the quality of the integration (how few steps it takes to go from request to usable data) is the actual product, and the underlying technology is just how you deliver it. Spend disproportionate effort on the API surface, the docs, and the first five minutes. That is the part your buyer experiences and the part they tell other developers about.
:::

## SEO for a product whose users are developers

At an earlier meetup I sat through an evening of SEO advice aimed at consumer products and took notes the whole time, then went home with one question: does any of this apply when your customers are other developers? Most of it does. Programmatic pages built around each document type and use case rank for the long-tail queries developers actually search. Even FAQ schema, which feels like a consumer trick, earns rich results for the precise technical questions a developer types before they integrate a tool.

:::advice{slug="programmatic-pages-for-developer-tools" category="seo" person="mihai-balint" title="Programmatic SEO works for developer tools too"}
SEO advice is usually framed around consumer products, which makes technical founders assume it does not apply to an API. It does. Build a page per document type, per use case, per integration, each answering a real question a developer searches before they commit to a tool. Add FAQ schema for the specific technical questions they ask. Developers Google their problems exactly like everyone else, and a tool that ranks for "extract structured data from a PDF" gets found at the moment of intent. Do not skip programmatic SEO just because your buyer writes code.
:::

## When you are cheaper, the price does the selling

There is one more advantage to the specialist-plus-owned-hardware approach: the price itself becomes a sales argument. When OCRskill is meaningfully cheaper per call than handing the same work to a frontier model, I do not have to win the accuracy debate to win the customer. The math does part of the convincing before anyone reads the docs.

:::advice{slug="let-price-do-the-selling" category="business" person="mihai-balint" title="When you are far cheaper than the alternative, price sells itself"}
OCRskill is so much cheaper per call than the general-LLM alternative that the price tag does part of the selling on its own. When you have a real structural cost advantage (a specialized model, owned hardware, a narrower problem), put the comparison front and centre instead of hiding it. A prospect who can see that you cost a fraction of the obvious alternative for the same or better result has most of the buying decision made already. A genuine cost advantage is a marketing asset, not just an accounting one.
:::

A purpose-built model can beat a frontier LLM on a narrow job

Owning your compute is what keeps a high-volume API profitable


Building Church Software Before I Wrote a Line of Code

Why I picked a slow, offline, unglamorous niche, and why distribution is the part I am solving first

I am a software engineer who turned into a sales and marketing generalist, dad of one and co-founder of three, and I have sailed through the Java, WordPress, and Kubernetes seas. The thing I am building now is the least glamorous idea I have ever been excited about: a management app for churches. Congregation management, business operations, the whole administrative stack (schedules, memberships, donations, communications) that churches need and rarely have good software for. I brought it to Indie TM #6 as a concept, not a launched product, and the room did exactly what I hoped it would do. It found the real problem fast, and the real problem is not the code.

## Why a church management app, of all things

Churches are transaction-heavy organizations. They run schedules, track memberships, collect donations, and send communications, week after week, and most of them do it without software built for the job. The niche is real, the demand is steady, and almost nobody is building software specifically for it. That combination is exactly what attracts me. The stack I started with is Laravel and Alpine.js, deliberately boring and productive, because the interesting risk here was never going to be technical.

I want to be honest about the stage: this is a concept in progress. There is no public URL, no launched tool, no customers, no revenue yet. I am writing this from the starting line, not the finish, and that is the whole point of telling the story now.

:::advice{slug="choose-the-unglamorous-offline-niche" category="mindset" person="mile-rosu" title="Choose a hard, offline, unglamorous niche on purpose"}
Mile deliberately picked church management software, an offline, slow-moving, decidedly unglamorous niche, because that is precisely what keeps casual competitors away. Nobody is racing to pitch a church admin tool at a demo day, which leaves the field open to whoever is patient enough to learn the domain. A transaction-heavy organization with no software built for it is a genuine opportunity hiding behind a boring label. The unglamorous niche is not the consolation prize, it is the one a committed builder can own while everyone else chases something shinier.
:::

## The hard part is distribution, and I am solving it first

The moment I finished pitching, the room zeroed in on the thing I already suspected: distribution. Churches do not move fast. Buying cycles are long. Decision-makers are not hanging out on Product Hunt, and they are not going to discover my tool from a launch tweet. If I build the whole product first and then go looking for buyers, I will have spent months on something I cannot easily put in front of the people who would pay for it.

So I am inverting the usual order. Instead of writing the software and then worrying about how to sell it, I am working out the distribution path while the product is still mostly a concept. Who actually decides, how long the decision takes, which channel a church will trust, and what the first reference customer looks like. When the buyer is this slow and this offline, that sequencing is not premature, it is survival.

:::advice{slug="distribution-before-code-for-slow-buyers" category="distribution" person="mile-rosu" title="When the buyer is slow and offline, solve distribution before you write code"}
For Mile's church software, the hard problem is not building it, it is reaching buyers who move slowly, decide over long cycles, and are nowhere near Product Hunt. When the buyer is that offline, distribution cannot be an afterthought you bolt on at launch, because there is no quick launch channel waiting for you. Map the path to the buyer (who decides, how long it takes, which channel they trust) while the product is still a concept, and let that path shape what you build. Writing all the code first and discovering you cannot reach anyone is the most expensive order to do it in.
:::

## One pain point, not the whole suite

My instinct, like every engineer's, was to imagine the full management suite: scheduling, memberships, donations, communications, all of it, beautifully integrated. The room pushed hard against that. Instead of building the entire stack, find one specific pain a church actually feels and solve that first. Billing? Scheduling? Member communication? Pick one and nail it before you so much as sketch the rest.

The risk they kept naming was the one I most needed to hear: building something too generic for a niche that needs something very specific. A church does not want a vague all-in-one platform. It wants the one annoying thing fixed. I genuinely believe in finding one pain point before building the full suite, and saying it is easy. Resisting the suite when you can already picture it is the hard discipline.

:::advice{slug="narrow-to-one-pain-before-the-suite" category="product" person="mile-rosu" title="Nail one specific pain before you build the full suite"}
Mile's instinct was the full church management suite (scheduling, memberships, donations, communications) and the room talked him down to one pain point first: billing, or scheduling, or member communication, solved completely. The biggest risk in a specific niche is building something too generic to be worth switching to, a vague all-in-one that fixes nobody's actual Monday. A narrow tool that ends one real misery gives a buyer a concrete reason to say yes, and a wedge you can expand from later. Decide which single pain you will own, finish that, and earn the right to the suite instead of assuming it.
:::

## Co-design with a friendly church

The most practical advice was about how to get the product right at all. Find a friendly church, one contact who is willing to work with you, and co-design the product with them as a design partner. Do not build in a vacuum and hope you guessed the workflow correctly. Build alongside someone who lives the problem, who can tell you that the donation flow you imagined does not match how their treasurer actually works, or that the schedule they care about is the one I would never have thought to model.

For early feedback, the channels are humble and offline, matching the buyer. WhatsApp groups and local community channels, not a polished beta program. And the people to target are the ones who already handle the tech: the church IT contact, or the volunteer who quietly keeps the website and the spreadsheets running. They are the bridge into an organization that would otherwise be very hard for a stranger to enter.

:::advice{slug="recruit-a-design-partner-to-co-build" category="product" person="mile-rosu" title="Recruit a friendly customer as a design partner and co-build"}
Rather than guess at church workflows from the outside, Mile's plan is to recruit one friendly church as a design partner and build the product alongside them. A design partner who lives the problem corrects your wrong assumptions before they become wrong code: the donation flow that does not match how the treasurer works, the schedule you never thought to model. For early feedback, meet the buyer where they already are, in WhatsApp groups and local community channels, and target the people who handle the tech, the church IT contact or the volunteer keeping the spreadsheets alive. Co-building with one real customer beats a polished product designed for an imaginary one.
:::

## Selling on their clock

There is a deeper thing about this market that I keep circling back to. Trust in a church does not run on my timeline. I can want a fast sale, but the church is going to decide when the church decides, after the people involved have talked it over, vetted me, and felt comfortable. Pushing against that rhythm only signals that I do not understand the buyer. The right move is to sell on their clock, show up patiently, and let the slow buying cycle be a feature of the relationship rather than a frustration.

This is where being a generalist helps more than I expected. I am an engineer who can also sell, which in a market this slow is a genuine edge. I can sit with a church contact and talk about their real administrative pain in their language, then go build the fix myself without a handoff, then come back and adjust it after they have used it. The engineer who only codes needs someone else to find and hold the customer. The salesperson who cannot build needs an engineer to make anything real. Being both, in a niche that rewards patience and a personal relationship, is the unfair advantage I am betting on.

:::advice{slug="sell-on-the-buyers-timeline-not-yours" category="distribution" person="mile-rosu" title="Sell into slow buyers on their timeline, not yours"}
Churches buy slowly, so Mile's sale runs on the church's clock, not his own preference for a fast close. In a slow-moving, relationship-driven market, pushing for speed reads as not understanding the buyer, while patient, in-person presence reads as someone worth working with. The long buying cycle is not a bug to fight, it is the texture of the relationship, and accepting it is part of the qualification. Show up, build the relationship the organization needs, and let the deal close when the buyer is ready instead of when your roadmap wants it to.
:::

## The generalist bet

I do not have a launch to report, a metric to brag about, or a URL to send you to. What I have is a concept I believe in, a clear-eyed read on why it is hard, and a plan that puts the hardest problem (reaching a slow, offline buyer) before the easy one (writing Laravel). At Indie TM #7 I chimed in on a completely unrelated SEO talk to point out a new Romanian law about inspecting mandatory home insurance policies, the kind of slow, rule-bound detail most people tune out. It is the same instinct that drew me to churches: the unglamorous, rule-bound, slow corners of the world are where a patient generalist who can both build and sell can quietly make something nobody else wanted to bother with.

Pick the hard, offline, unglamorous niche on purpose