How We Rebuilt a Web3 Launcher in Six Weeks After a Project Takeover

A metaverse platform company approached us in March 2023 with an urgent problem. They had committed to a high-profile virtual event with a major partner in six weeks. The event would showcase their technology to thousands of users. But their existing development team was struggling to deliver a working desktop launcher.

The client needed someone who could step in quickly and deliver under pressure. They had already invested months with another vendor. That codebase wasn’t working. Time was running out. The event date was fixed and non-negotiable.

We had six weeks to build a cross-platform desktop launcher from scratch. The launcher needed to:

• Authenticate users through a cryptocurrency wallet
• Download and launch a game engine
• Let users customize their nickname and avatar
• Work reliably across Windows and Mac

Technologies

• Electron (Chromium + Node.js) for the cross‑platform desktop application
• React with React Boilerplate for the renderer UI
• Web3 wallet browser extension integration for authentication
• Download manager and archive extraction for large game builds
• Child‑process game launcher with microphone/camera permission handling
• Code signing: Apple Developer ID (macOS) and Windows Authenticode with a hardware key
• Kubernetes hosting for the metaverse engine, managed via Infrastructure as Code (IaC) and deployed in a multi‑region setup

Challenges

The Clock Was Ticking

Six weeks. That’s not much time to build production software from scratch. We decided to work in one-week sprints instead of our standard two-week approach. The faster cadence would keep us nimble. But the deadline wasn’t flexible. The client had contractual obligations to their partner. The event was scheduled. Tickets were sold. Backing out wasn’t an option.

The pressure was real. This wasn’t just about delivering software. It was about the client’s reputation in a competitive market. Failure would damage their credibility with partners and their community.

This was early 2023. AI coding assistants had just launched but weren’t yet useful for developing production-level code. We could not rely on AI to speed up development. They were just a nice appendix. This made the six-week timeline even more challenging.

The Existing Launcher Was Unsalvageable

We got access to the previous vendor’s launcher code repository. What we found wasn’t encouraging:

• Significant technical debt throughout the codebase
• Many features partially implemented but not working
• Mock-ups and prototypes mixed with production code
• Hard to tell what actually functioned

The launcher had serious problems.

The previous launcher was also built for a different use case. The client’s main product was a persistent virtual world. But this event needed something different. An instanced experience for a specific occasion. The existing launcher architecture didn’t fit.

We faced a critical decision. Should we try to fix the old launcher? Or build a new one from scratch? Fixing existing code is usually faster than rebuilding. But that assumes the foundation is solid. This one wasn’t.

There was another problem. Taking over the existing launcher would require support and transparency from the previous vendor. The client warned us upfront that this vendor was very hard to communicate with. We couldn’t afford to bury the project under lack of transparency and communication. Not with six weeks on the clock.

We decided to rebuild the launcher from scratch. It was riskier upfront but gave us more control. We could make architectural decisions that fit the timeline. We could avoid inheriting problems we didn’t understand.

Complex Technical Requirements

The technical requirements were demanding. We needed to build a desktop application with several complex features:

• Authenticate users through a cryptocurrency wallet extension
• Download game builds from remote servers
• Extract compressed files efficiently
• Spawn the game engine as a child process
• Handle microphone and camera permissions for in-game communication
• Sign the application digitally so operating systems would trust it

We had experience with web applications. But desktop development with Electron was new territory. Electron apps bundle a Chromium browser engine with Node.js. They let you build desktop software with web technologies. But they come with their own quirks and challenges.

Browser extensions work differently in Electron than in Chrome. The wallet extension needed special handling. We had to manage the extension lifecycle manually. Chrome normally handles this automatically. We had to figure it out ourselves.

Code signing added another layer of complexity. Operating systems need to trust desktop applications before users can run them. MacOS was straightforward. We already had an Apple Developer account. Windows was harder. We couldn’t automate the signing process in six weeks. We had to use a physical signing key plugged into a laptop in our office. Team members connected remotely to sign builds manually. Not elegant, but it worked.

Game engines running as child processes create their own complications. Passing permissions for microphones and cameras between the launcher and the game engine required careful configuration. Getting this wrong would break core functionality.

Communication and Coordination

The client had their own technical team. They had a tech lead and product managers who understood the domain. We needed to coordinate closely with them. We also needed to work with their 3D artists and game developers.

Clear communication was essential. We had to align on requirements quickly. We had to surface technical risks early. We had to show progress regularly so everyone knew where we stood.

Building trust was critical. The client had just been burned by another vendor. They needed confidence that we could deliver. We needed to prove ourselves fast.

Solutions

Strategic Decision: Build From Scratch

We made the call to rebuild the launcher rather than rescue the existing one. This decision shaped everything that followed.

Building a new launcher from scratch gave us clarity. We could define a clean architecture. We could choose technologies we understood. We could avoid the technical debt that had trapped the previous team.

We selected Electron as our framework. It was proven technology. Discord, Slack, and VS Code all use Electron. We knew it could handle our requirements. We chose React Boilerplate as our starting point. It gave us a solid foundation and let us avoid inheriting the architectural problems from the previous vendor’s codebase.

The risk was time. Starting over meant building everything. But we believed we could move faster with a clean slate than fighting existing problems. We were right.

Ruthless Prioritization

With six weeks to deliver, every decision mattered. We couldn’t build everything. We had to identify what was critical and what could wait.

We mapped out the core user journey:

1. Download the launcher
2. Authenticate with the wallet
3. Download the game build
4. Launch the game
5. Join the event

Everything else was secondary.

Some features got cut entirely. Others got simplified. For example, the game build came as a large compressed file. Extracting it took time. We could have optimized the extraction process. But that wasn’t critical. As long as it worked, speed was a nice-to-have.

We hardcoded the wallet extension version into the repository. Normally, you’d want to download the latest version dynamically. But building that system would take time we didn’t have. Bundling the extension directly was good enough for launch.

The launcher had performance issues we didn’t fix. All UI components refreshed during downloads and file extraction. Not optimal, but not a blocker. We also skipped automated tests entirely. Testing manually was faster in the short term, even if it would cost us later.

We focused on making things work, not making them perfect. Technical debt was acceptable if it didn’t block the event. We could refactor later if needed.

This approach required discipline. It’s tempting to over-engineer. To build for future scenarios. To add features that might be useful. We resisted that temptation. We shipped what was necessary.

Technical Implementation

We built the launcher in layers. Each layer solved a specific problem.

Electron applications have two main architectural layers. The renderer process handles the visual interface. The main process communicates with the operating system. Understanding this separation was critical. UI logic stayed in the renderer. System operations like spawning the game engine and managing permissions belonged in the main process.

The authentication layer integrated the cryptocurrency wallet extension. We embedded the extension in the Electron app and created a custom flow for wallet-based login. This gave users a familiar authentication experience while meeting the partner’s requirements.

The download layer handled fetching game builds from the client’s servers. We implemented progress tracking and error handling. Users could see the download status and retry if something failed.

The extraction layer unpacked the compressed game files. This was one of the slower operations. We added clear status messages so users knew the app was working, not frozen.

The launcher layer spawned the game engine as a child process. This was technically complex. We had to configure permissions correctly so microphones and cameras worked in-game. We had to handle process lifecycle management. Start the game cleanly. Shut it down properly. Handle crashes gracefully. We didn’t prevent users from launching multiple game instances. Platforms like Steam block this, but building that protection wasn’t worth the time.

We tested each layer as we built it. We didn’t wait until the end to integrate everything. Continuous integration helped us catch problems early.

Strong Client Collaboration

The client’s team was excellent to work with. They understood the pressure we were all under. They didn’t add unnecessary stress. They trusted us to make technical decisions.

Their tech lead and product managers were engaged but not micromanaging. They helped us understand requirements. They gave us access to the resources we needed. They reviewed our progress regularly.

We established clear communication channels. Regular sync meetings kept everyone aligned. We documented decisions and shared them widely. We surfaced risks immediately rather than hoping they’d resolve themselves.

When we hit technical challenges, we discussed trade-offs openly. Should we spend time optimizing this feature? Or move on to the next priority? These conversations helped us stay focused on what mattered.

The client also monitored progress closely. They learned from their experience with the previous vendor. They wanted visibility into what was happening. We showed them working increments regularly. This built confidence that we were on track.

This collaborative approach made the tight timeline manageable. We weren’t fighting the client. We were working together toward a shared goal.

Team Coordination

Our team moved fast because we stayed aligned. We had a dedicated product manager who coordinated with the client. Our developers focused on building. We didn’t waste time on miscommunication or rework.

We identified dependencies early. What did we need from the client’s team?

• API access for authentication
• Design assets for the launcher UI
• Game build URLs and hosting infrastructure

We requested these upfront so they wouldn’t block us later.

We worked in one-week sprints. Two-week cycles would have been too slow for this timeline. The shorter iterations kept us nimble. We could adjust priorities quickly as we learned more.

Everyone on the team understood the constraints. Six weeks. Non-negotiable deadline. Critical business event. This clarity helped us make decisions quickly. When in doubt, we chose the option that reduced risk.

Conclusion

We delivered the launcher on time. The client’s event went ahead as planned. Thousands of users downloaded the launcher, authenticated with their wallets, and joined the virtual experience. It worked.

But the story didn’t end there. The launcher we built in six weeks became the foundation for the client’s main product. When they needed to rebuild their main launcher, they used our code as the starting point. Despite being built under time pressure for a different use case, our launcher architecture was cleaner and more maintainable than the old one from the previous vendor.

The partnership lasted over two years. We continued working with the client on their platform. We built trust by delivering under pressure. That trust opened the door to a long-term relationship.