Nice article Ben! I think the HN crowd would be more familiar by calling those "Entities" but I like the new perspective of all companies only handling two or three of them really well.
I think there is more nuance about it for the SaaS-pocalypse though. I have been talking to hundreds of B2B companies and customers are now vibe coding solutions when they need something that the platform doesn't support: a dashboard, a workflow, or an integration.
And once a B2B customer gets a taste of vibe coding... then it's just a matter of time before they start to think about replacing the entire SaaS completely. I have seen this play over and over again so many times in the last few months, it's honestly shocking.
I am working to find solutions to the SaaSpocalypse but don't want to derail from the main topic, there's more info in my profile if this has been something you're thinking about!
Something I'm really good at is ending my articles with half-baked ideas :) so thank you for challenging it
Regarding "entities", totally understand. I like to write in ways that my mom would understand- not the HN community. In fact, I have a post called "Everything is a Spreadsheet", where I explicitly defined that Entity<->Noun relationship. Should have linked it!
Back to the Saaspocalypse... my startup is reckoning with this like all others. My next blog post will be titled "What's Preventing Me from Building Your App in a Weekend?". The ultimate "what's your moat" question. I think every SaaS should be forced to answer this on their marketing site. Thinking aloud, I'm considering good answers companies can say to this question... I think a perfectly legitimate answer is still "our prompts are better than your prompts". There are some companies where I simply believe the founders/engineers when they say they understand the problem better than I, because they've explored it more deeply. This is kinda what I was hinting at at the end... softwares that go mega-vertical in one or two nouns accrue more subject matter expertise than I ever will. Thus, that gives me more reason to trust their infrastructure, their configurations, and their prompts. This is not new but rather an extension of what created the SaaS economy in the first place.
I will definitely check out your profile- thank you for the thoughtful reply!
This makes me think of domain models in domain-driven design. Very useful to think about what these models are and how it makes sense to set them up & relate them in your area of work.
Makes me wonder if a similar level of analysis was done in reverse to conceive these, hopefully not word yahtzee. At least they don't end with "ly" - the horror.
Identifying the right taxonomy is not only an exercise in naming things, but also building the appropriate data structures and systems in your programs. I think this exercise is incomplete in the absence of studying how these nouns interact with one another.
I don't think that a loose-hanging 'payment intent' evokes a particular emotion, without its constituents' (credit cards, direct debits, cryptocurrencies) relationship to other nouns (customers, invoices, taxes, countries).
This is a great point. I did bring up the relationship exercise in the post, but admittedly I didn't give it enough respect.
In college, my database teacher told us to design a database with at least 50 tables and 100 relationships by the end of the lecture. "It will be easier than you think", he said. And it was! And I thank him for that, because that lecture alone probably got me through more progress in product design discussions than anything else.
Kinda feels like identifying the key user stories with a bit too much naval gazing at the implementation.
That said, the implementations start to gain their own weight as user expectation grows to meet the implementation. I suppose the noun thinking is not entirely frivolous for an established app with expected core workflows and design language.
Something frustrating is when a company is being _clever_ with their nouns. Sometimes it's relatively innocuous, but spending time remembering what unique name I should be searching for instead of something obvious is not my idea of a good time.
Nice article Ben! I think the HN crowd would be more familiar by calling those "Entities" but I like the new perspective of all companies only handling two or three of them really well.
I think there is more nuance about it for the SaaS-pocalypse though. I have been talking to hundreds of B2B companies and customers are now vibe coding solutions when they need something that the platform doesn't support: a dashboard, a workflow, or an integration.
And once a B2B customer gets a taste of vibe coding... then it's just a matter of time before they start to think about replacing the entire SaaS completely. I have seen this play over and over again so many times in the last few months, it's honestly shocking.
I am working to find solutions to the SaaSpocalypse but don't want to derail from the main topic, there's more info in my profile if this has been something you're thinking about!
Something I'm really good at is ending my articles with half-baked ideas :) so thank you for challenging it
Regarding "entities", totally understand. I like to write in ways that my mom would understand- not the HN community. In fact, I have a post called "Everything is a Spreadsheet", where I explicitly defined that Entity<->Noun relationship. Should have linked it!
Back to the Saaspocalypse... my startup is reckoning with this like all others. My next blog post will be titled "What's Preventing Me from Building Your App in a Weekend?". The ultimate "what's your moat" question. I think every SaaS should be forced to answer this on their marketing site. Thinking aloud, I'm considering good answers companies can say to this question... I think a perfectly legitimate answer is still "our prompts are better than your prompts". There are some companies where I simply believe the founders/engineers when they say they understand the problem better than I, because they've explored it more deeply. This is kinda what I was hinting at at the end... softwares that go mega-vertical in one or two nouns accrue more subject matter expertise than I ever will. Thus, that gives me more reason to trust their infrastructure, their configurations, and their prompts. This is not new but rather an extension of what created the SaaS economy in the first place.
I will definitely check out your profile- thank you for the thoughtful reply!
Oh yeah the SaaS-pocalypse is so new and there are so many different ways to try and understand and tackle it. Scary but exciting times!
> The ultimate "what's your moat" question
One effective moat might be "Your LLM has never been trained on our closed source codebase."
This makes me think of domain models in domain-driven design. Very useful to think about what these models are and how it makes sense to set them up & relate them in your area of work.
Makes me wonder if a similar level of analysis was done in reverse to conceive these, hopefully not word yahtzee. At least they don't end with "ly" - the horror.
Identifying the right taxonomy is not only an exercise in naming things, but also building the appropriate data structures and systems in your programs. I think this exercise is incomplete in the absence of studying how these nouns interact with one another.
I don't think that a loose-hanging 'payment intent' evokes a particular emotion, without its constituents' (credit cards, direct debits, cryptocurrencies) relationship to other nouns (customers, invoices, taxes, countries).
This is a great point. I did bring up the relationship exercise in the post, but admittedly I didn't give it enough respect.
In college, my database teacher told us to design a database with at least 50 tables and 100 relationships by the end of the lecture. "It will be easier than you think", he said. And it was! And I thank him for that, because that lecture alone probably got me through more progress in product design discussions than anything else.
Kinda feels like identifying the key user stories with a bit too much naval gazing at the implementation.
That said, the implementations start to gain their own weight as user expectation grows to meet the implementation. I suppose the noun thinking is not entirely frivolous for an established app with expected core workflows and design language.
Something frustrating is when a company is being _clever_ with their nouns. Sometimes it's relatively innocuous, but spending time remembering what unique name I should be searching for instead of something obvious is not my idea of a good time.
https://youtu.be/fKXk1VhAuvE?si=oWnhYn2AEkntAvDA
Really cool framing, never saw this broken down this way