
Current Project Status
The project is currently on track and we have resolved most of the technical issues identified at the start of the project, as per our project plan. We have achieved this by dividing the tasks into smaller, separate development projects to address the challenges on a smaller scale.
Below, you can see a short description of some of these backend and mostly Internet Computer specific tasks:
task Task | description Description | show_chart Status |
---|---|---|
task Data migration | description Integration of existing data from a MySql database into a canister. | show_chart 100% |
task Backup | description Sync data offline into noSQL database. | show_chart 50% |
task Full-text search | description Two options are being considered, but no decision has been made yet. | show_chart 90% |
task E-Mail notification | description It is essentially carried out by a bridge to a Web2 server. | show_chart 100% |
task Onboarding II user | description The implementation was successful with minor issues in authenticated calls when the Internet Identity is not valid due to time constraints. | show_chart 95% |
task Multi tenant approach | description The current approach being explored is to have one logic backend canister and a separate data canister for each client. However, this solution may result in performance issues and requires further investigation. | show_chart 0% |
task Performance | description The primary distinction between Web2 and Web3 lies in data management. Due to the Internet Computer latency, frontend and backend data handling needs to be continuously adapted and optimized. | |
task Backend data migration strategy | description Zhenya Usenko’s approach is currently implemented and functional. However, upcoming Motoko changes related to orthogonal persistence and self-writing internet apps may render this approach unnecessary. Further developments are pending. | show_chart 100% |
The modularization of code logic has been implemented, but there is still room for improvement.
Ensure that exported DID file names are well-formed. This improves clarity and understanding.
In addition to the Motoko Base Library we use the map and vector packages from the Mops.one package manager for simplicity and familiarity.
However, we could utilize instead the new OrderedMap stable key-value ma, which is also available within the Motoko base library.
The frontend is also moving forward. We see performance benefits with Angular 19, and we take also advantage of new features like signals and the resource API to further enhance speed. Given the latency issues, frontend optimization is a priority.
To enhance performance, we are also looking into enabling a Progressive Web App (PWA) mode. With PWA we can combine the best features of web and mobile apps. It works in a browser but offers native app-like experiences, including:
- Offline support (via service workers)
- Fast performance (cached assets & minimal loading)
- Installability (can be added to home screens like native apps)
- Push notifications (for engagement)
- Responsive design (works on any device)
The UI framework we are using is Material Design. A sneak preview is shown in the image below. The final look and feel will be improved, of course 😅.

The application, frontend and backend, is currently running on the Internet Computer under its canister Id. In this way we can test it under more realistic conditions in the upcoming weeks.
What is running: User management, project management, and basic task management functionality are currently functional.
You are in Charge
Why not utilizing an existing issue tracking system from major tech companies instead of developing this on the Internet Computer?
Eliminating Centralized Cloud Providers with the Internet Computer Protocol (ICP)
The Internet Computer completely removes the need for AWS, Google Cloud, Microsoft Azure or any centralized cloud provider by running backend logic, frontend hosting and data storage entirely on-chain.
The current project aims to show whether this is feasible for business applications and, if so, how and under what conditions it can be implemented.
The Internet Computer’s most compelling feature is its ability to return control to users and eliminate the cloud provider layer. The fact that no one can stop a canister or lock a user out of his canisters ensures that the user truly owns his data. More than AI or self-writing apps, this is what sets the Internet Computer apart. At least for me.
The previously mentioned features are remarkable and are based on this fundamental concepts as well.
Despite some challenges and slower performance compared to the Web2 world, this new stack offers a significant advantage: It eliminates the need for firewalls, security setups, databases, and other rigid components that are typically required in the Web2 environment.
This approach eliminates the need for constant security checks on the production environment, leading to enhanced security, cost savings, and increased trust.
How Web3 on ICP Replaces Cloud Providers
The Internet Computer removes third-party cloud dependencies by running applications directly on a decentralized blockchain network.
Here you can see how each Web2 cloud component is replaced:
public Web2 Cloud Service | brick Web3 - ICP - Alternative |
---|---|
public AWS, GCP, Azure (backend & compute) | brick Canister smart contracts (compute & logic) |
public AWS S3, Firebase Hosting (static assets) | brick On-chain frontend hosting (directly in asset canisters) |
public PostgreSQL, MongoDB (database) | brick Stable memory in canisters (On-chain storage) |
public OAuth, Firebase Auth | brick Internet Identity (decentralized authentication) |
public Cloudflare, AWS Load Balancers | brick ICP codes & canister scaling (no middleware needed) |
Instead of running on big tech data centers, ICP applications run on decentralized node machines operated by independent data centers worldwide in different subnets.
What are the Benefits of Replacing Web2 Cloud with the Internet Computer
Some of the advantages are summarized below:
- No Amazon, Google or Microsoft controlling your backend.
- Your app cannot be censored or shut down due to centralized policies.
- No need to rent virtual machines, containers or cloud servers.
- Compute and storage run directly on-chain via smart contract-powered canisters.
- Instead of paying monthly bills for cloud usage, ICP developers prepay cycles, which are stable in cost.
- Eliminates surprise bills caused by traffic spikes.
- No need for load balancers, CDNs, or API gateways.
- Canisters automatically scale based on demand without additional services.
- User data is not stored on centralized cloud databases controlled by corporations.
- Decentralized identity (Internet Identity) ensures private logins without passwords.
I appreciate your continued interest and I look forward to sharing updates on this exciting project as it progresses.