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.

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!

Comments URL: https://news.ycombinator.com/item?id=47716840

Points: 73

# Comments: 20

Comments URL: https://news.ycombinator.com/item?id=47161759

Points: 662

# Comments: 380

The coolest part is the "Bonus". Anyone online can contribute to the Bonus Thing. What's there at midnight will be saved permanently (unless I think it's inappropriate).

I built this with Vercel, Convex, Vite, and Blocknote.

You can learn more about the meta of this project here: https://ben-mini.com/2025/things-to-be-happy-about-and-perfe...

Comments URL: https://news.ycombinator.com/item?id=46421977

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46121609

Points: 2

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=46100348

Points: 4

# Comments: 3

The idea of deleting and recreating views is an interesting one. I see that as a really cool approach- considering we can go without it as a v1 then include it as we scale.

Thank you for all your advice so far! This has been truly helpful.

Dumb question- is creating a set of Views for each customer even efficient for my MySQL database? I could realistically see us having ~12 customer-facing views- is having 12*N views a smart and scalable way to architect this?

1) I create a baseline set of views I want my customers to have 2) For each new customer, I’ll run a script that create a replica of those views- filtered by their customer ID 3) I’ll allow my customers to write pure SQL- limiting them to only SELECT queries and a couple niche business rules, as well as masking any DB-level errors, because that just feels wrong

How does that approach sound?

One customer needs full first names but only the first letter of the last name. Another needs a very specific JOIN with an entity almost no other customer cares about. To accommodate, I’ve been building custom Looker reports for each customer, which won't scale well.

I started looking into how other SaaS companies solved this. Many built their own SQL-like query languages:

- Salesforce -> SOQL - Shopify -> ShopifyQL - Stripe -> Sigma

All of them seemed to address the same problem I’m seeing: customers have unique reporting needs that no-code GUIs can’t handle. A drag and drop builder is great for non-techies, but most real requests require joins and transformations, and I’m trying to avoid becoming a consulting shop for every customer.

I'm particularly impressed by Stripe Sigma because of how they combine SQL with an LLM layer. Users can ask for a report in plain English, customize it in a lightweight BI tool, and edit the query only whenever needed.

Has anyone gone through this or have advice on alternative approaches? I’m open to any direction here.

Comments URL: https://news.ycombinator.com/item?id=46088109

Points: 3

# Comments: 11

Comments URL: https://news.ycombinator.com/item?id=45870191

Points: 5

# Comments: 1