I’m slowly developing my own list of advice: have a creative mindset, embrace radical transparency, and write down what makes you happy. I’d like to add one more to the list: stealing is a skill! 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 to be an efficient way to achieve our goals. And as we stole, our intuitions brought us to that 3%. Our nav popover can be much more minimal. Our team is our brand- let’s add their pictures to the CTA buttons. Part of our product is videos- let’s have more videos than screenshots. These little “side quests” taught us more about our brand than any 3-day workshop could have. In less than a month of weekend work, we had a deployed site 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!

Consider the “nouns” the live inside an app of your choice: You can spend hours building a list for just one app. But the more interesting exercise is weighting the nouns by impact 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.

Happy to share a new project: Things to be Happy About - things.ben-mini.com. It’s a daily blog where I simply write five things to be happy about. 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 the 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 we’re heading in the right direction, and SaaS will need to evolve to retain its users. I imagine SaaS companies beginning 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

Revisiting an old 2020 Invest Like the Best podcast that interviews John Collision, co-founder of Stripe. When asked about his thoughts on no-code: 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?