Stealing is good for the soul. If done well, you will be able to build value at lightning pace and learn about yourself along the way.

But what is “stealing”? Is reading from a textbook considered stealing? Adopting an open-source library into your codebase? No- that’s not radical enough… I’m talking about literally copying another person’s creation.

My coworker Justin taught me about “the 3% approach”, coined by the late creative, Virgil Abloh. When designing his version of Air Force 1s, Abloh disciplined himself to only edit 3% of the original design, so as not to dilute the original work perfected by visionaries before him.

Abloh never went into much detail beyond that, but Justin and I began to make it our own at Kibu. I love the 3% approach¹, particularly when engaging in a project unfamiliar to you. When asked to alter 3% of something, you are challenged to determine which 3% you ought to alter. This forces you to inspect all 100% of that thing: every stitch and seam of the original. To us, the best way to get to 3% was to rebuild something we loved, stitch by stitch. We had to steal to succeed.

Justin and I wanted to rebuild our marketing site, but we lacked a solid vision. We knew we wanted a beautiful top-fold and a modern, minimal component library that could be reused across pages. We came across Mintlify’s 2025 marketing site and fell in love: an eye-grabbing top-fold, decisive use of colors, and a “show, don’t tell” ethos revealed all we wanted to create. The fact that Mintlify and Kibu are both documentation tools (albeit very different definitions of the word) was an added bonus. So, we literally rebuilt the Mintlify site, pixel-by-pixel.

When you recreate someone’s creation, you learn their story: every piece of brilliance, tradeoff, and imperfection. Why add a hover effect here and not there? What does three consecutive black and white sections do to the mind? Oh wow, look how all components’ widths fall perfectly flush with the floating, bg-blurred navbar:

Mintlify’s site wasn’t perfect by any stretch; yet stealing it proved an efficient way to reach our goals. And as we stole, our intuitions brought us to that 3%. Our nav popover can be more minimal. Our team is our brand- let’s put their faces on the CTA buttons. Our product is video- let’s show more video than screenshots. These “side quests” taught us more about our brand than any 3-day workshop could have. In fact, they quickly became the main quest: decisions we’d thought trivial turned our “3%” into “50%.” Our real work lived in every picture and video we added. By then we couldn’t lean on Mintlify anymore. We had to trust our instincts to connect our product to our story. But that’s the point: the 97% approach never holds at 97%. Honest actors will always drift. Mintlify just gave us a North Star we agreed was “good”, so every drift had to earn its place against it. In under a month of weekend work, we had a site deployed in Framer².

Coming out of this project, I had a newfound perspective of stealing. While I’ve always admired certain people’s crafts, I now prioritize it in my ideation process. No matter the project, I always ask myself and my team, “has anyone done something similar before us?” There’s thousands of free blogs, podcasts, and videos on problems you’re actively solving. It’s never been easier to prompt AI with your use case and ask who’s come across this issue before you. However, it’s your job to go down the rabbit hole, learn the 100%, and sprinkle in your 3%.

At the beginning of my career, I believed I’d be rewarded for the originality of my ideas. The truth is that you’re rewarded for identifying and solving problems efficiently. And odds are, smarter people before you have already done both. So, turn stealing into a skill: spend your days identifying what you ought to steal, why you ought to steal it, and how much you’ll steal of it.

“Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something.” - Steve Jobs

Blech. So cliche to end on a Jobs quote. One more:

Everything I do references something that influenced me.” - Virgil Abloh

¹ Abloh’s “3% approach” is an approach, not a rule. If you Google this term, you’ll find a lot of blogs fetishizing this as a sacred rule. I’d guess Abloh himself would dissuade you from that line of thinking. Abloh developed this concept in context to his work in a new Air Force 1 series: the fundamental task to mimic an existing design- a distinguished design that I’m sure Abloh heavily revered. You are allowed to be original! There is a spectrum to creative originality. This post is about one end of the spectrum.

² In March 2026, we migrated off Framer and into a full codebase. We bet that vibecoding would allow us to move faster than a drag-and-drop builder with ancillary AI tools and lock-in. We think it’s paying off!

You can spend hours building a list for just one app. But the more interesting exercise is weighting the nouns in the app- considering which ones have the most “gravity” from the eyes of the user:

You quickly realize that most apps, even the multi-billion dollar ones, revolve around one or two nouns- I like calling these nucleus nouns. Every other noun is a “satellite”.

Nucleus nouns are how I think about apps. Whenever I’m learning an app for the first time, I consciously build out this gravity model. It’s an easy way to cut through the bullshit. I don’t care that your app “optimizes sales efficiency with streamlined processes”. Fuck that. Oh? Your nucleus noun is “Email”? Got it. Now we’re getting somewhere.

Companies with a firm understanding of their nucleus nouns can use them as weapons. They make them part of their brand: ✨ the company that knows X better than anyone else ✨. If companies lose sight of it, the customer feels it:

• If nucleus nouns are not represented in your marketing materials, buyers feel it.
• If nucleus nouns are not at the top of your API documentation, engineers feel it.
• If nucleus nouns don’t impact hiring decisions, expertise will crumble.

Nucleus nouns may seem obvious to many readers. Those that understand the basics of database design might find this second nature. But, I have experienced major communication breakthroughs with team members of all technical abilities by explicitly listing out the “nouns in scope” for a new project.

When starting a new project, list out the nouns with your team. Then, consider this:

• Are only existing nouns impacted, not new ones? If so, awesome, let’s move fast and break things.
• Are any satellite nouns introduced? If so, alright, let’s consider its relationships, UX, and see if the business value justifies these new nouns.
• Are any nucleus nouns introduced? If so, stop everything. Call in the CEO. Rip out the ayahuasca. This decision could change everything.

I’m reminded of Dylan Fields’ reflection of Figma’s release of Figjam: its second product behind its flagship “Design” offering. For an ambitious tech executive, Dylan was awfully pensive about working on a second product (Figjam was released 9 years after Figma’s creation in 2012). I think it was the recognition that a new nucleus creates inertia¹: huge upside if it works, but at what cost?

I’m optimistic in the apps that maintain a uni- or duo-nucleus nouns strategy. Resend is nailing email automation. Plaid is nailing bank linking. To me, this is craft: having the discipline to stick to your nucleus noun and go mega vertical with it. Explore all its quirks and edge cases. Honestly, I think this is the most likely way to win in the SaaSpocalypse. Being “okay” at a lot of things won’t cut it anymore. Your market can vibecode “okay” in a weekend. Craft, focus, and expertise are your moats. I guess some things don’t change.

¹ Shoutout Three-Body Problem!

I was a few months into my first job out of college, and I was feeling… empty. I couldn’t explain why, so I set out to fill the void. I built side projects, went drinking with coworkers, and got really into the upcoming election. These all felt like things I should be doing as the yuppy I had just become, but the emptiness resided.

Indiana loves its basketball, so it was easy for me to find a local gym to play pickup. I became friendly with the regulars and the staff. One day, the athletic director told me they were looking for a volunteer assistant basketball coach for the middle school league. Being a former camp counselor, the idea intrigued me. Unexpectedly, the “assistant” position became the “head” position, and I was quickly thrown into a clinic, where I had to draft all my players by the end of the session.

Team drafted. 6 kids. 1 game per week. 2 practices per week. 14 parent emails (somehow). Practice starts tomorrow.

You know those bullshit leadership positions we all had in high school and college? Like how you were “VP of Operations” for some club, and all you did was order pizza? Yeah, this was not that. Getting thrown into an empty gym with six kids and two basketballs is a thrilling experience! I’m so grateful my buddy Clayton joined me as co-coach. I spent the whole day preparing for that 2-hour practice, and I think it showed. We learned each other’s names, had a solid skills assessment, set some ground rules, and had some fun with a little knockout.

Here’s the headline: I fucking loved being a coach. And, I don’t want to brag, but I was really good at it. We lost one game, our first game, and went undefeated after that. But improving each kid’s skill and confidence was the real mission. Instead of my desk job, I’d be asking Clayton how we could make Corey¹ use his body for rebounding. Or how Monte’s soccer skills could be best leveraged. Or how Evan, our best player, could become an on-court leader.

David, our self-deprecating goofball who insisted he’d be benched in the 4th quarter, made two game-changing dives for the ball in our last game. At the end of every game, I’d ask if anyone had any shoutouts to give about their teammates. Evan called David “a beast” for his dives, followed by rousing applause from the whole team. David’s smile is likely something I’ll be taking to my grave.

As the kids’ confidence grew, mine did too. I walked around the gym with a strut. I greeted their families with confident eye contact, remembering every word they said. I felt myself performing better in all parts of life: work, community, relationships… I became “that guy” who made shit happen in our friend group.

Heading into March, I was planning a surprise for the team. I had a contact at the Indiana Pacers, and I was scheming to get them to play on the court during a break in play. But to much ruin, Covid became a pandemic, leading to an abrupt end to the season, and an immediate global quarantine…

But that’s another story for another time. This is a story about happiness- and finding it at any point in your life.

I was happy when I was a youth basketball coach. And I find it notable to recall why I was happy:

• I love helping kids. I can’t exactly explain why… perhaps it’s biological. But I’m pretty darn good at it. I find it much easier to talk to kids than adults.
• I love being in the real world. If I taught those kids on Zoom… it wouldn’t have been the same. To travel somewhere, break a sweat, and high-five my team was such a gift.
• I love being in control. Coordinating practice, calling the plays, making substitutions- coaching let me steer my own ship. “Loving control” has its drawbacks. But succeeding within that control gave me real confidence and belief in myself.
• I love basketball. I can’t think of a better activity to learn about your mind, body, and role within a system. I’m a junkyard dog. When I get mad, I work extra hard doing the stuff nobody else wants to do. But I lose energy faster. I learned this from the game.

If I could give any advice to someone who needs it, I’d tell them to write down the things that have made them happy, and then explore why.

Why am I writing this now? I have a sense that many people in tech are feeling what I’m feeling. For years, you’ve sat in front of a rectangle, moving tinier rectangles, only to learn that AI can now move those rectangles 10x better. As someone outside the equity class, you begin to wonder what your role is in this new paradigm. And whether rectangles were ever your ticket to happiness in the first place.

When I was the age my basketball kids were, The Social Network came out. Like so many, I am a product of that generation. I accepted the propaganda that my value to this world only went as far as my product could scale. At 28, I’m finally beginning to challenge that.

Don’t get me wrong, I love tech. I think it’s magical. But I really hope to live in a world where my future kids find sitting in front of a rectangle all day to be dystopian and cringe. I really really really hope the invisible hand finds its way to getting me back into something I love. Maybe this “death of SaaS” talk, regardless of truth, is the wakeup call to so many us need.

¹ Names have been changed to protect their privacy.

Back in college, I had a tiny whiteboard outside my dorm where I did the same exercise. I also brought it to my cabin as a camp counselor (below). I would always leave the marker out with a little “Bonus:” section, where any passerby could add what they wanted. Not to brag, but it was quite a hit!

things.ben-mini.com is the same concept: I add my own five things every day, and anyone on the internet can add the Bonus. Just like the real world, anyone can add, append, or completely write over it. At midnight, the present Bonus is locked- entering a readonly state with all prior entries.¹

What’s cool to me is how I built this. You’ll be unsurprised to hear that most of this was vibe coded. Here’s the Github. The whole site, with a CRUD admin view, was built in a day:

• Claude Code for vibe coding
• Vercel for hosting
• Convex for db/auth/realtime sync (this product is awesome! I could write a whole post about it. It actually makes the Bonus entry realtime across all visitors, like a Google Doc.)
• BlockNote for an easy Notion-like editor

Perfect Software

Three years ago, I considered making this a Substack, but it didn’t feel right. I had specific ideas about how to present the daily entries, how my own admin view should work, and how the visitor-contributed Bonus should work. Substack couldn’t hold any of that. I had to sacrifice my artistry and workflow in exchange for Substack’s convenience.

Last week, I read Gaurav Ramesh’s blog about Perfect Software, where he makes the claim that LLMs make it possible to efficiently build small, non-scaling software that is “perfect” because it fits a single person’s needs exactly.

Before LLMs, “perfect software” was largely a myth. For most of us, the effort required to build exactly what we wanted was simply too high. So we rented other platforms. We begged or waited for features. We accepted friction and exploitation - limitations, ads, data stealth - as the rent.

In the 12 years I’ve written online, I’ve never found the perfect writing and publishing tool. […] It wasn’t because I needed something fancy. It was precisely because I didn’t.

But over the last 18 months, I’ve increased my odds of finding the “perfect software”. Because now, I’m making it.

This revelation is so important and liberating to me. I’ve written a fair amount about my love of software (I plan to write more!). Vibe coding has reignited that love, as it’s allowed me to explore projects like these- faster and better than ever.

With that said, I don’t think Substack, or the broader SaaS market, is dead.² While Substack didn’t fit Gaurav’s or my needs, it has for a large denomination of writers. It’s also worth noting that Gaurav and I sacrificed Substack’s distribution advantages in exchange for more control over our publications. Still, I think he and I are heading in the right direction, and SaaS will need to evolve to retain its users. I imagine SaaS companies will begin to launch Lovable-like build modes, with hosting, auth, and APIs already in context. Imagine a world where writers on Substack, sales teams on HubSpot, and healthcare workers on Kibu can all build interfaces that fit their own workflows.

SaaS will become less valuable for its UI and more for its opinionated, shared data layer. The winners in consumer SaaS will have data layers with the strongest distribution. In B2B, it’ll be the ones whose data layers produce trusted guardrails of compliance, reliability, and operational best practices.

It’s a tale as old as time and a recurring theme in ben-mini: centralized platforms that provide real, complementary value to builders will continue to dominate tech for the foreseeable future.

Anyways, enjoy things.ben-mini.com! Feel free to drop your own Bonus 😄

¹ Of course, I reserve the right to remove any inappropriate entries.

² My existing career path depends on SaaS flourishing, so I could be ignorant. “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” -Upton Sinclair

I think the kids will be alright.

For the first time in recent American history, I seriously don’t think parents have any idea what the fuck their kids should be doing with their lives. AI has threatened white collar career growth at levels we haven’t seen since… maybe never? While automation has steadily replaced monotonous back-office work, AI’s creative engine is now stepping into higher-level “thought” work at unprecedented scale. So, what professions should children today be groomed for?

Lawyer? Nah, AI’s already pretty good at reciting books and drawing connections.

Finance? Don’t think so- AI can produce ad-hoc reports faster than junior analysts can blink.

Software Engineer? Even the undergraduate-to-upper-middle-class-sure-thing is being threatened.

For several generations, there’s been a cultural certainty that regardless of economic or political standing, an American-born child could secure a long, moderately happy life if they had the privilege to pursue a traditional, careerist education. That certainty is starting to fade.

I reflect on the last time young people faced this kind of uncertainty. I’m humbled to remember that before 1970, any young man could have his life taken away and drafted to war. What could a middle class family do for their boy in the face of Vietnam and rising globalism?

With this uncertainty, something amazing happened… things got weird. The draft era birthed a counterculture of drugs, art, protest- all of which got baked into the next generation of industry. Silicon Valley’s darling child, Steve Jobs, came out of this era, very much a part of its hippie, anti-authority culture. In the Steve Jobs biography:

[Jobs] still fancied himself a child of the counterculture. On a visit to a Stanford class… [t]he students asked questions, such as when Apple’s stock price would rise, which Jobs brushed off. Instead he spoke of his passion for future products, such as someday making a computer as small as a book. When the business questions tapered off, Jobs turned the tables on the well-groomed students. “How many of you are virgins?” he asked. There were nervous giggles. “How many of you have taken LSD?” More nervous laughter, and only one or two hands went up.

Later Jobs would complain about the new generation of kids, who seemed to him more materialistic and careerist than his own. “When I went to school, it was right after the sixties and before this general wave of practical purposefulness had set in,” he said. “Now students aren’t even thinking in idealistic terms, or at least nowhere near as much.” His generation, he said, was different. “The idealistic wind of the sixties is still at our backs, though, and most of the people I know who are my age have that ingrained in them forever.”

Are we underestimating what kind of counterculture will spawn from the AI era? Sure, kids have always rebelled against their parents… but somewhere in America right now, there’s a kid saying, “no, Mom and Dad, I’m not becoming a lawyer” and she has a defensible rationale to back it up. That kid might end up taking a path of true non-conformity- bringing something genuinely new into the world.

As uncertainty grows, our usual cycle of rebellion will spike sharply and lastingly, as more brilliant, well-resourced young people take part, just like their great-grandparents did in the ’70s.

My shamelessly naive prediction is that counterculture could defeat the algorithms that imprison us today. Doomscrolling, isolation, and parasocial relationships will be seen as “lame” or “cringe” by the youth. We’re already seeing positive trends towards this with “dumbphones”, in-person social clubs, and the touch grass movement.¹

Of course, there will be many challenges ahead: housing, energy, climate change, and wealth inequality- to name a few. But, history shows that humans are really fucking resilient. Our job isn’t to solve everything today, but to build the infrastructure of technology, free-thinking, and optimism needed to finish the job.

The kids will be alright.

¹ One of my role models, Slack co-founder Stewart Butterfield, recently said he’s unsure what he’ll build next, build it will “help people use their phones less often.”

I don’t think no-code is fully a panacea. Even when you’re doing no-code, you’re still reasoning about the relations between different objects and data flows and things like that. When you’re building an app with Zapier, you’re still doing a form of engineering.

If you’re looking at Excel, I think it is one of the most underappreciated programming environments in the world. The number of Excel programmers versus people using what you’d probably think of as more traditional languages is really something to behold. I actually think there are lots of features of Excel that make it a really nice programming environment and really nice to learn in.

The fact that it’s continuously executed means that, unlike running your code and getting some error that’s hard to comprehend, the code is just continuously executed in the form of the sheets you see in front of you. And the fact that it’s individual cells and you lay out the program spatially, where the code and the data are interspersed and no one part gets too big, is really useful.

There are all these ways in which anyone who’s developing a no-code or new software paradigm should look at Excel, because so many people have managed to essentially learn how to do some light programming by looking at other people’s models and workbooks and emulating what they see.

Yep- everything is a spreadsheet. If you’re okay at Excel, you’re in the 99% percentile of most “technical” people on Earth.

This summer, I reflected on why Google Sheets is the greatest application of all time: the ability to extend the Excel GUI into the cloud, introducing both APIs and multiplayer, is truly a marvel. But the core concepts of spreadsheet software have been so important to my development.

The building blocks of any modern application begin with entities, the core nouns of the system. These entities are described by attributes, the adjectives that give each proper noun expression. Relationships connect entities to one another, giving the system structure and identity. And methods introduce behavior, allowing the application to perform computations that change entities.

What is a spreadsheet but:

• A series of tabs (entities)
• Columns on each tab (attributes)
• VLOOKUP and INDEX formulas between tabs (relationships)
• A library of other formulas that creates or mutates data to the user’s desire (methods)
• An approachable interface that allows users to present data however they wish

If our goal as technologists is to put the creative power of computing into the hands of every human, I firmly believe that this understanding of data and applications is baseline knowledge for everyone. This is what Collison meant in the quote above about no-code builders still needing “reasoning about relationships and data flows”.

This is a foundation of data literacy. There- if anyone ever told to become more data literate, I just gave you a crash course.

I’ve been thinking a lot about this concept for a few reasons:

• Learning the basics. It’s not that deep. Every application is secretly a fancy Excel sheet. Whenever you’re learning or communicating a new application, consider how you would rebuild it in a spreadsheet. The number of tabs relative to the number of formula is a good indicator of if their strategy is more breadth or depth. If the application asks you define your own tabs, it’s more of a platform.
• 10x’ing vibe coding. I can guarantee non-technical vibe coders that if they communicate their application needs like they’re building an Excel sheet, they will 10x their effectiveness. Tell the AI what your nouns are, the actions they ought to do, and their relationship with one another.
• Building better product. Whenever I’m met with a new product challenge, I use Excel as my mental model to figure out the data I’m working with and how it impacts the customer. How might this spreadsheet look to the customer, are we confident we know the right formulas, and how do we feel about how this spreadsheet might evolve?

Duolingo seems to nail feedback- at least for internal testing. In How dogfooding helps us build a better Duolingo, employees at the company get a special beta version of the app that features Shake-to-Report:

Shake-to-Report works pretty much exactly how it sounds: if an employee encounters a bug while using the app, they can shake the device (or on Web clients, click a button), which pulls up an internal bug report form…

To help diagnose bugs, reports automatically contain a screenshot and a host of metadata, including the experiments in which the user is currently treated, the user’s device and app version, and the user’s specific course and lesson data. We include a unique Fullstory recording in every bug report that shows what a user was doing in the app before they experienced a bug. Shake-to-Report bugs also contain a log file, which is particularly useful as engineering teams often add log statements at different points to help debug issues.

Duolingo hits the trifecta: Shake-to-Report is fast, valuable, and delightful. Imagine being a Duolingo employee, identifying a bug, and getting giddy at the idea of sharing it with your team…

I believe dogfooding is a critical part of every well-crafted product. In fact, I believe a lack of it is an existential risk to my startup. Nevertheless, my team does periodically use the product. Our Sales team demos it, Customer Success trains new customers on it, and Engineering continuously tinkers in it (albeit in dev branches). So, it got me thinking… how do we make feedback easy, fun, and valuable for our team?

Right now, we’re likely doing what most startups do: we have #feedback and #bugs Slack channels. We encourage all team members to share their thoughts in those. However, I noticed something alarming: in the past two months, 79% of our feedback came from only three of our twenty employees.

I find this problematic, because it’s unlikely that our smart, talented workforce does not have an opinion of their company’s output. There’s a multitude of reasons why this imbalance exists:

• Cultural: Those top three employees likely have more intense ownership of the product and a personal incentive of fixing it. The rest of the team might not think it’s part of their job or fear their feedback is “bad” or “a waste of time”.
• Exposure: Certain team members simply don’t use the product enough to develop thoughtful, pointed feedback (i.e. the no-dogfood conundrum)
• Operational: Sharing feedback can be too time-consuming or difficult to express, causing people to give up. And when they do submit feedback but nothing changes, it creates apathy toward the process.

Leadership can do a better job with the cultural issue. I’m still a bit stumped on how exposure can be reckoned. This leads me to the rest of my thoughts on making feedback operationally better.

There is so much that we (and all startups) can do to make feedback-sharing better than a Slack channel. We should go as far as to productize internal feedback: consider and engineer the best damn internal feedback experience. Great internal feedback is a privilege. Unlike outside customers, communication and privacy barriers are significantly diminished. You all use the same apps. Decorum and polish can be kept to a minimum. And, feedback systems perfected internally could very well transcend into a customer-facing solution

This week, I vibe-coded a Google Chrome Extension only meant for my team. Now, during demos and prep calls, our team will be one click away from submitting feedback:

In addition to a textbox, the submission captures your URL, triages it as a bug or feedback, and shares a screenshot upon request (the extension automatically captures your screen, saving you that extra step).

In the future, I would love to attach each submission to a RUM log- exactly what Duolingo does with Fullstory. It would also be cool to remove the “Bug or Feedback” selector and just let AI triage it thanks to the added context. Hey, maybe even the textbox could be optional.

I’m obsessed with making feedback submission as fast and low-calorie as possible. I want five seconds to become two seconds. I want AI to do as much training as possible. I want Devin to solve the simple stuff. I want to create a magical feeling to our non-technical team that not only does their feedback matter, but it might be able to be resolved in the middle of the freakin’ demo.

Upon opening the file, you create an account. From there you’re introduced to a feature stack that went well beyond any typical PDF: shared collaboration, comments, version history… the benefits of cloud computing- all within the familiarity of a PDF!

Dropbox achieved strong network effects in the 2010s due to generous free tiers, easy file sharing, and one-click account creation. Last year, I wrote a blog post on network effects, guessing if (and how) they would be brought into the AI market. In the post, I argued two points:

1. OpenAI began flirting with network-driven growth by introducing Custom GPTs in November 2023, and even more so when making them accessible to free users in May 2024. They will double down on Custom GPTs in the interest of network effects.
2. AI companies might not need network effects to succeed, as user-generated content might not be what incrementally improves these tools (rather, artificial content, better memory, & great UX)

The rest of this post will be a follow-up of #1. In short, OpenAI appears to have basically abandoned Custom GPTs since their Spring ‘24 update, and I’m a bit stumped as to why. Sure, engagement might have been low, or a desire to shift the product team to other features like Canvas, improved memory, Deep Research, and Apple Intelligence integration. But, one would think that the allure of network effects would drive any consumer tech startup to continue toying with the idea!

Meanwhile, Anthropic’s Claude has been quietly pursuing a more powerful way for users to build for other users. Two months after the Custom GPT release, Claude announced Artifacts, allowing users to create single-page HTML apps, among other things. Artifacts became a hit within the tech community, potentially mainstreaming “vibe coding” for the first time. Writer Simon Willison (or dare I say, fellow writer) became quite obsessed with Artifacts over the past year.

Unlike ChatGPT, Anthropic has doubled down on Artifacts, making it more reliable and accessible to users. And in June 2025, they went big. Anthropic announced that Artifacts can now become AI-powered:

Today, we’re introducing […] the ability to embed AI capabilities directly into your creations—transforming artifacts into interactive, AI-powered apps.

Artifacts turn anyone into an app creator—no coding needed. Just tell Claude your idea to instantly create shareable apps, tools, and games.

Here’s their announcement video of a drum-making kit. You’ll see that users can “Describe [a] beat” in the Claude-powered search bar.

It’s pretty cool! But, wouldn’t the creator need to worry about API authentication? Then, users abusing their credits? Or entering abusive prompts that would flag their account? It appears not. Here’s what makes this announcement newsworthy:

Claude [turns] artifacts into AI-powered apps, where the economics actually work for sharing.

When someone uses your Claude-powered app:

• They authenticate with their existing Claude account
• Their API usage counts against their subscription, not yours
• You pay nothing for their usage
• No one needs to manage API keys

While technically impressive, I find this to be an oddly brilliant business strategy for the prosperity of the Claude Chatbot- especially when Ben Thompson himself categorized it as non-focus for Anthropic. As an Artifact creator, I can infinitely extend the power of my Artifact at zero risk; all my users need is a Claude account.

Claude is the Dropbox of the Gen AI era. It’s providing real value to the market for the return of user acquisition and CLV- something that its competitors are incapable or avoidant of doing.

Coding is the easiest part

One week before this Artifacts update, the father of vibe coding himself, Andrej Karpathy, went on stage to deliver a talk about the continued shifts in software development. At the end, Andrej shared that while the “coding” step of app development is easier than ever, getting to that last mile of production deployment still exists:

While Claude Artifacts are still in this “toyish” phase of single-page web apps, you can’t help but be in awe at all the things it solved on this slide: LLM API keys, Deployments, and Authentication. And no one needs to pay an Enterprise license to make it happen.

After Karpathy’s talk, I spent most of my time thinking about “Payments”. How hard would it be for a PayPal or Link to partner with a v0 or Lovable? I could see a future where vibe coded apps can be locked behind a paywall with one click- making apps as easy to monetize as a Gumroad product. I suppose pricing tiers would complicate things, but hey, there’s nothing code can’t solve!

Perhaps I’m romanticizing the tech ecosystem- Google can do everything on Andrej’s slide. Maybe that’s what Sundar will task Varun and Douglas to do.

A world where existential issues, like housing and energy, are addressed at blazing speeds.

A world where risk-taking in the spirit of results and output is rewarded.

I’ve never agreed more with a policy proposal. I highly recommend the read.

In Chapter 4, Klein dissects the healthcare industry in particular, citing that scientists spend about 44% of their research time on administrative activities, like grant writing and compliance reporting.

This stat hit me hard.

My startup, Kibu, builds compliance software for Disability Providers (those who support those with mental disabilities), and I’ve seen firsthand the amount of paperwork they must complete. Imagine writing a set of essays, medical trackings, behavior assessments, activity breakdowns, and goal completions- all with timestamps- for every individual, every day. While our product aims to make this record-keeping easier, it’s not lost on me that we’re building inside a jungle of regulations.

How did we get here?

The bureaucrats who manage these regulations are underfunded, out of touch, and lack cohesion. In disability care, bureaucrats provide funding to Disability Providers. Because of this exchange, bureaucrats must trust that the money is being well-used. But because they cannot physically be in all facilities, they must build a different infrastructure to communicate and receive trust. That usually comes in the form of forms and reports.

Over time, these forms grow more complex. An edge case turns three questions into five. A lawsuit turns five into eight. A private partnership creates a new compliance rule, and eight becomes twelve. It’s become much easier to add more questions than to remove them.

As the reports get more convoluted, the bureaucrat’s eyes start to blur. He begins to check for “completeness” of the form rather than the outcomes or the story within it. There’s no time! Eventually, the providers start to recognize the real game being played. In the most technical sense, they don’t get funding by providing the best care to their individuals: they get funding by writing “the right stuff” in the forms.

When I first joined Kibu, I thought I’d be challenged by the complexities of special needs and the nuances each diagnosis presents. Instead, I’m challenged by a jungle of rules and procedures.

The dilution of institutions that focus more on compliance than outcomes is what we call procedural fetishism. It has permeated the way our government operates and is a major reason why public faith in it is at an all-time low.

So, just dismantle the government, right?

A natural reaction to all of this is to antagonize, belittle, and destroy these institutions. But if something has a disease, there are smarter ways to address it than killing the host.

Government is the reason we’ve been able to innovate in projects without any clear profit motive. The government created our sewage, highways, and Internet as ways to protect, connect, and improve our ways of life. They’re the truest platform developers that for-profit companies have benefited off for centuries. It would be a damn shame if the next Internet was stymied by procedural fetishism.

Doesn’t procedural fetishism create jobs?

Another reaction is to argue that procedural fetishism is good, as it’s created jobs (and entire industries) in the form of auditors, lawyers, and procurement brokers. Heck, one could argue that with less compliance, Kibu might be existentially threatened.

The tradeoff is that although these jobs are around care, they aren’t in care. We can all agree it would be cool to have more engineers in healthcare. But instead of developing compliance software, they ought to be building real medical equipment that directly helps patients. In a world graded on outcomes over procedures, I actually think capitalism could drive more jobs.

At Kibu, I often fantasize about a world without compliance. I fall asleep at night wondering what data and AI could do to actually improve the lives of individuals. I imagine how freeing it would be to build a solution that’s unburdened by the misaligned requirements of policy. Kibu wouldn’t be diminished- we’d thrive.

Final Thoughts

In 1980, the National Institutes of Health gave 22% of its research grants to scientists age 35 or younger. In 2001, that number was 3.8%. It continues to decline.

The root of procedural fetishism lies in distrust and conservatism. Over time, our government’s desire to swing for the fences has decreased. Perhaps it’s because we’ve been in relative peace for half a century. Or perhaps it’s the natural decline of empires.

If we want to enter a world of abundance, care, and decency, we must change our government’s culture to one of faith in the low-level entrepreneurs- one that puts purpose over paperwork.

But as Bill Simmons puts it best, there’s always a good “zag” to every “zig”. I want to challenge my own assumptions that platforms are inherently the best business model and explore how the opposite model, point solutions, can be just as healthy in product design. I want to compare two companies I admire: Notion (the platform) and Linear (the point solution). I also want to acknowledge my feelings about Kibu’s place in this battle and how forces like competitors, AI, and market needs influence us.

Notion, the Platform

Notion, known for its minimalism, speed, and extensibility, has been the techy alternative to Google Docs for almost a decade. Its approach of building ‘Lego for software’ is embedded in the company’s culture and felt inside its product.

From the beginning, Notion’s mission was to allow anyone to create software. But, after realizing that everyday humans had neither the time nor care to develop, they switched to productivity. Create a Notion account today, and you will be greeted with a blank canvas, much like a Word doc. But the real magic is the first time you press the / key, which opens a world of blocks, allowing you to seamlessly create lists, tables, charts, mentions, and embeds that all cooperate in the ecosystem of your given folder. Notion called itself the Lego of software. With blocks, you can define your own things. With a collection of things, you can design templates, which can be consumed by many.

Notion entered a rocky era when it strayed from this path. On Lenny’s podcast, CEO Ivan Zhao recounts Notion’s “lost years,” where he reflects on a failed feature. Notion introduced Sprints, a specific methodology for managing projects. From the start, Ivan and the team felt Sprints didn’t feel right. After a year, they could articulate that injecting a rigid, less adaptable solution didn’t align with Notion’s core philosophy of block-based design. Imagine opening a box of Legos and finding a perfectly curved, painted airplane inside! Where’s the fun and customization in that??

For Ivan and Notion, anything outside of block-based thing-builders is not a tool that belongs in Notion. While incredibly friendly and familiar, Notion is very much a platform.

Linear, the Point Solution

I’ve already written about what makes Linear so beautiful. Linear’s strength lies in its focus on building the best issue-tracking tool for the IC engineer: the 20-something developer who just wants to code without the bureaucracy. This unwavering focus on a specific persona is what makes them a point solution for modern software development teams.

A point-solution mindset is embedded in how Linear decides on features. In an interview with Head of Product Nan Yu, he reflects on one decision (paraphrasing):

We never liked the idea of letting management add custom fields to Linear because if you add 100+ custom fields, all your ICs would hate it.

But we kept getting requests for it, and we’d ask, “Well, why do you want custom fields?” And 40% of customers said, “Well, I have Customer X, and their request is really important. I need everyone to know that Customer X needs this. I need to track it.”

That sounded like a very useful and powerful thing for us to do. So let’s build a solution that solves that problem without making ICs’ lives harder.

Instead of building custom fields, Linear created Customer Requests, which captures issues and tags direct customer quotes from various support channels- all without ICs needing to do anything.

I’m impressed by the incredible discipline Linear exemplifies here. Clearly, the easy and “more scalable” solution would have been to introduce custom fields. But because they knew it would undermine their key persona, they kept poking at the real problem and addressed that instead.

In spirit, Linear and Notion have polar opposite perspectives: Notion welcomes platform-like design with blocks, custom fields, and automations, while Linear rejects it- staying disciplined in building out-of-the-box solutions that fit the lowest common denominator of its addressable market.

So, what’s right?

Cold take: they’re both right, and the lesson is that two roads can lead to equally desirable destinations.

I’m much more focused on the question: what’s right for Kibu?

Kibu is already much closer to Linear as a point solution, and I believe it should stay there. Kibu already has an incredible niche in the Disability Provider market, and we’re building real point solutions tailored for Day Habilitation programs within these providers.

Our competitors, namely Therap, take a horizontal approach to their solutions- seeing Disability Providers as just one vertical of many. This forces customers to do upfront and ongoing management of defining generic things within Therap. Some providers may see this as powerful and extensible- likely large organizations with dedicated IT resources. Kibu’s bet is that the vast majority of the market doesn’t have this luxury and would prefer out-of-the-box solutions where things are already in their language (service records, attendance, members).

Kibu, as a point solution, makes more sense for the market. Our market is exceptionally non-technical, highly regulated, and rightfully sees software as a secondary asset to their true offerings: the physical facilities and human resources that provide the service. Taken together, my bet is that our market would rather be told what they need than inspired to build it themselves. The more specific we can get, the better. A press release that reads “Kibu launches ready-made solution for Day Habs in Georgia” will resonate more than “Kibu introduces custom fields, allowing any organization to build their own solutions.”

Kibu, as a point solution, will open the floodgates for our product team to introduce omotenashi- anticipating our users’ needs before they ask. Notifications and help documentation can be more specific. LLM solutions can be prompt-engineered with niche instructions. Our codebase will be hardcoded with the nouns and verbs our market understands, forcing our tech team to truly understand the needs of our users, which is constrained by our inability to dogfood.

There’s so much more to unpack with AI’s influence, scaling the “Day Habs in Georgia” solutions, and more. Nevertheless, I believe that point solutions are what our market needs, and our messaging and product decisions should be guided by that assumption.