Killed by Google: a JSON graveyard that ships as a Next.js site

What the dataset actually is, and who it is for

The project is two things stacked together. The first is graveyard.json, a flat file of product obituaries at the repository root. The second is a Next.js application that renders that file as a site. The README describes the whole thing as "a tribute and log of beloved products and services killed by Google," which is accurate about the intent and silent about the data model beyond the contribution fields.

The audience is narrow and clear. If you want to add a discontinued Google product to a public list, this is the path: a CLI prompts you for the entry and writes it into the JSON file, and a Jest test checks the result. If you want to consume a list of dead Google products programmatically, graveyard.json is right there and is MIT licensed, so you can copy it. What you cannot do is call an endpoint, because the README documents none. There is a homepage at killedbygoogle.com, but nothing in the repository describes an API behind it.

Each entry carries six fields according to the README: name, dateOpen, dateClose, description, link, and type. Type is one of app, service, or hardware. That is the whole schema as documented, and it is worth checking graveyard.json directly before writing a parser, because the README lists the fields for contributors rather than as a formal specification.

How graveyard.json, the CLI, and the Next.js app fit together

The data flow is a straight line. graveyard.json sits at the root. The bin/kill script, exposed as the yarn kill command, is an interactive prompt built on enquirer; it collects the six fields, validates them as you go, and appends the entry to the JSON file. graveyard.test.ts then reads that file and asserts that it is formatted properly and that all values are valid. The web app imports the same file and renders it.

That single-file design is the project's main structural decision, and it cuts both ways. There is one source of truth, so a bad entry is caught by one test rather than by a pipeline of services. There is also no database, no migration path, and no way to serve a subset of the data without touching the repository. The test suite is invoked as jest graveyard.test.ts, so validation is scoped to the data file rather than to the application code.

The stack is current rather than conservative: Next.js 16.2.6, React 19.2.6, TypeScript 6.0.3, Tailwind CSS 4.3.0, and Radix UI for the select component. The dev script runs next dev --turbopack. None of this is documented in the README; it comes from package.json. A contributor adding a product never touches any of it, which is the point, but anyone forking the site inherits that dependency surface.

Adding an entry: yarn kill, then yarn test

The README gives a concrete sequence for contributors who already use git. Fork the repository, create a branch named after the product, then install dependencies and start the interactive CLI. The command is yarn && yarn kill, which installs and launches the prompt in one line.

yarn && yarn kill

The CLI asks for the product name, launch date, discontinued date, description, link, and type, validating each value as it goes, and writes the result into graveyard.json. After the prompt finishes, the README says to run the test suite to confirm the file is well formed.

yarn test

The expected outcome is a passing Jest run against graveyard.test.ts. If your entry has a malformed date or a type outside app, service, and hardware, this is where it should surface. Then commit on your branch and open a pull request.

The README also names a no-git path: open a new issue using the add-an-obituary template and request the change. That is the right route if you do not want to run Node locally, and it shifts the validation burden to whoever merges.

Two editorial rules matter more than the mechanics. The description must be a single sentence beginning with the product's name, written in past tense, because it gets spliced into a generated line like "Killed about 5 years ago, Google Reader was an RSS/Atom feed aggregator." The link must be a resource that mentions the discontinuation date, with Wikipedia or a news organization preferred. The README explicitly rules out Google Support articles, the product's own URL, its marketing URL, and other Google-provided links, on the grounds that Google removes them quickly after a service ends.

Where the project is thin: no API, no releases, no rollback story

The most consequential limitation is that there is no documented interface other than the JSON file. The README does not describe an API, a schema version, or an export format. If you want the data in a pipeline, you clone the repository, and you own the refresh problem yourself. There is no published package for the dataset in the repository, and the package.json name is killedbygoogle with version 3.0.0, which describes the site rather than a consumable library.

The repository also lists no releases. For a dataset, that means there is no changelog telling you when entries were added or corrected, and no tag to pin against. You can pin a commit hash, and that is about it. Anyone treating this as a dependency should plan for that.

The README does not document rollback, and it does not describe what happens if a merged entry is later found to be wrong. The test checks formatting and value validity, not factual accuracy, so a well-formed entry with a bad date passes. That is a real failure mode: the automated gate is structural, and the editorial gate is a human reviewer.

Finally, the schema itself is sparse. Six fields, one of which is a free-text link. There is no field for the reason a product was killed, no category beyond app, service, or hardware, and no stable identifier other than the name. If your use case needs to join these entries against another dataset, you will be matching on strings.

Killed by Microsoft and the wider graveyard pattern

The obvious alternative is one of the sibling projects in the same genre, such as Killed by Microsoft or Killed by Apple. The difference is not cosmetic. This project keeps its data in a single graveyard.json at the repository root with a documented six-field schema and a CLI that writes to it. A sibling site with a different editorial process may keep entries in Markdown files, in per-product pages, or in a CMS, which changes what you can extract and how you would contribute.

If you only need a list, the practical comparison is between copying graveyard.json and scraping rendered HTML from a sibling site. Copying the JSON gives you typed fields and an MIT licence. Scraping gives you whatever the page happens to render, with no field guarantees. That difference matters more than any feature comparison, because the value of a graveyard dataset is entirely in whether you can trust the fields.

Within the same project, the alternative to the CLI is the issue template. The README offers both, and they produce different review loads: the CLI validates before a pull request exists, while the issue route asks a maintainer to transcribe and validate. For a one-off correction, the issue is less work. For anything more than that, the CLI is the path that keeps the test suite meaningful.

Licence, maintenance, and what an upgrade costs you

The project is MIT licensed, and the licence file sits at the repository root. For the dataset, that is permissive: you can copy graveyard.json into your own product, including a commercial one, provided you keep the licence terms. The README does not discuss attribution requirements for the data beyond the licence badge, so read LICENSE rather than this article before you redistribute. Nothing here is legal advice.

The last push to the repository was on 2026-09-01, which is recent. That matters for a dataset that is updated by pull request, because a stale repository means stale entries. It also means the dependency versions in package.json move: Next.js 16.2.6, React 19.2.6, and Tailwind 4.3.0 are all major-version-current, and a contributor running yarn install years from now will get whatever those ranges resolve to.

Upgrade cost splits by role. If you only read graveyard.json, your cost is zero and your risk is that the file changes shape without a version number to warn you. If you fork the site, you inherit a Next.js application with Turbopack, Tailwind 4, and Radix UI, and you own every one of those upgrades yourself. The project offers no upgrade guide in the repository, and the README's contribution section covers data, not code. The separate Contributing Guide at .github/CONTRIBUTING.md is where code contributions are directed.

Editorial conclusion

Adopt this if you want to read or extend a small, MIT-licensed JSON dataset of discontinued Google products and you are willing to work inside a Next.js repository to do it. Do not adopt it if you need a versioned API, a release cadence, or a data source you can consume without cloning the repo; the repository lists no releases, and the README documents no API or export format beyond graveyard.json itself. Before you build on it, open graveyard.json and confirm the fields your code needs are actually present, and run yarn test to see whether the current file passes validation.

Frequently asked questions

Official sources

1. codyogden/killedbygoogle on GitHub
2. Issues
3. License: MIT
4. Project website
5. README