Real Estate Tokenization Companies: Infrastructure, Marketplaces, and Development Shops Compared

A fund manager evaluating five real estate tokenization companies for a $30M residential portfolio receives quotes ranging from $40,000 to $1.8 million. The deliverable, on paper, sounds identical: tokenize the asset, onboard investors, handle compliance, enable secondary trading.

The spread is not negotiation theater. These vendors sell structurally different products to structurally different buyers. One is a SaaS subscription. One is a listing on an investor marketplace. One is a six-month custom build. Confusing them is the most expensive procurement mistake in this market right now.

Why 'Real Estate Tokenization Companies' Is a Misleading Category

The label collapses three distinct business models into a single search term. When a fund manager lists Elevated Returns, Harbor, RealtyBits, RealT, Fluidity, AssetBlock, and Realty Mogul as comparable vendors — as Custom Market Insights does in its market mapping — the list mixes a fundraising boutique, a compliance-token issuer, a marketplace, a retail platform, and a regulated broker-dealer. These companies do not compete for the same RFPs. They serve different parts of the issuance stack.

The Fibree research group documents the same problem from the platform side. Its archetype comparison identifies at least six operating models among active platforms, with infrastructure SaaS, retail-fractional marketplaces, and turnkey compliance providers all marketed under the same "tokenization platform" label. The result is predictable: pilots stall, budgets blow out, and issuers end up with a deliverable that does not match the goal they started with.

The right way to classify these vendors is by business model. An issuer that needs to keep the investor relationship should not buy from a marketplace. An issuer with one deal and no repeat issuance plan should not commission a custom build. The procurement question is which archetype fits the issuance strategy — three archetypes, three different answers.

Market Size and Why Vendor Categories Are Multiplying

The forecasts diverge by an order of magnitude, which itself explains the vendor sprawl. Custom Market Insights puts the real estate tokenization market at USD 3.5 Billion in 2024, projecting USD 19.4 Billion by 2033 at a 21% compound annual growth rate (CAGR), with Europe as the largest current market and Asia-Pacific as the fastest-growing. Deloitte's projection, summarized in an Adventures in CRE analysis, places tokenized real estate on blockchain networks above USD 4 trillion by 2035, up from under USD 300 billion in 2024.

The methodology gap matters. CMI tracks platform revenue and issuance flow. Deloitte models total tokenized property value, which captures the underlying asset rather than the service layer. Both can be correct. Neither tells an issuer which vendor to hire.

What both forecasts confirm is a market large enough to sustain specialization. When BlackRock's BUIDL fund — a tokenized money-market product — surpassed $1 billion in assets under management, institutional capital signaled that tokenization infrastructure had arrived as a real category. That signal pulled three distinct vendor archetypes into formation rather than driving convergence on a single platform model.

The reason is structural. Issuers with a $200M office portfolio in Frankfurt have nothing in common operationally with a developer selling $500 fractional shares of a Detroit duplex. Both need tokenization. Neither needs the same vendor. The market is splitting into infrastructure providers selling to professional issuers, marketplaces selling to retail-facing operators, and development shops selling to one-off custom projects. On-chain RWA trackers like RWA.xyz show the same pattern in their issuer breakdowns: the providers serving institutional volume are not the platforms running retail marketplaces.

Tokenization Infrastructure Providers: The White-Label Layer

Infrastructure providers sell software to issuers. The output is a configured platform — branded for the issuer, deployed under the issuer's legal entity, integrated with the issuer's chosen custodian and KYC (Know Your Customer) vendor. The issuer owns the deal, the investor relationship, and the cap table. The provider owns the code, the upgrades, and the compliance modules.

What the deliverable actually contains

Fibree's archetype mapping describes this model precisely. "Party C takes the role of an infrastructure enabler, offering white-label tokenization technology to local operators and connecting tokens to existing property registries," its platform comparison notes, while "Party D also acts as infrastructure SaaS, but with a strong emphasis on turnkey compliance and secondary trading integrations." Both descriptions match the same commercial pattern: the issuer rents the rails.

A typical deployment configures the jurisdiction (Luxembourg SPV — a Special Purpose Vehicle, meaning a separate legal entity created to hold the asset — Liechtenstein TVTG, Swiss DLT Act, UAE ADGM), the token standard (ERC-3643 or ERC-1400 for permissioned transfer), the KYC/AML provider, the custodian (the regulated entity that holds the digital assets on behalf of investors), and the investor onboarding flow. Setup runs four to twelve weeks depending on jurisdiction complexity. Pricing is subscription plus issuance fees — typically tens of thousands per year for the platform, with per-deal costs in the same range.

Where the model fails

The infrastructure provider does not bring investors. The issuer who treats the SaaS subscription as a fundraising tool will be disappointed inside three months. Tokeny's ecosystem map makes this division explicit: infrastructure sits in one column, distribution sits in another, and the issuer is responsible for sourcing distribution separately. A fund manager with a captive investor base sees this as a feature. A first-time developer with no distribution sees it as a missing deliverable.

The second failure mode is over-customization. White-label platforms are built to be configured within set limits. An issuer requesting bespoke smart contract logic — self-executing code on a blockchain that automates deal terms — novel waterfall mechanics, or a non-standard secondary venue is asking the infrastructure vendor to act as a development shop. Pricing and timelines diverge accordingly. Some providers explicitly protect the configured-not-custom boundary to keep delivery economics stable.

This model works for issuers who already have deal flow, an investor base, and a repeat issuance plan. The issuer's legal structure drives the configuration; the configuration does not replace the legal structure.

Real Estate Tokenization Marketplaces: The Investor-Facing Model

Marketplaces sell access to investors. The output is a listing on a platform that already has retail or accredited users onboarded, KYC'd, and funded. The issuer hands the deal to the marketplace, which runs the offering on its own terms, takes a fee, and keeps the investor relationship.

Fibree's mapping captures the archetype clearly: "Party A represents the retail-first approach, selling direct fractional ownership in residential properties, usually down to small ticket sizes." Tickets often start at $50 to $500, the property is held in a per-asset SPV controlled by the marketplace operator, and the token represents an indirect economic interest rather than legal title. The investor signs the marketplace's terms, not the issuer's.

Revenue flows three ways for the marketplace: a listing or origination fee at issuance (typically 2–5% of raise size), a spread on secondary trading, and an ongoing AUM (Assets Under Management) or asset-servicing fee. Brevitas analysis of fractional ownership models notes that marketplace economics depend on listing velocity rather than per-deal margin — which shapes what kinds of deals the platform accepts and how it prices them.

Three issuer consequences follow. First, the issuer does not control investor selection. The marketplace's existing user base is the audience, and onboarding new investors directly to the issuer is restricted by the platform's terms. Second, the issuer does not control pricing post-listing. Secondary trading happens on the marketplace's venue, with bid-ask spreads and discounts the issuer cannot influence. Third, the issuer does not control the investor relationship for the next deal — the marketplace does. Repeat issuance routes through the platform.

For an issuer whose primary problem is investor acquisition, this trade is rational. Marketplaces deliver a retail audience that a fund manager would otherwise spend years building. For an issuer with an existing investor base — a family office network, a developer's repeat-buyer list, a fund's LP roster — the marketplace model gives away the most valuable asset on the table.

The binding limit on this model is investor base ownership. An issuer who needs to keep the LP relationship for follow-on funds cannot accept a structure where the platform owns the contact. That is the procurement question to answer before requesting a marketplace quote.

Tokenization Development Companies: The Custom-Build Path

Development shops sell engineering hours. The output is a bespoke platform — smart contracts written from scratch or forked from a template, a custom frontend, a custom admin panel, and integrations specified by the issuer. Pricing is project-based, typically $150,000 to $1.8 million depending on scope, with delivery timelines of four to twelve months.

The pitch from firms profiled across Synodus, EcoFico, and Antier Solutions is consistent: full ownership of the codebase, custom logic for any deal structure, branded end-to-end, and no recurring SaaS fees. For an issuer with novel mechanics — a tokenized hotel revenue waterfall, a development-stage construction draw structure, a multi-asset rebalancing fund — the custom path is sometimes the only way to ship.

The liability inherited is maintenance. Once the engagement closes, the issuer owns the code, the bugs, the upgrade path, the smart contract audits for every change, and the regulatory updates as MiCA (the EU's Markets in Crypto-Assets regulation), the Swiss DLT Act, and equivalent frameworks evolve. Firms like those listed by Oodles typically offer post-launch support contracts, but those contracts price separately and shift the issuer back toward recurring-cost economics — without the multi-tenant cost sharing that makes SaaS subscriptions affordable.

The second hidden cost is regulatory drift. A custom platform built to 2024 EU rules needs rework when MiCA implementing standards finalize, when a new jurisdiction is added, or when the secondary venue's listing requirements change. Infrastructure providers absorb this work across their tenant base. Custom builds absorb it on the issuer's balance sheet.

The model fits issuers with three characteristics: deal mechanics that no configured platform supports, capital to fund the build, and a roadmap that justifies owning the technology long-term. For everyone else, the math points back to infrastructure.

Side-by-Side: Deliverables, Costs, and Failure Modes

The three archetypes compared on the dimensions that determine fit:

Synodus's tier analysis of active providers confirms these cost bands across recent engagements, and Entralon's 2025 market data shows that issuer-reported time-to-launch concentrates in the 6–14 week range for configured deployments versus 6–10 months for custom builds.

The failure modes follow the cost structure. Infrastructure providers fail when the issuer expects distribution. Marketplaces fail when the issuer expects to keep the investor relationship. Development shops fail when the issuer underestimates maintenance — Chainalysis tracking of on-chain RWA activity shows that abandoned custom-built platforms outnumber abandoned SaaS deployments by a wide margin, because the maintenance cliff arrives roughly twelve months after launch.

The procurement question is which failure mode the issuer can absorb. None of the three is universally wrong. All three are wrong for the wrong issuer.

A Selection Framework for Fund Managers and Developers

Four variables determine the right archetype: deal size, who owns the investor base, jurisdiction count, and whether the issuer plans repeat issuance. Each scenario points to a clear answer.

Scenario one: a $12M institutional single-asset deal

Take a boutique fund manager tokenizing one office building in Luxembourg, with thirty existing LPs already identified, and no plan to issue again within eighteen months. Investor acquisition is solved. Jurisdiction is one. Repeat issuance is unlikely. A real estate tokenization marketplace would surrender the LP relationship the manager already owns. Custom development is overbuilt for the scope. The tokenization infrastructure provider archetype fits: configure the Luxembourg SPV, deploy the permissioned token, run KYC against the existing LP list, list on an integrated secondary venue. Insight Ace market data shows this profile — small institutional issuers with captive distribution — as the fastest-growing infrastructure-buyer segment.

Scenario two: a $50M multi-jurisdiction portfolio

A developer with twelve assets across Germany, the UAE, and Spain, planning quarterly issuances over three years, faces a different problem. Jurisdiction count is high, repeat issuance is the strategy, and the investor base needs expansion. The infrastructure archetype handles multi-jurisdiction configuration and issuance cadence. A marketplace could supplement retail tranches but, as a primary venue, would fragment the cap table across three platforms. Custom development would tie the developer to a codebase needing reconfiguration for every new jurisdiction. Institutional issuers consolidate on one infrastructure layer and use marketplaces as an optional distribution channel rather than the primary venue — a pattern visible in ecosystem mapping of repeat issuers. The same logic applies to single-asset versus fund-level decisions.

The decision rule

Owns investor base and plans repeat issuance: infrastructure. Needs investor acquisition and accepts platform terms: marketplace. Has novel mechanics and capital to maintain the code: development shop. Issuers who select against this logic — marketplaces chosen by issuers with captive LP bases, custom builds chosen by single-deal issuers — produce the highest pilot-abandonment rates in the sector.

Selecting a tokenization partner is a procurement decision about business model fit. The feature comparison comes after the archetype question, not before. An issuer who answers "which archetype" correctly will find three or four vendors competing on configuration, pricing, and jurisdiction coverage — a tractable evaluation. An issuer who skips that question and goes straight to feature comparison will receive quotes spanning two orders of magnitude and have no framework to judge them.

The deals that close are the ones where issuer goals and vendor archetype were matched before the first demo. Fund managers and developers evaluating their options can review the jurisdiction configuration, compliance modules, and white-label deployment model at Tokenizer.Estate.