Loading page…
A Calendly competitor priced per meeting booked instead of per seat, free to embed for anyone building software, designed to run on a few hundred dollars a month forever
running cost 'a few hundred a month' · portfolio design target of at least $1M revenue per employee. Benchmarks named in the episode: Tally at roughly $4M with a 3-5 person team; his own earlier browser-extension company at 7 people and over $10M.
If your cost is a few hundred a month, nothing stops you being around forever — so the bar for initial success is just existence, while the ambition stays enormous. That is the whole design.
Fewer bars = easier, cheaper, or faster for an AI-assisted solo builder. Editorial judgments based on the case details.
This is a podcast episode about designing one-person software companies that are built to survive indefinitely rather than to win a market. The guest runs Poolside Ventures, writes on product-led sales, was previously CPO at Dealfront, and structures every company he starts around a single constraint: at minimum $1 million of revenue per employee. His history explains the constraint. His first attempts failed because of co-founders — insufficient commitment, or someone getting pulled elsewhere — which frustrated him enough that he decided he could not be dependent on anyone else. He taught himself to code despite a business background, well enough to build a prototype in an era before AI assistance, and used prototypes to attract people or funding. Today, with Lovable and Cursor, he describes himself as unstoppable on that front. His point for people who have not spent two decades doing this: you no longer need a few hundred thousand dollars to reach a first product. You no longer lose one or two years, and a few hundred thousand dollars, just to find out what the thing is. The episode's most valuable section is the idea he killed. Having written a book on product-led sales, he started building a tool for it — product signals, account identification, CRM integration, opportunity qualification — and got quite far, because building is his comfort zone. Then he talked to the market and found two problems: very few companies actually run product-led sales and many had already built internal tooling, so the market was small; and worse, the onboarding resembled a customer-success tool, which is notoriously hard to implement because you need access to so much product data. That means humans, account managers, guided setup — and therefore linear scaling with customer count. He discarded it. His test: can this problem be solved entirely by the product? If not, it does not fit a one-person company.
The launch was deliberately unspectacular. He told people beforehand to expect 10 to 20 signups on announcement day and got 12, and his own summary is that unless you release something everyone has been waiting for, which is rarely the case, not much happens.
The quick-reference card — acquisition channels, replication playbook, risks & traps, and our verdict — is members-only.
Join the Unicorn Club — $5/moCancel anytime, in one clickPaste into Claude Code / Codex and get a working version of this product end-to-end.
Two production-grade prompts per idea — a full build spec and an SEO growth plan — plus 10 tailored build specs a week. Members only.
Join the Unicorn Club — $5/moCancel anytime, in one clickEvery claim traces back to a listed source — open any of them and check the number yourself. The exact words are quoted below, with a timestamp that jumps to the second each figure is said.
“He builds these oneperson companies that are growing fast and they just have the ambition to have at least 1 million revenue per employee at the minimum.”
1:39 · hear it in the video“But we were seven people doing over 10 million in revenue, right?”
24:39 · hear it in the videoData credibility: Unverified, and graded that way. meet.bot discloses no revenue, no customers and no dashboard anywhere in the episode; the single traction figure is 12 signups on announcement day, which the founder volunteers as a deliberately deflating example. The running cost of 'a few hundred a month' and the portfolio target of at least $1M revenue per employee are stated intent, not results. The two supporting revenue figures belong to other companies and are stated by the participants without documentation: Tally at roughly $4 million with a 3-5 person team (stated by the host), and the founder's own earlier white-label browser-extension company at seven people and over $10 million in revenue. A third figure — a build-in-public founder taking a product to '20 million or whatever' — is explicitly hedged by the speaker as a number he cannot remember, so we have excluded it. The guest's surname is rendered inconsistently across the auto-transcript ('Jung', and 'Yang' in a companion episode); his identity is otherwise clear from his book on product-led sales, his prior role as CPO at Dealfront, FunnelFox, Poolside Ventures and the SaaS on the Beach events. The episode is a founder interview on a vendor-adjacent podcast; nothing is audited.
The first dollar is slow to appear in this design, and the reason is structural. Pricing is per meeting booked rather than per seat, and embedding is free, so revenue lags adoption by however long it takes a partner's users to start booking.
Two loops are available and only one is reachable from zero. The obvious one is scheduling's native virality: you share a link, the recipient sees the brand, and enough repetitions later they sign up.
This model is engineered so the quiet stretch cannot kill it.
meet.bot is a scheduling product in the same category as Calendly. He is completely open that this is a red ocean — Calendly is the number one player and scheduling has been absorbed as a commodity feature by most go-to-market and customer-facing tools. His justification for entering anyway is domain-specific insight: he built eight scheduling implementations over the past few years, first at his previous company FunnelFox and then at an agency, and from seeing the problem from that many angles he concluded something was missing that everyone bumps into. Two design decisions differentiate it, and both are pricing or architecture rather than features. First, pricing per meeting booked rather than per user. His reasoning is that people are now thoroughly used to credit and usage-based billing in a way they were not a few years ago, and that if you want scheduling across an entire company you do not want to pay a full seat rate for people who barely use it. Second, API-first with free embedding. Calendly and every other scheduler wants you to visit their scheduling page so you see their brand; he explicitly does not mind if you go straight through the API. Anyone building a product can include his scheduling functionality — his example is someone building in Lovable adding a scheduler for their vertical in a few clicks — at no cost. The comparison point he names is Nylas, which charges builders a fee for embedded scheduling; his approach removes that fee entirely and monetises the meetings instead. His summary of the whole thing: sometimes very little tweaks completely change the model.
Usage-based revenue on meetings booked, with distribution given away free — and it is important to be precise that no revenue figure exists. This is not a business with disclosed numbers; it is a business design. The economics he is optimising for are on the cost side, and this is the genuinely instructive part. Once the product is built, it costs almost nothing to keep running — literally a few hundred dollars a month to be in business. His argument is that a large share of a company's value comes simply from being around long enough that people associate your name with a topic, so that when they eventually need the thing, they think of you and arrive. If your cost base is a few hundred a month, there is nothing stopping you being around forever, even if you have a job. He needs only a few customers to break even. He frames this as a low bar for initial success and an extremely high ambition simultaneously: the low bar just means we are alive and cannot go out of business anytime soon. From there, he does not need to be the most popular tool in the market — he needs his share. The counter-example he gives from his own history is instructive about what that looks like at scale: an early browser-extension company for e-commerce where nobody knew their brand because they were always white-labelled or embedded as an SDK into something that already existed — seven people doing over $10 million in revenue. Brand recognition was irrelevant; distribution through other people's products was everything. The benchmark named for the model working today is Tally, which the host says has a team of roughly three to five people and is at around $4 million.
Partnerships and embedding, chosen deliberately because the classic product-led motion does not work in a saturated market without scale. He explains the trap honestly. A scheduler is inherently product-led — you share your scheduling link, someone sees your brand, and if they need one they sign up. But that flywheel only turns if you already have a lot of users, and getting to that critical mass in a saturated market normally takes a lot of money. So instead of buying users, he gives the functionality away to builders: include our scheduling at no cost, and we monetise the meetings that flow through it. His reference point for why this works is the app-store land grab: whoever was first on the Salesforce AppExchange or the Slack app store grew really big. He is watching MCP servers and GPT apps as the possible next version of that, while being candid that neither has picked up yet — he has MCP servers and does not know who is using them. His honesty about launch is the most useful part for anyone planning one. When meet.bot was ready, they announced it. He told people beforehand he expected 10-20 signups on day one. They got 12. His conclusion: unless you are releasing something everyone has been waiting for, which is rarely the case, not much happens. It is the continuous grind and the continuous optimisation that bring growth in 99 out of 100 cases, and results are always asymmetric — a few things bring most of the growth. He also names the alternative to cold outreach for builders who dislike it: partnerships, in-product virality, and integrations with products that will list your name on their site.
The stack is unremarkable by design; the cost structure is the product decision. He builds with Lovable and Cursor and asks an AI agent for anything he does not know, including infrastructure. His caveat is precise and worth keeping: vibe-coding tools are not yet very good at creating good technical infrastructure, so you still have to ask the right questions to make sure it builds the right way — but he expects that to be solved, because it is a very solvable problem they simply have not got to yet. Running cost is a few hundred dollars a month. That number is doing enormous strategic work: it is what converts an uncertain product into an indefinite option, and it is why he can give the core functionality away to builders for free without endangering the company. His view on where the effort actually goes contradicts the standard ship-fast advice, and it is the strongest argument in the episode. He rejects the old Reid Hoffman line about being embarrassed by your launch: that was true when building took so long you had to start learning immediately and most use cases were uncovered. Now that building is easy and the categories already exist, users expect a certain level of usability, so it matters that you build something genuinely good. You reach 80% quickly with a few prompts; the remaining 20% is where you spend most of your time and where the difference is made — the founder's opinionated view, the obsessions, the attention to how someone arriving on the site actually experiences it. His working rhythm: build phases where he ships the next version properly, then a hard switch to growth mode with roughly one day a week for building and four for messaging, website and distribution.
Copy the cost constraint as a design input, not an outcome. Deciding up front that the company must run on a few hundred dollars a month changes every subsequent decision — no sales team, no human onboarding, no data-integration-heavy product — and it buys you the one thing money normally buys: time. Copy the disqualification test. Ask whether the problem can be solved entirely by the product. If it needs guided implementation, account managers or deep access to a customer's internal systems, it scales linearly with headcount and is not a one-person company. He killed his own on-brand product for exactly this reason, which is unusually good evidence that the test is real. Copy the pricing wedge. In a commoditised category, changing the billing unit — per meeting instead of per seat — is a differentiator an incumbent structurally cannot copy, because they have existing revenue and existing customers to protect. He is explicit that speed and freedom from those constraints, not lower costs, is the real advantage over incumbents. Copy the give-it-to-builders distribution bet: free embedding, API-first, monetise usage. And copy the honest expectation of a launch: plan for 12 signups, not 1,200. Change the assumption that a unique insight is optional. His entire justification for entering scheduling is having built eight of them. Without that, the same plan is a generic clone. His warning is direct: do not go to Lovable and say make me a scheduling solution for this and that — that is not the point. Why is it different, why is there an opportunity now, who are you selling to and how will they use it. Add what he admits he lacks: AI has created no new distribution channel. There is no mobile-2010 moment to ride, so distribution remains the hard part and needs a real plan before you build.
The evidence risk is the headline: meet.bot has no disclosed revenue, no customer count and no dashboard. The only traction figure in the entire episode is 12 signups on announcement day. Everything else is either design intent (the $1M-per-employee target), cost structure (a few hundred a month), or a number about someone else's company (Tally at roughly $4M with 3-5 people, his prior 7-person company at over $10M). We have graded this 🔮 Unverified for that reason, and it is included for the model and the pricing insight, not as proof of income. The competition score is a 5 because it is honestly a 5. Calendly owns the category, and scheduling is a free commodity feature inside dozens of go-to-market tools. Entering means competing against free. The distribution risk is the one he names himself: product-led virality requires scale he does not have, and the partnership strategy depends on other builders choosing to embed him. That is a business built on other people's roadmaps, and every embedded partner can replace him with the next free option or ship their own. The pricing-model risk cuts both ways. Per-meeting billing is a genuine differentiator, but it also means revenue is invisible until volume arrives, and heavy users may compute that a seat licence would have been cheaper. The patience risk is structural rather than accidental. A business designed to survive forever on low costs can also stagnate forever on low revenue, and the low bar for success — we are alive — is exactly the condition under which a founder keeps a zombie product alive for years. He is candid that he is currently in build phases and growth phases and that growth is uncharted territory for him. And the MCP bet he is watching is unproven by his own admission: he has them and does not know who uses them.
The four founder playbooks — first customers, first dollar, the flywheel, the silent stretch — are in the Unicorn Club, on this idea and on all 1,435 others. The story, the numbers, the sources and every later section stay open to everyone.
Join the Unicorn Club — $5/moCancel anytime, in one click