Tokenization earns its cost in three situations: you need fractional ownership at a scale a spreadsheet cannot manage, you need transfer restrictions enforced automatically across parties who do not share a system of record, or you have a realistic path to secondary transfer through a venue that actually exists.
If none of those apply, a token wrapper adds regulatory surface, a key management obligation and an operating cost to something a cap table and a fund administrator already handle competently. A fund with a dozen limited partners and annual distributions does not have a tokenization problem.
The version of this worth saying plainly: if there is no venue where holders can trade, tokenizing an illiquid asset produces illiquidity with extra steps. Liquidity comes from buyers and a place to meet them, not from a token standard. Decide whether that place exists before you compare platforms.
The build versus buy decision is really six decisions
Most teams take a single vote on what is actually a stack of independent choices. Separate them and the answer usually stops being contentious:
Identity verification, KYC and AML screening
Custody of assets and institutional key management
The token contract and its compliance logic
Issuance and investor onboarding workflow
Secondary transfer and any venue relationship
Reporting and integration with your existing systems
Nothing requires the same answer across all six. A sensible architecture usually buys the first two, argues seriously about the third, and builds the fourth and sixth.
Buy the layers that are regulated and commoditized
Identity verification, sanctions and AML screening, custody, fiat payment rails and node infrastructure share three properties: they are heavily regulated, they are undifferentiated between issuers, and they carry a maintenance burden that never ends. Building any of them consumes engineering capacity on work no investor will ever notice, and in the case of custody it usually means taking on obligations you are not authorized to hold.
Almost nobody should build custody. Very few should build KYC. Treat both as procurement decisions and spend the scrutiny on vendor security posture, data residency and incident history instead.
Build the layers where generic assumptions cost you daily
Origination and deal structuring workflow, distribution and waterfall logic, investor reporting, and integration into fund administration, accounting or ERP systems are where vendor platforms impose their model on your business. The gap between a vendor's assumptions and your actual process does not disappear. It gets filled with manual operations, and manual operations are where errors and reconciliation breaks live.
This is also where a build to own arrangement matters. If you commission this work, the repositories, deployment scripts, keys and intellectual property should be yours at the end. A platform you cannot operate, audit or modify without the original vendor is a dependency, whatever the contract calls it.
The token layer is the argument worth having
This is the genuinely contested decision. A plain ERC-20 cannot check eligibility at transfer time, cannot restrict holders by jurisdiction, and cannot support a forced transfer when a court orders one or a holder loses access to their wallet. Standards such as ERC-3643 and ERC-1400 exist to handle exactly this, using an identity registry and compliance checks enforced at the moment of transfer.
Buying gives you an implementation that has been audited and run in production. Building gives you a contract that fits your structure precisely and an audit cycle you own for as long as the system exists.
Two things to verify either way. First, a compliant standard does not produce a compliant deployment; configuration, the identity layer and the legal wrapper decide that. Second, if a vendor offers ERC-3643 support, ask whether it is the reference implementation or a modified fork, and ask for the independent audit reports covering the exact version you will run. "Based on" is not the same as audited.
If you build, budget independent review after every change to deployed logic, not once before launch. Contracts get modified. Audit reports do not update themselves.
Software cannot buy you a licence
Several functions in a real-world asset offering are regulated activities, and writing code for them does not authorize you to perform them. Depending on jurisdiction and structure, that can include broker-dealer or investment firm activity, operating a secondary trading venue, transfer agent functions, qualified custody and money transmission for fiat.
This changes what "buy" means. Some vendors sell software. Others hold permissions and act as service providers. Those are different purchases with different failure modes. Map every regulated function in your intended flow, name who performs it and under what authorization, and do it before scoping software. Gaps in that map make the platform decision premature.
Keys and upgrade authority decide who really controls the asset
Both paths need the same answers:
Who holds the keys that control upgrades, minting, pausing, and forced transfers
What constrains them: a multisig, a timelock, a documented governance process, or nothing
Separation of duties between whoever deploys and whoever controls funds
Rotation and offboarding, including when staff leave or a vendor relationship ends
Recovery procedures that have been tested rather than written down
If you buy, put these in the contract. A vendor holding unilateral upgrade authority over the contract that records your investors' positions is a concentration of risk that belongs in your risk register no matter how good the software is.
Compare three-year totals, not quotes
The common costing error is setting a development capital number against an annual subscription. Build both columns across three years, including internal cost on each side.
For a build: infrastructure, indexing, monitoring, custody tooling, independent review after each change, compliance operations, investor support, and engineering retention. For a buy: setup and per issuance fees, anything charged against assets under management, minimum commitments, your integration work, and the operational cost of the gaps. Neither column is small, and which one wins usually turns on issuance volume over the period rather than either headline price.
Ask the exit questions before signing
If we leave, what happens to deployed contracts and existing holder positions? Is source code escrow available for the version actually in production? Can investor and KYC records be exported in a usable format? Has the vendor performed a migration before?
For a build, ask the same thing inward: could another team take this over from documentation and tests alone? If the answer depends on one engineer or one vendor relationship, you have rebuilt the lock-in you were trying to avoid.
RWaltz is a blockchain and enterprise software development company building custom smart contracts, dApps and tokenization platforms that integrate with existing business systems. We work to a build to own model: clients hold their keys, repositories and intellectual property, engagements are scoped honestly including the cases where buying or not tokenizing is the better answer, and security review is treated as continuous rather than a single sign off.
📖 Read the full blog: https://www.rwaltz.com/blogs/rwa-tokenization-platform-build-vs-buy
Connect with RWaltz:
LinkedIn: https://www.linkedin.com/company/rwaltzsoftware
X (Twitter): https://twitter.com/rwaltzsoftware
Facebook: https://www.facebook.com/RWaltz-Software-PvtLtd-255590135349493
Telegram: https://t.me/RWaltzCrypto
GitHub: https://github.com/rwaltzsoftware
Clutch: https://clutch.co/profile/rwaltz-software
Website: https://www.rwaltz.com
Top comments (1)
Your insights on the nuanced build vs. buy decisions for tokenization are spot on, especially regarding the need to separate each layer's requirements. I completely agree that the complexities of custody and KYC should often steer teams towards procurement rather than in-house development, allowing more focus on unique business workflows. For those custom layers you mentioned, ensuring you retain ownership over the code and architecture is critical to avoid vendor lock-in. If you're considering scaling or optimizing specific components of this platform, I’d be interested in discussing a paid collaboration to lend a hand with that implementation. What challenges have you encountered in balancing compliance with innovative architecture?