Started as my MA thesis in 2022, kept building since, mostly solo with a little funding. Fully open source, self-hosted, AGPL-3.0, Next.js + Deck.gl on the frontend, Strapi backend, Python ETL pulling from museum open-access APIs. Currently indexing over 100k artifacts from all over the world, across 8 collections (Met, V&A, SMB Berlin). Recently added an md export so researchers can download provenance data for a filtered set of artifacts.
The infrastructure is conceptualized as an indexer, not a hoster. Even images are kept as URLs pointing to the source institutions. It's connective tissue between archives that were never designed to speak to each other, with an origin-first search UI concept. The data model is on purpose flat, to avoid encoding problematic taxonomies, and routes researchers directly to the source giving responsibility to the source institutions rather than duplicating institutional data. It indexes the relationship between origin sites and destination collections.
Coming from a design background, taking this project from prototype to production app has been incredibly rewarding, but honestly it\u2019s getting a little bit overwhelming to scale alone. I would love community\u2019s feedback on performance scaling, any code contributions, data pipelines for missing museum apis or general feedback.
Repo: https://github.com/hburakyel/ex-situ
Live: https://exsitu.app"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Ex Situ \u2013 Open-source spatial index of displaced cultural artifacts"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://exsitu.app/map"}},"_tags":["story","author_hbyel","story_48988158","show_hn"],"author":"hbyel","children":[48988677,48988753,48988960,48988995,48989035,48989268,48989317,48989522,48989530,48989919,48990114,48991281,48992302,48992673,48992779,48995536,48995708,48996086],"created_at":"2026-07-21T04:48:32Z","created_at_i":1784609312,"num_comments":41,"objectID":"48988158","points":51,"story_id":48988158,"story_text":"Hi, I designed and developed a spatial index that maps museum artefacts as connecting arcs/hyperlinks from their origin site to institutional location/sources. The Index specifically looks at western/euro-american institutions and maps their collection categorised by them under Islamic art, Asian/African art, ethnological collections, Middle East, South America etc.
Started as my MA thesis in 2022, kept building since, mostly solo with a little funding. Fully open source, self-hosted, AGPL-3.0, Next.js + Deck.gl on the frontend, Strapi backend, Python ETL pulling from museum open-access APIs. Currently indexing over 100k artifacts from all over the world, across 8 collections (Met, V&A, SMB Berlin). Recently added an md export so researchers can download provenance data for a filtered set of artifacts.
The infrastructure is conceptualized as an indexer, not a hoster. Even images are kept as URLs pointing to the source institutions. It's connective tissue between archives that were never designed to speak to each other, with an origin-first search UI concept. The data model is on purpose flat, to avoid encoding problematic taxonomies, and routes researchers directly to the source giving responsibility to the source institutions rather than duplicating institutional data. It indexes the relationship between origin sites and destination collections.
Coming from a design background, taking this project from prototype to production app has been incredibly rewarding, but honestly it\u2019s getting a little bit overwhelming to scale alone. I would love community\u2019s feedback on performance scaling, any code contributions, data pipelines for missing museum apis or general feedback.
Repo: https://github.com/hburakyel/ex-situ
Live: https://exsitu.app","title":"Show HN: Ex Situ \u2013 Open-source spatial index of displaced cultural artifacts","updated_at":"2026-07-24T10:59:51Z","url":"https://exsitu.app/map"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"tanin"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["arc","institute"],"value":"Hi HN,
I\u2019m Tanin. For about four years, I worked on the Revenue Recognition and Analytics teams at Stripe. Today, I'm open-sourcing Book of Revenue, a self-hosted revenue engine and drop-in alternative to Stripe Revenue Recognition (with optional support for Metronome).
### The Problem:
Most founders track MRR or cash collected in Stripe and assume that reflects revenue. But cash collected isn't revenue, and MRR isn't an accounting metric. Once you hit scale, raise institutional capital, or prep for an audit, ASC 606 / IFRS 15 rules kick in:
- Annual upfront subscriptions must be amortized monthly as deferred revenue.
- Mid-cycle upgrades, prorations, usage overages, refunds, and disputes quickly turn into messy manual spreadsheets.
- Finance and engineering end up arguing because Stripe dashboard numbers never match QuickBooks or NetSuite during month-end close.
### What Book of Revenue Does:
- Automated Revenue Recognition: Computes GAAP/IFRS-compliant revenue schedules from your Stripe billing and payment events out of the box.
- Unified Financial Truth: Aligns founder analytics with your accountant\u2019s ledger so both sides look at the exact same numbers.
- Full Data Ownership: Self-hosted with no vendor lock-in. You retain complete custody of your customer financial records and intermediate data models.
### Looking for Early Users:
I\u2019m looking for early design partners\u2014particularly companies processing over $100k in annual volume who dread month-end reconciliations.
I'm offering free hands-on deployment and a complimentary audit of your current Stripe/Metronome billing architecture. If you\u2019d like to test it out, drop a comment below or email me directly at tanin@bookofrevenue.com.
Website: https://bookofrevenue.com
GitHub: https://github.com/tanin47/book-of-revenue"},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Open-source revenue recognition and analytics for Stripe and Metronome"}},"_tags":["story","author_tanin","story_49758181","show_hn"],"author":"tanin","created_at":"2026-09-18T18:21:06Z","created_at_i":1789755666,"num_comments":0,"objectID":"49758181","points":3,"story_id":49758181,"story_text":"Hi HN,
I\u2019m Tanin. For about four years, I worked on the Revenue Recognition and Analytics teams at Stripe. Today, I'm open-sourcing Book of Revenue, a self-hosted revenue engine and drop-in alternative to Stripe Revenue Recognition (with optional support for Metronome).
### The Problem:
Most founders track MRR or cash collected in Stripe and assume that reflects revenue. But cash collected isn't revenue, and MRR isn't an accounting metric. Once you hit scale, raise institutional capital, or prep for an audit, ASC 606 / IFRS 15 rules kick in:
- Annual upfront subscriptions must be amortized monthly as deferred revenue.
- Mid-cycle upgrades, prorations, usage overages, refunds, and disputes quickly turn into messy manual spreadsheets.
- Finance and engineering end up arguing because Stripe dashboard numbers never match QuickBooks or NetSuite during month-end close.
### What Book of Revenue Does:
- Automated Revenue Recognition: Computes GAAP/IFRS-compliant revenue schedules from your Stripe billing and payment events out of the box.
- Unified Financial Truth: Aligns founder analytics with your accountant\u2019s ledger so both sides look at the exact same numbers.
- Full Data Ownership: Self-hosted with no vendor lock-in. You retain complete custody of your customer financial records and intermediate data models.
### Looking for Early Users:
I\u2019m looking for early design partners\u2014particularly companies processing over $100k in annual volume who dread month-end reconciliations.
I'm offering free hands-on deployment and a complimentary audit of your current Stripe/Metronome billing architecture. If you\u2019d like to test it out, drop a comment below or email me directly at tanin@bookofrevenue.com.
Website: https://bookofrevenue.com
GitHub: https://github.com/tanin47/book-of-revenue","title":"Show HN: Open-source revenue recognition and analytics for Stripe and Metronome","updated_at":"2026-09-20T07:32:25Z"}],"hitsPerPage":50,"nbHits":25,"nbPages":1,"page":0,"params":"query=Arc+Institute&tags=story&hitsPerPage=50&advancedSyntax=true&analyticsTags=backend","processingTimeMS":15,"processingTimingsMS":{"_request":{"roundTrip":16},"afterFetch":{"format":{"total":1}},"fetch":{"query":9,"scanning":4,"total":14},"total":15},"query":"Arc Institute","serverTimeMS":16}