Explore
Need help with your project?
Oops! Something went wrong while submitting the form.
Kraster Wallet is a hardware crypto wallet that combines an NFC card with a mobile app. See how Purrweb implemented the NFC component, scaled support from 6 to 20 blockchain networks, and released the MVP for iOS and Android in five months.
Kraster Wallet is a cold hardware crypto wallet in the form of a card that is accessed via a mobile app. Rather than storing a seed phrase in notes or elsewhere, users receive an NFC card on which the wallet's recovery key is stored.
To access the wallet, users need the card plus an additional verification method, such as a PIN or biometrics. This makes working with cryptocurrency easier and safer. You don't have to remember anything, and your assets are protected by a physical device.
Initially, the wallet was intended for internal business tasks. However, the client later began considering Kraster Wallet as a standalone product for a broad audience, with support for multiple blockchain networks and room for scaling.
The Kraster Wallet app is already released and available on the App Store and Google Play.
We were solely responsible for developing and implementing the product from a technical standpoint. The Flatronica team handled the design. Purrweb was responsible for:
Although we didn't work directly on the design, we actively reviewed the mockups, checked the screen logic, collaborated with the design team to find the best solutions, and suggested alternatives based on our expertise.
Throughout the project, the client proposed new ideas, added functionality, and clarified constraints, resulting in changes to the requirements. Given these circumstances, we had to develop an architecture and processes that would preserve the core product concept and ensure its release.
The most important — and simultaneously the most difficult — part of the project was the NFC card. It’s the foundation of Kraster Wallet: the card stores the wallet access key. If it doesn't work, the whole product doesn't work. So this block became the team's top priority.
Why difficulties arose. At the start, the project had no ready-made solution for working with NFC cards. The client planned to use cards from a manufacturer, but in reality:
We couldn't wait for everything to fall into place, so we took a different approach. We started developing the app and architecture without waiting for the final version of the card.
How we looked for a solution. The team tried several approaches: we talked to card manufacturers, looked for contractors with NFC experience, and simultaneously tested our own hypotheses.
Ultimately, we brought in external specialists who had experience with similar solutions. Most of the work was done in an experimental manner: testing ideas, observing how the card behaved under real conditions, and making changes on the fly.
How we got the card to a working state. When it became clear that the standard pace wasn't working for us, our CTO took over the project. He developed the card's logic and, within a few days, assembled a solution that could be used in the product.
He handed the finished component over to the card distributor, who then passed it to the manufacturer. The manufacturer then wrote the component onto physical cards. It was a multi-step process, but it worked 🙂
As a result, the project had a working scenario: the card could be used to restore access and manage the wallet.
In the end, we:
Initially, the plan was for Kraster Wallet to launch with support for six blockchain networks and different cryptocurrencies. This scope was manageable for the beginning stages, and given the tight deadline, we opted for a straightforward approach. Each network was integrated separately, which enabled us to reach the market faster.
However, during development, the requirements changed. The client wanted the wallet to support 20 networks by the time of its release. This would make the product more competitive and appealing to users.
Integrating each new network requires separate tasks, such as integration, testing, and scenario validation. It became clear that the original approach, which was justified for quickly starting with six networks, did not scale. Had we continued on that path, development would have taken significantly longer, and the product would have become more difficult to develop and maintain over time. At some point, it became obvious that we needed to rebuild the entire approach.
| Rather than working with each network individually, we developed a shared logic based on primary blockchains, such as Ethereum and Bitcoin. In short, we created a universal layer that enabled us to connect similar networks more quickly without having to rewrite everything from scratch. |
Although this solution required more effort upfront, it provided a key advantage: the product could then be developed faster and more smoothly. Thanks to this approach, we:
As the project grew, we realized that technical expertise alone wasn't enough. We immediately shifted our focus to transparent and predictable processes. We divided the project into several independent streams:
This was convenient for the team both technically and organizationally. Everyone had clear areas of responsibility with minimal unnecessary overlap.
How we worked with changes. As work progressed, new requirements and project boundaries emerged. Instead of fighting this, we accepted change as part of the process.
To keep everything manageable, we:
In the end, the product grew beyond the minimum feature set, but didn't turn into a random collection of solutions.
Strengthening the team and fast onboarding. When the workload exceeded what the team could handle at the previous pace, we added more people so the project could continue moving at the required speed. To accomplish this, we defined tasks as clearly as possible and set up processes in advance. New developers immediately understood what they were responsible for and how their part fit into the overall product.
If someone couldn't keep up with the project's pace or requirements, decisions were made quickly to avoid slowing down the team and maintaining development quality.
In addition to development, the project required constant coordination. Several stakeholders and contractors were involved on the client's side, so we needed to help everyone align and move in the same direction.
Sometimes, the team received conflicting requests or urgent tasks that did not align with the agreed-upon plan. In such situations, we acted as the central point of coordination:
At the same time, we coordinated with external contractors, including those responsible for design and NFC cards. In several cases, Purrweb took over the coordination of adjacent processes to keep the project on pace.
Throughout the project, new inputs kept appearing. To prevent confusion, we did one simple yet important thing: we documented everything.
We shared agreements, changes, and decisions with both the team and the client. This allowed us to always return to the context and avoid misunderstandings. Even when an issue fell outside our direct responsibility, we stayed in touch and helped find a solution. This approach worked especially well during the public product presentation when responding quickly to questions was critical.
Ultimately, the project was completed and presented as a fully functioning product. By launch time, the Purrweb team had developed the following:
Although this was formally an MVP, the product turned out to be more robust. Many solutions were designed from the start with future development and scaling in mind.
The app was published on the App Store and Google Play, and the team prepared it for a public presentation at a crypto conference. For the team, this was an important moment. A project that began with many uncertainties had become a tangible product available to users.
Current status. By the time we finished our work, the product was in beta. The client's team had implemented the core features and created a roadmap for future development.
We have expertise in complex development. On this project, we worked with technologies rarely seen in typical mobile apps, such as NFC cards, blockchain networks, non-standard architecture, and high-cost errors. Over the years, we have gained experience working on more than 550 projects, ranging from mobile services and marketplaces to Web3, IoT, and internal systems. We know how to tackle complex challenges and find working solutions where no ready-made templates exist.
On the Kraster Wallet project, for example, we helped keep the product on track by syncing stakeholders, documenting agreements, coordinating adjacent processes, and taking responsibility for results. We integrate into our clients' processes, work at the same pace as the product team, and maintain simple, transparent communication without unnecessary bureaucracy.
At the beginning of the Kraster Wallet project, there was no perfect brief or ready-made solutions, only an idea and an understanding of the desired outcome. We helped define requirements, designed the architecture, built the minimum viable product (MVP), and took the product to release. If you have an idea or a complex challenge, we'll help you turn it into a working digital product, step by step.
.svg)
