Companies are changing their pricing every six months. Buyers don’t know what they’ll pay, how to budget, or whether all the AI being stuffed into products is creating enough value to justify the cost.

What’s going on?

The market is moving away from traditional seat-based pricing toward usage- and outcome-based models. But we’re stuck in the messy transition: companies are changing their products and business models simultaneously, while customers are being asked to absorb unfamiliar, and often unpredictable, ways of paying.

I’ve been working to figure this out, because we’re launching Candor, a synthetic user research product we’re building at Highline Beta, and we need a business model. That means instrumenting the real costs, researching the market, building a model and putting it in front of potential customers.

Here’s what I’ve learned so far…

Subscribe now

AI Changes the Cost Structure

Classic SaaS had one huge advantage: adding a customer cost almost nothing. Add a seat, print money. That’s why per-seat pricing worked and why margins sat at 80-90%.

AI breaks that. Every action a user takes burns real tokens, so cost scales with usage instead of staying flat. Bessemer pegs AI-first companies at 50-60% gross margins, not 80-90%. Ben Murray, the SaaS CFO, put it well: “If SaaS is about margin efficiency, AI is about value density.”

Two things follow:

1. A flat monthly fee plus a heavy user can mean you lose money on your best customer.

2. Per-seat pricing leaves money on the table when one person with AI does the work of three, and you end up selling fewer licenses.

No surprise seat-based pricing is shrinking (21% to 15% of companies in a year) while hybrid models climb.

I wrote about this in Lean Analytics, Reconsidered. Now I’m living it.

First: Do Your Research

Before I touched Candor’s pricing, I did my homework.

The clearest thing I found is Kyle Poyar’s Growth Unhinged, specifically Manny Medina’s framework for AI agent pricing built from 60+ AI companies. He breaks it into four models: price per agent (the “replace an FTE” model), price per action (consumption), price per workflow, and price per outcome. Each has a different upside and a different way to get you killed. Per-action is transparent but commoditizes you. Per-outcome aligns you best with the customer but is hard to attribute. Here’s a diagram they put together:

a16z has been beating the outcome-based drum for a while too. The most quoted example is Intercom’s Fin, priced at $0.99 per resolved conversation. You pay when it works. Fin was recently acquired by Salesforce for $3.6 billion dollars, so something must have been working! 🤑

I mentioned Kyle Poyar above, but want to highlight his research and writing on this topic:

Do your homework, but recognize that AI pricing is a moving target.

Share

Cost Sets the Floor, Value Sets the Ceiling

I never wanted to price Candor on what it costs to run. Customers don’t care about my token bill. They care about getting sufficient value to justify the price.

But “price on value” is only half the battle. Here’s the fuller version I actually worked with: cost sets the floor, value sets the ceiling, and customers tell you whether you got it right.

• Cost is the floor. A Candor interview costs me around $2.50 all-in. I can’t price below that. But cost doesn’t decide the price. It just tells me how low I can’t go.

• Value is the ceiling. If a study saves someone days of work and stops them from shipping the wrong thing, it can be worth thousands of dollars to them. Maybe more. But that value has to be proven. And it may not come in one study through Candor, it might be several. Ultimately, people will pay what they think it’s worth, so value is the top of the band.

My job is to pick a number above the floor and below the ceiling, then watch what people actually do. Behavior is the referee. You don’t really know if you read the value right until customers buy, use, upgrade, or churn.

One caveat: I meter interviews, but an interview isn’t the true unit of value. What the customer values is the finished study, the synthesis, the decisions it drives. The outputs leading to the outcomes. The interview is just the cleanest thing to count that still scales with that value. It’s a proxy, and there’s risk in confusing the proxy for the value itself.

Candid about Candor

Here’s what I landed on to start:

• $75/month for the platform and 5 active project slots

• $7 per automated interview

• $10/month for each additional slot beyond the first five

This is the Standard plan, publicly available on the pricing page.

A project is one audience: ~24 grounded synthetic personas you can interview as many times as you want. One interview is one automated conversation with one persona. Auto-interview a 24-persona audience and that’s 24 interviews, so $168 on Standard.

The interviews are where the cost and the value (for the most part) both live.

Generating an audience has a real token cost (covered by the monthly fee), but it’s the interviews, especially re-interviewing the same personas, that rack up usage.

That’s the whole reason it’s per-interview. If I fold unlimited interviews into a flat fee, a power user running hundreds of them would torch my margins. The alternative is guessing usage and stacking tiers (Standard, Pro, Enterprise) with overage math on top. I wanted to keep it simple.

The project slots keep the base fair. Five projects are included. Archive one (it stays viewable) to free a slot, since an idle project costs me nothing. Even if someone spins up all five on day one, there’s still a little margin in month one and more every month after, because audience & persona generation is a one-time hit. Extra slots at $10/month might lose me a bit up front and pay off later.

So Candor is a hybrid: a low platform fee for access, plus consumption pricing on the one unit that carries both cost and value.

In Medina’s language, mostly per-action with a small platform base. I’d like to push it toward outcome-based over time, but “we ran a study that changed our decision” is harder to meter than “we ran an interview.” Baby steps.

Your Costs Move Every Time the Model Does

I recently upgraded Candor from Sonnet 4.6 to Sonnet 5. It’s faster and the insights got better, exactly what I want for customers. But it also burns 25-35% more tokens in my testing. That lands straight on my margins.

Every model upgrade is a pricing decision in disguise. Swapping models sounds great in theory, but you have to understand the implications to how your product works and your costs. Quality may not always go up with a new model. Costs may not go up either, but you won’t know until you put the model in and run it through its paces.

In Candor’s case, I was able to absorb the additional token usage in my price (and worked on more robust caching), but costs definitely went up.

Subscribe now

The Tightrope: Inexpensive Enough to Try, Priced Enough to Matter

Price too low and people assume it’s a toy. Price too high and you never get the conversion, so it doesn’t matter how good your margins would have been.

And “too low” isn’t just a vibe. Venture Curator looked at retention across roughly 3,500 software companies and found AI products under $50/month retain terribly: about 23% gross retention, versus 45% in the $50-249 band and 70% (basically healthy SaaS) above $250. Cheap AI doesn’t only look like a toy. It churns like one.

I think part of the reason AI tools are seeing such high churn is because people are making a “build versus buy” decision. If your AI tool is $19.99/month, I gotta believe I can clone it quickly and feel like I’m paying nothing for it.

That’s a real risk for Candor. At $75 my base sits in that middle band, not the safe zone. My bet is that usage pulls effective spend up and ties it to value: a serious user spends well past $75, and every dollar is attached to research they chose to run. The failure case is the light user who pays $75, runs a couple of interviews, and drifts.

On the market, looking cheap isn’t my worry. The synthetic research tools I checked cluster in a $20-80/month self-serve band (Viewpoints, AskRally, Delve, Deepsona), but can scale up easily to $500/month or more. Many of them have “quote-only enterprise versions” as well. I know a couple tools have enterprise licenses in the tens of thousands of dollars range.

At $75/month plus usage, an active Candor account starts self-serve and climbs toward enterprise. If anything the risk runs the other way: a heavy month lands closer to enterprise money than a self-serve buyer expected.

Then I Launched a $0 Plan

Everything I just said argues for having a defined minimum price. So naturally, the next thing I did was launch a free plan. 😜

This came directly from feedback. I put Candor in front of potential customers who don’t run much research. They’re interested and would use the tool now and then, but $75 a month for occasional use tough. The subscription was the barrier, not the per-interview price.

So I’m testing a free plan. It’s really pay-as-you-go: $0 a month, 2 project slots, and you only pay when you run automated interviews. The catch is usage costs more, $10 an interview instead of $7, and $15 project slots instead of $10. I took the money out of the subscription and moved it into usage.

Does that contradict the churn warning? We’ll see. The data on high churn rates is focused on flat subscriptions people forget and cancel. Pay-as-you-go has no subscription to churn out of, and no monthly line item quietly asking “do I still use this?” If a customer goes quiet, I don’t lose revenue, because there wasn’t any until they ran research. The risk isn’t churn, it’s inactivity, and some of that just means they weren’t my customer to begin with.

Note: I’m not convinced the Free plan will survive and make sense for my ICP (Ideal Client Profile). I need to test the ICP more and sharpen it as I go along. The occasional researcher may not be a great customer.

The two plans are designed to quickly sort people. Here’s the monthly bill at steady state, once the slots are generated:

They cross at about 25 interviews a month.

• Below that, pay-as-you-go is cheaper for the customer but Standard is better for me (that $75 does a lot of work at low volume).

• Above it, Standard is cheaper for the customer but a pay-as-you-go customer is more profitable for me ($10 an interview instead of $7).

So a light-research user picks Free, a heavy one picks Standard, and I’m happy either way. The pricing does the sorting.

Ultimately, this is all a test. Synthetic research is still a relatively new concept, and a $0 door might be how people try it, see value, and upgrade. Or it might just pull in free-riders. I don’t know yet, which is exactly why I’m running it live instead of arguing about it in a spreadsheet.

Share

The Free Trial & the Real Cost of Acquisition

Before anyone picks a plan, they get a free trial: one project, one full run. Build an audience, interview it once across all the personas, see a real report. No credit card, no charge.

That trial isn’t free to me. A full run costs about $68 (a 24-persona audience generated and interviewed once, plus synthesis). I eat that on purpose. Synthetic research is easier to show than to explain, so I’d rather spend the compute letting someone watch it work than write another paragraph promising it does.

If they then move to the Free plan and spin up a second audience, that’s another ~$9. So I can be roughly $77 into a customer, in hard costs, before I earn a dollar.

I’ll call that hard-cost acquisition, not full CAC, because it leaves out sales and marketing. But it’s the part people miss when they stare at gross margins. My interviews may run 60-85% margin, which sounds like a healthy business, right up until you remember I paid $68 to $77 up front for plenty of people who’ll never convert. The number that decides whether Candor works isn’t interview margin. It’s what a customer spends over their life versus what it cost to acquire and activate them.

So I’ll be watching the funnel in stages:

1. The cost to get a free-trial signup

2. The % who actually run a study (add ~$68 in costs)

   1. The % who churn and just cost me money 😓

   2. The % who move to Free (add ~$9 in cost to generate a second audience)

   3. The % who move to Standard (up to ~$36 in cost for their extra slots)

On a single-customer basis those hard costs are manageable. Blended across real conversion rates and actual marketing spend, I genuinely don’t know yet. That’s the number I’m most nervous about.

You Can Check Out the Math

I decided to share all the math in a public model you can dig through.

If you’re pricing an AI product, you probably have something similar. Probably more robust. But if my model is helpful to anyone, that’s great.

I also think transparency in the AI world matters. I don’t expect all of Candor’s customers to view the spreadsheet and analyze costs vs. price vs. value, but I don’t need to shy away from it either. The tiers and logic aren’t arbitrary. If sharing the model encourages a broader conversation around Candor, Candor’s pricing and Candor’s value creation, I’m all for it.

Where I Think This Goes

One prediction: we’re going to see real pressure on high flat monthly subscriptions, and a growing willingness to accept usage-based pricing, even when the total bill ends up higher.

People don’t hate spending money. They hate spending money with no line of sight to the value. A $500 flat fee per month with no idea what you got feels worse than $700 of usage where every dollar points at something real. Usage-based pricing, done right, is just honesty about what you used and what it was worth.

If that’s right, the winners won’t have the lowest sticker price. They’ll be the ones that tie price to value so cleanly that spending more feels good, because you got more.

Recommendations for Pricing AI Products

Here are 5 recommendations for pricing an AI product based on what I’ve learned so far:

1. Instrument your costs before you price. You can’t price an AI product you haven’t measured. Know what each action costs you, including the invisible token spend (retries, reasoning, agent loops). If you can’t see it, you don’t know your margin.

2. Find the one unit that carries both the cost and the value, and meter that. For Candor it’s the interview. For you it might be a resolution, a workflow, a generated asset. Price the thing that scales with value, not the thing that’s easy to count.

3. Keep the base low for access, but not so low it churns. Make it easy to start, then let usage pull real accounts above the danger zone (cheap AI churns like a toy). Your heaviest users should be your best accounts, not your worst.

4. Let cost set the floor and value set the ceiling. Price well above what it costs you and below what it’s worth to them, then let customer behavior tell you if you guessed right. Cost is a constraint, not the target.

5. Expect to revisit it. Model costs move in both directions (a better model can cost you more, not less), usage patterns will surprise you, and your first guess will be wrong somewhere. Pricing is a product you keep shipping. Frequently.

Pricing is a product decision now, not a finance afterthought. That’s exactly what’s happening with Candor.

If you’ve priced an AI product, I’d love to know: what did you meter, and what did you get wrong the first time?

For more on Brent, check out his Substack: Growth Recalibrated, a weekly diagnostic for founders, CEOs and product leaders navigating growth inflection points. You can also find him on LinkedIn.

I recently met with a B2B software founder about the challenges he’s facing. The company hit $12M ARR and he believed they had achieved initial Product-Market Fit (PMF) 18 months prior (e.g. net revenue growth of 120%+, shortening sales cycle, rapid growth among “look-a-like” ideal/target customers).

But over the past two quarters, something shifted. The roadmap debates that used to resolve in a single meeting now drag across three. His sales team is requesting features that serve customer profiles he didn’t used to close. When a new hire asks him to describe the ideal customer, he finds himself hedging in ways he didn’t before.

I asked him what he thought was happening, his answer was immediate: “It’s hard to tell if this is normal friction or something more structural.”

That ambiguity is usually the first signal. He doesn’t have an execution problem. His product-market fit is eroding.

Subscribe now

Product-Value Fit and Product-Market Fit Aren’t the Same

Ben has written extensively on Focused Chaos about what PMF actually requires: a product that creates genuine value, customers who pay in some meaningful form, and a repeatable way to acquire more of those customers at scale. That third element is the one most companies underweight. Product-Value fit (the sense that existing customers love what you’ve built) can look a lot like PMF. It isn’t the same thing.

Consider what the full picture looks like when everything is working. This company (offering a B2B infrastructure solution for location services for mobile applications) hit all the right signals: net revenue retention above 120%, sales cycles that collapsed because buyers already had budget and urgency, API usage climbing as existing customers scaled their own products. By any reasonable measure, the system was working.

Then net new customer acquisition stalled. Not because the product declined. Because the company had worked through the initial Ideal Customer Profile (ICP) of fast-growing apps that already needed location services. When that cohort was exhausted, sales cycles expanded again. It wasn’t the team’s fault; they now had to educate cold prospects rather than convert warm ones.

The underlying market also shifted. As Android and iOS embedded basic location capabilities natively, the addressable market for a premium/custom API quietly narrowed. Product-Value fit was intact. The distribution engine needed to reach and acquire new customers at scale had never fully developed.

This is only one pattern. Market exhaustion and platform shifts are real causes of growth stalls, but so are ICP drift, channel saturation, pricing compression, and competitive entry. What the diagnostics below are designed to catch isn’t any specific cause…it’s the moment the system starts losing coherence.

Where PMF Erosion Shows Up First

PMF erosion doesn’t announce itself in revenue or retention. By the time it appears there, it’s been compounding for quarters. The earlier signals show up across three dimensions.

1. Ideal Customer Profile (ICP) drift. As I’ve written about, ICP expansion at this stage is rarely a strategic move. When the original segment starts producing less reliably, the instinct is to cast wider. Sales closes deals with profiles that are “close enough.” Marketing broadens the message to stay relevant. Each individual decision has logic behind it. Together, they represent the original fit quietly giving way to a more diffuse version of the customer the company was built for.

2. Product signal decay. This one is less discussed and harder to see. When a company has genuine PMF, the product team receives a coherent signal from customers: the same pain points, the same use cases, the same feature requests clustering around a clear job to be done (JTBD). As fit erodes and the customer base diversifies, that coherence breaks down. Feature requests start arriving from multiple directions at once because different customer types now need meaningfully different things. The roadmap debates that once had a clear anchor (e.g. what does our core customer need?) start generating multiple legitimate answers. The product is still shipping. What’s decaying is the clarity of what to build and why.

3. Messaging drift. The value proposition that used to close deals gets softer at the edges. Not because the team is less prepared, but because no single explanation covers the range of customers’ needs the company is now selling to. The pitch broadens to stay relevant. Specificity gives way to optionality. Deals still close, but the team finds itself making slightly different arguments to slightly different buyers, with slightly different framings of what the product does. Each version is defensible. None of them is as sharp as the original.

Share

Why PMF Drift Looks Like an Execution Problem

These three signals compound quietly. By the time they show up visibly — longer sales cycles, softer conversion rates, board questions that are harder to answer with confidence — they read as execution problems. Leadership responds with execution solutions: more pipeline, tighter process, a new hire. Each response is reasonable. None of them addresses the underlying cause.

That’s what makes this stage expensive. As one marketplace founder put it to me directly: “If you’re only selling to promoters, your net promoter score is going to be really good.” The surface holds. The erosion happens underneath it. Companies operating in that ambiguity tend to address symptoms for several quarters before realizing and naming what’s actually happening.

The Diagnostic

Three questions cut through the noise faster than any metric.

1. Deal Assessment

Pull your last 20-25 closed deals. For each one, ask:

• Who actually bought it?

• What problem were they solving?

• What triggered the decision to purchase?

Then run the same exercise on the cohort you closed 9-18 months ago. If the buyer profile, problem, and trigger have shifted meaningfully - not dramatically, but meaningfully - the center of gravity has moved.

2. Internal Consistency

Ask your product, sales, and marketing leads separately to describe your best-fit customer today. If you get three substantially different answers, fit has already fragmented across the organization’s mental model, not just the pipeline.

3. Primary Acquisition Channels

Are conversion rates holding or declining? Is the cost to reach a qualified prospect rising? If existing customers are healthy and expanding while new customer acquisition is getting harder, the issue may not be ICP drift at all. It may be that the pool of ready buyers has narrowed and the company hasn’t built the distribution engine to reach beyond it.

None of these is definitive alone.

Together, they tell you whether the original fit is intact, where the erosion is coming from, and whether you’re dealing with:

• a customer-definition problem,

• a product-clarity problem,

• or a distribution problem.

That distinction determines what comes next.

What To Do When You Find Drift

The first and most important step is distinguishing between two very different situations, because they require different responses.

1. Accidental Drift

The ICP or product focus shifted without a deliberate decision to go there. If that’s what the diagnostic reveals, the path forward is to narrow back. Say no to edge cases. Recommit to the original customer profile. Tighten the product roadmap around the core JTBD.

This feels counterintuitive when growth is the goal, but it’s often what restores the coherence that makes growth repeatable. The companies that do this well treat narrowing as a strategic choice, not a retreat. They get more specific about who they serve, sharpen the value proposition around that customer, and let the clarity do the work that activity couldn’t.

2. Deliberate Recalibration

Where the original market is genuinely exhausted, has shifted structurally, or was never as large as it appeared. This is harder, and riskier. The companies that navigate it well make an explicit choice about the next customer: who they are, what job they’re hiring the product to do, and why this company is the right solution. The ones that struggle continue treating the new segment as a slightly adjusted version of the old one, which means the same erosion pattern repeats in a different direction.

In either case, the organizational move is the same: name it explicitly.

When the leadership team can’t agree on whether the drift is accidental or structural, the company will continue operating under different assumptions and every debate from roadmap to Go-To-Market (GTM) to hiring will be harder to resolve than it should be.

And what happened to the startup I referenced at the beginning of the post?

They chose the “deliberate recalibration” path. The core organization stayed focused on serving and expanding existing customers and contracts, while the original founding team was carved out to rapidly discover the next $50M product and market. Structurally, it was the right call. It still produced real tension between the two founders over authority, resourcing, and whose mandate now defined the company, but at least they made a decision and pushed towards it. Time will tell if it was the right one.

Thank you Brent for this great post and deep dive on PMF. People: please go check out Brent’s newsletter.

The short answer is, “yes.”

I’ll share how I use Lovable, Cowork, Claude Code and ChatGPT. But I’m not married to any of them. New or upgraded tools show up regularly, I test them, and I’ll switch when something’s better. The real answer to “which AI tool” is boring and true: use whichever ones you want, because the point is to learn.

I can’t hand you a tidy chart that maps every tool to every job. Those posts are silly and they rot within weeks, because the tools change too fast. You only figure out your own toolkit by building with it, not by reading comparison posts. This one included. (But please keep reading!)

One thing that did help me: stop thinking of these as competitors and start thinking about what each one is really good at removing from your path. Every tool kills a different bottleneck. Lovable kills the time it takes to get something working. Cowork kills the wall between thinking and doing. Claude Code kills the risk of shipping something broken (if used properly). There’s overlap between them, but once you see it this way, “which tool” stops being a loyalty question and starts being a “what’s in my way right now” question.

Here they are, easiest to hardest to learn.

Subscribe now

Lovable: get something real, fast

Lovable is the simplest on-ramp. You describe what you want, it wires up the database, uses built-in LLMs, handles deployment and after a few minutes you’re clicking around a real thing. When a newbie asks me how to start building with AI, I send them here. They’re always amazed (because it’s amazing!)

Don't file it under "toys." I built a complete corporate venture studio builder in two days with it (learn more here). Last year I started building a sophisticated fantasy RPG in it: AI-generated map, thousands of items, hundreds of skills & spells, complex combat rules and more. Lovable does sophisticated work.

The trade is that it makes most of the decisions for you. That’s why it’s fast, and why you learn less. You’re not choosing how the pieces fit. Perfect when your only job is getting something in front of a human.

My most complicated Lovable app is a D&D game

Last year when I first got into Lovable I decided to build a robust fantasy game. It still needs lots of work, but it’s been insanely fun to build.

Some of the cooler features (imo):

• Music that changes depending on the setting

• City builder back-end where you can custom-build specific locations

• Decision paths that allow you to do class specializations

• A complete pantheon setup (courtesy of my old MUDding days)

If you’re interested in trying this out, message me. 😊

Share

Cowork: where thinking and building blur

Cowork is where thinking and building stop being separate activities. I write in it, research in it, build decks and work through analysis in it. That’s the part people know. What surprised me is how much it also builds.

Recently I made a multi-page marketing site for a client (copy, calculators, and more) that started in Cowork. I used it to pull logos off the web, strip their backgrounds, and lay out the pages.

Another recent build: a complete clickable prototype of an enterprise e-commerce product. No database, no auth, just flat files and interactivity, exactly the scrappy prototype you’d otherwise reach for Lovable to do. I ran it through Cowork on purpose, to find the edges. It held up well.

The one thing I don’t do in Cowork is images. I’ve tried, and they’re meh, so I generate those in ChatGPT and drop them in. Different tool, better result, no loyalty required. That’s the whole philosophy in one small task.

ChatGPT for second opinions

Sometimes I get into debates with Claude and need a “second opinion”. So I ask ChatGPT. I find it helpful to get a different perspective, from a different model.

You can use one LLM for most of your work, and use a second LLM as a critic or counterbalance. I know the models are autocomplete machines, but it’s easy to get value from comparing and contrasting their output.

What makes Cowork different from Lovable is reach. It’s plugged into my desktop and Google Drive. It works where my actual files and workflows already live, which means it’s often less about “building an app” and more about killing the twenty context switches a real task usually takes.

Claude Code: correctness, and the real story

Claude Code is the steepest climb, and it can do the most. It’s where things go when I actually believe in them.

Early on it drove me nuts, because it loves to declare victory before the job's done. You ask for a feature, it grinds away, then announces "all set" like an over-eager junior who never checked their own work. Better prompts barely moved the needle.

What fixed it was forcing it to define “done” before it starts. Three to five specific, pass-or-fail checks, written down first. Then a separate agent grades the work against them, one at a time, citing evidence. No scoring out of ten (a “7” just starts an argument with yourself). Pass or fail. If something fails, it stops and tells me which check and why. It doesn’t get to judge its own homework.

It’s important to recognize that you need to put a lot of work into ensuring Claude Code does what you want. Roughly 20 to 30% of my Claude Code time isn’t spent building the product. It’s spent harnessing Claude Code: the commands, the reviewers, the hooks, the rules.

AI hasn't eliminated software engineering. It's moved it upstream. I spend less time writing code and more time designing how the AI writes code. The leverage isn't learning Claude Code. It's teaching Claude Code how you work. Your setup becomes the product.

I put my whole workflow and setup on GitHub and wrote it up here. Every rule in that setup is a scar. Your config ends up reading like a list of mistakes you’ve agreed never to repeat.

Claude Code is wired for more than Cowork. Custom commands, hooks, configuration you build yourself. I've got one that wraps every session, saves my notes, and refuses to quit until my work is safely stored. Claude Code requires that you do more work: connecting the LLM of your choice, setting up the database, deployment infrastructure, etc. That's the price of looking under the hood, and it's worth paying when the thing has to be real.

My most complicated project with Claude Code is Candor.

Candor is a synthetic user research platform. It allows you to create digital personas (with your own data + Web search) and interview them for problem discovery, problem validation, concept testing and price testing. You can interview the personas manually, or have the AI Interviewer Agent do it. Everything is summarized into a comprehensive, actionable report.

Wanna try it? We’re open to beta testers now. It’s great for researchers, product managers, marketers or corporate innovators looking to do more research on a regular basis.

Join our waitlist at https://www.runcandor.com.

Moving between tools

I still prototype quickly in Lovable. It’s the most convenient tool and plenty powerful. But just because you start in one tool doesn’t mean you can’t move to another.

In a few cases, here’s what I’ve done:

1. Start in Lovable.

2. Connect the Lovable project to GitHub.

3. Ask Claude Code to clone the GitHub repo and work with it.

That’s a seamless way to move from a quick prototype to production-grade software, if you want to jump between Lovable and Claude Code.

Here’s my “cheat sheet” (today)

I just spent this whole post telling you there’s no clean answer. And there isn’t. But I want to make this as actionable as possible, so here’s how I split it right now. Use what you can, then outgrow it.

I should point out I use other tools as well, including Claude (chat), Perplexity (web search & research) and a host of others for the software I’m building: Tavily, Sentry, Vercel, Apify, Supabase, GitHub, Resend, Cloudflare, Inngest and more.

The actual point

Six months from now, nobody will care whether you started in Lovable, Cowork, or Claude Code. IMO, they shouldn’t care now. They should care about whether you shipped something useful, and whether you got smarter building it.

The people making the fastest progress aren’t hunting for the perfect tool. They’ve used enough of them to know, in their gut, which one fits the job in front of them. Sometimes that means jumping between three tools in an afternoon. Sometimes it means staying in one for a month. The switching was never the point. The judgment is.

So stop reading comparison posts (yes, this one too) and go build something this week. Which tool should you use? Doesn’t matter. Anything else is procrastination dressed up as research.

What are you going to build?

And yet, when it actually starts happening to you, something strange kicks in. You go quiet. The investor updates slow down, then stop. You stop returning certain messages. You start spending a lot of time alone with your laptop, refreshing dashboards that aren’t going to save you, telling yourself you’ll deal with it once you’ve figured out the next move.

I’ve been there. It sucks. But you can’t hide.

This isn’t a post about how to shut down a company. I’ve written about when to shut down and I’ve picked apart my own failure in detail. This is about something narrower and harder. It’s about what you do with yourself, and with the people who backed you, when the thing you’ve poured years into is going sideways.

Subscribe now

Hiding feels safe. It isn’t.

When things go bad, the instinct is to retreat. Curl up. Go dark. Pretend it’s not happening until you’ve got it under control.

This instinct is exactly backwards, and there’s decent evidence for why.

Avoidance feels like relief in the moment. You dodge the hard conversation, you skip the update, and the anxiety drops for an afternoon. But psychologists who study avoidance coping have found the same thing over and over: ducking the thing you’re afraid of gives you short-term relief and makes the anxiety and depression worse over time. The relief trains you to keep avoiding. The problem keeps growing. (Here’s a decent overview of the research if you want to go deeper.)

Founders are especially exposed. Michael Freeman’s research on entrepreneurs found that mental health conditions touched 72% of the founders studied, with 49% reporting a personal history and 30% reporting depression. That’s far above the comparison group. We are not a population that should be white-knuckling a crisis alone in a dark office.

Read enough founder postmortems and you see the same trap described from the inside. Nancy Hua, who ran Apptimize, wrote that she spent years hiding her struggles from her own team: “This was not fun for me because it was lonely, but I didn’t know another way to operate.”

That’s the thing about hiding. It doesn’t just fail to protect you. It walls you off from the exact people who could help.

Your investors already know

If you raised money, you have a second obligation on top of looking after yourself: you have to be straight with the people who funded you.

There’s an old adage that as soon as the investor updates stop, everyone knows there’s a problem. It’s true. Silence is its own message, and it’s the worst one you can send. It reads as either “things are bad and I’m hiding it” or “I’ve checked out.” Neither builds the trust you’re going to need later.

Rand Fishkin put it well when he wrote candidly about Moz going sideways: “It’s a hard time to be transparent, but to me, that is the most important time to be so. If we shy away from transparency when things are rough, then it’s not really a core value, it’s just a marketing tactic.”

That applies to how you treat investors, your team, and yourself.

Founders need to remember: investors run portfolios. They expect most bets to fail. That’s the entire model. So when your company is the one that doesn’t make it, you are not the disaster you feel like you are. You’re a known, priced-in outcome. A good investor would much rather hear “I’m done, I can’t do this anymore” than watch you disappear.

You don’t owe them an apology. They took a bet. It didn’t work. That’s the job. What you owe them is the truth, on time, even when it’s bad. You took the money. Be responsible for it.

The upside of doing this well is real. When a founder handles failure with transparency, good investors remember. I’ve backed founders who failed and then went on to win, sometimes watching the same investors write cheques two and three times. It happens all the time. Good investors back people. People occasionally fail, but that doesn’t mean they won’t win the next time.

A big part of whether I’d back someone again is decided right at the end, when things are falling apart, by watching how they carry themselves through it.

The flip side: some investors will treat you like garbage on the way down. They’ll talk down to you, go cold, or worse. Those are bad investors, and there are plenty of them. It stinks, but it’s not a reason to start lying or hiding. Be forthcoming anyway. You’ll know you did it right, and the people worth keeping in your corner will notice.

Share

The day I learned investors care less than you think

Late 2009. Standout Jobs was failing. We’d let the employees go. I went to my investors expecting help devising a plan, some type of direction, and what I basically got was, “Do whatever you want.”

I don’t like how they approached it, but I get it. The returns weren’t going to be there, and it isn’t economically rational for a VC to pour time into a company that’s going to lose. They’d moved on.

I remember sitting alone in our empty office, lights off, feeling completely abandoned.

I was depressed. Abandoned, angry at everyone, caring way too much about what other people thought of me. I should have gotten help. I didn’t. I just gutted it out.

I decided not to go quietly. I reached out to a bunch of potential acquirers, aiming to recover whatever value was left. It worked, sort of. We sold Standout Jobs for cents on the dollar. Everyone still lost money and time. But I did what I felt I had to.

Don’t think of that as a playbook. When it’s over, it’s over, and a good investor should help you get to that ending cleanly. I’m not even sure the perseverance was healthy. Part of it was me proving to myself, and I suppose to my investors, that I wasn’t quitting.

I pulled through and moved on. But I’d have traded a lot of that grim solo determination for someone to lean on. I definitely could have used it.

What I’d actually tell you

1. If your startup is going sideways, don’t put your head in the sand. Deal with it, and deal with it fast, for your own sake. The avoidance feels protective. It isn’t. It just lets the problem and the dread compound while you pretend.

2. If you took other people’s money, respect that. Most investors are adults who know the business they’re in, and they lose most of the time. That’s not a license to lie, withhold the truth, or disengage. You took the money. Own it all the way to the end.

3. Get help from people who’ve been there. Other founders with real scar tissue. A therapist. Your family (although in my experience family doesn’t quite “get it”). Failing is isolating by design, and the founder population is already carrying more than its share of anxiety and depression. The Lago founders, writing about scrapping their first product, said the thing that helped most was simply talking to friends a little further along the road: “It was good and refreshing to talk to them.” Don’t go dark. You’ll suffocate in there.

4. Don’t pin your worth to one outcome. Success isn’t all the founder’s doing. Luck plays an enormous role, and timing, market conditions, plus a hundred things outside your control. Failure usually isn’t all the founder’s fault either. Mistakes get made. That’s how this works. A startup dying isn’t necessarily a verdict on the person, unless you ignore it and shut everyone out (include those that supported you), then (as an investor) it starts to feel that way.

5. Everything has an opportunity cost. You are not immortal and Father Time is undefeated. Wasting time is a huge mistake. You are better off admitting defeat, moving quickly through the shutdown and grief, and restarting something new. Maybe you start another company, or join a startup, or take a break. Whichever way you go, I bet you’ll be stronger for it. The lessons learned from failure are real (and often more powerful than the lessons from success), and most founders go through it. But dragging things out, surviving on life support, is not worth it.

Failing hurts. A lot. Spending years of your life, singularly focused, and losing anyway is brutal, and it’s worse when it’s other people’s money on the line because the responsibility sits heavy. I’m not trying to soften any of that. I’m telling you the opposite of what your gut is screaming at you to do.

Don’t hide in your shell. Face it. Tell people what’s happening. And move on (for the better).

We’re still not 100% there. I’m constantly iterating on my workflow and setup.

That’s one of the key lessons learned: expect to spend 20-30% of your time improving your workflow, not writing code for your product.

This work is critical. Without it you’ll be caught in a near-endless loop of prompt-response, prompt-response, prompt-response. At best, you’ll launch cool demos.

If you’re interested in what I’m building, check out Candor: a synthetic user research platform. We’re looking for a few design partners right now. I share more about it here.

This post isn’t for Claude Code vibe coding experts or actual software developers. I’m definitely still learning (a lot), and I’m far from an expert.

Subscribe now

Claude Code declares victory prematurely

The more I worked with Claude Code, the more I realized it was eager to declare things complete, even if they weren’t.

The gap between “the AI says it’s done” and “the thing actually does what I want” is the most frustrating part of building software with an AI agent.

When it works, it’s amazing and you can move faster than ever before. When it declares victory early, it feels like managing an over-eager junior who says “yep, all set” before checking their own work.

Initially, I tried fixing this the obvious way. Better prompts. More detail up front. Robust PRDs. “Make sure you do X and Y and don’t forget Z.” It helped a little. It did not solve the problem.

As fun and easy as it is to prompt Claude Code to do stuff and watch it (partially) work, I knew I needed more process and rigor to build quality software.

The fix: write the test before the work

The real problem was never the prompt. The problem was that nobody defined what “done” meant before the work started. So the AI got to decide, after the fact, whether it succeeded. And it almost always decides yes.

So I flipped the order.

Before Claude writes a single line of code on anything non-trivial, it has to write down what “done” looks like. Not vaguely. Three to five specific, pass-or-fail checks. It’s my task rubric.

If the task is “add rate limiting to our API,” the rubric might be: requests over the limit return the right error, the limit is configurable without a redeploy, internal traffic is exempt, the counter survives a restart, and nothing else in the app breaks. Each one is a yes or a no. No “kind of.” No “looks good.”

Here’s an example task rubric (not for the rate limiting feature):

Once I approve the rubric, Claude Code does the work.

Then a separate step (using a separate sub-agent) grades the result against that rubric, pass or fail, one criterion at a time, with the actual evidence cited. If everything passes, great. If anything fails, it stops. It does not quietly patch over the gap and call it done. It tells me which check failed and why, and we go back and re-plan that specific piece.

I built this as a command I run, called /assess. (In my own setup it's actually a "skill," a slightly more capable cousin of a command, but a plain command file does the same job and is the simplest way to start, so that's what I'll show you below.) The discipline matters more than the tool. You’re just refusing to let the AI be the judge of its own work against a standard it invented after the fact.

You don’t need to be a developer to write commands (or skills).

They’re not code. A Claude Code command is just a markdown file you drop in a folder (~/.claude/commands/), and you write it in plain English. The entire /assess command is about half a page. It says, roughly: read the .rubric.md file, run a diff to see exactly what changed, go through the rubric one item at a time and mark each pass or fail while citing the specific line of code as proof, and if everything passes say so and stop. If anything fails, name which check and why, and do not try to fix it. That's the whole thing. The power isn't in clever tooling. It's in forcing that one honest grading step to exist.

A few things I deliberately kept out:

• No scoring out of 10. A “7 out of 10” invites a debate with yourself about whether 7 is good enough. Pass or fail is honest.

• No letting the AI fix and re-grade itself in a loop. It reports, it stops, I decide. An agent grading and re-fixing itself against a fuzzy standard is how you get a confident mess.

• No inventing the rubric afterward. If you didn’t define “done” before you started, there’s nothing to grade against, and the whole point evaporates.

If you’re not technical, this matters even more. An engineer can read the code and determine whether it’s right. I often can’t. The rubric is how I get a real answer without being able to fully eyeball the work myself. It turns “trust me, it’s done” into “the proof is right here, one line at a time.” When something fails, the failure is specific and useful: not “this doesn’t feel finished,” but “the limit isn’t configurable yet, it’s hardcoded.” That’s a thing I can hand right back, in plain English, and get fixed.

Share

What this actually looks like, start to finish

Let me walk through a real feature, end to end. Say I want to add a CSV export to the persona list in Candor.

I don’t have to run every step by hand. A lot of this is wired into the project’s instructions so Claude Code does it on its own. But this is the full sequence, and the specific commands and skills involved.

1. I describe the feature in plain English. “Add a button to the persona list that exports the visible personas to a CSV.” That’s the whole prompt. In some cases I may write something more robust and include a spec doc or PRD.

2. It investigates before it builds. Because this isn’t a trivial change, Claude doesn’t start writing code. It produces an Investigation Report first: which files it read, what the change touches, who else calls the code it’s about to modify, and what tests already cover it. A small command I use here, /blast-radius, greps the actual importers, callers, and tests of a file or function, so the report is grounded in real output instead of a guess.

3. It writes the rubric. The last section of that report is the task rubric, saved to a file called .rubric.md. For this feature: the button appears only when there are personas to export, the CSV columns match what’s on screen, exporting respects the current filter, large lists don’t time out, and no existing list behavior changes. Five yes-or-no checks.

4. I approve the plan, then it writes the code. I read the plan, not the code. If the plan is wrong, we fix it before a line gets written, which is far cheaper than fixing it after.

5. It runs the build and the tests. Standard checks that the project compiles and nothing obvious broke. For changes that touch sensitive parts of the system, it also runs what we call a smoke test, a more expensive check against the real services. The instructions tell it which kinds of changes require that, so it doesn’t skip it and it doesn’t waste money running it when it isn’t needed.

   

6. It runs /assess. This grades the diff against .rubric.md. Say the “respects the current filter” check fails, because the export grabbed all personas, not the filtered ones. The /assess command catches it, says so, and stops. It does not commit. We re-plan that one piece, fix it, and re-run /assess. Now all five pass.

7. It runs /pre-commit. A broad gate that fires on every commit, built up over time. It scans for the security stuff you never want to ship (hardcoded secrets, a missing permission check), confirms the tests and types still pass, and runs a pile of project-specific checks I've taught it. For Candor that includes flagging when a code change has left one of our help articles out of date, and, when I've touched a marketing page, making sure the SEO basics (sitemap, structured data, an FAQ) are in place before it ships. This time it passes. When it doesn't, it hands me the list to fix first.

   

8. It commits and opens a pull request to our staging branch. Staging is our pre-production environment. The PR merges automatically once the automated checks pass, so I’m not babysitting it.

9. It deploys to staging and I actually click the button. This is the one step no automation replaces. I open the staging site, export a CSV, and confirm it does what I wanted. The rubric tells me the criteria were met. My own eyes tell me it feels right.

10. I run /session-end. First it checks I haven't left unfinished work lying around that the wrap-up could bury. It won't proceed until that's clean. Then it writes a structured entry to a running SESSION_NOTES file: what got done, what's still in progress, the decisions I made and why, and any open questions for next time. It scans that note for anything sensitive, commits and pushes it, and only then clears the temporary workspace the session used. It refuses to clear that workspace unless my work is provably saved on the server first, so wrapping up can never cost me work. The SESSION_NOTES file has become one of the most useful pieces of the whole setup. It lets me break big work across many sessions without losing the thread, and lets me (or Claude) remember what we did weeks ago without re-reading a pile of code. Next time I sit down, Claude reads the recent notes and picks up where we left off instead of starting cold.

Production is a separate, deliberate step. Staging is automatic. The promotion from staging to live is a human decision I make on purpose. The AI never ships to production on its own.

That’s the whole loop. Plan, build, grade, check, ship to staging, wrap up. The feature took one prompt and maybe fifteen minutes of my attention, and I trust it, because every step had a gate that wasn’t “the AI says so.”

Every so often, a deeper sweep

The loop above runs on every feature. There are a couple additional checks I run once in a while. These are deeper sweeps. (The video quality sucks, but the video is epic.)

The first is called /code-watch. It does a lot at once, which is exactly why it isn’t an every-commit thing.

It makes two passes over recent work. The first is a real security and bugs audit, the kind that hunts for the classic vulnerability patterns: injection, missing authorization, leaked data, that sort of thing. The second grades the code against my project’s own quality rules.

Two lenses, security and quality, in one run. It’s slower and more thorough than the per-commit checks, so I treat it as an occasional deep clean rather than a daily habit: after a stretch of riskier work, before a bigger merge, or just every once in a while to catch what slipped through.

The second is called /project-health.

Where /code-watch audits what I've built, /project-health audits how I've configured Claude Code: whether my CLAUDE.md files have quietly bloated, whether I'm missing an obvious command or guardrail, whether the docs still match the actual code. It's the same instinct, one level up. The tools that build the software need maintenance too, and left alone they drift.

Subscribe now

An instruction file that earns its space

A lot of what makes the loop run on autopilot lives in two CLAUDE.md files: one global and one for the project.

Claude Code reads both CLAUDE.md files at the start of every session. They are effectively briefing docs: how we work, what to never do, what the project is.

The global file holds the cross-project stuff: how I want the AI to behave in general, and the “define done before you start” habit that the rubric comes from. It loads no matter what I’m working on. Candor’s project file holds the machinery specific to that codebase: the maintenance protocol that forces an Investigation Report before edits, which changes require a smoke test, which sub-agents to use for reviews, how our branching and deploys work. The project file leans on the global one instead of repeating it.

The temptation with CLAUDE.md files is to stuff everything into them. The trap is that a bloated briefing makes the AI follow instructions worse, not better, because the important rules drown in the noise.

Keep it disciplined with one test for every line: does this shape how the AI thinks, or just tell it what to do?

The “how it thinks” stuff stays in CLAUDE.md and loads every session: behavioral principles, our security posture, the workflow loop. The “what it does” stuff gets moved out and referenced instead of inlined.

For example, Candor’s CLAUDE.md does not contain our architecture write-up, our data schemas, our database schema, or the distilled research that grounds how we model things. None of that is in the file. Instead, the project CLAUDE.md has a short “required reading” section that names those documents and says: before you implement anything in this area, go read these. Claude pulls them in only when it’s actually about to do relevant work, and ignores them the rest of the time.

Same idea for tactical detail like framework gotchas and our UI conventions. Those live in separate rule files that load only when Claude opens a matching type of file, so the front-end rules show up when it’s touching front-end code and stay out of the way when it isn’t.

This isn't something I rigged up. Claude Code supports it directly: a rule file with a short paths: line at the top loads only when you open a file that matches it. The "required reading" pointers work the same way, the documents sit in the repo and get pulled in on demand, not jammed into the briefing.

# CLAUDE.md  (loads every session — short and behavioral)

## How we work
- Before any non-trivial change, write a task rubric to .rubric.md, then run /assess.
- Match existing style. Touch only what the task requires.

## Required reading (pulled in on demand, not pasted in here)
Before working in an area, read the relevant doc first:
- Architecture:  docs/architecture.md
- Data schemas:  docs/data-schemas.md

# rules/frontend.md  (loads ONLY when you open a matching file)
---
paths:
  - "src/**/*.tsx"
---
- Every list needs a loading state and an empty state.
- Validate money as a finite number before storing it.

The result: the always-loaded briefing is short and behavioral, and the heavy detail is one pointer away, loaded on demand. For Candor, that cut the always-loaded instructions roughly in half with no loss of coverage. The deep knowledge is all still there. It just shows up exactly when it’s relevant.

The other thing I’ve learned: treat every rule like it was earned, because it was. Almost every good line in Candor’s CLAUDE.md is a scar from a specific time something broke. The AI truncated a long output once and corrupted a file. Now there’s a rule about output size. A change got shipped from a stale branch and created a mess. Now there’s a rule about how we cut branches. Your instruction file shouldn’t read like best practices from a blog. It should read like a list of mistakes you’ve agreed not to repeat.

Why I didn’t just install someone else’s setup

There are great pre-built workflows out there. Garry Tan, the president of Y Combinator, open-sourced his entire Claude Code setup as gstack, 23 opinionated tools that turn Claude into a virtual startup team. The rubric idea I use came from a framework called SPEAR. My thinking on lean instruction files was shaped by Yanli Liu’s article “The 4 Lines Every CLAUDE.md Needs” and the Andrej Karpathy thread behind it.

I could have just installed gstack and run with it. I didn’t. And I’d push you not to, either.

These aren’t bad. They’re genuinely good. The problem is that grabbing a pile of skills and commands you don’t understand is how you end up with a workflow you can’t debug, can’t tailor, and can’t trust. When something goes sideways, and it will, you’re stuck, because you never understood the system you’re running.

I took the core idea from SPEAR and deliberately modified it to fit my approach. Pass-or-fail instead of scoring out of 10 is my call, and I can defend it, because I worked through why. I read Yanli Liu’s article and fact-checked it against Anthropic’s actual documentation, and several of its specific claims didn’t hold up (it cited hard character limits that don’t exist). The direction was right. The details were wrong. I’d never have known that if I’d just copied it.

Don’t ignore what other people built. Engage with it instead of copying it. I point Claude Code at someone else’s setup, a public repo like gstack or a workflow described in a blog post, and ask it to compare that setup to mine. Where are they doing something I’m not? What gap does theirs expose in mine? Is there an idea worth adapting, and if so, how would it actually fit the way I work? Then we work through the changes together. I get the benefit of other people’s thinking without inheriting a black box, because every change that lands in my setup went through my understanding first.

Doing this work yourself is valuable precisely because you learn how things work. And if you’re a non-developer, that learning is critical. You’re not going to out-code a senior engineer. But you can architect a system good enough to ship real software, as long as you understand it.

Borrow ideas freely. Take other people’s frameworks apart to see how they tick. But build your own version, and understand every piece of it. The understanding is the asset, not the config file.

Where I actually work on the workflow

If I spend close to a third of my time improving the workflow, the fair question is where that work happens. Not in a project directory. That was a mistake I made early.

At first I tinkered with my setup inside whatever I was building. Bad idea. A project folder is for the product. The moment you start drafting half-finished workflow experiments in there, you clutter the project with things that have nothing to do with it, and the AI starts loading your unfinished ideas every session. That’s the exact noise problem the lean-file approach exists to avoid.

So I made a separate place for it. A dedicated folder, its own little repo, with no product code in it at all. Workflow ideas live there until they’re ready.

It runs like a lab. When I get an idea or read someone’s article, I ask Claude to evaluate how it compares to what I already do and whether it holds up. If it’s worth pursuing, I write down the exact change I’d make. Then I either adopt it, in which case it graduates into my real config, or I reject it and keep a short note on why, so I don’t reargue it in six months.

Two things come out of that. My live config only ever holds rules that actually work. And I have a written record of why every rule is there, which matters, because most of them are scars from something that went wrong.

The pieces, if you want them

I put my own setup, sanitized and templated, on GitHub: github.com/benyoskovitz/claude-code-workflow.

This is in no way the world’s greatest workflow, but it’s a start. 😄

It’s not my actual Candor config dumped out. It’s the reusable bones, with the project-specific parts marked for you to replace. A starter instruction file. The /assess rubric skill. The lean-instructions pattern. The session and cleanup commands. And a small “lab” structure for treating your own workflow as something you version and improve over time.

Don’t install it wholesale. That would contradict everything I just said. Read it, take the one or two ideas that fit how you work, and rebuild them yourself so you understand them.

Start this today

If you’d rather not touch my repo at all, don’t. You can stand up the core of this in about twenty minutes.

First, create the rubric command. Make a file at ~/.claude/commands/assess.md and paste in the plain-English instructions (see code block below): read the rubric, diff the change, grade each item pass or fail with evidence, stop and report on any failure, don’t self-fix. That file is your /assess. (Claude Code turns the filename into the command name, so assess.md becomes /assess automatically. No extra wiring.)

You are grading a code change against a task rubric. Do not write or fix any
code. You only read, grade, and report.

1. Read the file `.rubric.md` in the project root. It lists 3 to 5 checks, each
   a pass-or-fail criterion. If the file doesn't exist, say "No rubric found"
   and stop.

2. Run `git diff HEAD` and `git diff --staged` to see everything that changed.

3. Go through the rubric one check at a time. For each, decide PASS or FAIL and
   cite the evidence: the specific file and line that satisfies it, or the exact
   thing that's missing. No "probably fine." If you can't point to proof, it's a
   FAIL.

4. If every check passes, say "PASS, ready to commit" and stop.

5. If any check fails, list which ones and why, in plain language. Do not try to
   fix them. Do not commit. Stop so I can decide what to do next.

Be honest, not generous. The whole point is to catch the thing that isn't
actually done.

You could create this as a more robust skill if you want, which is how I’ve got it setup in the Github repo.

Second, add one line to your CLAUDE.md. Something like: “Before any non-trivial change, write 3 to 5 pass-or-fail checks to a file called .rubric.md, and don’t treat the work as done until /assess grades them all green.” That single rule changes how every task runs.

Third, start a workflow notes file. A plain text file, anywhere outside your project, where you jot the ideas you want to try and what happened when you tried them. That’s the seed of the lab.

The rubric and /assess command together are a powerful combination. Make your AI define “done” before it starts, and grade the result (through separate sub-agents) against that and nothing else. That single habit fixed more of my frustration than anything else I’ve tried.

The people getting the most out of these tools aren’t the best prompters. They’re the ones who treat the workflow around the tool as the actual work, and keep sharpening it.

What rules have you put in your own setup? How are you wrangling Claude Code to be better?

Candor is a synthetic user research platform built by Highline Beta.

You can join the waitlist today.

Why did we build Candor? A few reasons:

1. We do a lot of research. Building things is easy. The hard work is the early validation (and then the go-to-market). Candor is helping us do in-depth research quickly. It’s not replacing human interviews. It’s a strong compliment.

2. We’re all-in on AI. I’ve shared a few posts about my experience building with AI and how to create value with AI features. If you’re not neck-deep in it, you’ll be left behind. Simple as that. I don’t want to be left behind. 😄

3. We’re experimenting with GTM and new business models. AI is fundamentally changing a lot of things. Go-to-market (GTM) is one of them. How do you acquire users? How do you build a brand? How do you automate things intelligently without it feeling like AI-slop? From a business model perspective, we see the rapid shift in pricing and how software companies have to adapt. It’s a world we’re building and investing in, so what better way to figure it out than to do it ourselves.

I want to explain a bit more about how Candor works, then share some interesting things we’ve done and a few lessons learned.

Subscribe now

How Candor Works

Candor is a synthetic user research tool. You create personas and interview them, either manually or automatically. Everything is rooted in our expertise and scientific rigor.

1. Generate an audience

First you generate an audience. Audiences can be B2B or B2C (there are meaningful differences between how these are handled). You fill in some basic information, and can upload documents.

The system does deep Web research and uses your inputs to generate several archetypes/segments. Here’s an example:

Every pain point, behavior, goal, attitude, belief, preference, etc. is grounded in evidence from your documents and/or Web search.

The goal is to build personas from a very in-depth, fundamentally grounded base.

2. Generate personas

Next you generate personas. These are the actual “people” you interview.

Persona generation is equally in-depth and validated. Everything that’s generated is reviewed by a critic. You can double click into the details, or jump into interviews.

Each persona has a ton of detail. We spent a lot of time on this part, ensuring that the personas are robust. This goes well beyond what you get from simulating conversations in ChatGPT or Claude.

Share

3. Create an Interview Guide

Once you have personas, you create an interview guide. There are four basic types: Problem discovery, Problem validation, Concept testing & Price testing.

Each requires different inputs and generates different learning goals. From there, Candor creates an interview guide and allows you to automatically interview the personas. Or you can manually interview personas and chat with them as you see fit.

4. Synthesis

Once interviews are complete, the system runs a detailed analysis and generates a synthesis report. The report highlights everything you need to know (at a glance or in depth) to move forward.

I know that was a lot to go through, but I wanted to highlight Candor’s ease of use, along with the underlying sophistication.

Next Steps

We’re putting Candor through its paces and will open it up to early testers soon.

• If you’re interested, sign up on the waitlist.

• You can also follow Candor on LinkedIn.

Our goal is to launch within a month or so. There’s a lot of work to do on refining the product and experience. We also have to implement a business model.

Beyond Candor’s Core Product Features

Building a production-grade product involves more than its features. I want to share a bit more about those experiences.

Candor’s Website

Not surprisingly, Candor’s site is designed by and mostly written by AI.

I’m not in love with the site’s design, but I did use VoltAgent’s awesome-design-md to kickstart the process. It helped me identify similar brands to take inspiration from. I now have a couple design-related Claude Skills for future projects too.

For content, I used my own SEO/AEO experience and fed Claude Code with best practices, so it could structure the site and create key anchor pages. Some examples include Use Cases, Comparison, FAQ and Glossary.

I then used Kyle Poyar’s Claude Skills to refine the copy. I found /icp-sharpener was quite helpful. I combined the output from ICP sharpening with domain expertise from Anthony Pierri to rewrite the copy.

One last thing: The screenshots on the website are AI generated. They’re accurate images, but composites of a few features. Claude Code and I decided which images would resonate, and then it built them for me. This took a bit of work, but it was still easier than taking screenshots of the product and having to mash everything together in Figma or another tool.

Candor’s Help Files

Candor already has a bunch of help files (although this isn’t complete). They’re generated by AI; reviewed by me.

Claude Code went through the code base to structure the help files intelligently and write them.

The coolest thing is that help files get automatically updated when the product changes. This is done through a Claude Skill I created called /pre-commit, which I run before committing code.

The pre-commit skill does a few things, including running standard tests, verifying security issues and checking to see if help files need updating. It will tell me which help files need changing, write the changes, and give me an opportunity to review. As a result, help files should never be outdated and the site’s content gets frequent updates.

This is a great example of how AI can speed up the development process, including “around the edges” where things are often forgotten. Integrating help file management into the AI coding process is an easy win.

The Admin System

Every software product has an admin system for managing users, updating settings, tracking performance, etc. Historically this has been a pain in the ass to build: it can take a lot of time and it doesn’t provide users/customers with value. But without it, you can’t manage things properly.

Using Claude Code, I built a robust admin system very quickly.

I asked Claude Code to identify SOC2 compliance requirements, so we could build the necessary infrastructure. Candor isn’t SOC2 compliant yet, but the underpinnings are there. For example, it has a robust audit log of everything that’s done. It also tracks what admin users are accessing. This is “boring stuff” but super important.

• Candor’s admin system has full account and user control.

• Multi-factor authentication is built in (required by admins, configurable for regular users)

• Email templates are fully customizable

• Failures are monitored and reported in real-time

• And more…

One of the more interesting aspects of the admin system is the cost management part:

Almost every action in Candor costs money, because it’s heavily reliant on LLMs. In the last 30 days I’ve spent $499.75 testing!

Cost tracking is a huge part of building a successful AI product. You have to know what costs money, how much, how frequently those features are used and by whom.

Your power users could bankrupt you.

I wrote about AI business model shifts here: Lean Analytics, Reconsidered.

Candor’s cost management system tracks every action and its cost. It slices the data by user, project and feature. I know what it costs to generate interviews, run reports, create audiences, etc.

This should help me create a reasonable business model to cover my costs, provide customers with maximum flexibility (I don’t want to restrict usage significantly) and maintain a margin.

I’m not focused on optimizing LLM costs yet. Claude Code did occasionally recommend using cheaper models for certain tasks, so there’s some cost optimization built in. But more can be done.

Subscribe now

Lessons Learned Building Candor

Candor is the first production-grade AI product we’ve built at Highline Beta (for ourselves). It’s teaching us a lot.

1. PRDs & feature building can get out of control

The more you feed an AI code assistant tool (like Claude Code) the more it’ll do. But it’s also easy to get overwhelmed. I would never recommend that you build a “massive, feature-rich product” in one sitting. It’s better to eat the proverbial elephant one bite at a time. But it’s so alluring to write a gigantic PRD, try to think of every detail, feed it into Claude Code and watch the magic happen.

Thankfully, Claude Code will chunks the work, but it’s still up to you to deploy and test things piece by piece, review what’s going on, and encourage / force Claude Code to iterate. Otherwise…it’ll just keep building.

Vibe stuffing is a legitimate risk.

Candor already does a lot. After showing it to a couple people, guess what they said? “Very cool, but you could also do X and Y and Z…”

AI + vibe coding is encouraging everyone to build more. But more doesn’t always equal value creation. When building was hard, we had to be a lot more disciplined about what we built. Today that’s out the window unless you’re really pragmatic and careful.

Lessons learned:

• Don’t over plan. Focus on designing the minimum first, testing it, sharing it with others, and then adding new things.

• Don’t over build. Launch early and often. It’s why we’re releasing Candor now; otherwise we could spend the whole time building.

2. Invest meaningful time in building better systems

When you want to build production-grade, scalable software, you need the right infrastructure to do so.

I use the term “infrastructure” loosely, but some things to consider:

• Code quality: Claude Code (and others) are great at software development, but they make mistakes. I’ve gotten into heated discussions with Claude Code about drift or being lazy. You need systems to vet code quality, so you can hold your AI code assistant accountable.

• Performance: One person testing the product is a lot different from 5 people using it simultaneously, or 20, or 200, or 2000. You need to engage with your AI code assistant about performance, otherwise it won’t get prioritized. I’ve had multiple discussions with Claude Code about what we’ll need to do as users onboard, although to be honest, I don’t know what will happen.

• Tests: Every software developer will tell you that tests are important. But if you’re not a developer, you won’t know what kind or how to build them properly. Code quality tests are usually pretty basic and not enough to catch actual bugs. Candor has a variety of smoke tests that run, which simulate workflows, but even that’s not enough.

• Staging vs. Production: Many people will vibe code and push changes to their live system on the fly. I’ve done it, but it’s risky. For Candor, I implemented a staging environment. If you’ve never worked as a developer it’s not something you might think about. But managing dev, staging and production is important to minimizing risk.

Lessons Learned:

• The key is that you need the right systems to do the job. Vibe coding can be completely ad-hoc or very structured. The more serious you get, the more serious your infrastructure needs to be.

• I spend a meaningful percentage of my time on these issues. Probably 25-30%. I’ve spent entire “sprints” (1-2 weeks of time) on hardening the infrastructure, so that Claude Code is better/smarter, my hosting is more robust and error logging is in place.

3. Build and learn at the same time

You do not need to be a software developer to vibe code a quality product.

You do need to be willing to learn best practices.

You do need to pay attention to what your AI coding tool is doing so you’re not simply agreeing to everything blindly.

If you don’t learn along the way, you won’t get better. If you don’t get better, you can’t guide your AI coding tool to be better.

Lessons learned:

• Read (most of) what your AI coding tool spits out. Ask it questions. Challenge it. I often ask Claude Code to explain things in plain English, because it’s getting too technical for me.

• Focus on pattern matching. You need to build up your instincts around how to do things, so you can implement the right systems. Instincts = patterns.

• Don’t vibe code tired. It leads to laziness, which increases the odds of mistakes or failures.

• Don’t leave sessions unattended for too long. When you return to a session a couple days after starting it, I can almost guarantee you won’t remember what was going on. You were letting Claude Code run wild and now you don’t know how to pick things back up. You’re better off doing smaller, discrete sessions, ending them and moving on.

• Learn how to use the tools. AI coding tools are insanely powerful. You need to learn how to use them, shape them and build systems for yourself and the tools to do what you want. Don’t just install Claude Skills blindly. Ask Claude Code to tell you what they do, why you might need them, how you could use them. Do your research. Spend a meaningful portion of your time learning, not coding.

We’re going to continue developing Candor and sharing our experience.

If you do any form of user research, please check it out and join our waitlist!

My co-author, Alistair Croll and I have been jamming on this too. He’s thinking way further ahead than me (as is always the case!) but we’re seeing the same things: the cost of building has collapsed, models drift under your feet, and your “users” might not be human at all.

The short version: the core Lean Analytics frameworks survive. Many of the specific metrics you were taught to obsess over need a rewrite. Some have been replaced entirely.

This post is about how to tell them apart. Fair warning, it’s a long one. We’re going to cover what still works (fast), what’s changing at the product metric level (in detail), what’s changing at the business model level (where some of the real damage is happening), and what’s coming next (more speculative, but important).

Subscribe now

A quick primer, in case you haven’t read Lean Analytics (the book)

If you’ve read Lean Analytics, skip this section (or skim it). You can probably ask ChatGPT or Claude for a synopsis. You can always get the book, too. 😉

Here’s enough to follow along.

Lean Analytics has four ideas worth anchoring on:

1. Know your stage

In Lean Analytics, we proposed 5 stages that all businesses go through: Empathy → Stickiness → Virality → Revenue → Scale.

Here are a couple primers:

• From Empathy to Scale: What Stage Are You Really At?

• You Don’t Have Product-Market Fit (and that’s OK)

At each stage there are key metrics to track. A lot of founders lie to themselves about the stage they’re at, eager to hit hockey stick growth before laying down a solid foundation. That’s very true in today’s rush to build the next AI darling.

2. Know your business model

We defined six archetypes: SaaS, e-commerce, two-sided marketplace, user-generated content/community, mobile app, and media. These are outdated, but the principle of knowing how your business works is critical.

When you’ve mapped your business it helps determine which metrics to track. Here’s a classic example from the book:

You can dig into the concept of mapping your business (and the business model) through a few posts:

• Deconstructing & Mapping B2B SaaS Business Models

• The Importance of Business Models to Building Great Products

• Your Startup is a System You Can Map to Identify Problems, Align the Team & Win

3. Pick the One Metric That Matters (OMTM)

At any stage, for any business model, there’s a single metric you should be focused on. This is the concept of the One Metric That Matters.

You can’t fix everything at the same time. The OMTM helps you identify what to work on and the right way to measure it.

Here are some relevant posts:

• OMTM vs. NSM: Why You Need Both to Drive Startup Growth

• Build, Measure, Learn: The Expanded Edition

4. Use lines in the sand

Benchmarks tell you when you’ve earned the right to move on. We called them “lines in the sand” because they’re not writ in stone. Thankfully there’s a lot of data out there on targets for specific metrics, although with AI and agentic products, the metrics and targets are moving quickly.

Here’s a post with more information on benchmarks: 4 Steps to Building Super Stick Products Leveraging Your Best Users

None of these principles change in an AI era

Although Lean Analytics was written in 2013, the core principles are sound. But the businesses being built today are significantly different. AI changes user interfaces, pricing models, profit margins, and much more. AI-first and agentic products are used differently. Expectations for value creation change. Connectivity between platforms changes.

Example: The five stages don’t disappear. They get a question mark attached to each one.

We need to integrate new metrics in with old ones to define each Lean Analytics stage. We need new metrics to help evaluate whether our business model is working. We still need to measure what’s going on, but we’re changing what and how.

Let’s start with product metrics.

Product metrics: six shifts that matter

Shift 1: Time to value collapses

Traditional SaaS had straightforward onboarding flows. Users signed up, went through a few steps, saw value and hopefully returned. It was rarely immediate, and Time to Value (TTV) wasn’t even a priority for many companies.

In 2024 I ran a study on TTV and the results were fascinating. Here’s one example:

How should you think about TTV value for AI products?

My experience: People are willing to try but fickle.

As people get more comfortable with AI, there’s a recognition that things are a touch experimental. They’re willing to test things out, but to an extent.

If they’re not convinced that the output quality is high enough they’ll move on. Fast. And the expectation bar is going up; people are aware of the hype so they expect your AI product to blow them away.

This isn’t just about chat products. A user drops in a messy document and expects a polished proposal back. Uploads a spreadsheet and expects clean analysis. Sketches a wireframe and expects a working UI. Hands over a contract and expects an instant review. The input method varies. The expectation is constant: fast, high-quality output, first try (or very shortly thereafter).

There’s a flip side that’s interesting. Time to competency has collapsed too. Non-technical users can now generate expert-level outputs without the training curve that used to gate them. Your activation curve used to be a learning curve. Now it’s an interaction or two.

That’s a real Lean Analytics shift. What used to be a multi-week journey to competency is now a single input away. The instrumentation has to change to match.

Shrinking time to competency is a good thing. But it may have a negative impact on business models (which I’ll focus on later). If one person can now do the work of three because AI fills in the expertise gap, you don’t need to onboard everyone in the company. That hits your seat counts, your expansion revenue, and your ACV curves. Happy users, fewer seats. That tension starts right here in Shift 1, and it ripples through everything downstream.

What to measure: time to first useful output, and the percentage of users who get a useful result on attempt #1, regardless of whether attempt #1 is a prompt, an upload, or a sketch.

Share

Shift 2: Activation isn’t deterministic anymore

In traditional SaaS, activation was a deterministic event. If the user completed a set of steps (connect your data, invite a teammate, create a project), they hit a predictable output. You could instrument the funnel because A + B + C reliably produced D. I wrote about this with Ben Williams, in the context of early PLG metrics, and most of those metrics assumed that deterministic relationship.

AI breaks that assumption.

In an AI product, a user can complete every step of your activation funnel and still get a mediocre output. They set up their account. Connect their data. Upload the document. Hit run. And the result is... meh. Your dashboard shows them as activated. They are not.

Activation isn’t a binary gate anymore. It’s a quality-weighted event.

This matters because everything in product is a loop. Nir Eyal’s Hooked gave us the dominant mental model for how product habits form: trigger, action, variable reward, investment. Every trip around the loop deepens the habit. That framework still applies in an AI era, but with one critical caveat that breaks a lot of the math underneath it.

In the classic Hooked model, the “action” is deterministic. User takes the action, a reward follows (variable in magnitude, but reliably present). AI loops introduce variance on both sides of the action. Users will stretch and test the edges of what you’ve scoped, prompting or asking for things you never designed the product to do. The outputs will range in quality. Two sources of variance in a single loop is a genuinely harder thing to instrument, and the old retention math wasn’t built for it.

This doesn’t mean activation has to collapse to a single prompt. Compound multi-step activation can still work beautifully in AI products, and often works better than one-shot activation when the setup actually improves outputs. Connecting context, uploading reference material, configuring templates, training the tool on your voice. More setup can equal higher first-run quality, which is exactly what you want. The shift isn’t “activation got shorter.” The shift is that completing the steps doesn’t guarantee the user got value.

What to measure: the old funnel-completion metrics still apply (for now), but pair them with the attempt #1 quality signal from Shift 1. The funnel tells you the user finished the steps. The quality signal tells you whether finishing the steps actually produced value. You need both, and your activation dashboard has to show them side by side.

Shift 3: Engagement is directional (and the axis isn’t product type)

Traditional product wisdom: more time in product = good. Longer sessions. Higher DAU. Deeper feature usage. Session length went on every investor deck.

AI flips the question. The right frame isn’t whether engagement is going up or down. The right frame is more fundamental: what is the user’s time being spent on?

• Time spent struggling (regenerating, re-prompting, tweaking inputs to try to get a useful output) = bad engagement, every single time. High regenerate rate, long sessions with no copy or ship event, users abandoning mid-flow. This is failure dressed up as engagement, and it will flatter your dashboard while your product is silently dying.

• Time spent with AI doing the work on users’ behalf (spreadsheet being manipulated, proposal being generated, document being reviewed, emails being drafted) = good engagement, potentially very high. The minutes represent AI labor, not user friction. A user whose spreadsheet is being restructured by AI for 20 minutes is getting real value. That engagement number is a feature, not a problem.

• Time spent exploring or creating (brainstorming, ideating, iterating on a design or draft) = good engagement. Traditional intuition holds here.

• Zero user time, task completed = ideal for agent and automation products. The best outcome is invisible.

Stop asking “is engagement up or down?” Start asking “what is the time being used for?” That’s the PM question now, and most dashboards aren’t set up to answer it.

GitHub Copilot reports percentage of suggestions accepted as a core metric, hovering around 27-30% industry-wide according to published research. That’s a KPI that literally didn’t exist in traditional SaaS. It’s a direct measure of “was the AI’s work useful?” rather than “did the user stick around?” Huge difference.

Shift 4: Stickiness becomes about flow, not walls

Traditional stickiness was a frequency game: DAU/MAU, return visits, habit loops. Andrew Chen wrote a well-known piece years ago about where DAU/MAU breaks down: episodic-but-high-value products, weekly-rhythm tools, anything that doesn’t fit a daily habit pattern. AI doesn’t kill DAU/MAU. It amplifies the limits Andrew was already calling out.

Two things are happening at once.

First, users expect to do more diverse tasks with an AI product than they did with the linear SaaS tool it replaced. “Surely I can do more with this AI than the single-function tool, right?” is becoming the default customer mindset. That’s a real opportunity. PMs should be actively mining what users are prompting, uploading, and asking for beyond the current scope of the product. Task diversity per user is a growth vector that didn’t exist before, and the signal for where to expand your product is sitting in your prompt logs and your interaction data right now.

Second, sticky AI products are less about walls that keep users in and more about being in the flow of their work. Trace Cohen recently wrote a piece called “Moats are dead. Long live canals.” that captures this well. He wrote: “moats scale through exclusion, canals scale through throughput.”

Stickiness in an AI era looks a lot more like canal thinking. You’re indispensable because of throughput and embeddedness, not captive because of switching cost. “Routes,” as Trace puts it, “tend to outlast empires.”

What to measure: DAU/MAU still matters as a baseline (especially while humans are in the loop), but pair it with metrics that actually capture flow:

• Task diversity per user. Are users stretching your product into use cases you didn’t originally scope?

• Integration depth. How many of the user’s tools and data sources are connected to your product? Each connection is a canal.

• Trigger diversity. What brings users back? One trigger or many? Multiple entry points means you’re plugged into multiple parts of their workflow.

• Workflow chaining. Does your product hand off to other tools, or receive handoffs from them? Being a node in a multi-step process is the literal definition of being “in the flow.”

When humans stop becoming the primary user, classic DAU/MAU will become problematic.

Don’t be a tiny canal

Stickiness as flow has a failure mode. Being “in the flow” can mean being a small canal between two big rivers, useful today but vulnerable to being widened, narrowed, or rerouted by whoever owns either bank. Today you’re indispensable. Tomorrow the tool upstream ships an AI feature and absorbs your slice.

The defensive move is to eat more of the chain. Legacy moat software is fat, slow, expensive, and not AI-native. The opportunity isn’t to fit neatly between two of those tools. It’s to replace them.

Claude Code didn't just sit alongside your IDE. It replaced enough of the editor, enough of Stack Overflow, and enough of the actual work that developers used to do by hand to become a different shape of product. That's the model.

So add one more metric to the four above: replacement breadth. How many adjacent tools, subscriptions, or manual processes did your customer drop when they adopted you? If the answer is zero, you’re still a tiny canal that can be rerouted around. If the answer is meaningful, you’re becoming the route everything else flows through.

Subscribe now

Shift 5: Quality is a first-class metric now

We’re circling back. Shift 2 (activation is a quality-weighted event) and this shift share a root cause: AI outputs are probabilistic, not deterministic. That single change cascades through every metric you inherited from the SaaS playbook. Activation is one place it shows up. Ongoing product quality is the other, and that’s what this shift is about.

Traditional: the feature works, or it doesn’t. You ship it. You instrument it. You move on.

AI reality: outputs are a distribution, not a property.

An 80%-good product and a 95%-good product feel like completely different products to users. That gap matters more than any other gap in your funnel. Quality isn’t something you ship once. It’s something you watch like retention.

Klarna is the cautionary tale. They went big on AI-only customer support in 2024, claiming the AI did the work of 700 agents. By mid-2025 the CEO publicly walked it back and started hiring humans again.

There’s a second piece most teams aren’t tracking well enough: brittleness. Your quality depends on models you don’t own, integrations you barely control, and prompts that can silently regress when an upstream provider updates something. Quality can drop without anyone on your team touching the code. That’s a new risk category, and it doesn’t fit anywhere on a traditional dashboard.

The defense is to measure models against each other on your actual prompts. If you’re using more than one model across your product (and most teams are, or will be), each one has its own quality distribution and each can shift independently. Run the same evals across every model you touch and watch the gaps. When one provider regresses, you’ll see it. When another improves, you’ll see that too. Your model is now a vendor you have to actively manage, not a dependency you can set and forget.

What to measure starts with the basics: thumbs-up rate and regenerate rate as your core signals. Regenerate rate showed up in Shift 3 as a struggle indicator. Here it’s the inverse: same number, different question being asked.

Layer on top of that: eval harness scores tracked over time, the way you’d track retention. Run those evals across every model you use, not just one, so you can spot regressions and improvements as they happen.

And finally: quality distribution by cohort. New users experience a different product than power users do. They don’t know how to engage yet. The tool is worse for them by default, and most teams aren’t measuring that gap.

Sidebar: Alistair on why evals are the new MVP

My Lean Analytics co-author Alistair Croll recently wrote a piece I think every PM should read: “The feedback loop is the product.”

His core argument lines up exactly with this shift. In the Lean Startup era, the MVP was the smallest experiment that tested your riskiest assumption. In an AI era, your riskiest assumption is no longer “can the model do this?” (it can). It’s “does our system behave correctly in the situations that matter most to our users?”

He writes: “The eval suite IS the MVP: the smallest set of behaviors whose improvement you can automate and measure.”

If you’re building AI products and you don’t have an eval harness, you don’t have a product. You have vibes. Go read the post. It’s the clearest explanation of evals-as-management-tool I’ve seen.

Shift 6: Trust and comfort with AI are leading indicators

This wasn’t in the Lean Analytics book, because it didn’t need to be. Tech savviness has always mattered, but it’s never had the range it has now. With a traditional SaaS tool, if a user can click buttons and read labels, they can use the product. With AI, comfort with the technology itself is a variable, and it shapes every downstream metric you care about.

The macro picture is clear. Gallup’s February 2026 study of 23,717 US employees found that what separates AI adopters from holdouts isn’t access to the tools. It’s whether employees see AI as useful, ethical, and a fit for their workflow. Non-users tend to question whether AI is relevant to their role at all. Infrequent users see some potential value but get held back by practical concerns and risk.

Stanford’s 2026 AI Index Report shows global adoption at 58% of employees but the US trailing at 28.3%, far behind Singapore at 61% and the UAE at 54%. The same product can sit on top of dramatically different user populations, and most teams aren’t measuring that.

In a B2B context, my hypothesis is you’ll see meaningfully different activation, stickiness, and task diversity curves between AI-native users and AI-hesitant ones. Same product, same plan, same role, different behavior. The AI-native user stretches the tool, prompts it in ways you didn’t design for, and gets more value per session. The AI-hesitant user is cautious, underuses the tool, and quietly concludes that “this isn’t for me” even when the product is working correctly. If you measure them as one cohort, your averages will hide the real story.

In a B2C context, the stakes get more intimate. Products for companionship, mental health support, friendship, and emotional wellness are now a real category. Stanford’s data shows 52% of respondents globally are excited about AI for companionship, with that number climbing past 80% in places like Singapore and Indonesia. Comfort with an AI in those contexts is the core product question. Value creation is literally measured through the user’s willingness to keep showing up, keep talking, and keep engaging emotionally with something that isn’t human. That’s a very different measurement frame than “did they complete the task?”

Trust also isn’t one thing. It’s at least four things, and they move independently:

1. Trust in the output: Is this correct? Is this useful?

2. Trust in data handling: Where does my prompt go? Who sees it?

3. Trust in security: Can this be exploited or leaked?

4. Trust in reliability: Will this embarrass me if I rely on it?

I don’t know of teams doing rigorous AI-comfort cohort segmentation in their own product analytics yet. But the variance exists, the tools to measure it exist, and it make sense to do. A single onboarding question (”How often do you use AI in your daily work?”) plus behavioral signals you’re likely already capturing (prompt complexity, regenerate rate, time-to-advanced-feature-use) is enough to build a working cohort view. Run your existing activation, retention, and trust metrics through that lens and you’ll likely see gaps that aggregate dashboards are hiding.

What to measure:

• Adoption and activation curves segmented by AI-comfort cohort, not just role or plan.

• Accept rate, which we saw in Shift 3 as a measure of “was the AI’s work useful?”, becomes especially revealing when sliced by AI-comfort cohort. How quickly does trust build for AI-native users versus AI-hesitant ones? The slope of the curve, more than the absolute number, tells you whether your product is earning trust or losing it.

• Override rate, meaning how often the user rewrites, edits, or redoes the AI’s output. A falling override rate is a rising trust signal.

• For emotionally intimate B2C products: session depth, return rate to sensitive features, qualitative tone of interactions.

• Signals of data/security concern: feature opt-outs, support tickets asking “where does this go?”, usage that avoids sensitive inputs.

Trust and comfort with AI aren’t soft, squishy, unmeasurable things. They leave real signals in your data. Instrument them the same way you’d instrument retention, because in an AI era they effectively are retention.

Share

Business model metrics: three key shifts

Product metrics change. The bigger shock is what AI is doing to business models.

Picture the scene. Your AI feature launches. Engagement is 10x any other feature in your product. Your CEO is ecstatic. You’re in every all-hands slide for a month.

Six months later, finance review: gross margin has collapsed, your power users cost more than they pay, and your best engagement metric is the one strangling your P&L.

This is happening quietly in products everywhere.

Shift 1: Cost-per-successful-task is your new CAC math

Traditional SaaS: CAC, LTV, and gross margin were relatively stable per customer. Scale made things cheaper, not more expensive. Marginal cost of adding a user was close to zero.

AI reality: your power users literally cost you money.

Tokens are variable cost. Flat-rate subscription plus a heavy user equals negative margin per account. SaaS LTV curves don’t hold. The more someone uses your product, the worse your unit economics get, which is the exact inverse of what you want.

What to measure:

• Gross margin per active user. Not per paying user. Per active user. Big difference.

• Cost-per-successful-task

• Model cost as % of revenue

• Marginal cost of power users vs. marginal revenue from them

Intercom’s Fin is a great example of getting this right. They didn’t price per seat. They priced at $0.99 per successful resolution. You only pay when Fin actually solves the issue. That’s outcome-based pricing, and it’s mathematically honest about what AI products actually cost to run. ElevenLabs went usage-based from day one. Anthropic and OpenAI have both publicly wrestled with consumer subscription economics.

If your pricing and metrics don’t reflect variable compute cost, you’re flying blind.

(I wrote more about how business models shape which metrics matter a while back. The core argument holds, the cost structure is what’s new.)

Shift 2: Pricing is a product decision now

Usage-based and outcome-based pricing are still early. Hybrid models (low monthly fee plus usage, with overage) are probably where most AI products eventually land.

Here’s what matters for PMs: pricing decisions are product decisions now, not just finance decisions. The pricing model tells the user what success looks like. It has to match the unit economics underneath. Get that wrong and you’ll either burn margin or cap your growth. Sometimes both.

Think about the difference between “unlimited AI queries for $20/month” and “$0.99 per successful outcome.” Those aren’t just two pricing models. They’re two completely different products from the user’s perspective. The first says “experiment freely, we’ll eat the cost of your learning.” The second says “we only win when you win, and you have to think about what winning means.” Both can work. Neither is neutral.

This is a real shift, because most PMs haven’t had to think deeply about pricing. It was finance’s problem, or the CEO’s problem, or the “we’ll figure it out when we need to” problem. That’s changing fast, and AI-native PMs need to treat pricing as a core part of product design.

Side note: As I build AI tools for Highline Beta (we’re releasing things soon!) I’ve spent a lot of time instrumenting the tools to track AI usage and calculate cost. I’m sure there are tools that do this for you, but I wanted to understand how to do it: learning through building.

It’s interesting to see what actions (features) drive cost, and then determine if they drive commensurate value, and then figure out how to price everything.

You may have AI features in your product that are expensive but don’t create a ton of user value, which can easily kill everything for you. Adding SaaS features was typically cheap (i.e., new features don’t cost a ton to run), which simply isn’t true for AI features.

Subscribe now

Shift 3: Experimentation isn’t a vanity metric anymore

Experiment count used to feel like a vanity metric. In an AI era, I think it’s mission critical. And it’s earned that promotion through a specific mechanic that didn’t exist before.

AI-enabled product building lets you release way more, way faster. The cost of shipping a feature has collapsed. That sounds like an unambiguous win, and it isn’t.

If you’re shipping faster but not running real experiments, you’re vibe-stuffing your product (as far as I know, I just invented this term!)

You’re adding features because you can, not because you have evidence they’ll create value. Most of those features won’t. Some will be ignored. Some will be used in ways you didn’t anticipate and couldn’t measure. The product gets bloated, the codebase gets bloated, the cognitive load on users goes up.

On top of that, every AI-powered feature you ship has a cost attached to its use. Not a one-time build cost, an ongoing per-call cost. Inference isn’t free. So the bloat from vibe-stuffing isn’t just clutter, it’s a tax that compounds with usage. You’re paying tokens every time someone touches a feature you didn’t have evidence for. The more it gets used, the more it costs, and you don’t even know if it’s creating value.

That’s a uniquely bad outcome. Slow, expensive, and unproven, all at once. Pre-AI product bloat was annoying. AI-era product bloat is a margin killer.

Strong experimentation is the only defense, and Lean Analytics goes up in value here, not down. The discipline of picking a metric, writing a hypothesis, pressure-testing it, and deciding what to do next is the difference between a team that’s learning and a team that’s just shipping. The Lean Analytics Cycle was built for exactly this, and it has never been more relevant.

A useful filter: for every experiment, write down the hypothesis and the decision criteria before you ship. If you can’t do that, you’re not running an experiment. You’re running a release. Both have their place, but don’t confuse them.

What to measure: experiments-per-quarter as a real metric, not a vanity one. Hypotheses written down before launch. Features sunset based on data, not just features added. And cost-per-feature in production, because the AI-era product audit isn’t just “is this used?”, it’s “is this used enough to justify what it costs us to keep running?”

Tying all of this together: value density

A note before we leave business models. There’s a principle running underneath all three shifts above, and it’s worth naming.

Ben Murray, the SaaS CFO, said it cleanly: “If SaaS is about margin efficiency, AI is about value density. You’re optimising for how much output, productivity, or labor you replace per dollar of compute.”

That’s the new unit economics question, and it’s measurable. The numbers are already showing up in the data. ICONIQ’s January 2026 State of AI report puts inference at 23% of revenue for scaling-stage AI B2B companies. That same report shows AI gross margins averaging 52% in 2026, up from 41% in 2024 but still well below the 70-90% that mature SaaS companies hit. Bessemer pegs AI-first companies at 50-60% gross margins. Jason Lemkin’s framing: “as you grow, you need ever more inference. You can’t cut it without degrading the product.”

So how do you actually measure value density? It’s not one ratio. It’s three, and they move independently.

• Cost-to-deliver per task. What does it cost you, in tokens and compute, to produce a successful output? This is the bottom of your funnel. If you can’t answer this, you can’t answer anything else.

• Revenue captured per dollar of compute. Are you charging enough to cover variable cost plus margin? A flat-rate plan with a power user can mean negative revenue per dollar of compute on that account.

• Value delivered to the user per dollar of compute. This is the one most teams skip. Did the user get something worth what you spent? A team can be strong on the first two ratios and still build a product nobody wants to pay more for. A team can be strong on the third and have terrible economics. The diagnostic only works if you measure all three.

The future: humans receding from the loop

Business models are getting way more complex. But products still have to drive them. That’s a Lean Analytics principle that hasn’t moved an inch.

What has moved is what a “product” even is, and who (or what) is using it. The thread running through everything below is the same shift viewed at four different distances. The human is receding from the loop. Still building. Still using. Still paying. But increasingly through, behind, or alongside agents that decide what actually happens.

Build-too-much is the new overfitting

Building is so easy now that the risk is shipping more than users can absorb, or more than your data can tell you is actually right. Every feature has a cost (cognitive, operational, and literal), but when the cost of adding one drops to nearly zero, the urge to ship everything is hard to resist.

Alistair wrote about this exact problem from the engineering side:

Fallbacks and the deletion problem

In “Fallbacks will be the death of us,” Alistair argues that AI removes the friction that used to force deletion. Old code stayed because rewriting was expensive. Old features stayed because building was costly. Friction was the garbage collector.

Now that building is cheap, nothing gets pruned. Fallbacks pile up into “invisible load-bearing walls.” Tests become dishonest (AI-generated tests often optimize to pass themselves rather than to validate the desired behavior). The whole system bloats silently.

He wrote, “deletion feels riskier than retention, and without friction, things stay.”

PMs need to own this. If nobody on your team is saying “this has to go,” you’re accumulating debt that’s hidden from your own metrics. Worse, as Alistair notes, you can’t trust your regression suite either, because the AI wrote the tests and the AI is grading the tests. Go read it.

The PMs who resist build-too-much and learn to measure deletion as carefully as they measure addition will win.

Agents as users

When a Claude agent uses your product on behalf of a human who never sees your UI, who is the user? What does “activation” even mean? What’s session length? What counts as engagement when the thing using your product has no attention, no fatigue, and no churn risk?

I don’t fully know. I’m not sure anyone else does yet either.

What I do know: if you’re not instrumenting agent traffic as a separate cohort today, you’ll miss the shift when it happens. And it’s going to happen.

The practical move is to start capturing user-agent strings, API patterns, and anything else that helps you distinguish “human driving the UI” from “agent hitting the API.” Track them as separate funnels. The behavior is different, the success criteria are different, and mixing them into one metric is going to give you the wrong answer on both.

Sidebar: Rob May on why HX replaces UX

Rob May recently wrote a piece worth reading: “The End of The Funnel: Why HX Is The Next Big Design and Investment Frontier.”

His argument: thirty years of UX has been about getting humans to click the right button. Conversion funnels. Onboarding flows. A/B tests on button color. When an autonomous agent books your flight, it skips all of that. It hits an API and returns a result.

His line: “The funnel isn’t just broken. It’s irrelevant.”

What replaces it is what Rob calls HX, or Harness Experience. The metaphor is deliberate. You don’t operate a harness, you wear one. It distributes load, keeps you tied to something powerful, and lets you stay in control without doing all the work yourself. HX is the design layer for a human who is steering, trusting, and auditing a fleet of agents working on their behalf. The user becomes a director, not a driver, and the metrics shift accordingly. You stop measuring clicks and conversions. You start measuring outcomes, oversight, and intervention.

If you want a sharper mental model for what “agents as users” actually means in practice, Rob’s piece is the best one I’ve read on it.

Discoverability and reuse

Two problems, one root cause: an AI that isn’t yours decides whether your product gets used.

Discoverability is the obvious one. A user opens ChatGPT and says “help me plan a trip to Mexico.” ChatGPT decides whether to invoke Expedia, Booking, Kayak, a niche specialist, or none of the above. The user never picked a tool. The AI did. For thirty years, distribution was about getting a human to find and choose you. In an agentic world, the human delegates the choice, and you’re competing for the AI’s selection logic, not the human’s attention.

Reuse is the one most teams haven’t grappled with yet, and it’s the more unsettling of the two. A user signs up and pays for Canva. They have the Canva ChatGPT app installed. Then they ask ChatGPT to help design something. ChatGPT still decides whether to invoke Canva. The user already chose. The user already paid. The AI gets to override that choice every single time the user goes through the AI to get work done, unless the user explicitly asks.

Same dynamic with Claude skills. You install a skill, you can be explicit about when to use it, or Claude decides. As more work routes through AI assistants, the AI becomes the gatekeeper not just for acquisition but for reuse of tools you already own. Owning the customer doesn’t mean owning the moments where the customer actually gets value. That’s a new kind of platform risk, and most teams haven’t priced it in yet.

What to start tracking: the gap between “users who own or pay for the product” and “users where the AI actually invoked it when it could have.” A paying subscriber whose AI hasn’t invoked them in 30 days is more at risk than a subscriber who hasn’t logged in directly. The first one might never log in directly again. They might just talk to ChatGPT. And the AI may have quietly stopped picking you.

Agent-to-agent products

When your product is a network of agents collaborating with other people’s agents, what’s the OMTM? What’s stickiness? What’s churn?

We don’t fully know. But the PMs thinking hard about these questions in 2026 will write the next version of the book.

If you remember Shift 2 for product metrics, I leaned on Nir Eyal’s Hooked as the dominant mental model for product loops. Trigger, action, reward, investment. Every single phase of the classic Hook Model has to be reconsidered when humans are receding from the loop.

The four phases are still there. Each one now has a question on it that didn’t exist five years ago. What does a trigger mean when the AI is doing the triggering? What’s an action when the AI takes it? How do you reward something that doesn’t experience reward? Does investment apply to a system that has no memory of previous loops, or has perfect memory of every loop it’s ever been part of?

The PMs that figure this out will lead the way. They’ll build new products and experiences for AI-”users” and simultaneously figure out what to measure to learn if they’re heading in the right direction.

What to actually start doing today

The Lean Analytics frameworks still work. Know your stage. Know your model. Pick the one metric that matters. Draw a line in the sand.

The specific metrics you inherited from the SaaS playbook need a rewrite. Time-to-value collapsed. Engagement is directional. Stickiness is trust. Quality is a cohort, not a property. Your power users might be your biggest unit-economic hole.

Here’s what I’d do, concretely, starting today:

1. Audit your engagement metrics. Stop asking "is engagement up or down?" and start asking "what is the user's time being spent on?" Time spent struggling is failure dressed as engagement. Time spent with the AI doing the work on the user's behalf is real value. The number on the dashboard is the same in both cases: your job is to know which one you're looking at. Get this wrong and you'll spend the next quarter optimizing for failure.

2. Add a quality-by-cohort view. Measure output quality for new users separately from power users. The gap might be bigger than you expect, and it tells you exactly where onboarding has to get better.

3. Look at gross margin per active user. Not per paying user. Per active user. Your best users are either your best asset or your biggest liability, and your current dashboard probably doesn’t tell you which.

4. Start instrumenting agent traffic separately. Even if it’s 2% today. It won’t be for long, and you’ll want the baseline before the shape of your traffic changes.

5. Build an eval harness. Alistair is right. If you can’t systematically evaluate whether your AI is doing the thing you want it to do, you don’t have a product. You have vibes.

6. Evaluate how you build features. Are you running tight experiments, or vibe-stuffing your product to death? How efficient and effective are your teams?

The book still holds up. The lens has shifted.

How are you handling the shifts in product, business models and metrics being created by AI?

14 years ago I wrote a blog post that was extremely personal. It was about my brother who died on April 22nd, 1986. That blog doesn’t exist anymore, but I need the content to live on.

If you’re not interested in a long, super-personal post about my life, don’t read on. Totally cool. This one is for me.

Today, April 22nd, marks the 40th anniversary of my brother's death.

He died in 1986 at the age of 8 from leukemia. I was 10 at the time. He was my only sibling.

Strangely enough, he and I share a birthday. He was born two years after me. I don't know the odds of that happening, but they’re small.

April 22nd, the day Jacob died, is also one my aunt's birthdays. She was (and is) our closest aunt, dearly loved by Jacob (and me).

Jacob was diagnosed with cancer when he was 6. He suffered, off and on, for two years. There was the occasional bout of remission, but it never lasted long. Most of the time he was shuttling back and forth between Guelph (where we lived) and Toronto's Hospital for Sick Children. He spent a lot of time at that hospital. So did my parents. I visited Jacob there, but never stayed for long periods of time. I was still going to school, and I think my parents wanted to shield me from what was going on. So I stayed with family friends, often for weeks at a time, and tried to lead a "normal life."

I miss my brother.

I often wonder what it would be like had he survived. In that fantasy world, we're best friends, close enough in age to have shared many milestones together: turning 30, getting married, having kids. Who knows...

I often wonder what he'd be like. He and I were very different. I was always more serious, he was always sillier and more fun. He liked tuxedo costumes, I couldn't care less what I wore (still sort of true.) He put a lot of effort into holidays and parties, I didn't. Even when he was sick, he had a jovial personality and enjoyed himself as much as he could, although as you might expect, there were occasions when he was so sick and in so much pain (made worse by the chemotherapy) that even his bright personality could not shine through. I really don't know what he would be like, but I have a feeling he'd be a fun guy to hang out with. And caring. Ridiculously caring.

My memory of my childhood is very spotty. My memory overall is bad, but it's amazing how little I remember of my brother's illness. Maybe I blocked it out to get through the situation, I don't know. But there are some things I remember.

I remember we both enjoyed LEGO (I still do!) We used to build Transformers and Thundercats out of LEGO, playing in our bedroom (which we shared with bunk beds) for hours.

I remember eating a lot of hospital food (don't do that), including ham and cheese sandwiches on white bread. I'm pretty sure I ate as a coping mechanism.

I remember throwing things at each other from our bunk beds and joking around while we were supposed to be sleeping.

I remember going on vacation to Cape Cod, near the end of his life. My parents already knew it was over, but I didn't. We had a great time buying a ton of gear at an Army surplus store and playing G.I. Joe. Did he ever love G.I. Joe.

I remember the day he died, when family friends came to pick me up at school. I was called out of class and I walked to the top of a set of stairs. Looking down the stairs I saw our family friends and knew instantly my brother had died. One of them said, "It's time." I went back into the class, collected my things and they took me home. It must have been a 20-30 minute car ride at least, but I have no clue what we talked about or said during that time. I also don't remember the last time I saw Jacob alive. I wasn't at home the night he died, my parents knew it was coming to an end, so I was staying with family friends.

The world is a shitty, brutal place. It's absurd how much suffering there is. And when people say "life is short," are they ever right. Most people don't really know what that means. Some definitely do.

It's difficult to say how my brother's death changed me. I don't know what I would be like had it not happened. While I feel like I grew up more quickly than my peers (at the time), I also never outgrew a lot of "kid" stuff. I still love cartoons, comic books and toys. So do a lot of people, but for me, "capturing a bit of my childhood" is so much more than nostalgia. It's a way of remembering my brother.

Reflecting on yourself is hard. I look back on my life and the experience with Jacob, and wonder why it didn't propel me more in terms of career choice (although I always wanted to be a doctor, I couldn't handle the years of school), or why I don't donate more money to research and charity. I don't know if my experience made me a better person. Somehow personal selfishness and laziness overruled my desire to help. I don’t think I'm a bad person, but I look at what some people do in the world—how they devote themselves to making a difference in huge ways—and I marvel at their desire and ability to do so.

People are incredibly resilient, more than they realize. Few people are ever pushed to their absolute limit. My grandparents on my father's side survived the Holocaust. They spent years in ghettos and concentration camps. Talk about pushing past one's limits. People survive horrible tragedies and experiences every single day. And most persevere. You've gotta believe in the human spirit and will to live. They're almost insurmountable. Having said that, I'm not an optimist when it comes to the human race. I'm not really a pessimist either. I'm ... neutral. It's not where I want to be, it's just where I am. We (collectively) do some fantastic things, but we're also so easily capable of evil that it's impossible for me to believe we get it all right "in the end." Life is just too complicated for that.

People are also insanely stubborn and irrational. We know right from wrong, and still go down the wrong path a lot. I’ve just started eating better and exercising. I finally committed to it. I always knew I should take care of myself and never did. I think it was my way of saying, “Fuck you” to the world (and death). But I’m 50 and running out of time. It’s something I’ve written about (if you want more sad, personal stories). Recently, my mom got very sick and that was it, I decided enough is enough…

Of course something will get me someday. As long as it's not cancer; you've already taken enough from me.

While stubbornness and irrationality can be bad qualities, they're also good. I don't think I would have achieved much of anything in life if I wasn't stubborn and irrational. I would have just turned over and given up.

I haven't mentioned my parents much here. I can't begin to imagine what they went through (even though I was there), and the pain they felt burying their son. We all suffer loss in our lives—that's part of life itself—but losing a child is unimaginable, even for me. It's something I have to force myself not to think about, given that I have two boys of my own.

My parents and I have our differences, just like any family. But I love and respect them dearly for the people they are and what they've gone through in life. They gave me a happy, good childhood.

For my kids, I'm saddened by the fact that they'll never get to know my brother. I think Jacob would have been an awesome uncle. They’re both now adults, but I used to be so scared every time they got sick. I hid it, but on the inside I was mess. Jacob's leukemia started with flu-like symptoms. That's it. From "having a cold" to a "rare form of leukemia" is a hell of a jump. But sometimes, that’s how it happens. Most parents don't think the same way that I do (although parents are universally and constantly afraid for their kids), because a cold is 99.99% of the time just a cold.

I think about Jacob a lot. Not on a daily basis, but he's never too far from my thoughts. I think about him in good and bad times. I think about him when I'm going to do something hard, and remember what he went through. I get a sense of strength from him that helps me. More than I probably realize. It's still hard though—forty years later—to think about him. Our time together was just too short, and the pain is still there.

My goal with this post was to share a part of me that's never really been shared. I'm sharing with myself and for myself, and sharing for my brother and with him. For my kids too. I would never presume to preach to you, I don't know what you've been through. The truth is, you can't really know someone until you know everything they've been through. But I can tell you this: whatever it is, I bet you can get through it. It's in our very core to fight (in a good way, and unfortunately in a bad way too) and survive. You can make it.

One thing Jacob taught me for sure, was to be happy.

It's a cliche, but genuinely important. Unfortunately, most of us never really get there. And while I admire the few people that can drop everything and do exactly as they please all the time, I'm not wired that way. But I do seek happiness. And I think I've done a pretty good job charting my own path (with the occasional hiccup along the way), always in an attempt to be and stay happy. If you can achieve even a little bit more happiness in your life—through anything—you owe it to yourself to at least try.

In Jacob's short life he touched a lot of people. Even today, people still visit his grave, evidenced by the small stones or pebbles they leave on his headstone (which is a Jewish tradition.) One of his childhood friends still leaves small toys on the headstone; a tiny connection to the friendship they shared. Just before my brother died, he asked my mother to take care of his friends. To the end, Jacob was thinking about others he cared about.

He was an awesome kid. He was an awesome brother. And I love him.

That’s what pre-seed investing feels like right now.

And if you’re thinking: didn’t Gandalf show up at Helm’s Deep and save the day? Sure. But that’s Lord of the Rings. This is real life. VCs love to think of themselves as Gandalf-level awesome. They’re not. Nobody’s riding in at dawn with the Rohirrim to save your startup. You’re going to have to break through those walls yourself.

The barrier to starting a company has never been lower. AI coding tools, AI GTM tools, AI everything tools means you can get from idea to functional product in days. So founders are launching. Lots and lots of founders. Throwing their startups at the wall to see what breaks through.

Cannon fodder.

• To be clear: I’m not being dismissive. I’ve written before: we need more founders. More entrepreneurs, not fewer. Small businesses employ nearly half the private sector workforce and generate enormous amounts of economic value. More startups means more shots on goal, and some of those shots will matter enormously.

• On the investor side, I’ve also argued that we need more angel investors to fund the next generation of founders. Someone has to take the earliest bet…

So yes. More startups. More investors. More entrepreneurship. 💪

But there’s a signal-to-noise problem right now that I’ve never seen before. If you’re trying to invest at the pre-seed or angel stage, you feel it constantly.

Here’s how I’m thinking through these challenges…

Subscribe now

1. The “Why” Matters More Than Ever

The ease of starting a company means founders don’t always have a great reason for doing so. They see opportunity. They think they’ll win fast. They’ve read the stories about AI companies hitting millions in ARR within months of launching and they want some of that. It feels a bit like the dot com era.

I’ve argued for a while that the most important question a founder can answer is why. Why are you building this? What happened to you, or what did you see, or what do you uniquely know that made this feel necessary?

Of all the things you could be doing with your life, why this?

That question matters more in a cannon fodder environment. Founders building because it’s cool, or because the timing seems right, or because they’ve spotted a gap from the outside, are the ones getting mowed down. Founders with a genuine insight, born out of lived experience or deep domain expertise, have a different quality of conviction. Conviction is what carries you through the grind.

Ed Sim from Boldstart, who’s been investing at the inception stage (his preferred term for pre-seed) for many years, describes the founders he backs as being on a mission. They can’t stop thinking about it when they wake up in the middle of the night. That’s the bar.

Founders: Using AI Aggressively is a Requirement

The use of AI tools to build and operate your startup is now table stakes. Not a differentiator. Table stakes.

Ed frames this as a direct question he now asks every founder: how much of your code was written by agents? His expectation for a software company is close to 100%. But it doesn’t stop at code. It’s product marketing, GTM, research, operations. The entire company needs to be agent-native.

What I’m looking for beyond the basics is creativity in how founders are using AI to innovate on startup creation itself. Not just building the product faster, but reimagining how they go to market, how they serve customers, how they operate. Founders who treat AI as a weapon rather than a utility.

Speed of execution matters more than ever because differentiation is compressing fast. But speed alone doesn’t win anymore either. Necessary condition, not sufficient.

Share

A quick aside, because this isn’t only about VC

One of the things I genuinely love about where AI is taking us: it’s opening the door for all types of entrepreneurs to build all types of things. Not just VC-scale swings with giant exit ambitions. Side hustles. Lifestyle businesses. The person who wants 50 paying customers a month to generate $5K in recurring revenue and buy back some freedom. That’s legitimate. That’s valuable. AI has made it more achievable than ever.

But if you think a lower bar is easier, you’re in for a world of hurt.

Getting 50 customers consistently is hard. Keeping them is hard. Distribution is hard regardless of your revenue target. Traction at any scale requires repetition, discipline, and more iteration than most people expect before they’re in it. The rules of building a real business don’t soften just because you’re not chasing a Series A.

Please: build the side hustle. Build the lifestyle business. Not everything has to be a moonshot, and frankly the failure rate on moonshots is brutal. But go into it with open eyes. “I don’t need to raise capital” is a feature, not a shortcut.

The Moat Problem

People are panicking because the moats they once held dear are drying up.

Network effects? Sometimes. Data advantages? Possible, but hard to prove early. Technical differentiation? Compresses in days, weeks, months. Ed Sim put it bluntly: what used to take 12 to 18 months to replicate in software now takes a fraction of that time.

Let’s not forget, moats (or ditches and walls) in medieval times weren’t perfect either.

The siege of Château Gaillard in 1203–1204 is a classic example. Built by Richard the Lionheart, it was considered nearly impregnable, yet it still fell to Philip II of France. After months of conventional siegework, French troops ultimately exploited an unguarded latrine shaft leading into the chapel and climbed through, opening the way for the castle’s capture. When someone is determined enough, they find a way. Moats and walls bought time. That’s it.

I came across an approach from Patrick Salyer, Partner at Mayfield, that’s worth sharing:

“There’s a simple filter I’m starting to use when evaluating AI agent startups: single-player or multiplayer?

Single-player AI apps are most at risk. They handle discrete tasks with limited complexity, exactly what Claude is designed to do incredibly well today.

Multiplayer apps require collaboration across multiple stakeholders to complete complex workflows. They need human-in-the-loop engagement, governance, and security around who can access what. Multiplayer is the moat.”

That maps to something Ed talks about too: the investments that hold up have domain complexity that can’t be collapsed into a single skill or replaced with the next model release.

Rob May, who writes Investing in AI (which you should read) argues that “weird stuff wins.” His take: the only durable opportunities might be genuinely low-probability and out-of-distribution. Ideas that don’t show up in training data patterns. Things that require real information asymmetry to even recognize as opportunities. As AI makes marginal innovation obvious and replicable, the success distribution shifts toward the weird ideas. It’s a provocative take, but there’s something real in it.

Which brings me back to what I think might be the last genuine moat: what does the founder know that nobody else does?

A proprietary insight developed through years in an industry, or a specific pain they’ve lived through, that gives them an unfair head start. That’s the question I come back to most in early-stage meetings.

Go narrow first, then scale

There’s endless debate: start in a niche or go for a platform play immediately?

My vote, most of time: start narrow

Insights come from going narrower. Finding complex problems comes from going narrower. The deeper and more specific you go into a market, the higher the likelihood of finding something that actually matters. You may uncover some boring problem that 10,000 other startups aren’t already chasing.

Subscribe now

Founders: Please Don’t Pitch at the Pre-seed Stage with Only a Deck

If you can ship an MVP in days using AI coding tools, and generate early demand signals using AI GTM tools, then showing up with just a pitch deck sends one clear message: you haven’t done the things you could have already done.

Pre-seed and angel investors want to see a functioning product. An early waitlist. Some proof that someone out there cares. That doesn’t have to be hyper-growth. But you need to demonstrate two things: (1) that you’re creating real value; and, (2) that you know how to reach your market.

The bar on traction has gone up, because the bar on building has dropped. Those two things are connected.

It’s Still a Bet on People. Maybe More Than Ever.

Remember the old adage of the ideal founding team? A hacker, a hustler and a hipster. Otherwise known as the builder, the seller and the designer.

First coined by Rei Inamoto of AKQA, the idea was that you needed at least three different people with complementary skills to build a company.

That framework made sense when each role required years of specialized skill to be competent.

It’s not quite the same world anymore.

AI has dramatically lowered the floor on all three. A solo founder can now hack (build a product with AI coding tools), hustle (run outreach and GTM with AI), and design (ship a polished product experience without formal training). I wrote recently about how the skills bar has expanded for everyone. The T-shaped model is under real pressure. The horizontal bar is becoming load-bearing. And what’s true for knowledge workers in general is especially true for founders.

The expectations on a founding team have changed. Hacker, hustler, and hipster skills still matter. But I don’t want to hear that you need to hire a CTO before you can start building. Or that you need to bring in a designer before you can ship. The solo founder is increasingly viable.

What I’m really betting on is whether a founder can figure things out. All kinds of things, in all directions, under pressure, with imperfect information. That’s always been the pre-seed bet. It’s just more nakedly true now.

Ed Sim calls it the “art of the possible.” He knows 9,999 things can go wrong when you invest early. But if one thing goes right, really right, how big can it be? That question drives everything.

Founders should build authority before jumping in

One signal I’m paying more attention to: has the founder already invested in building authority in the space they’re entering? Not just reading about it. Actually writing about it, building a following, becoming a known voice, knowing the players.

I’ve started to think: if I was building a new startup today, I’d spend 6 to 12 months doing exactly that before launching anything. Build the community first. Build the audience first. That work unlocks real problems, surfaces real insights, and gives you pre-built distribution before you’ve shipped a single line of code.

Founders who’ve done this aren’t a guaranteed bet. Authority isn’t a substitute for execution. But it’s a meaningful signal that someone has invested deeply in a space rather than parachuting in because the opportunity looked good from the outside.

Quick Reference: What I’m Looking At

For founders and investors both, here’s how I’d summarize the framework I’m working from.

If you’re a pre-seed/angel investor:

If you’re a founder pitching at pre-seed:

The medieval siege analogy feels right to me because it captures the brutality in an honest way. Most things don’t make it. The casualties are real, even if the walls are metaphorical.

But the founders who have something real, who are genuinely on a mission, who understand their problem better than anyone can still break through.

The job, as a pre-seed or angel investor, is identifying them early and having the courage to make a bet.

The moment that crystallized it: Figma’s Config 2023. Brian Chesky told a crowd of designers Airbnb had “gotten rid of the classic product management function.” The audience cheered. One tweet on the topic got six million views. Designers celebrated. PMs panicked.

Chesky later clarified he’d merged product management with product marketing. But the sentiment had spread. The broader critique wasn’t entirely wrong. A lot of PMs had spent years becoming backlog administrators and Jira ticket managers. That’s project management, not product management, and people could see it.

Then AI piled on. If everyone can build, why does a specialized role exist to manage the process?

The “PM is dead” crowd must feel pretty vindicated right now.

Except they’ve gotten it almost completely backwards. AI isn’t killing the need for product management. It’s making product management a skill everyone needs.

Subscribe now

Building Got Easier. The Hard Parts Didn’t.

Yes, AI has compressed the time and complexity of actually making things. A solo founder can build a working web app in a weekend. A marketer can spin up a prototype without filing a ticket. Anyone with an idea and some patience can ship something real.

I’ve been living this myself. I’m building stuff like crazy and it’s genuinely fun. Over the past few months I’ve built an LLM/SEO optimizer, an innovation toolkit, an applicant tracking system, an investor portal, a venture studio readiness tool, and a pile of automations. I’m a product person, not a developer. The line is getting blurry in ways I didn’t expect.

So yes. Building got easier.

But figuring out what to build? Still incredibly hard. Getting it into the hands of the right people and making them actually care? Harder than ever.

The cost of building wrong hasn’t gone down just because building got cheaper. If anything, it’s gone up. Because now everyone is building. The market is flooding with products, which raises the bar for everyone. Differentiation is harder. Getting your message out is harder.

And you know who else is building, or at least thinking about it? Your customer. If they look at your product and think, “I can just build that myself,” you’re in trouble Even if they can’t, the perception is powerful enough to kill a sale.

You’re Already Doing Product Management. You Just Don’t Know It.

If you’ve written a single prompt into an AI tool to build something you’re doing product management.

• Every time you decide what to build next, you’re doing product management.

• Every time you talk to a user (or skip talking to a user), you’re doing product management.

• Every time you choose which features to include, which to cut, and what success actually looks like, you’re doing product management.

• Every time you think about how someone is going to find what you built, you’re doing product management.

You’re doing it whether you have the title or not. Whether you’ve read a book or blog post about it, or listened to a podcast.

The question is whether you’re doing it well.

What I find fascinating is that product management skills are the very skills you need to use AI effectively to build something.

You need to think clearly about problems. Articulate what you want with precision. Break complex work into pieces that can be delegated. Synthesize messy, incomplete information into a decision. Catch when AI is confidently wrong and know how to course correct.

That’s not just AI literacy. That’s product management.

The moment everyone can build, the skills that were supposedly obsolete become the skills that determine whether you build something worth using.

Share

So What Are These Skills, Actually?

Product management confuses people because everyone has a different definition. The core is simple: find a real problem worth solving, build the right-sized thing that solves it, get it into the hands of the people who need it, and learn constantly throughout. It’s not easy, but it always felt pretty clear to me.

Here’s what it looks like in practice:

Know whose problem you’re solving. Not who you think has the problem. Who actually has it, how badly, and what they’re doing about it today. If you can’t answer those questions specifically, you’re building on assumptions. Assumptions that feel true are still assumptions.

Define success before you build, not after. What specific behavior change in users tells you this is working? What does the number look like in 90 days if you’re right? Set it before you write a single prompt. Otherwise you’ll rationalize whatever you ship as working, because you want it to be working.

Scope is a decision, not a default. AI makes it trivial to add features. That’s a trap. Lenny Rachitsky defines the job as “delivering business impact by marshaling your team to identify and solve the most impactful customer problems.” Not shipping everything you can think of. The best products do fewer things exceptionally well.

Distribution isn’t someone else’s job. Figuring out what to build is hard. Getting people to use it is equally hard. Product managers aren’t growth bystanders. Neither are you. If you’re building without thinking about how someone discovers, tries, and keeps using what you made, you’re building in a vacuum.

Your product needs to feel right, not just work. Use your own product obsessively. Feel the friction as a genuine first-time user. Notice what people don’t say in feedback sessions but reveal in their behavior. The judgment you build from this, over time, is what makes the difference between something that’s functional and something people actually want.

None of this is revolutionary. All of it gets skipped by people who just want to build.

Learn It By Doing. Not By Outsourcing It.

AI has a way of tempting us into being…brain dead. It’s so easy to agree with everything it outputs and stop reading and thinking.

AI can do a remarkable amount of PM work. It can synthesize user research, spot patterns in feedback, draft requirements, flag edge cases, simulate user reactions. That capability is real and improving fast.

But if you’ve never done these things yourself, you can’t tell when AI is wrong.

The judgment required to evaluate what AI gives you has to come from somewhere. It comes from talking to users, watching them use your product, shipping things that fail, understanding why they failed, and trying again. From the customer call where the data said one thing and the room said another, and knowing which one to trust. That instinct doesn’t come from reading about it. It doesn’t come from prompting your way through it. It comes from doing it.

Shreyas Doshi puts it plainly: “The only real long-term career moat for product people is how you can improve on the already-brilliant, already-comprehensive inputs and outputs that AI will provide for you.”

You can’t improve on something you’ve never tried to do yourself.

So if you’re new to building, here’s where to actually start:

Talk to five people before you write a single prompt. Not friends. Find five strangers who actually have the problem you think you’re solving. Understand how they solve it today, what it costs them, whether they’d change their behavior for your solution. If you can’t find five people with the problem, you probably don’t have a product yet.

Write your first product requirements by hand. Type it out. No AI help on this one. Describe what you’re building, who it’s for, what problem it solves, what success looks like, and what the riskiest assumption is. Then ask AI to evaluate it. You’ll learn more from writing it yourself than from anything AI could produce for you.

Launch smoke tests to validate the value proposition and your ability to get anyone to the front door. A smoke test is a way to see if you can attract users, but there’s nothing real yet. You might have a landing page with a few ads. Maybe you share some things on social media. You’re trying to test interest, perhaps a bit of conversion (e.g., through email signups). A lot of people skip this because they build and launch. When it doesn’t work, they’re not sure why, and there’s been little learning.

Build the smallest thing that tests your core assumption. Not the full vision. The one feature or flow that proves whether your hypothesis is true. Everything else is scope creep. AI will make adding more feel painless. It’s not. Don’t know what your core assumption is? Stop. Go back. That’s the first thing to figure out.

Use your own product as a stranger every week. Pretend you’ve never seen it. Where are you confused? What’s missing? What feels broken? This is not optional and it never gets easier, because your familiarity with your own product degrades your ability to see it clearly.

Expect to be wrong in important ways. Not about everything. But about the things that matter most. That’s how this works. The goal of a first version isn’t to nail it. It’s to learn what you got wrong fast enough to fix it before you’ve built too much on top of it.

The faster you can build, the more important it is to have done the thinking first.

Subscribe now

One Warning About AI and Product Skills

There’s a growing category of AI tools specifically designed to accelerate product management work. Frameworks, prompt libraries, agentic workflows that cover everything from discovery to strategy to go-to-market. A good example is pm-skills on GitHub, built by Pawel Haruyn: 100+ agentic skills replicating PM workflows end to end, nearly 9,000 stars. It’s genuinely impressive work and worth knowing about.

I use tools like this myself, including ones we’ve built at Highline Beta. In the hands of someone who knows what they’re doing, they’re a real accelerant.

That last part is the key.

These tools do a lot of things quickly, but without the product management fundamentals in your back pocket and an instinct for what’s good or bad, you’re following blindly.

This is the same failure mode PMs fell into before AI, just wearing different clothes. Before, it was mistaking status checks and coordination for product work. Now it’s running AI workflows and mistaking output for thinking.

The skills aren’t in the tool. The tool accelerates the skills. You have to build those skills first, or the acceleration is just moving faster in the wrong direction. (To be clear, I’m not referring to Claude Skills in this paragraph. 😆)

Product Management Isn’t Dead. It Became Everyone’s Job.

The irony of the “PM is dead” moment is that it was half right. The version of product management that died deserved to die: the backlog-managing, sprint-facilitating, paper-pushing version that confused coordination with creation.

It was never about that. It was always about judgment. About figuring out what’s worth building, for whom, and why. About caring enough about the user to understand them, and caring enough about the business to connect those two things.

That work doesn’t go away because building got easier. If anything, it matters more. When everyone can build, the products that win are the ones built by people who understand what they’re actually trying to do.

You’re going to build something with AI. You probably already are.

Guess what? You’re a product manager now. The only question is what kind.

What’s the hardest part of building with AI that no one prepared you for? Drop it in the comments.

These resources may help you get started:

• Test First, Build Later: A Guide to Validating Your Ideas With Stimulus & Prototypes

• How to Apply the Scientific Method to Startups Without Being a Zealot

• What Comes Before Zero to One?

• Build, Measure, Learn: The Expanded Edition

• Product Management is Communication

• Using Product Requirement Docs for Scoping Features & Uncovering Unknowns

You’ve probably heard the term, “a T-shaped person.” It’s been floating around business and tech for 40+ years, and there’s a reason it stuck.

The concept traces back to the 1980s, when McKinsey & Company started using it internally to describe the ideal consultant profile. It made its way into mainstream business conversation when David Guest coined the term publicly in 1991. By 2001, Harvard Business Review had put a formal frame around it in an influential article about T-shaped managers and knowledge sharing. Then Tim Brown, CEO of IDEO, brought it to an even wider audience in a 2010 interview that became the most-cited articulation of the model.

The model spread fast. It got baked into agile methodology, talent acquisition, career development frameworks, and performance management systems.

McKinsey still uses it. A 2023 CompTIA study of HR and L&D professionals across the US and UK found companies still actively use the T-shaped model to guide talent management and training. Forty-plus years after it was coined, it remains the dominant mental model for what a great hire looks like.

Subscribe now

The visual is simple, which is part of why it works:

• The vertical bar of the T = deep expertise in one domain. Your specialty. The thing people hire you for.

• The horizontal bar = enough breadth to collaborate across disciplines. The ability to sit in a room with people from other functions and actually contribute to the conversation.

Research backed it up. Studies on agile teams consistently showed T-shaped members outperformed specialist-only groups on complex, ambiguous problems.

The concept got refined over time: Pi-shaped (two verticals), comb-shaped (many verticals), and more. Consultants, futurists, and HR practitioners kept iterating on the model.

But the core idea held for decades: be great at one thing, and be collaborative enough to work well with people who are great at other things.

That model is no longer enough.

What the T Got Right (And What AI Just Unlocked)

The original definition was more nuanced than most people remember.

Tim Brown, who popularized the model at IDEO, described the horizontal bar this way:

It’s the disposition for collaboration across disciplines, built from two things. First, empathy. The ability to stand in someone else’s shoes and understand a problem from their perspective. Second, enthusiasm for other disciplines, “to the point that they may actually start to practice them.”

That second part is the key phrase. And it’s the one AI just supercharged.

In the pre-AI world, enthusiasm for other disciplines had a ceiling. You could be genuinely curious about how engineers think, or how data analysts work, or how a marketer approaches positioning. You could follow that curiosity into books, courses, or conversations. But converting that curiosity into actual capability took years. Apprenticeship. Formal training. Time you often didn’t have.

So for most people, in most roles, the horizontal bar stayed at “collaborative and empathetic.” Genuinely valuable. But not execution-level.

AI removes that ceiling.

If you have the enthusiasm and the natural inclination to figure things out on your own, you can now actually do it. Not perfectly. Not at the level of a specialist with a decade of practice. But well enough to build something real, do or ship something useful, and keep learning from doing.

The curiosity was always the unlock. AI just made it exponentially more powerful.

What I’m Seeing From My Own Work

I’ve been building a lot lately.

• An LLM/SEO Optimizer (if you’re interested, let me know!)

• An innovation toolkit using Highline Beta’s best practices.

• An applicant tracking system for Highline Beta and a few of our portfolio companies.

• A web app for evaluating corporate venture studio readiness.

• A ton of different automations for interlinking blog posts, adding LLM-specialized content to my web site, naming screenshots, removing backgrounds on images, and more.

These are all things I would have never touched even a year ago, because (a) I didn’t think they were my job; and (b) I didn’t have the capabilities.

I’m a product person. Not a developer. But the line is getting blurry in ways I didn’t expect.

Every week I’m posting on LinkedIn about new things I’m building or figuring out with AI. It’s not a flex. It’s just freaking cool what’s possible. Meanwhile, the tools keep improving, the things you can do keep expanding, and the skills I’m acquiring — even imperfectly — are changing how I think about my own work.

That’s when Tim Brown’s original framing really clicked for me.

I always had the enthusiasm for adjacent disciplines. I was always curious about how developers think, what good system design looks like, what separates a working product from a fragile one. I’ve been building software for 30 years, so I have a solid base of knowledge and experience, but now it’s growing exponentially.

AI is unlocking things I never thought possible. I’m not just collaborating with developers anymore. I’m doing development. At a certain level, in a certain context. Not at the level of a senior engineer building sophisticated systems. But building real things that work and deliver real value.

The curiosity was always there. AI just let me follow it all the way through to execution.

Share

What AI Is Actually Doing to the T-Shaped Model

For most people, in most roles, the horizontal bar was decoration.

Not useless decoration. But you weren’t expected to ship code, or build an analysis, or run an ad campaign. You were expected to understand it well enough to direct someone else to do it or provide other experts with the information they needed to do their jobs.

That’s changing across every function, and fast.

Marketers are doing data analysis. Designers are shipping code. Operations people are building automations that used to require an entire engineering sprint. Finance folks are generating their own reporting without waiting two weeks for a data team. Product managers are building the things they used to only spec out.

Beyond that, marketers are now building products. Product managers are doing growth (which, in my opinion, should have always been their job), developers are doing design and so on.

This isn’t theoretical. This is happening right now, at companies of all sizes, across industries.

The horizontal bar is no longer about perspective. It’s about capability. Real, functional capability. Not “I can have a conversation with the engineer about this.” It’s now, “I can build a version of this myself and iterate on it.”

That’s a different standard. And it’s coming whether or not people are ready for it.

Wealthsimple Jumped In With Both Feet

Recently, Wealthsimple launched an AI Builders program. Pay attention to how they describe what they’re looking for:

“We’re looking for people who look at a broken process and can’t help but imagine what it should be. Who move fast in ambiguity, own problems end-to-end, and think carefully about where AI should — and should not — take responsibility. Your story tells us where you’ve been. Your build tells us where you’re going.”

Dig in a bit more and you’ll find the key signal: they explicitly say that your CV isn’t everything. Degrees and experience aren’t the gating criteria. What you can build is.

This is a major Canadian fintech with hundreds of thousands of customers, not a scrappy four-person startup, saying: the old signals of competence don’t automatically apply anymore.

They’re not alone. They’re just one of the first bigger companies to say it out loud.

The T-shaped model was built on the assumption that your vertical is your primary value, and your horizontal is a nice bonus. What Wealthsimple and others are signalling is: we need the horizontal to be real. Not soft skills. Actual functional capability across multiple domains.

So What Does the New Shape Look Like?

I’ve thought a lot about this, and I don’t think a new letter captures it.

Pi-shaped. Comb-shaped. These add more verticals, which misses the point. The problem isn’t that people need two specialties instead of one.

The problem is that the horizontal bar has to become load-bearing. It has to represent actual capabilities, not just social ones.

Maybe we should just turn the T upside down…

In the old model:

• Horizontal = breadth of perspective, mostly soft skills

• Vertical = where you actually deliver value

In the new model:

• Horizontal = real functional capability across multiple domains, powered by and through AI

• Vertical = still important, but increasingly table stakes rather than your primary differentiator

It kind of looks like Thor’s hammer. Not everyone is worthy…

Your specialty doesn’t disappear. But it’s no longer enough on its own, and the breadth piece is no longer optional.

Subscribe now

AI Empowers Learning. It Doesn’t Replace It.

Before anyone gets the wrong idea: using AI doesn’t make you an expert in everything. Let’s not be silly.

I can build a working web app with Lovable or Claude Code, but I’m not a developer. I know enough to be useful. I know enough to ship something that works. I don’t know enough to architect systems at scale or debug deeply weird infrastructure problems. It’s easy to get caught in the hype and think that you can vibe code your way through anything. You can’t. You need enough foundational understanding to know when the AI is steering you wrong. And at some point, you need to bring in the experts.

AI compresses the time it takes to become functionally capable in something new. It doesn’t automatically install expertise.

What it does do is dramatically lower the activation energy.

That domain you always said was “not your area”? You can explore it now. And not just theoretically. You can build something in it. Fail at something in it. Learn from the failure. Iterate. That loop used to take years of apprenticeship or formal education. Now it can take weeks of deliberate experimentation.

That’s not magic. But it changes the math on what’s possible for any given person to develop.

The Skills That Actually Need to Be in the Horizontal Bar

If the horizontal bar is becoming load-bearing, what actually needs to go in it? I’m not talking about specific tools — those change too fast. I mean the underlying capabilities.

1. Comfort with ambiguity

People who need clear instructions before starting anything will struggle. AI-augmented work is exploratory by nature. You often don’t know exactly what you’re doing until you go through the process a couple times. If you freeze without a detailed spec, or you require a lot of handholding, that’s a problem.

2. Speed of experimentation

The willingness to try something, watch it fail, understand why, and try again. Not as a formal process. As a reflex. The people posting weekly about what they’re learning and building aren’t more talented than everyone else. They’re running more experiments and learning faster because of it.

Learn by doing. Please. I’m borderline begging you, because otherwise you’ll be obsolete.

3. Judgment about AI outputs

AI will confidently give you wrong answers (although it’s getting better). It will build things that work in demos and break in production. Knowing when to trust it and when to push back is a skill you develop through use, not through reading about it. You have to get your hands dirty to build that judgment. And as the Wealthsimple Builders program suggests, that judgment is going to become a critical skill for hiring.

4. Cross-domain curiosity

You can’t expand your horizontal bar if you’re only interested in your vertical. The people winning right now are genuinely curious about adjacent domains; not obsessively, but enough to explore and ask questions and try things.

Through building my LLM Optimizer I’ve done a deep(ish) dive into Schema frameworks, SEO, FAQ-style content, citations versus mentions, and more. I am not an expert at optimizing a website for LLMs, but I’m dangerous enough to do some cool things.

5. Self-directed learning

Universities aren’t teaching this. Most companies aren’t either. The people getting ahead are figuring it out themselves, sharing what they find, and iterating in public. Waiting for formal training is a losing strategy at the pace things are moving.

There are useful resources online to help, but relying on them isn’t worth it. Virtual classrooms are still classrooms. Pick up a few tools and get at it!

What This Means If You’re Paying Attention

If you’re a founder or exec: the T-shaped heuristic still works, but you need to re-weight it. The horizontal bar is becoming your primary filter, not a tiebreaker.

Can this person operate across domains? Are they learning fast? What have they actually built or figured out recently?

Those questions matter more than they used to.

The next time we’re hiring at Highline Beta, I’m all-in on the horizontal bar of the T. I don’t need deep experts in any particular field that are only interested in staying in their lane. I need people willing to say, “I’ve never done that before, but I can figure it out.” People that are insanely curious. People that just try stuff and figure it out. Without waiting to be told, without asking permission.

If you’re an individual: you need to deliberately expand your horizontal bar with real capabilities, not just soft skills. Pick one adjacent domain and get your hands dirty in it. Not a course. Not a certification. Build something. Ship something. Fail at something and figure out why.

If you’re in the middle of a career: the people who will be fine are the ones engaging now, with curiosity and a bias toward action. The people waiting for things to stabilize before jumping in are going to find the window closes faster than expected.

I’m not trying to panic anyone. But I’m living this awakening of “generalist superpowers” for myself and the rate of change is overwhelming.

The T Needs to Grow Up

The T-shaped model was a real insight. Depth plus collaborative breadth. It worked for decades.

But it was built for a world where the horizontal bar was a multiplier on your vertical. Today, the horizontal bar is becoming the foundation. “Collaborative” isn’t enough to describe what needs to be there.

The T needs to get wider. Much wider. And the width needs to mean something beyond being easy to work with.

The people who are building that broader foundation right now, even imperfectly, even messily, are the ones who will have the most options when this shakes out.

Start building. Even if you don’t know what you’re building. Especially then.

Sounds crazy, but it’s true.

And there’s science backing it up.

Meanwhile, the world is more disconnected than ever.

We live in silos with earplugs in, screaming at the world.

It’s disturbing. And sad.

My two adult children were home from university last week. We got to talking about AI, because I’m hacking away using tools like Lovable, Claude Code and others to build stuff I never thought possible on my own. I’m like a kid in a candy store.

They have a different opinion, and it’s not hugely positive.

Why?

My sense: they’re overloaded with AI slop from Instagram, TikTok and elsewhere. They can’t tell what’s real anymore. It feels like a tsunami of endless crap. Meanwhile the whole world is telling them humans are obsolete just as they’re entering the workforce.

Ouch.

Wrap that whole beautiful bun of awesomeness in the fact that younger generations are lonelier than ever (and they’re not the only ones). Everyone’s scrolling. No one’s connecting.

We’re all disconnected, overwhelmed by AI and lonely.

That’s not a great combination.

But a 15-minute call will make you happier?

Yup, it’s true.

I want to introduce you to Twos.

That’s my personal invite link to join.

It hasn’t fully launched, so you’ll need to setup TestFlight first and then install the app. But we’re hoping to get a few more brave folks to join us early!

Twos is the brainchild of a father-son duo, who came to Highline Beta with the goal of “reconnecting humanity.”

Just a tad ambitious, but why not? 😊

If I can put a bit of goodness into the world, I want to try.

They had an idea:

• What if we could connect people together for 15-minute video calls in a safe, secure space? Match people based on interests, conversational style and how they’re feeling. Measure post-call mood. Use science, but not in an overwhelming way.

• What if a 15-minute call every day with a stranger could make people feel better?

• What if enough people called enough strangers every day that the world got more connected?

What if?

Twos describes itself as quality conversations with real people.

AI helps you onboard, but the goal is to connect you 1:1 with someone to share, laugh, cry, listen, vent, help and…be human.

• Twos is not for therapy. If you need mental health support please find professional alternatives for that.

• Twos is not for dating. If you’re looking for love, there are plenty of other places.

Dr. Sonja Lyubomirsky is a Professor at the University of California and Twos’ Chief Scientist. She’s an expert in the field of happiness. Studying happiness is a thing, because finding or achieving it isn’t easy.

This quote from Sonja sums it all up:

I’ve been working with the Twos’ team for awhile, along with my team at Highline Beta. It’s been a very interesting experience. B2C is tough. How can you really know if something will take off? There’s an element of “magic” or “lightning in a bottle” that’s tough to predict.

We did a lot of research, experimentation, prototyping and validation. The Twos team kept going: testing, iterating, learning, redoing, trying again, testing, iterating, learning. You get the point.

Building something that people will love is not easy. And there’s still a long way to go. ❤️️

But there’s something intriguing about 15-minute calls with strangers. How will the call go? Will you enjoy it? Will you feel better? Will you have enough to talk about?

It turns out, in most cases, if you put two people together in a safe space and ask them to have a conversation, they do exactly that.

They find something to connect about. Twos prompts you with topics if you get stuck, but most people go with the flow. It feels awkward at first, but then you realize: (a) talking to people is OK; and (b) you never have to speak with the same person twice (if you don’t want).

Twos is not a social network. It’s not built to create followers, authority or brand. Remember: Quality conversations with real people.

If you try Twos (and I hope you do!) you’ll notice a couple unique things about it. For starters, in video calls you won’t see yourself. Don’t panic! It’s awkward at first because you’re used to staring at yourself in FaceTime, Zoom, Google Meet, Teams, etc. Twos took a different direction. Full video of the person you’re speaking with; no tiny video of yourself.

When I first experienced it, I flat out said, “This is weird.” And then I forgot about it because I was more focused on the person I was talking to. I stopped worrying about how I looked and just…talked.

Another interesting feature is how you connect with others. Since it’s not a social network, there’s no friending or following. You open up a “card pack” and it reveals matches that are available to talk.

If you don’t find people to talk to right away that’s OK. A new pack will show up soon enough and you can try again. Twos isn’t trying to keep you in the app endlessly. We hope you find someone to talk to, in the moment, feel a bit better, and go on with your day. Come back when you’re ready for more conversation!

I hope Twos wins.

Not because Highline Beta helped build it, but because it could actually make a difference. If Twos can reach enough people, and those people decide that speaking to a stranger isn’t weird, but actually healthy…we may have the antidote to mindlessly doomscrolling AI slop on social networks.

Maybe, we make the world a little less lonely.

Maybe, we make the world a little bit happier.

Maybe, we make it possible for two people that otherwise would never have connected to do exactly that.

Twos will be available in the iOS App Store soon. In the meantime, if you’re a bit courageous and curious, get early access. And maybe we’ll get matched and have…dare I say it…a conversation.

On one side, founders and execs are whispering (perhaps loudly): “Do we still need junior people?”

On the other side, universities are still graduating them like it’s 2012. (From 2012-2025, the US population grew ~9%; undergraduate degrees issued grew ~17% in that same time.)

In the middle, there’s AI.

Not as a vague force or sci-fi villain. But as a very practical tool that is already reshaping how work gets done.

I want to argue something specific (before we all run for the hills): AI might be the best training tool we’ve ever had.

Not because it’s magical or will save us from job losses (jobs will be lost, let’s not be naive).

But AI can compress the time it takes to go from “new” to “useful.” If we don’t intentionally use it that way, the alternative is obvious: We delete the bottom rung of the career ladder.

Subscribe now

The Hidden Cost of “New”

Every organization has the same problem.

New people are expensive, because they’re new. Onboarding uses precious resources. Getting a new person to a competent level is a real investment.

Often you see newbies miss invisible steps, struggle to understand what “good” looks like, make preventable mistakes, interrupt senior people constantly and require constant feedback.

Most companies “solve” this with:

• Documentation nobody reads

• A shadowing process that depends on one generous senior

• Or worse, vibes (not to be confused with vibe coding, which I’m a fan of!)

Training is rarely designed. It just sort of…happens.

AI changes that equation. It’s already being proven.

In an MIT & Stanford joint research study, Generative AI at Work, they tested the use of AI in a few circumstances with junior and senior people. One example focused on customer support, providing people with AI tools to help them resolve issues. The lowest skilled and newest human agents (which now requires specifying in a world of AI agents)) to the job, saw the biggest lift in resolutions per hour thanks to AI.

The study found that novice and low-skilled workers saw a 34% improvement, whereas highly experienced and skilled workers saw minimal improvement.

Let me give you three other examples that I’ve experienced over the last few months.

1. The Hackathon for Developers

At a recent hackathon hosted at Highline Hub, Alexander Zidros built something called DevFlow. He described it as an always-on task tracker for software developers, helping track the tiny steps between “in progress” and “done.”

During his presentation he said:

This could be valuable for new developers that may not appreciate all the tiny things that have to be done properly to go from idea to production grade code.

I lchuckled because I had written that exact thought in my notes before he said it.

New developers don’t struggle because they lack intelligence. They struggle because the work has hidden structure.

Senior engineers know:

• Edge cases to check

• Deployment nuances

• Testing expectations

• Naming conventions

• Performance implications

• What “done” actually means in production

Juniors see the feature(s). Seniors see the system.

While AI is doing a lot of the coding, developers are valuable orchestrators, and junior + orchestration = very risky, unless properly trained.

2. The Professional Services Signal

In recent conversations with leaders inside a professional services firm, they told me about internal prototypes designed to review work and provide feedback.

The goal was obvious:

• Maintain quality

• Speed up delivery

• Help new employees internalize standards faster

What struck me wasn’t automation. It was reinforcement.

AI reviewing deliverables against company-specific best practices, industry norms, style guidelines and regulatory requirements isn’t “replace the analyst”, it’s “train the analyst in real time.”

Maybe the most powerful use of AI in knowledge work isn’t generation, it’s review. And review is how standards transfer.

Share

3. Personal Experience Exploring Insurance Opportunities

Some time ago, Highline Beta was working with a partner to explore new venture opportunities in insurance, specifically around smaller agencies and brokers. We learned something interesting: they’re often held back by their ability to onboard new brokers quickly.

Why?

Because most training happens by osmosis.

New brokers:

• Sit in on calls

• Watch senior brokers negotiate

• Absorb patterns

• Learn what not to say the hard way

Almost none of that tribal knowledge is formally documented.

When we floated the idea of AI-assisted onboarding, the interest was strong. But there was an immediate constraint: “It can’t just be generic best practices.”

Each firm wanted to infuse the AI with their own expertise around qualifying clients, structuring renewals, handling edge cases, managing risk, building trust and more.

That means extraction. You might think, “How different can one agency’s onboarding be compared to another?” Tough to say, but the perception is there, and perception is reality.

So AI can play a role as:

• Knowledge capture engine

• Pattern recognizer

• Internal playbook enforcer

It’s not about replacing brokers, it’s about accelerating them.

The Fork in the Road

Here’s where it gets uncomfortable.

There are two obvious ways companies can deploy AI.

Path 1: Replace juniors

We’re already seeing signs of this.

• A Stanford Digital Economy Lab paper using ADP data found early-career workers in AI-exposed occupations are experiencing disproportionate employment pressure. Entry-level roles appear especially vulnerable.

• SignalFire’s 2025 State of Tech Talent report shows new grads now make up a much smaller share of hires compared to pre-pandemic levels.

• Dario Amodei, CEO of Anthropic, has warned that AI could eliminate a significant portion of entry-level white-collar jobs in the next few years.

Even if the precise numbers shift, the direction is clear.

The bottom rung is wobbling.

Path 2: Compress time-to-competency

Instead of eliminating juniors, you could:

• Reduce preventable mistakes

• Make expectations explicit

• Provide instant feedback

• Turn months of ramp-up into weeks

This is the version I’m arguing for.

Not because it’s guaranteed.

Because it’s intentional.

Subscribe now

What Matt Shumer Got Right (And Why It Freaked Me Out)

Matt Shumer wrote a piece titled “Something Big Is Happening.” It’s a wake-up call. Most of you will have read it by now.

He highlights the pace of AI progress, including models contributing to their own development cycles. AI is building itself. Come on now! The feedback loops are accelerating. The capability curve is steep.

His tone isn’t calm. It’s not “incremental change.” He’s saying, “this is moving faster than most people realize.”

I know this isn’t a fad. The technology works, it improves predictably, and the richest institutions in history are committing trillions to it.

I know the next two to five years are going to be disorienting in ways most people aren’t prepared for. This is already happening in my world. It’s coming to yours.

I know the people who will come out of this best are the ones who start engaging now — not with fear, but with curiosity and a sense of urgency.

And I know that you deserve to hear this from someone who cares about you, not from a headline six months from now when it’s too late to get ahead of it.

We’re past the point where this is an interesting dinner conversation about the future. The future is already here. It just hasn’t knocked on your door yet.

It’s about to."

He’s right.

Reading it scared the hell out of me.

Not because I think we’re doomed tomorrow.

But because I have two adult kids in university.

And I found myself thinking: What does the job market look like when they graduate What does “entry-level” even mean? Who trains them if nobody hires them?

That’s the structural risk.

If AI replaces junior roles, we don’t just lose jobs.

We lose the apprenticeship layer that produces future experts.

Societies run on apprenticeship, whether formal or informal.

Remove it, and five years later you wonder why nobody knows how to make hard decisions.

Schools are Stuck

High schools and universities are not built for exponential tooling shifts.

They optimize for standardized evaluation, information recall, controlled environments and syllabi that don’t change mid-semester (or ever).

I know there are many people at schools trying to move the needle, but it’s borderline impossible.

The real world now optimizes for ambiguity, tool fluency, self-directed learning and continuous adaptation. You’ll be hard-pressed to find that in school.

Most students are not being trained to:

• Work alongside AI

• Validate outputs

• Build judgment in AI-augmented workflows

• Understand where AI fails

• Hack

• Build things. Anything…just build something…please…

And many companies are not helping. I get the concerns around privacy, security and compliance, those are real issues. But “ban it” is not a strategy. It’s procrastination. Frankly, the question is whether or not big companies can even remotely keep up, because the pace of change is faster than ever before.

What AI Training Actually Looks Like

If we’re serious about AI as a training accelerant, it needs structure.

Here’s the practical model.

1. Make “good” explicit

Use rubrics. Define quality thresholds. Codify “definition of done.”

If a junior can’t articulate what great looks like, they cannot self-correct.

AI can enforce and reinforce that definition constantly.

2. Embed feedback inside work

Training is not a course. It’s a loop.

Do work → get feedback → revise → repeat. Dare I say, “build, measure, learn”?

AI should sit inside the workflow, not in a separate portal nobody opens.

3. Capture tribal knowledge intentionally

Interview senior staff. Extract patterns from past work. Turn recurring advice into structured guidance.

Treat knowledge like product. Because it is.

4. Simulate edge cases

Judgment forms under pressure.

AI can simulate difficult clients, objections, compliance traps, unexpected constraints and more.

It’s safer to fail in simulation than in production.

The Cultural Risk

If AI becomes “the boss,” this fails.

If AI becomes a reviewer that replaces mentorship, a surveillance tool, or a blunt cost-cutting instrument, people will resent it.

AI should amplify senior staff, not erase them. It should reduce repetitive review load, not eliminate human judgment.

Humans still need to:

• Own standards

• Approve exceptions

• Model judgment

AI can’t inherit responsibility. It can only inform it.

So Where Does That Leave Us?

I’m worried (but not panicked, despite the hilarious Chris Farley image).

I’m worried about the next generation.

I’m worried about universities moving slowly.

I’m worried about companies waiting too long to experiment or truly change how they work.

But I’m not ready to declare doom.

People still hire people for accountability, trust, nuanced judgement and relationship building.

Those things have not vanished. What has changed is the baseline.

The future belongs to:

• People who understand how to use AI

• People who know its limits

• People who get their hands dirty

• People who don’t wait for permission

Matt Shumer is right: the acceleration is real, but the worst response is denial. The second worst response is passive fear.

The best response is intentional deployment.

If we design AI systems that delete the bottom rung, then we break the pipeline.

If we design AI systems to compress time-to-competency, we strengthen it.

That’s a choice.

If I’m thinking about my kids, your kids, and the next generation of founders and operators, I’d much rather fight for the second path, because it feels more sustainable than the alternative, where we all just sit around doing our hobbies because we’re unemployable.

The world may be changing faster than we’re comfortable with, but we still get to decide how we build within it. And right now, the most leverage might not be in replacing newbies. It might be in training them better than we ever have before.

Alternatively, let the newbies burn and everyone goes into the trades or becomes a founder (I realize that took a quick turn!) Robots are well behind AI, so the trades are safer, and I’ll always bet on entrepreneurs over AI to create net new value. We need more founders. ❤️️

In May 2024, I wrote We Need More Founders. The core argument was straightforward: Founders drive economic value.

✅ They create companies.

✅ They create jobs.

✅ They create optionality in an economy that otherwise drifts toward stagnation and concentration.

That belief hasn’t changed. If anything, it’s become more obvious.

But there’s a missing piece in that story that doesn’t get nearly enough attention.

If we want more founders to succeed, we need more angel investors.

🚫 Not more conferences.

🚫 Not more ecosystem reports.

🚫 Not more think pieces about “what’s broken.”

More people writing early checks.

Subscribe now

Founders Don’t Create Value in a Vacuum

Even in the age of AI, founders still need capital.

The tools are cheaper, it’s easier to build and experiment, and a single person can now do the work that used to require a small team.

All of that is true.

But none of it eliminates the need for initial risk capital. It just changes how that capital is used.

Before you have traction, paying customers or any institutional investor will take your call, that first capital almost always comes from angel investors.

If you believe founders drive economic value, you have to accept the next step in the chain: Founders need early capital to unlock that value.

The Flywheel that Actually Matters

Healthy startup ecosystems are not mysterious. They’re repetitive.

The flywheel looks like this:

1. People start companies.

2. Some of those companies win.

3. A subset of founders who win become angel investors.

4. Those angels fund and support the next generation.

5. The cycle repeats, with better odds each time.

This is not theoretical. It’s how every strong startup ecosystem compounds over time.

The reason angels matter so much is not just the money. It’s the recency of experience.

The best angels have lived through:

• early hiring mistakes,

• product-market fit confusion,

• pricing experiments,

• distribution failures,

• fundraising errors,

• and founder stress that doesn’t show up in decks.

That experience is most valuable at the beginning, not the Series B (although having great investors later on with Series B experience is also important!)

When that flywheel works, ecosystems build momentum.

When it doesn’t, ecosystems stall and look outward for validation.

(Note: Sometimes the people who win become VCs. That’s also a good thing, although I think it’s better if they become angels first. And VCs are, unfortunately, a real choke point, not a huge enabler in a market where they’re building relatively small portfolios and picking after there are more signals. Angels make the earliest, riskiest bets, and without that taking place, you can’t build a healthy startup ecosystem.)

Step Two is the Choke Point

Most startup journeys, regardless of geography, follow a similar arc (or at least try to):

1. Start the company.

2. Raise angel capital.

3. Prove traction. (Sometimes this comes before raising angel money too.)

4. Then worry about larger rounds.

I recognize this is a gross over-simplification of the process! But if step two fails, nothing else matters.

You can talk all you want about the lack of venture capital, growth funds, or late-stage financing. If startups can’t get off the ground with a bit of early support, they never reach the stage where those conversations are relevant.

Angel capital is what turns “an idea with ambition” into “a company with a chance.”

• Without it, you don’t get enough experiments.

• Without enough experiments, you don’t get enough wins.

• Without wins, you don’t create new angels.

No flywheel. Just friction.

(Incidentally, venture studios can also play this role, because they’re there at the very beginning and provide capital. But venture studios often need early external capital too. Where does that come from? You guessed it: angel investors.)

Share

Angel Investors Are Not Optional Infrastructure

This isn’t just intuition or anecdote. There’s real evidence that angel investors materially improve startup outcomes and local ecosystem health.

Research from the U.S. National Bureau of Economic Research studied startups that were just above or below angel investment thresholds and found that angel-backed companies were:

• significantly more likely to survive,

• more likely to hire employees,

• and more likely to successfully exit the “startup phase.”

Importantly, these effects were strongest outside of major startup hubs, where angels often represent the only realistic source of early risk capital.

In other words: angel investors don’t just pick winners. They create more viable companies in the first place.

This matters at the local level. When early-stage capital is available nearby, more people are willing to try. When it isn’t, fewer companies get started, fewer founders win, and fewer future angels are created.

That’s not a funding gap problem.

It’s a compounding failure problem.

For more evidence on the topic, check out these posts:

• How Angel Investors Support Early-Stage Startups (Allied VC)

• The long-term impact of entrepreneurial financing on job creation based on the roles of venture capital and angel investment (ScienceDirect)
  

A Quick Aside on YC and Secondary Markets

Recently, Y Combinator made a change that removed Canada from the list of jurisdictions it invests in, pushing founders toward incorporating in the US if they want YC funding (which btw, they always encouraged). This sparked a lot of debate, especially in Canada. (Here’s a Betakit article for example, and an X thread from Fahd Ananta.)

Some people panicked. Others downplayed it. Some treated it as an existential signal.

It’s none of those things.

Here’s my perspective for founders from secondary markets (basically anywhere except Silicon Valley/SF and perhaps New York):

• leave if you need to (or want to),

• incorporate elsewhere if it helps,

• stay local if it makes sense, or because you prefer to.

Optimize for winning. Or don’t. Your call. It’s your company, no one else started it. That gives you the right to decide how you want to run it, and where you want to run it. If you leave a secondary market and people bemoan your decision, tell them to f**k off and start their own companies.

But if you win, after leaving or not, just remember where you came from and return the favor to the next founder. Invest.

Why Angel Investing Matters Even More in the Age of AI

AI changes the startup equation in two important ways.

1. First, more people can build more things. AI lowers the friction to experiment, prototype, and ship. That should increase the number of people attempting to start companies, which is a good thing.

2. Second, the capital required to reach meaningful proof points is dropping for many software startups. You can now do more with fewer people and less money. That’s been happening for awhile, but it’s even clearer now (there are exceptions, of course).

Put those together and you get a simple conclusion: Angel investors are more leveraged than ever.

A relatively small amount of capital, pooled across a few angels, can give founders just enough runway to:

• validate a real problem,

• test distribution,

• get early customers,

• and earn the right to raise the next round.

AI doesn’t eliminate the need for capital. It shifts where capital has the most impact. Increasingly, that impact is at the very beginning.

Subscribe now

How to Become an Angel (Without Cosplaying as One)

Let’s get practical.

⚠️ Calling yourself an angel investor does not make you one.

⚠️ Being in an angel group does not make you one.

⚠️ Attending pitch events does not make you one.

⚠️ Having opinions does not make you one.

💰 Writing checks does.

Basically, don’t be this guy ⬇️

This matters because in smaller markets especially, there’s a lot of “big fish, small pond” behavior. People get status from proximity to startups without actually taking risk.

That doesn’t build ecosystems.

My goal isn’t to be overly negative or pessimistic, but to focus on what matters: dollars going into early stage startups, quickly, under fair and reasonable terms, to give those startups an improved chance of succeeding. Which in turn creates more value for everyone.

1. You actually have to invest

Being an angel who helps build a community means:

• committing capital,

• accepting that most investments won’t work,

• and understanding that doing nothing is the least helpful position.

You don’t need to spray checks everywhere.

You do need to participate.

No checks equals no flywheel.

2. Start smaller than your ego wants

New angels often oversize their first checks.

Smaller checks let you:

• build a portfolio,

• learn faster,

• reduce emotional attachment to any single deal,

• and stay in the game longer.

Angel investing is not about finding one winner (although winners are nice!) It’s about giving multiple founders a real chance.

3. Optimize for learning early

One of the biggest early returns in angel investing is not financial. It’s learning.

You learn:

• how founders behave under pressure,

• what real early traction looks like,

• which markets surprise you,

• and how often your instincts are wrong.

You also learn about what you like to invest in, and start to develop a thesis that can help you find the right founders to back.

The learning compounds quickly if you’re paying attention. The more you learn, the better you become as an angel investor, which helps you (from a financial return perspective) and the founders you support.

4. Be useful, not performative

Founders don’t need more loud advisors with hot takes.

They need:

• timely introductions,

• honest pattern recognition,

• direct feedback without drama,

• and support when things get uncomfortable.

Sometimes the most helpful thing you can do is say nothing. Sometimes it’s one intro or one message at exactly the right moment. Sometimes it’s a hug.

Angel investing is not about being visible. It’s about being useful. And, founder friendly. There’s a time to push back on founders, and express your genuine concern and frustration—you’re not there to sugarcoat. But founders go through enough crap, they don’t need more. Back them up and be there for them when things get tough. They’ll remember and appreciate it. Your reputation in the market will grow. You’ll get into more and better deals.

5. Remember why you’re doing this

Of course, returns matter. But most great angels don’t do this purely because of expected value math.

They do it because:

• they enjoy supporting builders,

• they want to stay close to creation,

• they want to give founders a better experience than they had,

• and they believe strong companies lead to strong economies.

Founders can tell the difference.

Before Highline Beta, I was an angel investor, and learned a lot. I shared those learnings a couple years ago:

A Simple, Actionable Example

Recently, I was speaking with a senior executive in a mid-sized Midwest US city. He’d had a long, successful corporate career. He was leaving to start his own consulting practice. And like many people in that position, he was eager to “help the local startup ecosystem.”

He asked the question I hear all the time: “What’s the best way for me to actually make a difference?”

My answer was simple: Become an angel investor.

Not an advisor with opinions, or a mentor who never commits. And not someone who attends events and talks about potential.

Write checks.

Even relatively small ones.

In markets like his, one or two new angels who actually invest can:

• help a handful of founders get started,

• create early momentum,

• and start a flywheel that didn’t exist before.

In my experience when one new angel emerges, others follow. They see someone doing it, especially someone they trust, and then they want to participate. So not only does angel investing drive more quality startups in a local ecosystem, it creates more angel investors. And the flywheel strengthens.

Startup Ecosystems are Built by People Who Write Checks

If you believe founders drive economic value, then act like it.

If you believe startups matter, fund them early.

If you’ve won as a founder, pay it forward.

If you call yourself an angel, write checks (you can start at $5k!)

If you sit on the sidelines collecting status without risk, stop pretending you’re helping.

AI will increase the number of people building. That only matters if we increase the number of people funding the beginning.

Angel investing is not charity. It’s not a hobby or brand (although it can help you build your brand!). It’s infrastructure.

Angel investing is one of the few ways experienced operators and founders can directly shape the economic future of the places they live.

We don’t need more commentary. We need more angels who actually invest.

That’s how ecosystems compound. 💪

The goal of the hackathon was to build tools that help software teams build better. Most participants, as developers, built tools for developers, but some projects focused on other stakeholders too.

I spent a total of 16 hours working across two days. The hackathon ended Saturday night, and I was exhausted. The last hackathon I was involved in was 15 years ago. This was fun, and I hope we host more hackathons at Highline Beta in the future. (If you want to host a hackathon at our office, or any other events, check out Highline Hub.)

Subscribe now

So what did I build?

Introducing Subtexting, the universal translator to decode what your coworkers really mean. 🙃 🤭 😒 🤡 🤢

• Have you ever had a developer tell you, “It’s going to take two times as long as the original estimate to build that feature, because I need to refactor a bunch of code.”

• Or a salesperson say, “Can we get this one, tiny feature built ASAP? I’ve got a client that’s ready to close if we add it. I don’t think it’s a complicated feature to build.”

• Or a product manager say, “We need to reprioritize the sprint plan that we agreed to last week, we uncovered something really important!”

• Or an executive stakeholder ask, “How’s it going?”

Of course you have! But what do they really mean?!?!

That’s where Subtexting comes in. Input a message (one you might say to someone, or one that you’ve heard someone else say) and figure out what people really want to say.

Share

I built this (mostly) as a joke.

You’ll notice the tone options are Savage and Extra Savage. Subtexting only spits out crazy responses (although they’ll be on the nose a lot!) Do not use Subtexting to improve how you communicate with coworkers. But does it actually give you a bit of insight into how people are feeling? Yes.

Please give Subtexting a try! You can translate stuff for free, with no user accounts required. If you want to engage with the community, you’ll need to sign up.

Hopefully people find this amusing. If Subtexting gets used, I’ll keep working on it, because it’s a lot of fun!

In the meantime, let’s dig into how it was built.

How I Built Subtexting in 16 Hours

I had the idea a few days before the hackathon, but didn’t put any work into it before the hackathon.

I kicked off with ChatGPT to figure out the initial prompt for Lovable (that’s an affiliate link, please use it, I need credits!)

Here’s my original message to ChatGPT:

I want to build a hopefully humorous tool that translates what a product manager, executive stakeholder, designer and/or developer mean when they’re messaging each other. For example, when a product manager asks for an estimate on a feature from a developer what they really mean is, “I need this done yesterday, don’t tell me you have to refactor all the code.” This is a tongue-in-cheek system. I need a few things:

1. A website kind of like Google Translate, but the “languages” are: product manager, executive stakeholder, designer and developer. So the person selects their “language” (say “developer”), inputs text and picks the translated output. These translations should come from AI. So the AI has to do research on how these different people speak to each other and what they mean.

2. I’m going to build a Slack integration, so probably a Slack app that when installed automatically translates what a person inputs into a specific Slack channel. For this to work, they’ll need to tell the Slack app what they are: developer, executive stakeholder, product manager or designer. So they type in a message, “This is the message” and for everyone else in the Slack channel, who has also declared what they are, it shows up translated.

3. I think it would also be cool on the website to have a Reddit style feature for people to suggest translations. So they could input:

* A developer says, “message here” and it translates to, “...” for product managers

* They post that, and people can vote on whether they like that or not

* Then as the admin, I can incorporate that into the system, so that if anyone ever posts a message like that in the actual system it can use that translation. I think this might require RAG for the AI to pull from, but I’m not sure.

4. The website shouldn’t require auth for the Google Translate feature, but the reddit style voting system should require signup (but people can use anonymous user names). When they sign up, it’ll send them a confirmation email. They click the confirmation email. And then can login.

5. There needs to be an admin system (ben@highlinebeta.com is the admin) where I can view user signups, add/edit/block/delete users, resend invitations. The admin system also needs to see a log of all translations that have been done. Each translation should have a vote up/vote down feature, for me to train the model (RAG?) for better or worse translations.

6. Does this make sense?

7. What else am I missing to make this clear for Lovable, because I’ll need a comprehensive prompt to build this in Lovable.

After a bunch of back and forth refining the prompt, I put the prompt below into Lovable on January 16, 2026 at 6:30pm:

Build a fun proof-of-concept web app + Slack app called “Subtext Translator”.

The app translates workplace messages between 4 “languages”:
- Product Manager
- Executive Stakeholder
- Designer
- Developer

This is tongue-in-cheek workplace sarcasm:
- Humor via exaggeration and subtext.
- NO slurs, hate, harassment, or protected-class insults.
- Sharp but professional.
- Focus on “what they really mean”.

==================================================
SCOPE (POC – KEEP IT SIMPLE)
==================================================
- Public web translator requires NO authentication.
- Slack integration works ONLY via slash command.
- Slack does NOT read channel history.
- Slack does NOT work in DMs.
- Slack users MUST paste the text they want translated.
- Web translations are always logged.
- Slack translations are logged ONLY if enabled per workspace (default OFF).
- Admin user: ben@highlinebeta.com

==================================================
1) PUBLIC WEB TRANSLATOR (NO AUTH)
==================================================
UI similar to Google Translate:
- Dropdown: From Role
- Dropdown: To Role
- Text input (max 1000 chars)
- Tone slider (0–100):
  - 0–33 = gentle
  - 34–66 = standard
  - 67–100 = savage
- Toggle: “Include subtext explainer”
- Translate button
- Output panel

Translation output MUST be strict JSON:
{
  "translated_text": "...",
  "subtext_explainer": "...",     // empty string if toggle off
  "tone_label": "gentle|standard|savage",
  "confidence": 0.0-1.0,
  "tags": ["estimate","scope","deadline"]
}

Render:
- translated_text prominently
- subtext_explainer smaller / optional
- copy-to-clipboard button

==================================================
2) ROLE PERSONALITIES (ADMIN-MANAGED, SEEDED)
==================================================
Each role has an admin-editable “role personality” that defines how that role
speaks, thinks, and is perceived.

These role personalities are injected into EVERY translation prompt.

On first run, seed the following DEFAULT role personalities:

--------------------------------------------------
ROLE: Product Manager
--------------------------------------------------
voice_adjectives:
- deadline-driven
- context-switching
- optimistic
- vague-under-pressure

goals:
- ship something that works
- keep stakeholders aligned
- hit timelines without blowing up the team
- make tradeoffs feel reasonable

euphemisms_json:
[
  {"phrase": "Can I get an estimate?", "meaning": "I need to know if this fits in the roadmap and whether I’m about to disappoint someone."},
  {"phrase": "Let’s circle back", "meaning": "I don’t have an answer yet and hope this goes away."},
  {"phrase": "This should be quick", "meaning": "I have no idea how long this will take."},
  {"phrase": "We can iterate later", "meaning": "We are knowingly shipping something imperfect."}
]

taboos:
- Avoid calling out incompetence.
- Avoid implying work is easy.
- Avoid absolute technical claims.

--------------------------------------------------
ROLE: Executive Stakeholder
--------------------------------------------------
voice_adjectives:
- outcome-focused
- impatient
- high-level
- confident-without-details

goals:
- move metrics in the right direction
- reduce risk (without slowing down)
- show progress to the board
- maximize ROI and narrative clarity

euphemisms_json:
[
  {"phrase": "What’s the ROI on this?", "meaning": "Convince me this matters more than the other things I’m worried about."},
  {"phrase": "Do we really need this?", "meaning": "This wasn’t in my mental model and now I’m skeptical."},
  {"phrase": "Can we move faster?", "meaning": "I don’t see the constraints you’re dealing with."},
  {"phrase": "Let’s be pragmatic", "meaning": "I want a simpler version that shows progress."}
]

taboos:
- Avoid deep technical detail.
- Avoid sarcasm directed at leadership.
- Avoid questioning authority directly.

--------------------------------------------------
ROLE: Designer
--------------------------------------------------
voice_adjectives:
- user-centered
- principled
- expressive
- detail-oriented

goals:
- protect user experience
- maintain design integrity
- ensure consistency and clarity
- advocate for the end user

euphemisms_json:
[
  {"phrase": "This feels off", "meaning": "I can’t fully articulate it yet, but the UX is wrong."},
  {"phrase": "We should explore more options", "meaning": "The first solution isn’t good enough."},
  {"phrase": "This breaks the system", "meaning": "We’re accumulating design debt."},
  {"phrase": "Just a small tweak", "meaning": "This actually affects multiple screens and states."}
]

taboos:
- Avoid dismissing aesthetics as subjective.
- Avoid reducing design to visuals only.
- Avoid hostile or flippant tone.

--------------------------------------------------
ROLE: Developer
--------------------------------------------------
voice_adjectives:
- literal
- cautious
- constraint-aware
- technically precise

goals:
- maintain system stability
- avoid hidden complexity
- prevent future rework
- deliver correct, maintainable solutions

euphemisms_json:
[
  {"phrase": "That’s not trivial", "meaning": "This is more complex than it appears and will take time."},
  {"phrase": "We’ll need to refactor", "meaning": "The current codebase will fight us on this."},
  {"phrase": "It depends", "meaning": "There are several unknowns that affect scope."},
  {"phrase": "This might cause issues", "meaning": "I’m worried this will break later."}
]

taboos:
- Avoid implying others are ignorant.
- Avoid absolute refusals without explanation.
- Avoid unnecessary jargon in translations.

==================================================
3) SLACK APP — COPY/PASTE ONLY (OPTION A)
==================================================
Slack App characteristics:
- Installed to a workspace.
- Works ONLY in non-private channels.
- NO DMs.
- NO automatic translation of messages.
- NO reading channel history.

Slash command format:
/subtext <from_role> <to_role> <message>

Examples:
 /subtext pm developer I need an estimate on that feature
 /subtext developer pm This will require refactoring first

Behavior:
- Bot responds in-channel (or ephemeral if easier) with:
  - Original text (quoted)
  - Translated text
  - Optional subtext explainer
  - Footer showing tone (e.g. “tone: 72/100”)

Validation:
- If message text is missing → show usage instructions.
- Normalize role aliases internally:
  - pm → product-manager
  - exec → executive
  - dev → developer

==================================================
4) SLACK OAUTH + SCOPES (MINIMAL)
==================================================
Required Slack scopes:
- commands
- chat:write

No channel history scopes.
No DM scopes.

Store per workspace:
- team_id
- team_name (optional)
- access_token (encrypted)
- installed_at
- log_slack_translations (bool, default false)

==================================================
5) TRANSLATION LOGGING
==================================================
Logging rules:
- ALWAYS log all web translations.
- Slack translations:
  - Only log if workspace.log_slack_translations == true.
  - Default is false.

==================================================
6) ADMIN CONSOLE (ADMIN ONLY)
==================================================
Admin email:
- ben@highlinebeta.com

Admin routes:
- /admin/logs
- /admin/roles
- /admin/settings

==================================================
7) AI BEHAVIOR (CRITICAL)
==================================================
System prompt MUST include:
1) Global rules
2) FROM role personality
3) TO role personality
4) Tone guidance
5) JSON-only output requirement

==================================================
8) RATE LIMITING + COST CONTROL
==================================================
- Rate limit anonymous web requests
- Cache identical translations for 24h

==================================================
DATA MODEL (TABLES)
==================================================
role_personalities
translation_logs
slack_workspaces

==================================================
EDGE FUNCTIONS / API
==================================================
POST /api/translate
POST /api/slack/oauth
POST /api/slack/command

Lovable thought for 25s and asked me a handful of clarifying questions. It then presented a plan. For some reason I only approved the plan at 6:56pm (I think I was multi-tasking on another app that I was building!) By 7:10pm I had the first version.

I won’t go through every detail of the project, but there were a few interesting components.

Subscribe now

Implementing Moderation

Partway through, I realized I needed moderation. Subtexting is no place for hate speech, discrimination, etc.

I usedChatGPT to research the simplest / best options. It suggested OpenAI’s moderation model (along with a few other choices). This was easy to setup through an API key and a bit of Lovable prompting.

What’s not obvious is how to test it.

I asked a colleague to put in a few inappropriate messages for quick testing, but that doesn’t cover all uses cases. For now I built a comprehensive logging and flagging system. I don’t expect tons of usage (but prove me wrong, people!), so I’m not too worried, but this was an interesting exploration.

ChatGPT and Lovable started offering complex suggestions for building out automated testing of the logic, which I didn’t have time to do. Plus, the idea of generating 100s of inappropriate messages to test the system felt icky.

I set it to auto-ban people that try to input anything inappropriate, which works (you can see the test with diamond_bob — that’s me).

I also added Community Rules and Terms of Service. Part of the hackathon judging was on “completeness”. I took that to heart in my attempt to build a shippable, polished product.

Building a Slack App

Despite the initial prompt instructing Lovable to build a Slack app, it didn’t completely do that. It gave me some settings to work with (in the Admin system), and then I was able to figure things out.

My original idea for the Slack app was that it would auto-translate messages (at least in 1 test channel). That would require the app to know your role (so you’d get the right translations each time). After going back and forth with ChatGPT, I decided that was too complicated. It recommend implementing a /subtext command instead.

Once I agreed on the scope, Lovable was able to build the logic quickly and setting up the app in Slack wasn’t complicated.

I started testing it in Slack and then realized three things:

1. It wasn’t using the AI for translation (it was just generically translating messages)

2. There was no moderation

3. It defaulted to a specific savageness

So getting /subtext to work in a basic form was easy, but I wasn’t explicit enough about how I wanted it to work, so Lovable built something super simple. It took a bunch of time to get the AI logic and moderation working, but it does! Logging from Slack was a touch complicated too (it required updates to the code and Slack permissions).

Do you want to test Subtexting in Slack? Leave a comment or send me a message!

Enabling Post Sharing

If you’ve checked out Subtexting already, you’ll see that I borrowed a lot from Reddit. The Community Feed allows you to vote on posts, comment, vote on comments, etc. I didn’t implement a karma system (I couldn’t decide what I wanted, despite a lengthy conversation with ChatGPT on the topic), but then someone mentioned to me, “Can you share posts?”

Good idea!

I prompted Lovable to add a sharing feature, which it did. But when I copied & pasted the URL into Slack, it looked crappy:

It was using the Lovable app URL, but also there was no context or detail. I wanted it to show the original message, the translation and a visual (like Reddit).

I got it to use the proper domain, but of course, got the same result:

This was a terrible rabbit hole.

I went back and forth with Lovable and ChatGPT trying to resolve the issue. Lovable tried using an edge function to generate the shareable URL with Open Graph information, but it didn’t work well. Plus the URL was ugly. I went around in circles for a couple hours and eventually gave up.

Both Lovable and ChatGPT suggested using a Cloudflare Worker (which I’ve used for other projects), but my DNS is with GoDaddy and I didn’t want to move it. Lovable + Cloudflare is finicky (which I’ve learned on other projects). I didn’t want to risk the site not working. I may move the DNS, setup a Cloudflare Worker, and see if I can get proper sharing to work (once the site goes viral!) 📈

In the end I added a global setting for “turn sharing button on/off” so I can control the UI. You can still share feed URLs, it’s just bland.

Tech Stack

The tech stack for Subtexting is straightforward:

• Lovable (for hosting the website)

• Lovable Cloud (Supabase “light”)

• Lovable AI (which I believe is Gemini)

• OpenAI for moderation

• GIPHY for the GIFs (through an API)

• Slack

• Resend for email (although it’s not doing much right now)

I used ChatGPT for brainstorming and Notes for tracking.

Subscribe now

8 Lessons Learned While Vibe Coding

Here are a few lessons learned from this project:

1. Prompt with Detail

A more robust, detailed prompt that’s well thought out will be more effective than a simple one. It doesn’t take much to direct Lovable in one direction or another. For example, when Lovable built the app, it created a slightly different header for each page and didn’t reuse code. As a result, when I was fine tuning the header (particularly to make it mobile friendly) it wouldn’t do it across the whole app, it’d do it on one specific page.

Here’s an example of a bad prompt:

Loading the users profile is VERY slow, investigate

It assumed I meant in the admin system where we have a tab for viewing all users. Right before this prompt I was fixing something in the admin system, that’s probably why.

Here’s a better prompt (for something else):

on mobile the + sign for creating new translations overlaps the community feed title. So let’s do this:

1. Move the + button to the line with the filter tabs. On desktop and mobile it’s always a + sign.

2. On desktop when someone mouses over the + it should animate into the full + New Translation button

3. Remove the “Controversial” filter from the feed, that’ll provide more space

You don’t need to write a novel, but be precise and thorough to help the AI interpret what you want.

Having said that, it’s pretty easy to just yell at Lovable, “Fix it!”

2. Sometimes, Lovable is Slow

Every once in awhile, Lovable takes a long time to do its job. It’s not always on complex prompts/queries either.

When Lovable doesn’t respond quickly, it’s easy to get distracted and do something else. That can lead to losing context. And when Lovable finally spits out a solution (I’ve waited 2-5+ minutes before) you may be so eager to move forward that you don’t dig into the details of what it’s doing. That’s risky.

I wonder if Lovable could use Cerebras (one of the hackathon’s sponsors) to speed things up? That would be amazing!

3. You Need a System

Vibe coding without system design is a trap. A long prompt to kick things off isn’t a system, it’s a starting point.

I cannot believe what’s possible today with vibe coding. Fifteen years ago rounding the corners on a box in a web app was a pain in the ass. Today, it’s trivial. GoInstant (where I was VP Product) built real-time co-browsing technology in 2012 that was ahead of its time. Salesforce acquired the company because of that. Today, I can prompt Lovable to do the same thing.

The sheer power of vibe coding lulls you into a false sense of security that everything is solvable. It also reduces the willingness to think ahead and have a plan. I’m fairly convinced, despite how fast it is to build full products through vibe coding, that ironically, it’s inefficient. To be clear, I could never have build Subtexting without vibe coding, but was I actually efficient/productive while doing it? Shrugs.

Part of the challenge with vibe coding is that you’re munging all the work together: planning/product management, design (UI and UX), development and Q&A. You’re a 1-person army playing every role. It’s why I believe you need more skills, not fewer, to vibe code successfully.

In hindsight, I could have built a more robust PRD, with a well-documented plan, that would have allowed me to take chunks of the PRD and use those as prompts, one by one. It would have taken more planning up-front (including some initial design work so I could visualize the product), but would have helped with the actual building part.

While vibe coding, you realize you need to:

• Decide what you want to build (ideate)

• Validate if that’s valuable (during the hackathon I skipped this step entirely!)

• Research how to build it

• Consider how the thing you’re building affects other parts of the app

• Take into consideration security implications

• Think through how you’ll test

• Craft the proper prompt to your AI system so it understands what to do

• Go back and forth with AI to make sure it’s doing the right thing

• Wait for it to code

• Verify that it did the right thing

• Test it

• Rinse and repeat

It feels like you’re prompting and magically getting results (which is wonderful), but it’s a lot of work.

4. Testing Sucks

Testing an app, while simultaneously building it (especially quickly with a time constraint) is annoying. It’s great when your product works, but once you find bugs, especially edge cases that you hadn’t thought about, it’s…meh.

I need to learn how to test better. It’d be great if the AI would automatically run a web browser style test (like we used to do with Selenium and GoInstant back in the day) to verify that things are working properly. But the AI may not know what the behaviour is supposed to be unless its clearly defined.

Testing is a huge time suck (when you’re building solo or in a small team), Testing across devices and screen sizes is even more work.

Note: Testing is massively important! You need to test. But there’s gotta be a way to automate more of it (to be fair, I haven’t really looked).

5. Performance is Not Guaranteed

Lovable is definitely not focused on performance. I’m sure other AI code generators are the same.

The more I built, the more performance dropped. Near the end of the hackathon I started asking Lovable to improve the speed of certain pages (which it did). But Lovable doesn’t have any benchmarking capabilities (that I know of) and probably takes your word for it that a page is slow. You also need to retest everything after you try to improve performance, because you don’t really know what the AI is doing.

6. It’s Easy to Get Distracted While Vibe Coding

I mentioned this earlier, but it’s worth repeating. The more we rely on AI to do the work for us, the more we’re inclined to go do other things simultaneously. I love multi-tasking, consider myself good at it, and don’t shy away from the belief that multi-tasking is a valuable skill. I know a lot of developers abhor that concept; they believe in doing one task at a time and being laser focused. I wonder if that’s shifting because of vibe coding?

Vibe coding encourages distraction. It’s so easy to go do something else, or plan twenty steps ahead while ignoring what the AI is actually doing.

During the hackathon, I was vibe coding on a different project (an LLM Content Optimizer), responding to email, doing actual work, etc. I wonder how much of my time during the hackathon was spent on Subtexting versus other stuff?

Vibe coding does not encourage lock-in, it’s as if the AI says, “I got this, go do something else.” Sneaky risky.

7. Vibe Coding Tired is Dangerous

Developers will tell you that coding tired is dangerous. Totally get it.

Vibe coding tired is worse. Vibe coding is like bringing a nuke to a knife fight. You can vibe code a ton of stuff, very quickly, and your AI code assistant will keep going if you keep prompting it.

As I got more tired during the hackathon, I noticed:

• Prompts became less clear

• I stopped reading Lovable’s plans and just clicked the “Implement Plan” button

• I stopped testing and just stuffed “small” features/tweaks into the app

This definitely increases the likelihood of error—human and AI. Hackathons are designed with time pressure, but if you’re building something real, don’t vibe code tired (despite how easy it is to vibe code).

8. Vibe Coding is Awesome

I hate the term “vibe coding” but I love doing it.

I can only imagine where we’ll be in the next 5-10 years with AI assisting us in product development. It’s crazy powerful.

In the last month, I’ve built:

• An Applicant Tracking System (to replace the one we used, and to share with our startup portfolio)

• An LLM Content Optimizer (that scrapes a site and provides concrete recommendations on improving visibility/citation in LLMs)

• A Starburst Ideation tool (for Highline Beta workshops)

• An old school D&D game (let’s see if anyone reads this far and asks me about this!)

A few years ago I would have needed a decent-sized team of qualified designers and developers to generate this kind of output. Now, I can do it on my own. You can too. 💪

Let a thousand flowers bloom. I’m all in!

The problem: AI is very good at helping you build something. It’s not very good at helping you build something well.

The difference matters, especially for founders, product managers and product teams trying to ship real products, not prototypes or demos.

Subscribe now

Read more

Two things are needed:

1. A genuine insight or “secret” into your market / customer

2. A precise, targeted value proposition

Subscribe now

What Do You Know That No One Else Does?

Ryan Hoover (founder of ProductHunt and an active investor) shared this on LinkedIn:

A founder recently asked, “If you were starting or joining a startup today in AI what segments would you look at?”

Answer: “My honest but maybe cop-out answer: The best place to build is likely driven by a secret you discovered from your own experience.

Today, it seems like every rock is being turned over by founders. We’re seeing an increasing number of companies building obvious solutions with AI. Many of those companies will succeed but if I were to start a new company, I’d look for turly novel solutions OR novel (and new) problems.”

Ryan’s being generous when he says, “Many of those companies will succeed.” Some will, most won’t. Without any material differentiation, most AI startups will fail to achieve the scale they’re looking for. And differentiation is incredibly difficult.

I do agree with Ryan that you need a secret. You need to know something that most don’t—a genuine insight or “aha!” that drives everything you do. Finding that secret through your own experience works, but you can also dig very deeply into a vertical where you have less experience and still find insights. Either way, if you don’t have an insight or secret, specifically focused around the problem and why it matters to a targeted user group, you’re in trouble.

Incidentally, AI is not a differentiator.

And, “customers want AI” isn’t a secret. In some cases it’s not even true, despite the rush to put AI into everything.

Share

“Build it and they will come” is still not a strategy

AI has compressed the distance between idea and shipped product. New tools lower build time, reduce costs and scaffold entire features.

It’s amazing what can be accomplished. I’m blown away and loving every minute of it. But just because I can build a complete web application in a couple days through prompting alone doesn’t mean anyone gives a shit.

We’re seeing an explosion of undifferentiated, look-alike products. Each one promises to be “faster and easier to use” than the last one. It’s nearly impossible to prove, and at some point, customers stop caring.

❌ Just because you can build something, doesn’t mean you should.

❌ Just because you build something, doesn’t mean anyone will care.

These statements have always been true.

What Precise Value Do You Provide, And Why Should Customers Care?

In all the hype around AI, people are forgetting about the importance of value propositions. Every startup starts to look the same. It’s impossible to differentiate and customers are getting fatigued trying dozens of tools.

How many more generic workflow automation tools can we possibly need?

My bet: The sharper, more precise your value proposition, the higher likelihood you survive and thrive.

This means narrowing focus, and being very opinionated about what you do and who you serve, as well as what you don’t do and who you don’t serve.

A crystal clear value proposition will tell the world clearly:

“For [specific audience] who [specific context or pain], our product [delivers this outcome] by [unique mechanism or approach], so they can [specific business result].”

If you can’t articulate that quickly, repeatably and with force, I think you’ll lose. I know there are a number of unicorn startups at the moment that seem to serve everyone with everything, but they’re exceptions to the rule. There are also a number of unicorns that are specialized.

Standing out from the noise, which is a pre-requisite to having any chance at success, is insanely difficult. Getting a temporary bump from your launch video is cool…but fleeting. Growth hacks are great (and you should absolutely try them and build them into your product), but there aren’t a lot of secrets anymore. It’s a fairly level playing field.

A precise, narrowly-focused value proposition is different. It puts a line in the sand and declares, “We stand for something. Here it is.” You may piss off a big chunk of “the market” or they’ll simply ignore you. That’s OK, because the people you are speaking to will see your message and say, “Thank you for seeing me and speaking my language. You get me, and this is exactly what I need.”

Make a small group feel like you built the product specifically for them. That is the wedge that earns adoption, referrals, and authority. Then you can expand.

Subscribe now

Case study: Webflow’s early focus on designers

Webflow did not become Webflow by trying to be the everything-builder for everyone. Its early focus was explicit and intentional: build a professional-grade website creation tool for designers, especially freelance designers and small agencies who were stuck between rigid template builders and the complexity of developer-only tools.

That wedge came directly from co-founder Vlad Magdalin’s own experience as a freelancer. In Webflow’s early origin interviews, Vlad is clear about where the insight came from:

“Our experience as freelancers and building websites was paramount to understanding what was important to build into the product … we were the customers we were building for.”— Webflow Blog

Webflow’s designer-first thinking emerged long before “no-code” became a category. Vlad and his brother Sergie spent years building sites for clients in WordPress, Joomla, and Drupal, often re-implementing the same patterns over and over. That repetitive, frustrating workflow was the founding insight. Designers wanted control. They wanted custom. They wanted to ship work that looked and behaved like modern web experiences without having to negotiate with developers or learn full-stack engineering.

That is the designer wedge. A specific audience, a specific pain, and a specific promise.

This clarity became Webflow’s moat:

• The WHO was designers, starting with freelancers and small agencies.

• The WHAT was professional-grade website creation.

• The WHY was breaking the dependency on developers and eliminating the friction between design intent and production reality.

Only after Webflow dominated that designer wedge did the company expand into agencies and then enterprises, where its value proposition evolved toward scale, governance, and team collaboration.

Every founder should study this pattern: start narrow. Nail a painful, specific use case for a specific user. Let the wedge pull you upmarket.

A clearly defined primary user is not a limitation. It is an accelerant. Webflow won not because it was broad, but because it began as the most powerful tool for a very specific group of people who were underserved, frustrated, and ready to evangelize a solution built for them. From that base, expansion became inevitable.

A Useful Pattern: Narrow First, Then Expand

1. Uncover an insight. Find a non-obvious truth about a specific audience. It can come from lived experience or from rigorous research. I often ask founders: “What do you know that no one else does?” Without that, you’re building a generic product for a generic market.

2. State a sharp value proposition. For [specific audience] who [specific context or pain], our product [delivers this outcome] by [unique mechanism or approach], so they can [specific business result].

3. Validate resonance before you build broadly. Qual and quant. Talk to users, run smoke tests, check willingness to pay, and make sure they repeat your value prop back to you in their own words.

4. Build the smallest durable product that proves the insight. Every early feature should reinforce the value proposition. The MVP is not dead.

5. GTM from the niche outward. Start tightly aligned with your audience’s channels and language. Once you win a niche, expand to adjacent roles, workflows, or use cases.

Vertical AI Beats “AI for Everyone” Positioning

There are breakout horizontal platforms with massive network effects that can credibly say “for everyone.” That is the exception, not the rule. For most founders, the highest-probability path is a vertical AI wedge: a specific job, in a specific industry, with a specific solution.

I’ll take this one step further: go after a vertical within a vertical.

It’s entirely possible to win a tiny slice of a market and still build a remarkable business. You can also expand from that tiny slice into something much bigger.

Here are some examples of what “vertical within a vertical” looks like:

• Not “AI for law firms”

  Instead: “AI for antitrust teams doing merger filings across multi-country jurisdictions.”

• Not “AI for healthcare”

  Instead: “AI that generates cardiology progress notes for outpatient clinics using a specific EHR template.”

• Not “AI for accounting”

  Instead: “AI that prepares revenue recognition schedules for SaaS companies with multi-year, multi-entity contracts.”

• Not “AI for sales”

  Instead: “AI for mid-market outbound sales teams in cybersecurity that automates objection handling with company-specific threat vocabulary.”

The narrower the wedge, the more likely you can dominate it, because the product becomes impossible to copy without deep domain insight and painful attention to detail. You become essential to a group of people who feel like no other tool has ever respected the specifics of their job.

Founders need to get more opinionated, not less. You need to stand for something. Plant a flag and stick to your guns.

“What do you want to be the world’s best at?”

It’s a question I’ve started asking founders. Most startups don’t end up becoming the world’s best at anything or scaling to a point of world domination, but without that target and clarity you stand no chance at all.

Challenging yourself on this question isn’t just for the VC-backed startups that are trying to go public. Maybe you’re building a side hustle to generate a few thousand dollars per month. Or a lifestyle business that doesn’t put you on the venture capital rollercoaster. Totally fine. Love it.

✅ You still have to be great at something.

✅ You still have to stand for something.

✅ You still have to stand out.

Share

How to Craft a Pointed Value Proposition

Use this template. Fill it in without hedging.

For [specific audience] who [specific context or pain], our product [delivers this outcome] by [unique mechanism or approach], so they can [specific business result].

Here’s an example from Webflow (that I’ve written), which could represent their early value proposition:

For freelance designers and small agencies who need to deliver custom, production-ready websites without relying on developers, our product enables them to build fully custom sites visually by translating design directly into clean HTML, CSS, and JavaScript, so they can ship modern websites in hours instead of weeks.

Here’s a more recent Webflow example (again, written by me):

For marketing, design, and growth teams at scaling companies who need to launch and update websites without waiting on engineering queues, our product unifies visual development, CMS, and hosting into one governed platform, so they can move faster, publish safely, and reduce engineering overhead.

Messaging that passes the “for me” test

How does a potential user/customer know if your product is for them?

The value proposition needs to be specific. Try rewriting broad claims into targeted ones.

• Too broad: “AI that writes and analyzes contracts.”

• Pointed: “AI for antitrust teams that automatically maps merger filing obligations across 130+ jurisdictions and drafts regulator-ready information requests.”

• Too broad: “AI for doctors that saves time on paperwork.”

• Pointed: “Ambient clinical documentation that generates specialty-specific notes inline with EHR workflows, validated by a top-5 health system.”

• Too broad: “Automate your back office.”

• Pointed: “Autonomous coding for outpatient encounters that hits >90% automation in emergency medicine with audited accuracy and rapid turnaround.”

When buyers can see for whom, what, and why, they stop comparing generic feature lists and start imagining your product in their workflow.

Your value proposition is your company’s DNA

Your value proposition is not a paragraph. It’s the DNA of your company. It’s the seed that grows your messaging, product decisions, pricing, and positioning. It should be visible everywhere, even when it is never written out in full.

➡️ People should feel it in the tagline.

➡️ They should recognize it in the product benefits.

➡️ They should experience it inside the product.

I love the idea of writing a complete, detailed value proposition like the examples earlier. But that is an internal artifact. In public, it needs to be distilled into language that passes the “for me” test without friction.

Clarity is a superpower. When your product, copy, design, and GTM all reflect a single sharp idea, customers do not need to think hard. They immediately know, “This is for me.”

Insight → Value Proposition → Everything

Let’s end where we started.

Startups win when two things happen:

1. They discover a genuine insight. Something non-obvious that the market has not fully internalized. You get there through deep experience and/or deep research.

2. They turn that insight into a precise, targeted, unwavering value proposition. A focused promise for a focused audience with a focused outcome.

In an environment where AI has made building easier than ever, and every startup is promising the “magic of AI” as a value proposition, the winners will not be those who build the most features or slap AI into their tagline. They will be those who build the most meaningful solution for a very specific group of people, driven by a real insight that others overlooked (and probably uses AI to get there).

🧠 Insight drives differentiation.

👽 Differentiation drives a sharp value proposition.

🔪 A sharp value proposition drives traction.

🧲 Traction drives momentum.

⏩ Momentum drives expansion.

This is the wedge.

This is the way.

This is how you actually rise above the noise.

Real change does happen. The internet, mobile phone (remember the iPhone launch?) and now AI have reshaped everything. But there’s a difference between change and hype. Change endures because it’s built on fundamentals. Hype fades because it’s not.

We’ve been here before. What’s old is new again, and that’s fine—as long as we learn from the past instead of forgetting it.

Let’s take a quick walk down memory lane…

I’m pretty sure I owned this t-shirt in the mid-to-late 80s.

Today there’s a massive market for vintage clothing. I just liked Run DMC (and still do). 😄

The thrift store market is estimated at $10-$15B in North America. That’s just for physical stores. Thrifting is a regular activity for my university-aged kids (technically they’re adults, but whatever). Sometimes they go to bulk stores and buy “by the pound”. Sometimes they go to “high-end” thrift stores where t-shirts like that Run DMC one are proudly displayed.

The broader resale market for second-hand clothing is even larger, and there are many digital platforms you can use to buy and sell your stuff.

What drives this market?

For older folks it might be nostalgia (same reason they love old Pokemon cards or collecting 80s-90s toys). For younger people (like my kids) it’s about what’s cool, the thrill of the hunt, necessity (they’re broke and can’t drop $200 on jeans) and rejecting fast fashion. I always thought it was because they wanted to look as cool as I did back then. It’s not. 😝

People are irrational but they don’t do things randomly.

There’s always an underlying reason.

Subscribe now

People Get Caught in the Hype, But It’s a Crappy Way to Build a Sustainable Business

Hype is powerful. It draws people in and creates momentum. People want to belong and be in the know, that’s what makes hype so alluring.

But what goes up, must come down.

Hype is fickle. The next big thing is always around the corner, and if you’re not there with the cool kids (wearing Run DMC t-shirts) you’ll miss out. So you panic, chase every thread that might become a movement, aiming to stay ahead of the curve or at least ready to ride the wave and not drown.

If you build your business exclusively on hype, there’s a good chance you’ll fail. When hype fades and becomes nothing more than a fad, you’re in trouble. You might catch the wave, make a lot of money, and jump off at the right moment, but timing that is almost impossible.

Pet rocks, fidget spinners and NFTs

The Pet Rock might be the purest example of hype turned profit. In 1975, Gary Dahl sold literal rocks as pets, boxed up with air holes, a straw, and a training manual. It was a cultural joke that made him a millionaire for about six months. The brilliance wasn’t the product, it was the packaging, the timing, and the collective willingness to be in on the gag. Then it vanished. You can start with irony, but you can’t stay there.

A few decades later, fidget spinners spun through the same cycle. Marketed as stress relievers, they were everywhere—schools, offices, gas stations—until overnight they weren’t. The problem wasn’t that they didn’t work; it’s that there was nothing underneath the hype. They were easy to copy, impossible to differentiate, and had no repeat value once the novelty wore off. Schools banned them, prices collapsed, and retailers were left with unsellable stock. The fundamentals weren’t there: no defensibility, no ecosystem, no reason to keep spinning once everyone had one. What had been a billion-dollar toy category turned into clearance-bin plastic. I don’t even want to tell you how much I spent on fidget spinners for my kids at the time. 🤮

Then there’s Bored Ape Yacht Club: JPEG monkeys that rode the NFT hype wave straight into the speculative stratosphere. People spent hundreds of thousands on cartoon apes to flex digital status, and for a while the cheapest Ape (“the floor price”) traded for more than a luxury car. Then crypto winter hit, floor prices collapsed, and the club wasn’t so exclusive anymore.

The underlying technology—blockchain and Ethereum—still matters. It’s enabling real infrastructure shifts in transparency, finance and digital ownership. But NFTs like Bored Apes were a speculative expression of that technology, driven more by social signalling than substance.

Each of these moments had explosive energy. They made real money, for a minute. But hype isn’t a moat. It’s lighter fluid: quick ignition, short burn, and nothing left once the crowd moves on.

What’s Old is New Again

Live long enough and you realize everything is cyclical. For example, every generation rediscovers what was great before, like the Beatles, and convinces itself it’s found something new. They create their own music too, but it’s often derivative, or at least inspired from the past. Every generation thinks they’re the exclusive purveyors of taste, while simultaneously buying up vintage clothing, vinyl and old school memorabilia.

Technology makes the cycles spin faster. Every time we think something is brand new, it’s usually the same human impulse in a different wrapper.

AI is swimming in hype. The mistakes made during the dot-com era are resurfacing, although I believe we’ll plough through it. It’s a messy, experimental process, but we’ll get there.

A few months ago, I did an interview with Sidney Madison Prescott, who previously worked at Spotify, E*Trade, BNY Mellon and others, where she said, “AI is rebranded robotic process automation (RPA).” That struck a chord. We also chuckled about “Prompt Engineers” being an actual job title.

Sidney is super bullish on AI, and believes it will transform industries because the tools are amazing (and rapidly getting better), but the desire to automate things isn’t new.

Meanwhile, Kyle Poyar recently conducted a survey of go-to-market teams on the impact of AI. Here’s a quote from the post (paid access, but worth it):

The impact of AI is a mixed bag. More than half (53%) said they see either no impact or limited impact from AI. The disillusionment was most acute around AI SDRs. In the words of one survey taker, “We tried an AI SDR for six months and were unable to generate a single opportunity.” Ouch.

Despite signals like this (and the fact that most AI projects within companies seem to be failing), AI is a genuine step-change. We’re still figuring things out, but AI isn’t a fad.

Share

Forward Deployed Engineers: Old Job, New Myth

The thing that sparked this entire post was the growing hype around Forward Deployed Engineers (FDEs). Everyone credits Palantir with coining the term, but FDEs existed way before. Honestly, they’ve probably existed since the first enterprise software was built for companies.

I heard the term in 2023. By 2024 the hype was in full swing. A SaaStr post noted that, “Forward-deployed engineer job postings have increased from around 30 per month in early 2024 to 375 by April 2025—a 12x increase.”

Forward Deployed Engineers sounds super cool. Kudos to Palantir for an excellent rebranding. But this is not a new concept.

In 2012, I was working at GoInstant when we were acquired by Salesforce. I spent two years there, which was a great experience. Salesforce always deployed people to work with their enterprise customers. These people had the customers’ employee badges and access to everything. Some were project managers, others were technical salespeople, and some were engineers building software with and for customers.

At one point, our GoInstant team was selling into a large insurance company. We went in-person to demo our tech and learn more about their challenges. It turned out most of the people we were selling to were Salesforce employees. They’d been embedded for years. They knew everything that was going on inside the company. The customer was paying for them to be on-site full-time.

Being embedded with a customer for enterprise-level sales and deployments makes complete sense. The likelihood of project success goes up, and you can upsell constantly.

It turns out, in-person works. That’s how real relationships are built. Today people are “discovering” in-person events as if it’s a shock that meeting someone face-to-face is a good thing. I’m not arguing for full-time in-person, fully remote or hybrid, because all three are feasible. But I do laugh a bit when someone says, “You know, meeting people in person really makes a difference.” No kidding. We were rocking that in the 90s.

The Fundamentals Don’t Change

Rediscovering something that used to work is completely fine. Rebranding it is fine too. Value doesn’t come exclusively from net new inventions.

“Forward Deployed Engineer” sounds serious and cool, like Army Rangers going into a battle while simultaneously coding and solving every problem imaginable. Bring ‘em on!

But remember two things:

First: Most new things are built on what came before. If you ignore that, you’ll repeat the same mistakes or get caught in the hype without understanding how to navigate it.

Second: The fundamentals still matter.

A while back I wrote a post called “Did AI Kill Lean Startup?”. The short answer is no. AI doesn’t destroy the fundamentals of building a business. It doesn’t make customer discovery irrelevant, eliminate the need for right-sized MVPs, or erase the hard work of creating something people actually want. It just changes how quickly we can learn, test, and iterate. The scientific method still applies.

People are irrational, but they don’t do things randomly. There’s always a reason behind the behavior, even when it looks like hype. When you understand those reasons, you stop chasing trends and start seeing patterns. If you can uncover a genuine insight, something you know that others don’t because you’ve done the research and understand your customer deeply, you have a real competitive advantage. Insights may be the last true moat, or at least the spark that gives you a head start.

When the hype fades and people are tossing their AI pet rocks into the digital trash, what remains are real problems, real customers, and real value. That’s where great companies are built: not on novelty or noise, but on substance that endures. The fundamentals aren’t the enemy of innovation, they’re what make real innovation possible.

Valuations are crazy and the market is absurdly frothy. But AI isn’t going anywhere. It’s already too integrated into everything we do, even in enterprise (which is typically slow to adopt). When this hype cycle corrects, AI will still be everywhere.

I lived through the dot-com bubble. I was running a small digital agency building websites, web applications and e-commerce platforms. Everyone wanted to “get on the Web.” Then it stopped. Incidentally, it also cost hundreds of thousands of dollars to build an online store… 😝

Back then, people genuinely thought the Internet (and Web) might have been a fad. That’s not happening this time.

We’re early and being forced to adapt at an uncomfortably quick pace.

That’s why you get:

• CEOs demanding everyone uses AI, even without a strategic plan.

• Thousands of startups trying to automate every workflow possible, often without understanding the industries they’re entering.

• Billions of dollars invested by VCs and others, hoping to catch lightning in a bottle.

• Every startup claiming they’re an AI startup (since no one really knows what that means).

Trace Cohen writes a strong piece on this (better than I could): This Is Not 1999: Stop Calling It a Bubble.

Subscribe now

AI is Already Winning in the Enterprise

The biggest difference between 1999 and today: enterprise adoption.

In 1999, no Fortune 500 CEO was telling their entire company, “Use the Internet or you’re fired.” Today, every CEO is shouting, “Use AI now!” They might not completely know what that means, but they’re serious.

AI is already embedding into big companies’ operations: customer support, procurement, finance, legal, HR, etc. The adoption is uneven and often shallow, but the commitment is real.

That makes this cycle fundamentally different. We’re not debating whether the technology matters. Everyone agrees AI matters. The question is how to use it intelligently.

When the dot-com bubble burst, public markets were packed with retail investors chasing nonsense IPOs. For many, it was a “get rich quick scheme.” Today, venture capital is funding the mania (VCs fuelled the dot-com boom too, but liquidity was achieved through going public way too quickly). Many VCs will lose a lot of money this time around, but it’s a pittance compared to the public markets.

If every AI startup suddenly went public, we’d be in bubble popping territory, because a lot of those startups are propped up with tons of capital and unsustainable growth expectations.

We’ll see a correction, not a collapse.

Enterprise AI Adoption is Causing Chaos

A friend recently went through vendor onboarding with a major enterprise. For the first time, he saw AI-specific security questions:

• What’s your policy on using AI tools?

• Have you trained employees on safe AI practices?

• Do you have cyber insurance that covers AI-related incidents?

They still cared about the usual things — where data is stored, encryption, access controls, etc. — but now they’re explicitly calling out AI use as part of their risk profile.

The issue isn’t just where data lives anymore. It’s how data might be exposed or processed through AI tools.

That’s the new risk lens. Once company data touches an AI system, it’s perceived as being “out there.” Whether that’s technically true or not doesn’t matter. Perception equals risk.

For decades, enterprises asked, “Where is my data stored?” Now they’re asking, “What AI systems does my data touch?”

This shift is creating massive uncertainty. Most vendors don’t know how to answer these questions, and most enterprises don’t know how to evaluate the answers.

Meanwhile, nearly every SaaS tool has added AI features. You might not even realize that a tool you’ve used for years is now sending your company data through OpenAI, Anthropic, Mistral, or others. When your corporate IT team asks, “Are we using AI?” you may say no…and be wrong.

My bet: Startups will differentiate on the “secure use of AI”. SOC2 used to feel like a necessary evil/annoyance for startups selling into the enterprise. That’s changing. While SOC2 is technology-agnostic, auditors are already asking AI-specific questions. Expect this scrutiny to grow fast.

And recently I was talking to a startup that updated their Terms of Service to account for how it uses AI. They’d launched a new AI-driven feature and realized customers needed clarity on how their data was being handled. Sounds simple, but it’s not. Legal teams are scrambling to figure out what “responsible AI usage” language looks like.

BTW, their customers aren’t big enterprise either, but everyone (across all business sizes and sophistication levels) is twitchy about this stuff.

Executives are scrambling to get their companies using AI, and everyone, including IT, security, procurement, etc. is catching up. The lack of a coherent AI strategy makes this especially painful.

Most big companies don’t have an AI strategy. They’re experimenting everywhere without clear goals or alignment. One team is building copilots. Another is using ChatGPT for reporting. Another is banning it entirely. The result is chaos disguised as progress.

If you’re looking to develop an AI strategy and bridge the gap to execution, check out WorkLearn Labs.

WorkLearn Labs is a portfolio company launching soon. They’re focused on helping people define the right AI projects, assess ROI and connect the dots between strategy and delivery.

The next enterprise wave won’t just be about using AI. It’ll be about governing it.

Expect this over the next couple years:

1. AI training becomes mandatory. Like annual phishing and security training, employees will need “safe AI usage” certifications. Startups may eschew heavy-handed security training, but I suspect AI training will find its way to them as well.

2. Formal AI policies become table stakes. Companies will define what can and can’t go into AI workflows, when to disclose usage, how to vet vendors and models. The Australian government just released an AI policy template. This will be messy.

3. AI audit software emerges. New tools will track which LLMs are in use, what data is shared, how internal apps route data, whether prompts are logged, etc. Maybe these tools already exist (just like there are tools for tracking the software you use). Companies will demand visibility into AI usage within their organizations and with their vendors.

Share

AI is Changing “Build vs. Buy” But SaaS Isn’t Dying

AI tools for software development are amazing. It’s amazing what you can build quickly. And the tools are only getting better.

I’m a big fan of Lovable. I built a corporate venture studio design tool in 2 days.

Recently, at Highline Beta, we started building a new “Contacts tool”. The goal is to aggregate our collective contacts (primarily from LinkedIn), enhance the data (using AI) and make those contacts available to our team and portfolio. Instead of a portfolio CEO pinging us and asking, “Do you know any Series A investors that have recently invested in fintech and are at the earliest stages of their fund?” they can use the tool.

We could have used a CRM instead, but:

• We wanted to experiment with building something on our own (honestly it’s just fun!) Internal experimentation is a valid reason to build vs. buy, especially if you’ve mandated your employees to “use AI”. Just remember that experiments doin’t always work.

• It gives us the opportunity to tailor the software to our precise needs. This is one of the most common reasons for build vs. buy, you get exactly what you want. Of course, every time you want to add something, you have to build it.

• It should be less expensive than a monthly subscription to a CRM, although I don’t know what it’ll cost (more on that in a moment). The SaaS license fee model is evolving. For the Contacts tool we built, we would need 30-40+ licenses (which would be expensive in a CRM). Using Lovable, we don’t pay per user, we pay for use.

Still, I’m not convinced companies are going to replace a ton of software they buy with software they build.

There’s a lot of discussion about AI agents replacing traditional SaaS software. I can see that happening, but AI agents are still software. Whether you buy a platform for agent-building or specifically-focused agents for specific jobs, you’re still buying technology (software). AI agents are literally software as a service (SaaS), but re-packaged and priced differently. Lovable is a SaaS tool.

Building a lot of software in-house (versus buy) has implications:

• You have to maintain the software. Users will want more features (and since you told them it only took two days to build the whole thing, they’ll be clamoring for more!) They’ll report bugs and want support. You now have to manage all of that (you can’t outsource it to a vendor).

• You’re probably building the software side-of-desk. Some companies will have teams tasked with building internal tools (which is where most AI software is replacing “buy” decisions). Those teams are supercharged by AI dev tools; it makes their jobs way easier. But for the rest of us, we’re developing software while doing our day jobs. If building software with AI is a side hustle, there’s risk.

• If the people that built the software—even if it was vibe coded—leave, you lose institutional knowledge. We’re going to see hundreds of thousands of orphaned apps within companies that no one knows what to do with. When bugs emerge, or someone wants to extend the software (or integrate it securely into other systems), watch out.

• You have little idea how much the software will cost to operate. You may not be paying a subscription fee, but you’re paying for credit usage and that’s tough to measure and plan for.

With the two tools we’ve recently deployed at Highline Beta using Lovable, I have no clue what they’ll cost to run. I barely know what they cost to build, because I wasn’t tracking our time doing it, and I wasn’t tracking credit usage. A couple of times Lovable told me that we were at our credit limit (or fast approaching it) and I should top-up. I did. It wasn’t a lot of money, but I have no clue how long the top-ups will last.

Tracking and predicting future credit use isn’t clear. A lot of AI tools are hiding the numbers in an effort to obfuscate credit use; they don’t really want you constantly tracking it. They want you to use as many credits as possible and get hooked, so they can sell you more. It’s long distance calling and phone minutes all over again.

I also have very little insight into Lovable’s security. It makes security recommendations, which is helpful, but I don’t know how good a job it does designing secure software. We can’t assume people prompting a tool to build software applications know anything about security! When everyone within an organization can rip out vetted SaaS products with un-vetted, “randomly generated” vibe coded products, it’s a security nightmare.

Companies will build tools using AI instead of buying software. When traditional SaaS renewals come up, companies might ask if they can build a replacement for less. But it’s not going to shift the “build vs. buy” decisioning exclusively to build. Build comes with a lot of overhead and headaches that can be worth paying others to deal with. Division of labor is a thing.

Here are some further discussions on these topics:

• AI coding tools upend the ‘buy versus build’ software equation and threaten the SaaS business model

• I Found 12 People Who Ditched Their Expensive Software for AI-built Tools

• Is SaaS Dying for Good? A Look at How AI is Reshaping the Future of Software

• Build vs. Buy in the Age of AI: Why Smart Companies Choose to Purchase Non-Core Software

So Where Are We Headed?

We’re in a messy discovery phase that will last several years.

The combination of enterprise mandates, undisciplined startup building, and opaque infrastructure costs won’t cause a collapse. It’ll trigger a cleanup—a period of AI rationalization where companies focus on what actually works.

Here’s what I expect:

• AI compliance becomes a big industry. Training programs, certifications, audits and firms dedicated to AI governance will proliferate. Big companies buy-in first, followed quickly by startups.

• Transparency becomes a selling point. Startups that clearly explain their AI stack will stand out. Startups will need to address serious security policies earlier than they’re used to.

• Hybrid SaaS models explode. Software becomes both product and platform for AI workflows. This is already happening, and will continue.

• Big companies build a bunch and then buy. Experimentation isn’t the exclusive purview of startups. Big companies will experiment a ton to replace their complex and expensive software stack, overdo it and then settle back into purchasing SaaS + AI tooling (with a heightened nervousness around how their data touches integrated AI feature sets).

• Unbundling always leads to re-bundling. We’ve seen this pattern for decades: big companies buy a pile of point solutions, then realize they need “one app to rule them all.” Right now we’re in an unbundling phase driven by the explosion of AI tools and proliferation of startups. But that’ll shift. As major enterprise platforms bake AI deeper into their products, large companies will consolidate again, bundling for simplicity, security and procurement sanity.

• Procurement becomes the bottleneck. Enterprise customers (and smaller customers) tighten up their requirements and expectations. If your AI story doesn’t pass the test on security and clarity, you don’t make the shortlist.

AI isn’t going away. It’s already built into how companies operate and how people work.

The real challenge now isn’t belief, it’s competence. Most organizations are still figuring out what good AI adoption looks like. They’ll need to learn how to use it responsibly, measure its value, and build the right guardrails as they go. Startups will have to adapt, even faster than before, because demands on them in terms of how they use AI securely will increase.

This isn’t about hype cycles anymore. It’s about execution.

At the time, Lovable was super cool—it blew me away. But now it’s even better. (Note: This isn’t an advertisement for Lovable, there are a number of similar tools.)

Over the last two days I built a new web application.

Lovable recently added “Lovable Cloud” which sets up & manages the database automatically. This is a huge improvement from before. Feels like a game-changer for non-technical people building applications.

Subscribe now

I noticed a few other things as well:

• Lovable’s making way fewer mistakes. It’s much “smarter” with the code it creates. Previously, I found that Lovable wouldn’t always get things right, and would need multiple prompts to fix errors (that it had created). I felt like I was running around in circles. It’s still not perfect. Some things are still complicated and messy (e.g. exporting a nice looking PDF, or sending emails triggered on events). Both of these were rabbit holes for me, and I couldn’t get the PDF export to work the way I wanted to (after a lot of time and credits!)

• Lovable’s more precise. Previously you’d ask it to do something and it would, but it would also change something else, as if the left hand didn’t know what the right hand was doing. This was very frustrating, because it would seemingly change things at random. You were constantly going around fixing things that Lovable broke. That happened a lot less this time; Lovable seemed to understand my instructions more clearly.

• Lovable’s chat feature is helpful. This wasn’t available the last time I tried the product. The chat feature allows you to go back and forth with Lovable before it makes any changes to the code. I found this helpful for diagnosing issues, asking questions, and getting more comprehensive explanations for what it was doing.

It still took me 2 days (although I didn’t work full-time on it!)

The app is fairly basic, not ready for primetime…but it’s live.

Do you want to try it out?

Introducing: The Corporate Venture Studio Builder

The Corporate Venture Studio Builder is built from the Venture Studio Checklist that I previously created as a spreadsheet. It’s meant for corporate innovators and executives that are exploring the venture studio model.

• The builder uses fewer questions than the original checklist, but also provides more detailed analysis.

• It’s mostly a survey (I probably should have used a survey tool!) but it also does a few cool things like calculate the studio team size you’ll need and other criteria. In the future I may look at building a budgeting tool and other capabilities, which would go beyond survey software.

Building the Corporate Venture Studio Builder

I thought it’d be interesting to show off a few key steps in the process.

Here’s the initial prompt, which includes a copy of the Venture Studio Checklist spreadsheet:

Then it went to work. I did a quick Loom video to show you the immediate output and process it went through to create a basic, but functioning application, with a database, login/authentication, design and fairly complete survey:

Share

Remember: Garbage in, garbage out

My initial prompt could have been more detailed. A lot of the fine-tuning I had to do was a result of not being precise at the outset. I was too curious and eager to see what it would do. I’m sure this cost me a decent amount of time.

For example, the initial version used radio buttons for all options/answers, whether the answers were single- or multi-select. That felt strange UI-wise (multi-select = checkboxes). So I went through each question, verified if it was meant to be single- or multi-select and then asked Lovable to fix the UI.

The original spreadsheet had some information for Lovable to work from. On some questions it would say, “Select as many as you like” which Lovable interpreted correctly.

But generally it’s good to remember, “Garbage in, garbage out.” You can’t expect miracles. Note: As I’m typing this I’ve realized that I probably could have prompted Lovable once to go through every question, double check it as a single- or multi- select and then use either radio buttons or checkboxes. I did it one question at a time. 😜

Once the basic application was setup, I started fine-tuning the questions. I was asking Lovable to make small copy changes to questions and answers, which felt silly. So I asked if there was a different way to edit the questions and answers by accessing the database directly:

I had assumed the questions were in the database, but they weren’t.

Incidentally, Option 1 is pretty funny, because it’s useless and wouldn’t have solved the problem. At least Lovable recognized that.

I decided to keep the questions/answers hardcoded (and not in the database), because I felt like working in Supabase (the database Lovable uses) would be more complicated. As a result I spent hours tweaking questions and answers. This would have been much easier in a survey software tool. 😃

Lovable did a lot with very little

Lovable did a great job of creating insights from the small amount of content/data provided in the spreadsheet. It was a pleasant surprise!

Note: There was a lot of fine-tuning and nitpicking to add more details/context to questions and the insights that were generated. Again, this is a good reminder that if you don’t provide Lovable (or a similar tool) with enough details, it’ll use what it can (and probably make up the rest). So a lot of my chats with Lovable looked like this:

Subscribe now

Lovable can handle fairly complex prompts

The more you prompt a tool like Lovable, the better you get. I’m far from an expert, but I was super impressed with a lot of its output.

Here’s an example of one of my prompts:

There are at least three key instructions in there and each bullet under “Note” is also an instruction. Lovable followed everything. Here’s the output:

Note: Calculating the # of ventures to build per year is pretty simply, but it actually feeds into a future question.

Lovable also does a good job with fairly basic prompts

One of the cool things I added to the Corporate Venture Studio Builder is milestone reports. I want to give people something of value throughout the survey, by analyzing their responses and making recommendations. Here’s my very basic prompt for doing that:

I had no idea what it would generate, but it’s honestly quite good (it did take a bunch of work to refine it to this point):

What’s interesting is that this doesn’t use AI. It’s hardcoded based on logic that Lovable created. I’ll be honest: I thought the responses were AI generated. 😉

I started prompting Lovable as if it was using AI to generate the milestone summaries and reports. I didn’t look carefully at what it was doing (while Lovable works, I’m often doing something else!) But it’s clear this isn’t using AI and it’s trying to interpret my fairly open-ended prompt into code.

At some point Lovable asked me if I wanted to use AI. I’m not sure why. It came up as an option. I can’t find the prompt that triggered it, but it started using Gemini 2.5 Flash to come up with recommendations in the milestones and final report. BTW, telling Gemini to be more opinionated and punchy was hilarious (I wish I had captured screenshots). It was completely rude and essentially telling people off if their survey answers weren’t great.

I deleted some of these AI generated sections because it was too annoying to improve (although I’ll go back and try some very specific context/prompt engineering later). One section did survive (although the formatting occasionally breaks like in this screenshot):

Subscribe now

Not everything was easy: Export to PDF and Send the Report by Email sucked

Earlier I mentioned that building the Export to PDF featured was difficult. I won’t bore you with all the details, but the gist of it is that the PDF wouldn’t include all the information that shows up on the final summary page. I also created a Send the Report button, but the email was missing information as well. For fun, I created a quick video of all the work Lovable and I tried to do in order to make these features work:

Looking back, I think half my time was spent trying to get Export to PDF and Send the Report features working. They kinda work…

So what’s next?

For starters, feel free to try out the Corporate Venture Studio Builder and let me know what you think.

There’s a lot of polishing to do. Polishing takes credits, because you keep messaging Lovable to make small changes, and each message costs you. I burned through my monthly credit allowance already!

I do want to work on a few things:

• Administrative reporting on usage to track where people stop in the process, how many projects/surveys people create, etc.

• Event tracking on key actions; i.e. what features are people using and how often

• Fix the PDF and Email Reports

• Improve the analyses that are generated, with and without AI

• Add a “venture building process” tool, where the user can define the key milestones/stage gates in their operating model, how long they take, resources required, etc.

• Potentially add a budgeting tool

• Branding and UI—it looks good, but it can look much better; potentially bring this into Highline Beta as an official tool

I’m not an expert with Lovable (or any other similar tool), but the power and potential are clear. It’s a ton of fun to jump in and build something. Tinkering is super cool (until you run out of credits!) Lovable will only get better, which will translate to easier builds, less time invested and more stuff being launched (which is great!)

If people are interested, I’ll continue to share my journey building the Corporate Venture Studio Builder and other tools in the future. Let me know!