This page converts the full audit into a single self-contained HTML/CSS artifact. It preserves the layer model, the weighted scoring system, the project-by-project analysis, and the adversarial corrections that materially changed the ranking. Source links are embedded throughout the page rather than isolated in an appendix.
Best overall core backend for property and landlord operations: MIT-licensed, actively released, self-hostable, and structurally clean enough to be wrapped in a Bitcoin-only payment layer.
Strongest public-facing website and discovery layer: MIT-licensed Rails application with multi-tenancy, modern themes, and deployment options. Loses points because the booking/PMS layer is not yet first-class.
Best hospitality-specific PMS in the set: open-source hotel/pension management software with reservations, invoices, registration book, cash book, and iCal sync. Slightly lower due to GPL constraints and stronger OTA-bridge assumptions.
Useful as a Bitcoin-facing demand surface, but not a sovereign kernel. Public marketing claims a Bitcoin-only platform, yet the legally operative system remains centralized, closed, and governed by Airbtc-controlled databases, records, and payment logic.
One of the biggest corrections from the adversarial review was the recognition that these four systems are not the same type of object. Scoring a centralized marketplace directly against self-hostable open-source kernels creates category error. The final ranking therefore starts with explicit layer assignment.
| Project | Layer | Primary role | Verification links |
|---|---|---|---|
| MicroRealEstate | L1 – Core Sovereign Kernel | Landlord / property operations backend: leases, rent tracking, tenant information, notices, document generation, payment tracking. | Repository · Releases |
| PropertyWebBuilder | L1/L2 – Sovereign Front-End Shell | Public-facing real estate / rental website engine with multi-tenancy, themes, search, and embeddable property widgets. | Repository · Project site |
| FewohBee | L1 – Domain PMS Kernel | Hospitality PMS for guesthouses, pensions, hotels, and vacation homes: reservations, invoices, guest records, registration book, cash book, calendar sync. | Official site · Repository · Dockerized setup |
| Airbtc | L3 – Transitional / Bridge SaaS | Centralized Bitcoin-facing accommodation marketplace. Useful for routing BTC travelers, but not eligible as a core sovereign primitive because the platform itself is closed and Airbtc controls the system of record. | About · FAQ · Terms · Privacy |
Each criterion is scored from 0–100. The weighted composite is then calculated from the percentages below. This weighting reflects the adversarial corrections: separation of guest-facing Bitcoin support from deeper settlement purity, heavier emphasis on ownership of code and data, and explicit punishment for enclosure and non-forkable choke points.
BTC Guest-Facing Support — 10%
Measures whether the system allows guests or users to transact in Bitcoin out of the box.
Settlement-Layer Purity & Fiat Detach — 10%
Measures whether the actual settlement logic can remain Bitcoin-native and independent from cards, bank rails, and fiat backstops.
Payment Infrastructure Sovereignty — 10%
Measures whether a self-hosted stack such as BTCPay, Lightning, and on-chain infrastructure can be imposed and controlled directly.
FOSS License & Forkability — 15%
Measures code openness, licensing freedom, and long-term ability to fork and preserve sovereignty.
Self-Hosting & Infrastructure Control — 15%
Measures the ability to run the full system on owned hardware or operator-controlled servers without mandatory SaaS dependencies.
Data Topology & Ownership — 15%
Measures who owns the canonical database, event history, and records that prevail in a dispute.
Synthetic-Stack Entanglement — 10%
Measures how much Google/Firebase/S3/OTA or other legacy dependency is assumed by the default architecture. Higher score means cleaner separation.
Modularity / Composability — 7.5%
Measures how easily the project can be fitted into a larger sovereign OS or combined with other components.
Vitality & Longevity — 7.5%
Measures the project’s release cadence, maintenance signal, and survivability as of March 2026.
| Criterion | Weight | Why it matters in this framework |
|---|---|---|
| BTC Guest-Facing Support | 10% | A project can be strategically useful if it makes spending sats frictionless, but guest-facing Bitcoin support alone is not enough to qualify as sovereign infrastructure. |
| Settlement-Layer Purity & Fiat Detach | 10% | This is the deeper test: whether the project’s booking and payout reality ultimately depends on fiat rails or can remain Bitcoin-native by design. |
| Payment Infrastructure Sovereignty | 10% | A self-hostable open core that can be paired with owned BTCPay/Lightning/on-chain tooling is worth more than a polished black-box marketplace. |
| FOSS License & Forkability | 15% | Projects such as MicroRealEstate, PropertyWebBuilder, and FewohBee preserve exit rights. A closed platform does not. |
| Self-Hosting & Infrastructure Control | 15% | Running on owned or operator-controlled infrastructure is a basic sovereignty requirement for L1/L2 eligibility. |
| Data Topology & Ownership | 15% | The system of record matters. If canonical logs and records are owned by a third party, the user only “uses” the stack rather than controls it. |
| Synthetic-Stack Entanglement | 10% | Optional Google Maps, Firebase, S3/R2, OTAs, or channel-manager assumptions reduce separation from the legacy surveillance and dependency stack. |
| Modularity / Composability | 7.5% | The stronger the ability to combine front-end shell, PMS, payments, and local policy engines, the stronger the long-term system value. |
| Vitality & Longevity | 7.5% | A dead or abandoned project, even if beautiful in principle, is a weaker building block than an actively maintained one. |
| Project | BTC Guest | Settlement Purity | Pay Infra Sovereignty | FOSS / Forkability | Self-Host | Data Ownership | Synthetic Entanglement | Modularity | Vitality | Composite |
|---|---|---|---|---|---|---|---|---|---|---|
| MicroRealEstate | 40 | 80 | 90 | 95 | 94 | 92 | 90 | 85 | 92 | 85.4 |
| PropertyWebBuilder | 40 | 75 | 85 | 95 | 90 | 85 | 65 | 95 | 93 | 81.1 |
| FewohBee | 35 | 70 | 80 | 85 | 90 | 90 | 70 | 80 | 82 | 77.4 |
| Airbtc | 80 | 30 | 20 | 5 | 5 | 45 | 50 | 30 | 80 | 34.5 |
Highest overall because code, data, self-hosting, and composability are all strong while fiat entanglement is minimal by default.
Outstanding front-end shell and multi-tenant shell, with only moderate deductions for Google/Firebase/S3-style default assumptions and the lack of mature in-core booking logic.
Very strong hospitality-focused PMS; loses some room to the top two due to GPL flexibility limits and stronger OTA/calendar bridge assumptions.
Guest-facing Bitcoin support is real, but the core platform fails on self-hosting, forkability, data ownership, and settlement sovereignty.
A centralized marketplace and a self-hostable open-source backend cannot be judged as if they are the same class of object. Airbtc functions as a bridge marketplace. MicroRealEstate, PropertyWebBuilder, and FewohBee function as sovereign-capable building blocks. The ranking only becomes coherent after this separation.
The first pass gave too much weight to the fact that Airbtc publicly markets itself as Bitcoin-only. The later review separated outward payment experience from the deeper legal and operational settlement layer.
The contradiction is material: the FAQ says guests pay in Bitcoin and hosts receive Bitcoin, but the Terms also state that bookings can be confirmed by credit card, electronic funds transfer, or “some other payment method,” and that hosts must provide bank details.
For all three FOSS projects, the canonical data lives on the operator’s own infrastructure when self-hosted. That raises their ceiling sharply. In contrast, Airbtc’s Terms specify that Airbtc’s record prevails in disputes and that “all databases, information and systems are the property of Airbtc.”
MicroRealEstate and PropertyWebBuilder are MIT-licensed, which materially increases future forking, white-labeling, and deeper stack integration flexibility. FewohBee is GPL-3.0, which is excellent for internal sovereignty but more constraining for future closed or semi-closed commercialization paths.
PropertyWebBuilder explicitly documents Google Maps integration, Firebase auth, and S3/R2-compatible storage. FewohBee explicitly documents iCal sync and hospitality workflows that fit well with OTA bridge scenarios. These are not fatal, but they are not neutral either.
The final scoring assumes maximalist deployment modes where those dependencies are disabled, replaced, or controlled wherever possible, but their default presence still reduces the raw score.
MicroRealEstate is best understood as a back-office property operations kernel. FewohBee is best understood as a hospitality PMS. PropertyWebBuilder is best understood as the public front-end discovery shell. When these roles are respected, the set looks less like a winner-take-all contest and more like a potential composite stack.
MicroRealEstate describes itself as an open-source application designed to help landlords manage properties and rentals. The repository is MIT-licensed and the project’s own release stream shows 1.0.0-alpha.3 released on 2024-11-14, with self-hosting simplifications and HTTPS support highlighted in the changelog.
Use as the landlord/property operations brain. Attach custom BTC settlement, auditing, and public front-end layers around it rather than replacing it with a bridge marketplace.
MicroRealEstate is not a public checkout or guest-facing reservation portal. It is a back-office system. That keeps the score modest here. The low number is not a condemnation; it simply reflects the project’s actual role.
Because the system does not appear to hard-wire card processors or fiat gateways into its documented core, it is unusually clean for Bitcoin-only retrofitting. The operator can decide that all rents, deposits, or balances are expressed and settled via an external Bitcoin stack rather than inheriting a legacy processor from the application itself.
The application does not lock payment flow into a third-party black box. A self-hosted BTCPay-style approach or equivalent owned Lightning/on-chain flow can be layered around it. The deduction from 100 reflects the engineering work still required to implement a polished Bitcoin-native flow.
MIT is near-ideal from a sovereign infrastructure standpoint. It preserves freedom to modify, fork, white-label, and recombine without future licensing traps.
The project’s own repository contains multiple docker-compose files, and the latest release explicitly references simplified self-hosting and HTTPS support. That is exactly the direction an L1 component should take.
In a self-hosted deployment, property, tenant, and payment metadata remain on infrastructure controlled by the operator. That sharply contrasts with a centralized booking marketplace where records are maintained elsewhere and merely exposed through a dashboard.
No prominent Google Maps, Firebase, or OTA dependency is surfaced as part of the project’s public positioning. Any external dependency introduced later would be a deployment choice, not a design prison.
Its architecture and problem scope make it a strong candidate for composition. A public listing shell can sit in front of it. A Bitcoin payment service can sit beside it. A document, contract, or logging layer can sit behind it.
The project remains alive enough to matter: recent alpha releases, active issues, and an engaged GitHub surface together make it one of the strongest long-horizon primitives in the set.
PropertyWebBuilder is a modern real-estate website engine rather than a full PMS. The official project site states that Version 2.0.0 was released in December 2025, describing it as a major release representing five years of development and 500+ commits since v1.4.0. The same official materials highlight a Rails 8 / Ruby 3.4.7 / Vue 3 / Tailwind stack, multi-tenancy, optional Firebase auth with Devise fallback, Google Maps integration, and ActiveStorage for S3/R2-compatible storage.
Use as the public-facing shell: local property portals, federated listing hubs, sovereign “Zillow-class” fronts, or themed property microsites. It is a force multiplier for visibility, not a substitute for an operations backend.
The project is not natively Bitcoin-centric. It is neutral scaffolding. It can host forms, pages, and integration points for a Bitcoin checkout flow, but it does not ship with that flow as a defining feature.
Because the project is self-hosted and highly extensible, a BTC-only payment and contact flow can be enforced at the site level. The deduction comes from the platform’s broad and multi-currency orientation rather than any anti-Bitcoin design choice.
Rails makes custom integrations straightforward. A privately run payment service, BTCPay endpoint, or Lightning flow can be inserted without inheriting a default proprietary payment provider. Nothing in the official materials suggests that card processing is mandatory.
MIT again places the project near the top of the ranking for long-term strategic flexibility. This matters because front-end shells are often the layer most likely to be themed, specialized, or repurposed.
The project site lists numerous deployment paths, including Dokku for self-hosted PaaS alongside several hosted platforms. That means owned infrastructure remains fully viable.
When self-hosted, the operator owns listings, themes, and user data. The deduction comes from the fact that the default public documentation visibly leans on mainstream storage and integration patterns unless the installation is deliberately hardened.
This is the main cost center. The official documentation and project site explicitly mention Google Maps integration, optional Firebase authentication, and S3/R2-compatible ActiveStorage. These are all replaceable, but they are not invisible.
This is where PropertyWebBuilder is exceptionally strong. A multi-tenant front-end shell that can host many property sites from one installation has obvious civilizational utility. It can become the public membrane for many local nodes at once.
The project’s December 2025 v2.0 and v2.1 release train signals serious recent movement. The rewrite, the documentation, and the feature velocity all support a high vitality score.
FewohBee presents itself as open-source management software for pensions, hotels, accommodations, and vacation homes, with explicit support for self-hosting on an operator’s own server or local network. The official site emphasizes that the software can be used free of charge, while the public repository specifies GPL-3.0, identifies the application as a PHP/Symfony PMS, and lists features such as reservation management, guest data with GDPR export, invoices, conversations, statistics, registration book, cash book, and iCal sync.
Use where a real hospitality PMS is required immediately. It is the strongest out-of-the-box fit for guesthouses, pensions, inns, and small hotel-style operations.
FewohBee is payment-neutral but not Bitcoin-forward. It does not surface a Lightning or on-chain payment flow by default. That keeps the score restrained.
A self-hosted deployment can absolutely operate with a Bitcoin-only external settlement process. The deduction reflects the platform’s stronger assumption that the operator may sync calendars with legacy booking channels or otherwise coexist with fiat-linked hospitality infrastructure.
Because invoices, cash book, and booking records live in the local PMS, actual payment flow can be delegated to an owned Bitcoin stack. It is slightly less open-ended than MicroRealEstate because the hospitality workflows are more opinionated.
GPL-3.0 is real open source and excellent for preserving user freedoms, but it places stronger copyleft obligations on derivative distribution than MIT. That matters when future commercialization or white-label layering becomes relevant.
FewohBee’s own site encourages running it self-hosted on an owned server or local network, and the separate dockerized setup provides a concrete deployment path.
Guest information, invoices, and operational records remain operator-owned when self-hosted. This is one of the strongest sovereignty features of the project.
The repository explicitly advertises calendar export for other applications via iCal sync, and recent release notes mention additional iCal import support. These are useful tactical bridge features but also represent telemetry and dependency surfaces if left enabled indiscriminately.
The project is more monolithic than PropertyWebBuilder and more hospitality-specific than MicroRealEstate, but it remains scriptable, modifiable, and practical. Its shape is narrower, not weak.
FewohBee has long-running maintenance history and a still-active release stream. The public repository shows 557 commits at the time of verification, and the official project site continues to present it as an actively used and documented tool.
Airbtc’s public About page explicitly frames the project as a “Bitcoin only project” and says the platform will “never accept fiat currency or any other forms of crypto.” The FAQ states that guests can pay via Lightning Network or on-chain, that prices are displayed in USD for now, and that hosts receive the amount of bitcoin paid by the guest minus a 15% fee. A live property page also labels payment as “Bitcoin Only”.
That positive surface picture, however, is not the whole story. The decisive adversarial correction comes from the Terms & Conditions, which specify that bookings can be confirmed when payment is made to Airbtc by credit card, electronic funds transfer, or “some other payment method,” that Airbtc acts as the host’s agent eligible to receive payments, that hosts must provide bank details, that Airbtc’s record prevails in disputes, and that “all databases, information and systems are the property of Airbtc.”
Treat Airbtc as a Bitcoin-branded bridge into the broader world. It can route travelers inward, but it should not define property truth, booking truth, settlement truth, or long-term reputational reality.
This is the platform’s strongest axis. Publicly, guests can pay in Bitcoin via Lightning or on-chain, and listings explicitly signal Bitcoin-only payment. That is real utility.
This is where the score collapses. The Terms explicitly state that a booking is confirmed when payment is made to Airbtc by credit card, electronic funds transfer, or some other method, and later discuss fraudulent credit card payments, reversed bank deposits, and the need for host bank details. That legal substrate is not the same thing as a pure Bitcoin-native settlement layer.
Even if Bitcoin is used in the outward flow, the operator does not control the marketplace logic, escrow flow, dispute flow, or payout machinery. Airbtc is the agent, not the host.
There is no public core repository to fork. This alone disqualifies the platform from L1 status.
The platform cannot be run on owned infrastructure. It is consumed as a service.
Airbtc’s Privacy Policy says the company does not sell or share personal data except as required by law or with explicit consent, and the Terms include privacy commitments. Those are meaningful positives. But the same Terms also state that Airbtc’s records prevail in disputes and that all databases, information, and systems belong to Airbtc. That makes the platform a data choke point by design.
This score sits in the middle. The public Bitcoin emphasis is strong, but the legal framework still references bank-dependent realities and third-party availability software integrations. This is not a clean air-gapped sovereign system.
Airbtc is not a sovereign primitive. It is a closed marketplace. The best it can be in this framework is a tactical feed channel from a Bitcoin traveler market into infrastructure that actually remains controlled elsewhere.
The platform is visibly alive. That matters. But because it is closed, vitality here does not convert into sovereignty the way it does for the FOSS projects above.
MicroRealEstate occupies this slot most cleanly. It is the strongest neutral kernel for leases, tenants, payment tracking, and internal property operations under direct operator control.
FewohBee fills the PMS role where a guesthouse, small hotel, pension, or vacation-home workflow is required. It is narrower than MicroRealEstate but much more immediate for hospitality-specific operations.
PropertyWebBuilder is the front-end surface: portals, hubs, local site clusters, and searchable public property experiences. It is strongest when paired with one of the operational kernels behind it.
It combined the cleanest ownership model, high self-hosting quality, permissive licensing, strong fit for Bitcoin-only retrofitting, and minimal default dependency on external legacy services.
The decisive factor was not ideological hostility to a useful bridge. The decisive factor was that the platform remains closed, centralized, fiat-legible at the legal layer, and owned by someone else at the database layer.