A while back, I wrote a post titled “What is a Platform?”. I defined what a platform is and why tech companies are so determined to become labeled as one. My definition of a platform is a tool that allows users to define and build their own things, which can be used by other users. Tech companies wish to own platforms, as they are the engines that propel the flywheel toward infinite growth. 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.

I just finished listening to Lenny’s conversation with Nan Yu, Head of Product at Linear, about what it takes to build a great SaaS product. Like many SaaS apps, the Kibu team and I have taken inspiration from Linear. But as we plan our roadmap and implement new solutions, I ask myself: What’s preventing us from building a product as beautiful as Linear, Slack, or Figma? Sure, time and resources matter, but I sense deeper things at play. Lenny and Nan’s conversation shed light on Linear’s approach and helped me articulate some thoughts: No Dogfooding Nan said that ideas for SaaS apps often start as useful products inside of larger companies. A typical story: a developer solves a personal problem, shares it with her coworkers, gets tons of praise, and considers if other companies have the same problem. I recall the story of Slack going a lot like this, and I suspect Linear is similar. The advantage of this approach is that the founder is customer zero. By building for yourself, user empathy has an instantaneous feedback loop, allowing you to rapidly build based off “vibe” alone. This is obvious advice, as the “built by X, for X” has been a marketing cliché for decades. It explains why the most lauded products in app design are almost always built by a team who can dogfood their own product. Kibu cannot dogfood its own product. As a content provider and documentation platform built for disability providers, Kibu operates with no day-to-day usage of its own product, as one may see at Linear, Slack, or Figma. Without dogfooding, “vibe development” is overshadowed by the voice of the customer. Of course, there’s nothing wrong with customer feedback, but Kibu’s lack of dogfooding handicaps our ability to have that “spidey-sense” of our customers’ needs. This could lead us down a complicated or unscalable path. I am particularly concerned with the latter, as our stellar dev team always ensures the UX passes user acceptability. I wonder how Kibu can mitigate our inability to dogfood: Try to dogfood: We once tried dogfooding by documenting our company goals and providing weekly updates in Kibu (similar to how our customers provide daily updates to their special needs members’ life plan goals). This was a positive step but still a square peg in a round hole. We simply do not operate with the same speed, setting, vocabulary, or consequences as our customers. Hire industry folks: Wow, wouldn’t it be nice to hire a former caretaker that turned into a valuable SaaS contributor! We’re starting to find those on the business side, but we haven’t found an engineer that fits that description. Regardless, by joining Kibu, the employee would have left the industry and no longer be engaging in Kibu. I assume that Strava developers still jog after getting hired lol… Ignore the issue and build: This has been our status quo and likely will be for a while. Let’s double down on customer feedback by scheduling recurring meetings with diverse users. Maybe we even pay them! Is there a company that we can take inspiration from that’s been in our position? What’s the most beautiful app that can’t be dogfooded? My first thought is Shopify, as I’m guessing Tobi Lütke and the whole team don’t personally maintain an e-commerce snowboard shop. Let me know if you can think of other companies. Saying No to “The Man” On the topic of preventing bloat, Nan said Linear is hyper-focused on delivering an exceptional IC experience and is willing to turn down feature requests that don’t align with that vision. For example, if Nan got a request from a middle manager to make end-of-month reporting slightly easier, Linear will deny that request if it means the IC’s work is strained a bit. This “bottom-up” prioritization philosophy is downright enviable! Kibu is in the business of compliance, meaning that we are limited to the needs of our customers’ regulators. If a government agency or grant provider want our customer to complete a 3-page questionnaire for every member every day, then our customer has no choice but to pass that requirement down to us. Our ability to design a frictionless experience for ICs hits a ceiling when met with regulation, no matter how dumb. This hindrance is particularly frustrating because we recognize the economic value that an exceptional IC UX could bring to our customers. If a low-level caretaker can take notes and track attendance on a tool that won’t make them want to blow their brains out, then: The data will be better, incurring less failed audits and penalties. The data will be better, allowing management to better identify inefficiencies that lead to better resource allocation. The staff will spend less time record-keeping and more time caring, leading to better outcomes and success stories. At the same time, regulation is why Kibu Documentation exists in the first place, so if we’re sticking to a Linear-like “bottom-up” product strategy, then it is our duty to make compliance painless, if not a little fun. Reports Come Second: While the economic buyer and regulators relentlessly emphasize the importance of reports, Kibu must remember that reporting is merely a representation of rows and columns. What truly matters is the data inside—which aligns with our philosophy of prioritizing the IC’s data input experience. Kibu has already done a great job delegating customers’ reporting needs to the Customer Success team (hey, that’s me!) with custom Looker reports. Customers stay happy with white-glove reporting, while our product team remains focused on ICs. No BS copy: On the front page of every customer’s Documentation homepage, we have large text that reads “Your org is X% compliant. Found out why” If the goal is compliance, then let’s not blur anything. I’d rather sacrifice a little extra text on the page if it means our nontechnical users know exactly where to go and why. We should take this one step further and extend it to each entity in Kibu, like the member: “Here’s what you need to do to be fully compliant with Athena…“ More unicorns: Whenever you complete a task in Asana, a unicorn flies across your page! So cool. Per my bullet points above, a fun Kibu experience will lead to better financial outcomes for our customers. Tiny Thoughts Okay, the two sections above were the most provocative. Here are some more takeaways that Kibu is already doing. If we’re not, I don’t think it would be too controversial to implement: Y-combinatify Kibu: Our marketing page should be fast, fun, minimal, with lots of polished-up screenshots of our product (like Superhuman or Mintlify). Our brand should be “the new kids on the block” or “finally… Silicon Valley’s best are solving my disability provider problems” Say No to Enterprise: Linear demonstrates great restraint in saying no to Enterprise-level requests that they believe will lead to poor long-term growth. My last company experienced this, and I’m wary of going through it again. The 11-star Experience: The Linear team occasionally plays in a world where resources are unlimited and they can design the best gosh-darn experience. They’re always surprised by how many ideas are viable! Kibu should do the same… I love one developer’s idea of “Call Kibu”, where an IC can simply call a phone number and log their notes for the day- having a back-and-forth conversation with a robot who knows all compliance requirements.

Quick Update: I updated my domain to ben-mini.com! All old URLs and the RSS feed under ben-mini.github.io will automatically redirect, so no changes are needed on your end. By far, the most useful LLM app I’ve made is the Kibu Schema God: I try not to make my posts too technical, but I can’t resist. I’d like to briefly explain what the Kibu Schema God is, how I set it up in a day, and how you might create something similar. What it is The Kibu Schema God (KSG) is a Custom GPT that helps me get immediate answers on my product’s data. It has full knowledge of my company’s database schema and context around it. KSG allows all Kibu employees with a basic understanding of SQL to construct queries that provide insights into our customers. Humbly put, it is an omniscient data deity that takes mortals’ plain-English requests and provides the path to the data in seconds. As a VP of Customer Success with an engineering background, I use KSG daily to gain insights into our customers’ product usage. Which organizations watched the most videos this week? How many time-tracking events occurred after 5 PM ET this month? Relative to ARR, which customers have the most alarmingly low usage? I can copy+paste these exact questions into KSG, and it will return exactly what I need. The beauty of KSG is that it’s completely disconnected from our actual database, ensuring privacy and HIPAA compliance. No customer, user, or health-related data is ever shared with Schema God or the LLM. Further, it took me just a few minutes to create, with occasional tweaking and maintaining- all without code. How it Works This morning, I wanted to know which users watched the most classes on Kibu (by the way, Kibu offers a library of 400+ videos of educational and exercise content for adults with special needs). So, I logged onto ChatGPT.com, went into my Kibu Schema God GPT, and asked the question: Instead of returning data, KSG generates a MySQL query. A query is a structured language that enables interaction with Kibu’s MySQL database. I then copy+paste that query into an SQL editor, like TablePlus, and view the results: Not only has KSG saved me hours of writing these tedious queries, but it’s also proven worthy in crafting some of the most complex, disgusting, 25+ line queries in my life. I used to think of SQL query writing as an art- now, it’s a commodity. Configuring KSG was relatively simple. When creating a Custom GPT, I provided the following instructions: You are helpful assistant for Kibu employees to better understand their customer. Kibu is a software tool that supports the IDD community. It offers a library of video classes to individuals and Disability Provider organizations, as well as an admin tool for organizations to take notes & attendance of their members (IDD individuals). Your job is to provide MySQL queries upon request given Kibu’s MySQL schema. Always use the provided Prisma schema in schema.txt when constructing a query. A schema is the structure that defines how a database is organized. It includes the tables, columns, data types, relationships, and other elements that shape how data is stored and accessed. Even a Google Sheet can have a schema. In the image below, the schema of this Google Sheet consists of a User table with five columns (ID, First Name, Last Name, Age, and State) and two other tables (Activity and Medical Info) that are likely related to the User table. Most production databases and SaaS providers maintain a document that defines your data schema. Kibu’s schema is explicitly defined with Prisma. Schemas are written in a structured way that makes them readable to computers but indecipherable to humans. This is the perfect recipe for an LLM use case. When creating KSG, I went to my dev team and requested our Prisma file. I uploaded it to the Kibu Schema God, giving it the blueprints to our database’s design. After explaining to the GPT a few nuances (what time zone our dates are in, what each “status” value means in a business context, etc.), KSG was complete. I occasionally tweak KSG’s configurations when the schema updates or more context needs added. How to Implement Your Own Schema God Schema Gods are an awesome way to unleash your data analytics potential with minimal IT overhead. Regardless of your role, you work with data, and you need to get insights from it. Here’s how you can build your own Schema God: 1. Identify your data source and find its schema For someone in Product or CS, this could be your relational database or a layer on top of it (Mixpanel, Amplitude). For a salesperson, your data is likely in a CRM. Ask the owner of this data source for the schema. Salesforce has its own schema tool that lets you view and configure all the objects in your org. 2. Insert the schema into ChatGPT. Visit ChatGPT.com (or your preferred LLM) and paste your schema into a Custom GPT configuration or start a new conversation. 3. Explain the schema to ChatGPT Think of your Schema God as a really smart data analyst intern who still needs to learn. Explain your product, its core “nouns”, and what a successful answer may look like. The more specific, the better. 4. Ask ChatGPT to return your queries in a desirable format. Every data repository has its own method of analyzing data. For a database, this will likely be query language. For SaaS apps, it might involve using an “advanced filter” language available in its reporting interface. It might be an API. Salesforce has its own query language called SOQL that runs on sites like Workbench. Find the format that gets you from copy -> paste -> data as quickly as possible. Final Thoughts In about an hour, my six years of SQL knowledge became nearly obsolete. Granted, building and tweaking the Schema God would have been much more challenging without my data fluency, and my more advanced prompts to KSG are still grounded in pseudo-SQL-speak. However, in its current state- with all the context and rules I’ve provided- I have complete confidence that it can help my non-technical colleagues with minimal mistakes. The best KSG users are those who understand the business of Kibu the most, not the codebase. Fuck man… maybe it was a good idea to get that business degree instead of computer science! This year, “talk to your data” apps have exploded in growth. But, I’m yet to find a tool as cheap, easy to use, and privacy-friendly as the Schema God. Hopefully, this can help some of you become the data-driven business visionary you never knew you could be.

Between 2009 and 2012, Apple iPhones and iPod Touches included a feature called “Send to YouTube” that allowed users to upload videos directly to YouTube from the Photos app. The feature worked… really well. In fact, YouTube reported a 1700% increase in total video uploads during the first half of 2009- crediting that growth to its strong integrative ties to Apple and social networks. However, this two-click upload feature was short-lived when Apple severed ties with YouTube by removing its homegrown app in 2012. While Send to YouTube can be thoroughly analyzed as a milestone on the “frenemy” timeline between Apple and Google, I want to explore a pleasant consequence of this moment. Apple uses the ‘IMG_XXXX’ naming convention for all images and videos captured on iOS devices, where XXXX is a unique sequence number¹. The first image you take is named “IMG_0001”, the second is “IMG_0002” and so on. During the Send to YouTube era of 2009 and 2012, the title of one’s YouTube video was defaulted to this naming convention. Unwitting content creators would then upload their videos on a public site with a barely-searchable name. To this day, there are millions of these videos. Try searching for “IMG_XXXX” on YouTube, replacing “XXXX” with your favorite numbers (I used my birthday, 0416). See what you get! There’s something surreal about these videos that engages you in a way you’ve never felt. None were edited, produced, or paraded for mass viewing. In fact, many were likely uploaded by accident or with a misunderstanding that complete strangers could see it. YouTube automatically removes harmful or violent content, so what remains exists in a unique, almost paradoxical state: forbidden, yet harmless. Putting all this together, searching IMG_XXXX offers the most authentic social feed ever seen on the Internet- in video, no less! While many videos are redundant snippets of a concerts, basketball games, or kids’ recitals, you also get one-of-a-kind videos that provides a glimpse into a complete stranger’s life. You’ll see a tumultuous event that made them, their partner, or their friend say, “hey, let’s record this”. I’d like to show you three of these videos that I found in my search. IMG_0416 (Mar 17, 2015) - 23 views The video shows a woman excitedly unboxing a book she received in the mail. From context clues, she seems to be a wife and mother from Memphis who’s unboxing the first published copy of her book. She thanks the friends, family, and publishers who made this happen. After a quick Google Search, I was able to find the book: A Profit / Prophet to Her Husband: Are you ready to be a wife? The book is meant “to help wives understand who they are and who they were designed to be.” It clocks in at 94 pages and has 30 ratings on Amazon! Go IMG_0416! I don’t care what you’re creating- I’m just a fan of creators. It looks like she kept at it- making a second book in 2020! IMG_0416.MOV (June 24, 2015) - 26 views The video appears to show a woman playing a matching card game that teaches you “the basics of the potash stuff” according to the cameraman. As the woman (who I assume is the cameraman’s supportive mother) flips two matching cards, she reads off the countries who produce the most potash. I honestly didn’t know anything about potash! Turns out that it is a mineral with large amount of potassium, which is helpful as a plant fertilizer. With Canada producing the largest reserves in the world, the vast majority of Canadian potash is found in Saskatchewan. I wonder if this family lives in Canada. Or, if this is just another school project of useless facts… I miss those! IMG_0416 (Feb 8, 2011) - 114 views Let’s end on a fun one. The video shows a young man snorting powdered sugar and dealing with the consequences of it. Given his BU hoodie, Dunkin’ Donuts location, and ironic depiction of drug use, I gotta say this is a VERY Boston video. What’s genuinely heartwarming is the shared laughter between the man, the camerawoman, and the motherly figure leaving Dunkin’. The camerawoman calls her “Myra”, suggesting they all know each other. We have nothing better to do, so we’re snorting powdered sugar captures an essence of suburban America that I’m sure many of us can relate to. Edit: 11/3/24 IMG_0417 (Mar 14, 2014) - 16 views I found this after posting, and it’s just too amazing to not include… a woman filming her partner as he finds out she’s pregnant. Assuming all has gone well, the child is now almost 10 years old. I wonder if the family even knows this video still exists. After posting this on Hackernews, it looks like somebody commented on the video lol. I hope the family receives a notification it and is able to share this with their kid. ¹ Edit: The IMG_XXXX sequence isn’t truly unique—after 10,000 photos, the numbering restarts at IMG_0001 (Source).