The rules were simple:

• The first letter of the word had to be the first letter on the plate (“A”)

• The last letter of the word had to be the last letter on the plate (“E”)

• The other letters (“V T”) needed to appear in the word, in that order

The quickest person to blurt out a correct word won. We’re a nice family, so we’d let others in the car also come up with a word; often they’d try and come up with a bigger word to sound smarter. 😂

For AVTE you could go with: Adventure. Advocate. Abbreviate. (There are others too!)

It was a fun way to pass the time.

So I decided to build the game.

Introducing Wordspine.

I built Wordspine in a weekend. I’ve been improving it for a week, adding stats, badges, a native keyboard, cleaning up the UI, adding themes and more.

It’s amazing what you can do with AI code development.💪

I shared the game on LinkedIn, X and with a few friends. People showed up. As of 7:47pm last night, I’ve had 481 people play a game. Some try it and leave right away, but there are already a bunch of regulars that have played for several days consecutively.

I haven’t quite hit Wordle-level usage yet, but I’m working on it!

Share

Why am I doing this?

1. I love building things. Too many side projects is dangerous, but this game is really simple. I needed something easy to build compared to my work at Highline Beta and Candor (our synthetic user research platform).

2. The game is fun! If you’re a word game enthusiast, I think you’re going to enjoy it. You might prefer Sprint over Pro (or vice versa), but I genuinely think it’s fun.

3. I get to experiment with specific things. Wordspine is simple, but there are certain mechanics, like how to improve shareability and virality, that require real thought and high-level execution. Game mechanics aren’t easy, I don’t want the game to be too easy or too hard. UI/UX is so important; people have to understand the game quickly and find immediate joy in playing. These are all interestingly complex issues, despite the game itself being dead simple.

4. GTM is always tough. I want millions of people playing Wordspine. Word games are very popular, but getting people’s attention is tough. I’m not an expert. But I like to dabble, experiment and learn. Wordspine is the perfect thing to do that with.

5. There’s no AI. To be clear, AI is writing the code, but there’s no AI in the product. I’m a fan of AI and use it a ton, and Candor is incredibly AI-heavy in the product itself. Wordspine gives me a small little piece of the world that’s for the most part AI-free. 😃

Subscribe now

What’s next?

World domination. Maybe an exit to the New York Times. Who knows?!?!

Product-wise I’m tinkering. A few things I’m thinking about:

• Adding some type of score to Sprint. Right now it’s only time-based, but a few people have given me feedback that they’d like to get points for longer words and compete on score along with time.

• UI improvements. I’d like to tighten up the UI, and add a bit more to it. I want to give the game more personality. It needs to remain super simple, but it can also be distinct (without feeling foreign to word-game fans). (Brand is one of the only remaining moats!)

• Increasing competition. You can share your progress in Wordspine with friends and challenge them. The mechanism is starting to work, but I’d like to make it really valuable and fun for people.

• Native mobile apps. If the game gets popular enough, I want to build native mobile apps for iOS and Android. I’ve never built either, so I figure…why not?

Not all the feedback has been positive. I posted Wordspine in /r/playmygame and got this comment:

That was before I redid the brand and UI completely. They were right: the design was very basic and felt AI generated. Hopefully that’s not the case now. I have no clue if responding to comments on reddit makes a difference, but I couldn’t help myself. Also, come on reddit, be nicer. :)

GTM-wise, I’m also experimenting.

I used Claude Cowork to help me devise a plan. It generated a very cool interactive artifact that provides me with a to-do list, websites to visit, people to connect with and more. It recommended I spend more time on Bluesky (so I will!)

To-date, I’ve:

• Started posting on X and Bluesky

• Added Wordspine to a bunch of daily word game directories (one of them featured the game, which drove a lot of users!)

• Posted on LinkedIn

• Challenged a few friends randomly to see what they think

• Shared with 20-30 people I know

• Refreshed the user stats 100000x. 😏

I also used Claude Cowork to improve SEO/AEO. Discoverability matters. People do search for word games or “Wordle alternatives”. The site now has daily archives and word lists. We’ll see if any traffic comes from SEO/AEO in the future.

Stats are fun. Here are some that I’m tracking:

1. Where users come from. I’ve got Google Analytics and Search Console running too, but I find this gives me a quick sense of what’s working. A lot of users are flagged as “Unknown” because I implemented source tracking a few days after launching.

2. Viral loops / sharing. The game has a few sharing mechanics, where you can challenge others after winning a game. The people you challenge can play and brag back, or share with others.

Give Wordspine a try!

You can play Wordspine on desktop or mobile web.

You don’t need an account, play as a guest. Or sign up and track daily stats, earn badges and more.

I’m looking for feedback:

• Which version do you prefer: Sprint or Pro?

• Is the game too easy, too hard or just right?

• What other game mechanics or features would you be interested in?

• Is it fun enough to share with friends and family? (If yes, please do!)

• How could I market Wordspine more effectively?

• What else am I missing?

Thank you!

You’ve probably experienced this already. Someone feeds a pile of analysis into a model, writes a long prompt, and out comes 22 pages. The recipient opens it, sees 22 pages, and does one of two things: skims it and moves on, or drops it into their own AI and asks for a summary.

Machine generates. Machine consumes. Two humans exchange the illusion of work.

None of this is a new observation. Merriam-Webster made “slop” its word of the year for 2025 (sigh). But I’m living this on a regular basis now and starting to push back.

Subscribe now

If a document needs instructions, the document is broken

We recently wrapped a client engagement that required a series of strategic briefs. Deep topics, real analysis behind them.

AI loves this work. You feed it everything, write an extensive prompt, and it kicks into high gear. At first glance it looks fantastic.

Then you realize every single brief opened with a section called “How to read this document.”

I laughed the first time. By the third one I stopped laughing. If your document needs a manual, your document is broken. Nobody wrote a “how to read this” section when they had to type the whole thing themselves, because the cost of writing forced you to decide what mattered.

That cost is gone. So nothing gets cut, and the job of figuring out what matters lands on whoever opens the file.

People aren’t reading basic product instructions, let alone the manual

Here’s another example that I’m dealing with right now.

We’re piloting Candor, our synthetic user research platform. When a user builds an interview guide there’s an optional field called “Project Context.” The label says: “Add more context on anything specific you’re trying to learn from this interview.” There’s a one-line example sitting right in the field.

Multiple users have pasted hundreds of words in there. Persona behavior rules. Questions they want asked. Formatting requirements. In one case it read exactly like what you’d get if you asked ChatGPT, “I’m using a synthetic research platform and need to provide it with project context.”

They didn’t read the label, or the example sitting directly beneath it. They asked an AI what to put in a box, and pasted the answer.

Now, before I get too righteous: people never read. Jakob Nielsen measured this in 2008 across 45,000 page views and estimated users read about 20% of the text on a page. That’s not new.

What’s new is that the 80% they skip is now infinite, and they’ve got a machine to write their half of the exchange too.

Share

Provenance tells you which machine, not whether anyone thought

Anthropic just started marking Claude’s output: an invisible watermark in the text itself, plus C2PA provenance on files.

Directionally, fine. But read what a detected mark actually tells you. That the content “may have been processed by Claude.” That’s it.

So a 3,000-word report the model wrote from a one-line prompt carries the same mark as a paragraph I wrote myself and asked Claude to tighten. Those are not the same act. AI-generated is verbose and hard to wrangle into something good. AI-edited means I brought the thinking and the structure, and that’s closer to spell check than authorship.

Which is the problem with provenance as an answer. It tells you which machine touched the words. It can’t tell you whether a human did the thinking.

Honestly, at this point we should be watermarking the human stuff. It’s rarer.

The more you can make, the more people want you to

Once you can produce a strategy deck in four minutes, the expectation becomes that you produce more decks. Not better ones. More. Volume is the only thing anyone can measure at a glance.

That’s the Catch-22. The faster you generate stuff, the more you’re asked to generate, and the less time anyone has to read any of it. This is true of documents, code or anything else.

Researchers from BetterUp Labs and Stanford’s Social Media Lab call the result “workslop”: work that looks polished but has no substance, so the recipient does the thinking the sender skipped. 41% of workers say they’ve received it. Each instance costs about two hours to sort out.

Cory Doctorow puts it more bluntly. Sending someone unverified AI output, he writes, “is an attempt to coerce a stranger into unpaid labor on your behalf.” I love this line. Hysterical, annoying and depressing all at the same time.

Content producers are turning off their brains and asking recipients to keep their brains on. Why should they?

Subscribe now

When everything is AI-generated trust collapses and no one learns

So where does all of this end up? Here’s my experience, and I’m sure others are there too:

1. The more AI-generated content you read, the more you see the tells. Even when people try to hide them.

2. The more tells you see, the more jaded you get about anything you’re asked to read, review or look at.

3. The more jaded you get, the more you skim, or skip, or hand it to your AI for the summary.

4. The more you do that, the less you learn from any of it.

5. Then you ask follow up questions or challenge the sender, but they’re incapable of answering because they didn’t create the work in the first place. They ordered it. Now we have two people that aren’t learning.

In the end, you start assuming everything you’re sent is mediocre. You see a long document and think, “AI generated. Probably garbage.” You start assuming you and your AI could have produced the same thing in four minutes anyway. You might be right.

This is now a product design problem

If people won’t read a one-line field description, what do you think happens to your onboarding, your tooltips, your product tour, or your docs?

Pew tracked 900 US adults across 69,000 Google searches. When an AI summary appeared at the top, people clicked through to an actual source 8% of the time. When there was no summary, 15%. The summary roughly halved the number of people that clicked into anything to dig in further. And only 1% clicked a link inside the summary itself.

In the relatively short time we’ve had LLMs to engage with, we’re already seeing a re-trained expectation. People want answers immediately, with no exploration and no reading. Then they bring that expectation to your product, which is a tool they’ve never used, doing something they don’t yet understand. If they don’t get value out of your product quickly enough or decide they can just ask their own AI for the same thing, you’re cooked. Incidentally, this is why I think time to value is collapsing and churn is increasing for AI products.

AI makes building much easier, but doesn’t make it easier to build the right thing for the right market. AI building can’t keep up with changing expectations, where users and customers decide they don’t need to read anything, they have no time to learn and they just want everything done for them magically. AI is not magic. Software is not magic.

Back to Candor. We stopped asking how to explain inputs better. Better copy doesn’t help someone who isn’t reading anything. Instead, we’re building comprehensive quality checks on input fields. For synthetic user research the inputs are critical, you have a very real “garbage in → garbage out” situation. We’re already seeing challenges with this: someone designs a study with bad or mediocre inputs, they get so-so results and question the value of Candor. I know Candor works, it’s my job to help others use it properly.

We’ve also implemented Candor Bot, a chat interface that knows how Candor works, has built-in best practices, and can read the context of your inputs. I don’t know if people will use it (everyone has “app chat fatigue” while they chat endlessly with LLMs) but it’s an attempt to embed real-time help into the application.

Here’s what I’ve learned:

• UI/UX is changing quickly. At some point I suspect most software UIs will be replaced by MCP servers / APIs integrated into a person’s AI interface of choice. People barely want to log into different software products any more. But that’s a discussion for another time.

• LLMs have set an expectation of instant results. If your product takes a few minutes to do something or explain something, you might be in trouble.

• People are trusting LLM output a lot, in an effort to move faster and feel like progress is being made. They’re blindly copying & pasting things everywhere, whether it’s a report or into an input field in your software product, without stopping to think.

The reality is that you’re no longer designing for a user. You’re designing for a user plus their AI, and the AI is going to do more and more of the work.

Share

What I’m telling our team

AI is good! AI is bad! AI is… 🤬 🤨 😢

I’m not interested in raging against the machine. I want to wrangle the machine to do what I need and help others do the same. The more I produce and consume “workslop” and see how people interact with Candor, the more I’m encouraging the Highline Beta team to take certain actions.

1. Write it yourself first, then use AI to edit. Not the other way around. The quality isn’t close, and you can’t defend something you didn’t think through. The pull to go the other direction is enormous. Resist it.

2. Ownership matters. Whenever you send something to a client, prospect or anyone else, you are responsible for it. You own the thing you sent, whether you produced it or not. That ownership means you now stand behind what was produced and sent. Tough to do when AI wrote it all.

3. Define “done” before you generate. I do this when building software with Claude Code: three to five pass-or-fail checks written down before any work starts. Same for a document. If you can’t say what good looks like in advance, the model will happily hand you 22 pages of not-that. A smaller version of this: write out the sections of the document, why you need them, what they should contain and how you expect them to link together. Better prompting (to some extent) can wrangle AI to produce better quality.

4. Treat length as a cost you’re imposing on someone else. If your document needs a “how to read this” section, cut it in half. Then cut it again. Editing is critical, but not if your eyes glaze over and you’re going through the motions.

5. Be ready for follow-ups. We don’t send things to clients hoping they file them away and ignore them. We want them digging in, asking questions, challenging us and connecting dots. We have to be prepared for that. If we can’t do that, we’re not doing our jobs.

6. Design for people who won’t read. Content needs super clear summaries that are actionable. Software products need to assume people skip all instructions and just copy & paste AI generated stuff into them. Think about how our output can do more of the work and make it easier for recipients to digest, learn and action things quickly.

Outsourcing to AI is the wrong way to think about it

We talk about outsourcing work to AI as if we’ve handed responsibility to another person. We haven’t. AI can produce the output, but it can’t own the outcome.

Most of the code in Candor is written by AI. But I decide what gets built and why. I evaluate the work, test it, change direction and ship it. If Candor sucks, it’s not the AI’s fault. It’s mine.

The same applies to everything we produce at Highline Beta. Clients don’t care whether AI helped generate a report. They care whether it’s precise, useful and worth what they paid for. They care whether we can explain the thinking, answer their questions and help them decide what to do next. Six hundred slides nobody has time to consume isn’t value. It’s output masquerading as progress.

That’s the distinction we’re losing. AI makes it easy to produce something and mistake that act for finishing the work. But generating is only the beginning. The work isn’t done until you understand what was produced, know why it matters and can defend it.

Delegate production. Accelerate execution. Use AI aggressively. But don’t delegate judgment or responsibility.

AI naturally leans toward more output. Humans need to stay focused on better outcomes.

Produce less. Mean it. Be able to defend it. 💪

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

Read more

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

Read more

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

Read more

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.