Truly a good idea, but it is somewhat hard to evaluate this when all we get are a couple high level graphs, and everything else is marked as "Unlock with Pro"

The freemium model is in and of itself interesting because most tech leaders in the public sector are quite allergic to the idea of monetizing the public view of data and content. They want the organizations who produce the data to fund the platforms, with the public views being a key piece of the puzzle, but not the funding source. I'm actually with you on it, that if the public wants deep engagement, it is worth some small fees. But we're the minority - most folks with whom I've discussed projects vehemently reject the idea.

As you are also asking for a "Pro" subscription for API access, I'd open up the public view and rely instead on API fees.

I hear ya. I'm just unsure that people will even use the API enough. That is assuming that most of the people that would use this/hangout here are programmer-y.

Perhaps I can make more things seen in the "Free tier"

> We can only speculate... Here are a few possibilities...

AI-generated or not, this is the tech blog equivalent of fan fiction, just making guesses based on a one-liner where Anthropic said they have 1000 customers at $1M+ ARR.

School walkouts typically have nothing to do with the school itself, and certainly do not ask for it to be allowed. It is the kids who walk out. The schools typically treat it like any other unexcused absence.

The "allowed" aspect that you're ignoring is about punishment. Some walkouts are punished while others aren't, based on ideology.

More likely based in scale, in the sense of "they can't punish all of us."

OK, cool, but... why? If your goal is release notes with content meaningful to the user, not just tech details, wouldn't it be even easier/better/cheaper to just send the content of Jira tickets instead of all the code into your context? (Or whatever PM system you use to track your product work)

After all, that would include user-meaningful content already as well as priorities and other business context. Why guess information from code when there is probably already a system that has those answers?

Edit: I just saw where you posted this a month ago, too. From that post: "I'm a PM at Arthur. Every release I'd spend hours combing through commit logs and PRs trying to write something coherent for our users. "

Now I'm doubly confused. You are a PM who doesn't track the work? You comb through code? This makes so little sense. That isn't at all typical of how PMs work?

What an odd way to achieve their stated goal of keeping it open.

No, I have the opposite reaction. A new company with funding to me just implies a runway that will run out, and no profitable business attached to it. Show me a balance sheet that is self-sustaining on their own revenue, and I'll work with them over VC-funded startups any day.

How possible is it these days to build a software business that is 'self-sustaining on their own revenue' without some decent funding up front?

Are you joking? The cost of writing code is practically free. Some basic hosting is very cheap. Find just a couple of paying customers and you are self-sustaining. Hire only when the revenue supports it, and you remain that way.

I think it is a lower level problem than that. "Founders" fall into the trap of thinking that getting funding is a fundamental aspect of building something new, when it is not. Instead of building a solid business plan, then applying funding if and where needed to resolve constraints of carrying out the plan, they make their plans with funding as the primary goal, and only later determine whether or not it is actually a viable business.

This is exactly right and there's a tell that I've noticed after reviewing hundreds of decks and talking to a lot of founders.

You can figure out pretty quickly whether a founder has been forced to actually sell something or whether they've been living in pitch mode. And the difference shows up in a really specific way.

Ask them about their customers. The founders who had to sell to survive talk about specific people. They know the person's name, what their actual objection was, why the third conversation went differently than the first two, what made them finally sign. The detail is almost uncomfortable sometimes.

The pitch mode founders talk about personas. "Our customer is a mid-market ops manager who struggles with workflow inefficiency." Technically an answer. Completely useless information that tells you they've been reading about their customer rather than talking to them.

The brutal thing is that early fundraising success can actually mask this for a long time. A founder who raises a seed round before they've had to sell anything gets 18 months of runway to stay in pitch mode. They raise the seed talking about potential. They raise the A talking about momentum. By the time you're at the B someone finally asks a hard question and there's nothing underneath.

The founders who couldn't raise early and had to go find a paying customer instead got the most important feedback the startup world has. Someone who has no obligation to be nice to you decided your thing was worth money. That's it. That's the whole game early on and most of the ecosystem is set up to let founders avoid finding that out for as long as possible.

A database is a file system when you get down to it. The reason people use them is to abstract up a layer so you can query the data and get the results you want instead of having to iterate through direct reads of a disk, then having to read, parse, and filter what you want from those reads. You could always write code to help do those things direct from disk, but you know what you have just written if you do so? A database!

I'd say the filesystem is a database.

It would be straightforward, for instance, to implement a lot of the functionality of a filesystem in a database with BLOBs. Random access might be a hassle, but people are getting used to "filesystem-like" systems which are bad at random access like S3.

> You could always write code to help doing those things direct from disk, but you know what you have just written if you do so? A database!

Yes, but that's my point. Why is this not a part of the standard library / typical package with very little friction with the rest of the code, instead of a separate program that the standard library / typical packages provide in an attempt to reduce the friction?

Or are you making the general point that databases already existed prior to the standard libraries etc, and this is just a case of interfacing with an existing technology instead of rebuilding from scratch?

Because a reasonably well optimized database with support for indexes, data integrity enforcement, transactions, and all the other important things we expect from a good (relational) database is complex enough that it takes a rather large codebase to do it reasonably well. It’s not something you slap together out of a handful of function calls.

ETA: look at SQLite for an example — it’s a relatively recent and simple entrant in the field and the closest you’ll find in the mainstream to a purely filesystem based RDBMS. How would you provide a stdlib that would let you implement something like that reasonably simply? What would be the use case for it?

Actual Title: How to Delete Yourself from the Internet in 2026 (The Real Version)

Welcome to HN, where the guidelines can be found here: https://news.ycombinator.com/newsguidelines.html, and which include both using the actual title and participating in the community, not just popping in for self-promotion.

That seems like an acceptable constraint to me. If you need a structured query, LLMs are the wrong solution. If you can accept ambiguity, LLMs may the the right solution.