Built, But Not Commercialized

A surviving homepage sketch puts the ambition plainly: “Real Estate Investing. Simplified.” Beneath it is a button labeled “Start Investing.” That was the experience we were trying to build toward: a way to connect a real property and its operating structure to a digital investor experience.

The tokenized real estate crowdfunding idea brought those two sides together. There would be a property, people responsible for it, and investors participating through a product. Representing ownership digitally still left the practical questions of how an investment would work and how someone would understand it.

One historical outline reduces the operating idea to a single line: “1 Property – 1 LLC – 1 Bank Account – 1 Property Manager – X Investors.” It is one of the clearest records of what we were organizing around. The property was the center of an operating unit, with an entity, an account, a manager, and a group of investors.

The token sat within that arrangement; it could not stand in for the property, management, banking, or responsibilities to investors. This was an operating-design outline, not a definitive final legal structure.

The requirements covered investor identity and KYC/AML checks, money moving into and out of the system, communications, documents, voting and surveys, and property and investment information. Digital ownership still required ordinary financial and operating infrastructure.

I hired and managed a third-party development team that built the React platform. When I later shut down the project’s AWS infrastructure, I did not preserve a source or deployment backup that I can locate today. The surviving product designs, requirements, branding, and planning material establish design intent and parts of the operating model. My account of the completed platform is firsthand recollection; those artifacts do not verify which planned integrations were operational.

The December 2022 process diagram shows an investor buying fractional shares of a partnership, the partnership purchasing a property, rent producing net cash flow, and a partnership bank account distributing that cash flow to investors.

The diagram retains its historical partnership terminology; the separate operating outline uses an LLC. It records an intended flow, not money that moved through the platform.

The surviving Financial Information screen separates “Input” from “Calculated” in red handwriting. Rent, property taxes, and management appear alongside revisions to return measures and token supply, including “Monthly Rent,” “IRR,” and “Token Supply.”

A field someone enters and a result the system produces have different responsibilities. The annotations show the work of deciding what those numbers meant and where they belonged. Blank fields, crossed-out labels, and overlapping revisions preserve a working design, not an actual property’s returns or a definitive calculation model.

While RealROI was being developed, I personally invested through Arrived and Lofty.ai, partly to understand the experience from the investor side. I wanted to use products in the category, alongside thinking about the one we were building.

That was a research method as much as a personal investment decision. Reading about a product from the outside is different from encountering it as a customer. Participating gave me a way to experience the investor journey directly, rather than considering it only as something our team needed to design.

Those were my personal investments. They were not RealROI partnerships or company investments. I remember the purpose of that participation; I would not turn it into a list of specific product lessons or design changes without the supporting detail. Its place in this history is the approach: trying to understand the category by becoming a customer in it.

My recollection is that the development team brought the React platform to a state we regarded as functionally complete for the product we had designed. The next decision was whether we were willing to use it for commercial investment transactions.

As the work approached that threshold, we became uncomfortable with the securities-law uncertainty surrounding tokenized assets. We perceived meaningful regulatory risk and decided we were not willing to assume it in commercial transactions. The platform was not commercialized and was not used to conduct those transactions.

Technical capability did not settle the question of whether we were comfortable operating the business. That was our assessment of risk and our decision about proceeding, not a regulatory order or a legal determination about RealROI. We reached the first threshold and chose not to cross the second.

“Built / Not Commercialized” is the most accurate way I can summarize the outcome. It preserves both parts of the history: the work the team completed and the operating decision we made afterward.