Why Town Walked Away from Nearly $1 Million in Revenue

1. Guest Background

Jean Denis, Town's founder and CEO, previously served as CTO of Plaid. His perspective in this interview comes from moving between technical leadership and company formation: first deciding which professional workflows AI could transform, then discovering that a working implementation did not settle the business question. After leaving Plaid, he explored business-to-business markets and initially chose tax preparation for small and medium-sized companies.

The attraction was grounded in the workflow. Business returns draw on financial information, lease documents, and other inputs that must be assembled into a structured output. Denis describes conducting technical diligence and concluding that AI could automate the process within the horizon the team was considering. Town then spent a year building the product. In his account, the product worked; reaching and selling to businesses efficiently remained much less certain.

That distinction gives the episode its focus. This is a founder's explanation of a strategic reversal, followed by an argument for a different kind of AI application. Town's subsequent direction centers on email, calendars, and work coordination. The discussion examines how an agent earns adoption, discovers additional useful work, and competes with the model suppliers it depends on. Denis's operating experience makes those questions concrete, while his forecasts and product positions should be read as the judgments of a participant pursuing that strategy.

2. What the Episode Covers

The opening business puzzle is that Town abandoned a product with revenue. Denis reports slightly less than $1 million in its first year and says the team believed a second year could reach $2.5 million to $3 million. The first figure is his retrospective disclosure; the second is a projection. His objection was that the company might not become large enough, quickly enough, to meet its venture ambitions.

Incumbents supplied the competitive clock. They already had customers and distribution, and Denis feared they could automate preparation for those customers faster than Town could acquire market share. Annual purchasing made the race harder. A satisfied customer could recommend the service after filing, when another business had already passed its buying window. Usage, advocacy, and conversion would therefore struggle to reinforce one another continuously.

The decision also involved the team's opportunity cost. Denis wanted broader impact and needed conviction that the opportunity justified employees choosing Town over other jobs. He acknowledges that persistence might have uncovered a solution. Timing nevertheless forced a choice: he describes roughly a month around October 15 when continuing tax and changing direction were both available. Further commitments could bind the company to another year of delivery and leave insufficient capital for a later pivot.

After seriously exploring about four directions, the team returned to requests from its tax customers. They wanted help arranging meetings, remembering their purpose, preparing for them, following up, and drafting recurring email answers. Denis associates the resulting traction with both recognizable demand and models becoming more capable of autonomous work. Email and calendar offered access to externally facing roles such as sales, recruiting, and business development. He also explicitly separates discovering substantial product complexity from establishing a defensible moat.

Town's adoption strategy starts with the person using the product. Denis favors product-led growth and a strong experience before expanding enterprise administration, provided security and privacy foundations are sound. Email and calendar should first demonstrate useful work, such as preparing meetings or updating presentation material. The product then asks for deeper connections, including CRM access. Auditability, restrictions on privileged information, and financial controls must develop alongside that expansion.

Later examples shift attention to the labor required to adopt AI. Denis recounts an island rental business comparing photographs of surfboards and beach buggies to assess damage and deposits. Someone inside the business had experimented enough to build the workflow. He similarly associates Town retention with connecting email, calendar, a key business system, and one valuable custom integration. Town wants to absorb that setup burden. Interviewer Alex adds stories of demonstrations overturning stale impressions of AI; Denis's claim that some computer-use tasks improved from roughly 30% to 90% success illustrates his optimism, but comes without an evaluation method.

3. Core Views: Reasoning, Examples, and Limits

The tax story establishes a useful separation between technical progress and entrepreneurial advantage. Denis's concern was that an entrant's speed in building software might not translate into speed in acquiring customers. An incumbent could use the same technological improvement inside an existing distribution network. Annual buying then lengthened the interval between a successful delivery and the next opportunity to convert its reputation into sales. This explains Town's decision relative to its ambitions. It does not establish that annual services are inherently unattractive businesses, and Denis's admission that continued effort might have worked leaves the counterfactual open.

His description of Town as a “token allocation machine” extends the discussion beyond replacing existing labor. The product should suggest outcomes that computation could produce and let the user choose which are worthwhile. He estimates that meeting-preparation notes could cost about a penny. Alex's account of Snap finding a London dinner missing from his calendar offers a more tangible illustration: it covered email-monitoring work he would not routinely ask his human assistant to perform. The potential market expands when previously neglected tasks become feasible. Alex's personal comfort with that arrangement, however, does not establish an appropriate permission boundary for every organization.

Restaurant purchasing makes the economic argument more demanding. Denis imagines an agent comparing supplier spreadsheets or PDFs containing thousands of items, identifying price increases, and suggesting changes in purchasing. He estimates five minutes to configure the workflow, around a dollar a month to operate it, and occasional opportunities worth hundreds or thousands of dollars. Even eleven uneventful months might be acceptable if the remaining month produces a valuable finding. Those figures are illustrative estimates, not measured customer outcomes. The important proposition is that low operating cost can justify searching for infrequent opportunities. A detected price difference still has to survive practical purchasing constraints before it becomes realized savings.

Personalization is Town's proposed answer to converging capabilities. Denis expects agent systems to become able to perform similar work, making a feature lead harder to sustain. Yet he says models currently generate relatively superficial suggestions when asked what a particular professional should automate. Town therefore identifies heavy users through aggregate metrics, interviews them, and builds shared workflows called routines rather than having staff inspect their underlying data. His account of restaurant templates expanding from about five to fifteen shows how a general product might become locally specific. His ambition extends to one person's multiple roles, including business finance, rental property, and family arrangements. Whether that learning actually lowers the next customer's setup burden remains unproven.

Denis contrasts this approach with FDE customization, in which people enter a business, understand its processes, and build software using AI. He predicts that increasingly automated customization will scale better than this human-led approach. The interview does not provide a comparative cost or delivery study. Nor does it establish that Town's current email-calendar experience is insulated from competition: Denis readily acknowledges that a model lab could choose to reproduce it. His stronger purchasing argument is neutrality, with the application selecting appropriate models and providers across different tasks and modalities. That could reduce dependence on a single supplier, but only if the routing produces reliable results at an acceptable cost.

Context ownership accompanies that argument. Denis treats data, memories, and accumulated business context as assets customers should own. He proposes switching to another product in approximately a day and accepts that easier departure creates commercial risk for Town. This is a product position and target, not a demonstrated migration result. Similarly, his statement that training models is outside Town's business philosophy should not become a universal claim about competitors. He acknowledges that sufficiently large businesses can secure no-training arrangements with labs. The practical distinction depends on what customers can actually retain, export, and reuse.

Agent collaboration exposes an unresolved boundary. Town's internal-CRM concept lets one employee's agent ask colleagues' agents who knows someone on a prospect's finance team. The attraction is eliminating a broadcast message and the wait for people to notice and recall relevant connections. Denis recognizes that privacy requires careful design, but supplies no permission implementation or measured risk. Trusting AI to mediate a request describes a direction; it does not demonstrate that the answer cannot disclose information the requester should never receive.

The closing commerce discussion applies the same attention to incentives. Denis favors a neutral agent funded by its user, rather than one whose recommendations might be distorted by advertisers. Yet he distinguishes unwanted replenishment work from enjoyable discovery: ordering familiar toilet paper and browsing toys are different experiences. Advertising can contribute to the latter. The speakers speculate that automated comparison shopping, coupons, and benefit redemption could weaken supply aggregation and revenue dependent on unused entitlements. Headless retail or retailer-owned agents are possible responses. These are mechanisms worth examining, not evidence that a particular incumbent or business model must disappear.

4. Learning and Application

A founder can apply the tax lesson by keeping two evaluations separate. One asks whether the system can perform the workflow with controllable errors. The other asks how customers will be reached, when they buy, when they recommend, and whether those channels can grow before competitors respond. Historical revenue and future projections belong in different columns. For seasonal products, referral timing deserves explicit attention. The conclusion should depend on the company's intended scale and financing model; Town's decision does not supply a blanket reason to reject low-frequency businesses.

The pivot window suggests a related planning exercise. Identify the next customer commitment that would materially increase delivery obligations, then calculate how much time and capital would remain for another direction afterward. This makes waiting a decision with a cost. It also preserves the uncertainty Denis acknowledges: continuing could work, but another month of observation may commit more than a month of resources.

For an agent product, begin with a result the user can inspect. Supplier-price monitoring is a suitable experiment if it first produces a comparison and supporting evidence rather than changing orders. Track how often it finds something useful, the time required to check findings, operating expense, and savings actually realized. Verify product equivalence and purchasing conditions before acting. Denis's dollar-per-month illustration is a hypothesis to test, while error costs remain relevant even when computation is inexpensive.

Industry templates should face a similar test. Interview users about repeated work, turn a small number of shared problems into routines, and observe whether new customers understand and adopt them with less assistance. Measure setup effort and continuing use alongside the size of the template library. The rental-business story identifies a promising photographic workflow, but decisions affecting deposits warrant review before automation is expanded. One resourceful experimenter does not establish easy deployment across an industry, and Denis's retention observation does not by itself prove which integration caused a customer to stay.

His Canva scenario offers a concrete demonstration pattern: use an existing subscription to create an event poster, let the user review it, then discuss recurrence and brand adaptation. The suggested five minutes and 25 cents are expectations to validate on the actual task. For users whose impressions were formed by older models, a fresh demonstration can make new capabilities legible. Show the output and its remaining weaknesses; neither one successful demonstration nor an unspecified success percentage establishes operational reliability.

Enterprise evaluation should combine useful experience with bounded authorization. Start with the integrations needed for the chosen outcome, then expand only as value and controls become clear. Check logs, spending responsibility, and information access. For cross-employee agent queries, test whether the requester is entitled to the answer, rather than merely whether the answer arrives quickly. Test context ownership through a small migration: determine which data, memories, and rules export, what remains usable elsewhere, and which permissions need rebuilding. The one-day target and no-training position need corresponding capabilities and contractual clarity.

Finally, commerce teams can divide tasks into administration users want removed and exploration they want preserved. Replenishment can emphasize budgets and confirmation rules; discovery can deliberately expose recommendations. Examine whether the agent earns money from the user, advertising, or data used elsewhere, and whether a benefit program depends on customers failing to redeem. This reveals incentive conflicts and vulnerable revenue assumptions. It does not establish how quickly agent adoption will change those economics, so the episode's scenarios should guide experiments rather than become a market timetable.

Source

• Original episode: Why a $1M Startup Wasn’t Worth Building in the Age of AI