Modernizing a Historic NFT Project for Modern dApp and AI-Native Workflows

Su Squares helped lay the foundation for mainstream NFT adoption, ushering in the multi-billion dollar NFT ecosystem, but its legacy web presence no longer felt competitive with modern dApp standards or emerging AI-native ways of building and exploring software. Rito built a modernized fork on top of the existing infrastructure to make the project more usable, more legible, and more extensible without discarding its historical foundation. That effort earned him co-maintainership on the upstream project, where he landed a scoped set of improvements before exiting on his own terms.
Quick Highlights
Rito made an ambitious effort to modernize a historically important NFT project, expand it into a stronger platform for learning and experimentation, introduce AI-native developer workflows, and navigate the upstream relationship through to a clean exit.
- Reframed Su Squares as a more credible modern dApp without replacing its legacy base.
- Expanded the project into a stronger platform for learning, experimentation, and extension.
- Introduced an AI agent-guided developer workflow alongside improvements to wallet UX, metadata, branding, and maintainability.
- Earned co-maintainership status and trust, then landed a scoped set of upstream improvements.
- Set boundaries clearly and exited on principled terms when the collaboration model stopped working.
Why This Project Mattered
Su Squares was a pioneering project in the multi-billion dollar NFT ecosystem: an early example and use case of ERC-721, the first mainstream NFT standard that formalized and defined the term as we know it. But eight years is an eon in dApp development, and its design choices had become so dated that the project was no longer positioned competitively. The challenge was not to erase that legacy, but to make it legible and competitive again in a world shaped by modern dApps, mobile-first expectations, and AI-native workflows.
That made the modernization effort more interesting than a routine front-end refresh. It was an opportunity to show how a historically important project could evolve into a stronger platform for onboarding, experimentation, exploration, and future contribution without discarding the infrastructure and identity that made it notable in the first place.
Problems, Vision and Rationale
A Product Growth Problem
Su Squares had a serious product growth problem. After roughly eight years, around two-thirds of the token supply remained unsold, and the project's fixed primary-sale pricing no longer felt credible relative to the market. As Rito later argued more explicitly, the pricing model had become an insurmountable constraint on growth unless the sale system itself was rethought.
A Dated dApp Surface
At the same time, the dApp's product surface was dated and underwhelming compared with modern standards. The issue was not just visual age. From both a UX quality-of-life standpoint and an architectural standpoint, the site no longer looked competitively positioned against contemporary dApps. If the goal was to get people's attention back onto the project and expand adoption, the product surface needed to become dramatically more usable and materially broader in its use cases.
A Pedagogical and Architectural Opportunity
There was also a pedagogical opportunity. Will clearly liked teaching developers, and Su Squares had the historical character to function partly as a kind of museum piece. But while the project's hourly blockchain-driven site update was a genuinely clever and distinctive element, much of the surrounding stack reflected older frameworks and practices that were no longer ideal as a learning surface for modern developers.
Rito's vision was to use the modernization effort to turn the repo into an ecosystem-as-a-playground architecture: a monorepo that preserved the legacy Jekyll deployment model while adding the kinds of tools a modern dApp project should teach from, including typed Node workspaces, smart-contract tooling, local blockchain infrastructure, testing suites, UI staging, bundling, and AI-native guided workflows for touring, setting up, and building on the system.
Taken together, that vision was meant to do more than refresh the site. Expanding the product surface while turning the project into a stronger pedagogical platform could help restore attention, improve usability, and create new paths for adoption.
What Rito Built in the Fork
Rito spent a full month creating an expansive fork that tried to reframe Su Squares as a more credible modern dApp and as a serious developer playground; the full fork can be experienced at su.ritovision.com. Rather than rely on one flashy improvement, he expanded the product surface, redesigned core flows, and introduced a modern architecture around the legacy Jekyll deployment model without breaking GitHub Pages deployment.
A More Credible dApp Surface
The fork expanded Su Squares far beyond its original narrow site surface. It introduced a fully mobile-responsive dApp, installable PWA support, centralized navigation, richer square lookup and chooser flows, and a clearer personalization experience with CSV and image batch tooling. The point was not novelty for its own sake. It was to make the project feel dramatically more usable, more legible, and more credible as a living product.


The Billboard Was Rebuilt as Core Product Infrastructure
The billboard was the most project-specific part of Su Squares, and one of the fork's most important changes was treating it like core product infrastructure rather than a single page widget. Rito broke it into a shared core with reusable view and event layers, then extended it so the same system could support browsing, selection, embedding, and personalization instead of just rendering the homepage grid.
That architectural shift also changed how the billboard felt to use. It became more touch-friendly on mobile, more legible as an interactive surface, and far safer when dealing with user-curated links. It also became meaningfully more accessible: the grid was rebuilt with ARIA semantics, per-cell labeling, and focus management so interaction did not depend on pointer-only behavior. Instead of throwing users straight into destinations, the rebuilt flow could show a readable disclaimer-style leaving modal, block unsafe targets outright, and preserve those same protections even inside embeds. Just as importantly, it turned the signature interface of the project into something other pages and other sites could actually build on.
- The billboard was rebuilt as a reusable core instead of a homepage-only script, with wrappers for homepage navigation, embeds, personalization flows, and chooser modals.
- Accessibility and mobile interaction were both treated as core requirements: the grid gained ARIA grid and gridcell semantics, per-square labels, focus management, and touch-friendly pan-zoom behavior instead of remaining a brittle visual-only surface.
- Outbound interaction stopped being abrupt. A leaving-modal style disclaimer showed the full destination before navigation, while a blocked-modal intercepted disallowed targets instead of failing silently.
- Security was layered into the interaction model itself: domain blocklists, square blocklists, text silencing, locked override policies, dangerous URI-scheme rejection, and tooltip sanitization all helped keep user-curated links from becoming a blind-trust surface.
- The same system became portable as a shareable iframe with the same contained homepage-style interaction model, plus URL-driven configuration and a dedicated embed-builder page for controlling theme, header, blocklists, and behavior.
- Square overrides and wrapper hooks made it possible to reuse the billboard for genuinely different purposes without cloning the implementation every time.
A Rebuilt Personalization System
One of the fork's biggest UX overhauls was the personalization stack. In the original flow, users had to bounce between separate pages for single and batch personalization of Squares, or leave the site entirely for depersonalizing the old legacy contract. Rito collapsed those three legacy destinations into a much more coherent in-app system centered on personalize-modern.html, while moving unpersonalization into a modal that reused the dApp's shared web3 runtime, branding system, and transaction controller.
The result was not just consolidation. The rebuilt flow preserved the original mint-to-personalize handoff, kept the legacy pages available as historical alternatives, and dramatically expanded what users could do once they landed there. It turned one of Su Squares' most important product surfaces into something that finally felt deliberate instead of stitched together.


- Single and batch personalization were consolidated into one clearer page instead of being split between personalize.html and personalize-batch.html.
- The new flow introduced a row-based table for personalizable entries, with billboard-based square picking and removal.
- Owned-square fetching, draft preview mode, glow overlays, and locator feedback made the billboard feel like an active editing surface instead of a passive reference.
- CSV tools and image batch tooling turned the page into something materially more powerful than the legacy forms.
- The broader contract and runtime work left room for both the original main-contract path and the cheaper underlay path, while moving depersonalization in-app as the older-contract-specific flow.
Wallet, Account, and Transaction UX
One of the clearest ways the fork stopped feeling like a static artifact and started feeling like a modern dApp was through first-party wallet UX. Instead of relying on a generic, awkwardly branded modal, Rito introduced branded connect, account, and transaction flows that were globally available, mobile aware, and aligned to Su Squares' product logic. That included multi-wallet support, better WalletConnect handling, clearer balance and network context, and transaction states that made the dApp experience feel intentional rather than bolted on.


Ecosystem-as-a-Playground Architecture
The technical expansion was not a sidecar. It was central to the fork's thesis. PR #52 proposed turning the repo into something modern developers could meaningfully learn from while still honoring its static Jekyll deployment constraints. That meant wrapping the legacy site in a stronger architecture rather than replacing it outright.
- A monorepo that preserved the legacy Jekyll root while adding six modern Node workspaces.
- A Hardhat-based smart-contract workspace for the primary and underlay contracts in coordination, migrated from the older setup with continuity-preserving tweaks that made customization and deployment easier.
- A local Besu dev chain with Blockscout so the full dApp could run end-to-end away from mainnet.
- A builder layer that produced vendored bundles for the static site, stabilizing Wagmi and QR dependencies and removing the brittle React-CDN Web3Modal approach the site had been leaning on.
- A runtime-generated site config layer so chain, RPC, and explorer settings could be injected into the static site without depending on GitHub Pages-incompatible env/plugin behavior.
- JSDoc annotations in the Jekyll-root JavaScript so the live site gained stronger type safety without forcing TypeScript into the legacy runtime.
- Storybook for staging and reviewing dApp components in isolation.
- Vitest and Playwright coverage for core logic, security-sensitive behavior, and end-to-end product flows.
AI-Native Developer Workflow
The purpose of the AI-guided workflow was to make a complex ecosystem-as-a-playground system accessible to developers. Su Squares was no longer just a website repo. It had become a broad, interconnected environment where legacy Jekyll pages, modern frontend workspaces, smart-contract tooling, local chain infrastructure, testing suites, UI staging, vendored web3 dependencies, and runtime-configured deployment constraints all served different but related purposes. That kind of architecture was valuable precisely because it exposed developers to multiple parts of a complete dApp stack, but it also created a real accessibility tradeoff: a smart-contract- oriented contributor might not know frontend tooling like Storybook, while a frontend-oriented contributor might have little familiarity with local chain infrastructure or contract workflows. Rito introduced explicit Tour and Builder workflows, backed by AGENTS.md guidance, to give developers a sensible path through that complexity instead of forcing them to piece the system together from scratch.
- Tour mode gave newcomers a single coherent entry point across the whole stack, guiding them through a staged local setup and walkthrough of the full system.
- Builder mode added guardrails and preflight expectations so contributors could start making edits and validating assumptions without needing full-stack fluency upfront.
- README, AGENTS.md, and supporting mode files turned the repo itself into an onboarding surface, making the architecture approachable from whichever corner a developer arrived from.
Trust, Scope, and Working Relationship
Rito did not keep the fork private. He pushed the entire rewrite upstream as PR #52 so Will could evaluate the whole vision and expanded scope in public: the dApp modernization, the architectural expansion, and the pedagogical tooling vision all at once. That turned the fork from a side experiment into a concrete directional pitch for what Su Squares could become.
The fork was intentionally presented as a large model showcase rather than as a realistic one-shot merge candidate. Will treated it that way too: not as something to land wholesale, but as a broad demonstration of directions worth triaging into smaller upstreamable pieces. That made PR #52 less a merge request than a public proving ground for the quality and seriousness of the work.
- PR #52 impressed Will enough that he offered Rito co-maintainership over email, changing the relationship from outside contribution to direct stewardship of the project.
- The co-maintainership offer did not come with explicit scope or responsibilities. It rested on the premise that Rito could materially improve Su Squares beyond isolated outside contributions.
- That change in relationship later showed up in practice when Rito began opening scoped work directly from in-repo su-squares:tenthousandsu.com branches instead of only from his fork.
Pushing the fork as PR #52 changed the relationship. It made the ambition of the work undeniable and helped convince Will that Rito should be trusted not just to contribute ideas from the outside, but to help maintain and improve Su Squares directly.
Upstream Merges for the Official Su Squares Site
Once the fork had established the quality and seriousness of the work, the collaboration shifted from showcasing a full alternative vision to landing a narrower sequence of upstream improvements. Rito did not transplant the fork wholesale. He split out the parts Will was willing to accept and shipped them directly into the official codebase, improving the live project in visible ways without requiring the entire architectural rework to merge at once.
- Mobile responsiveness (#61) was the clearest user-facing win. Rito made the entire site mobile responsive, improved header behavior, adapted the billboard and tooltip experience for smaller screens, and brought the overall layout much closer to modern dApp expectations.
- Previewability and metadata (#64) made the site more legible off-platform as well as on-platform. Rito centralized canonical, Open Graph, and Twitter metadata, cleaned up page URLs, and improved how Su Squares presented itself when links were shared.
- Branding and asset clarity (#58, #67, plus issue #65) improved the project's visual legibility across the site and GitHub surfaces. The old branding put the full Su Squares wordmark in gold on a light background, which became unreadable at small sizes. Rito replaced it with a new SU logomark on the project's trademark gradient background, alongside cleaner asset organization and branding guidance that pushed the project toward marks that actually held up in favicon and GitHub contexts.
- Developer setup and maintainability (#57, #70) reduced friction for future work on the official repo. Rito added site config for faster and more discoverable local builds, including optional exclusion of heavier legacy directories that reduced build time from minutes into seconds, and later refactored duplicated footer code into shared includes.


Rito went from creating an impressive fork to materially improving the official project. The project later publicly thanked Rito for responsive mobile improvements, link preview support, improved logo artwork, easier developer setup, and future-facing ideas, and the post was also reposted by Will's personal account.
Boundaries and Exit
Misalignment Becomes Clear
Rito discovered fairly early that Will was not interested in expanding the official site toward the broader product vision Rito believed would be necessary to grow Su Squares' audience. That became especially clear around PR #59 and PR #60. When the proposed CSS refactor for scalable growth was rejected, and the reusable menu/modal navigation system was turned away in favor of fixing navigation directly onto the homepage while leaving articles buried at the bottom of the About page, it became clear that Rito and Will had sharply different product sensibilities and visions for the project.
That mattered because the co-maintainership offer had not come with explicit scope or responsibilities. What had been clear was that Will saw Rito as capable, skilled, well-intentioned, and positioned to improve the project. What was not clear at the outset was how much room there actually was for Rito to enact the level of product and architectural expansion he believed the project needed. Over time, that ambiguity resolved into a genuine misalignment.
Scope, Boundaries, and Exit
Rito responded by making the misalignment explicit rather than letting it linger. In issue #62, he announced that he would not be retaining his co-maintainership role, outlined the narrower scope of work he was still willing to complete, and set up a clean path toward exiting the project. That decision did not come from a loss of interest in the project itself. It came from recognizing that the collaboration no longer offered a realistic path for the kind of stewardship and product direction he had expected to be able to exercise.
Will did outline which parts of Rito's proposed scope he was willing to accept, and Rito followed through on most of them. Mobile responsiveness, metadata and previewability, branding improvements, developer setup, and maintainability work all landed or substantially progressed. But as more of that upstream work moved forward, Rito also noticed a recurring pattern in the collaboration model itself. In his final note on issue #62, he got specific: substantive rationale was often not being engaged in kind, review scope drifted away from the PR or issue under discussion, structural questions were not being answered directly before discussion moved into smaller implementation details, and claims were sometimes made without being checked against the evidence first.
That was the point where Rito stopped treating the remaining work as something he should simply push through. He had already completed most of the scope he had agreed to, plus a few extra improvements, and the site was leaving the collaboration in a meaningfully better state than he found it. But he was volunteering his time and compute, not being paid, and the collaboration had stopped feeling sustainable or like a good use of his bandwidth. So rather than keep forcing more work through a model he no longer believed in, he closed out the remaining PRs and ended his involvement.
Parting Guidance
What makes the ending notable is that it was not dismissed or reframed as drama. Will followed up on issue #62 by thanking Rito for all his help, saying he had made good progress, agreeing with his points, and saying that his notes would live on. That response matters because it confirms that Rito's criticism was not only boundary-setting, but substantively received. The collaboration ended because the working model was misaligned, not because the contributions lacked value.
Rito also left behind concrete strategic guidance in issue #72, where he laid out a material strategy for overcoming the project's pricing-path problem, arguing that the fixed primary-sale flow had become a major barrier to growth and proposing a repriced intermediary sale system that could work around the legacy contract constraints. That mattered because it showed that even on the way out, he was still leaving behind concrete product strategy rather than only criticism of process.
Conclusion
Su Squares is one of the clearest public records of how Rito approaches ambitious work. He spent a month of unpaid time building a full modernization fork on a pioneering NFT project, pitched it publicly through PR #52, earned co-maintainership off the strength of it, and landed a scoped set of upstream improvements the project publicly thanked him for.
What makes the project notable beyond the craft is how it ended. Most case studies stop at shipped work. This one closes with Rito naming a collaboration pattern that had stopped working in issue #62, closing out remaining PRs rather than forcing more work through a model he no longer believed in, and leaving behind concrete product strategy in issue #72 on the way out. Will's reply, which thanked Rito, agreed with the points, and said the notes would live on, confirmed that the criticism was substantively received rather than dismissed as drama.
Taken together, the project puts four things on the public record: willingness to invest serious unpaid effort behind a vision, the technical range to execute across contracts, frontend, infrastructure, and tooling, the judgment to name misalignment before it curdled into resentment, and the care to leave strategy behind even on the way out.








