My first web applications (IT Asset Management, B2B Procurement, Offline PWA) - Looking for feedback!

[JimmyAlter]

🏷️ Discussion Type

Product Feedback

Body

Hi everyone!

I am an IT Support Specialist transitioning into Full Stack Development, and I've recently finished and deployed my first web applications. My primary goal was to build practical, real-world tools for IT operations and systems administration, with a focus on security-first architecture.

I have deployed all frontends on Vercel and the backends on Render, and I've open-sourced all codebases on GitHub. I would love to share them with the community and get your feedback and advice on how to improve them!

Here is what I've built:

1. 📊 AssetDesk — IT Asset Management & Service Desk

A lightweight workspace to track corporate hardware inventory, handle support tickets, and manage user directories.

Live Demo (Vercel): https://assetdesk-demo.vercel.app/
GitHub Repository: https://github.com/JimmyAlter/AssetDesk
Architecture & Security: Built with React 19, Vite 8, Node.js, and SQLite. It features a hybrid design: if no live API URL is configured, it falls back to a browser-based database mock using LocalStorage so users can interact with it instantly. The backend is hardened with Helmet security headers, request body size limits, and login rate-limiting.

🛒 2. CommerceSuite — B2B Procurement Portal

An administrative portal for purchasing corporate IT hardware, licenses, and tracking orders.

Live Demo (Vercel): https://commercesuite-demo.vercel.app/
GitHub Repository: https://github.com/JimmyAlter/CommerceSuite
Architecture & Security: Uses React and Express. Supports role-based access (buyer vs admin workflows) and order status tracking. Just like AssetDesk, it runs in client-side LocalStorage simulator mode by default but connects to a live persistent backend on Render when configured.

🔐 3. Helper — Secure Offline RSA Token Generator (PWA)

A Progressive Web App designed for field technicians to cryptographically sign repair tokens in remote zones without internet signal.

Live App (Vercel): https://helper-ten-pi.vercel.app/
GitHub Repository: https://github.com/JimmyAlter/helper
Architecture & Security: 100% offline-ready static PWA using Service Workers and browser-native Web Crypto API. To keep keys safe, the private key is stored locally in localStorage and never sent over the network. It features local rate-limiting lockout (60s block after 5 failed password attempts) and secure DOM rendering to prevent XSS.

💬 What I'd Love Feedback On:

Since these are my first complete applications, I would appreciate any opinions or advice on:

Code Structure & React Best Practices: Is my component structure logical? (I recently modularized the CommerceSuite frontend from a single file).
Security Implementations: Are there other client-side or backend security concerns (SQL injection, XSS, authentication flows) that I should address?
Database & Deployment: How do you handle SQLite database persistence on free-tier providers? (Currently, I'm using Render's ephemeral storage, which resets to clean seed data on dyno restart—which I find convenient for public demo safety).
UI/UX: Any design changes or additional features that would make these tools more useful for IT support teams?

GitHub Profile: https://github.com/JimmyAlter
Portfolio: https://thiagolangone.vercel.app/

Thank you so much in advance for your time and feedback!

Guidelines

• I have read and understood this category's guidelines before making this post.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Lopesnextgen]

Hey Thiago,

This is a strong first portfolio direction

What stands out to me is that these are not random tutorial apps. They all come from a real IT operations angle: asset tracking, procurement, service desk workflows, field technician tooling, offline access, and basic security controls.

That domain focus is a big advantage.

Security feedback

The biggest thing I would revisit is the Helper PWA private-key storage.

Storing a private key in localStorage is convenient, but I would not describe it as “keeping keys safe.” If any XSS bug, compromised dependency, malicious browser extension, or injected script runs on that origin, it can read localStorage.

For a cryptographic/offline tool, I’d consider:

• using Web Crypto non-extractable CryptoKey objects where possible
• storing keys in IndexedDB instead of raw localStorage strings
• encrypting exported keys with a passphrase-derived key
• adding a clear “demo/security limitations” section in the README
• treating local lockout as a UX feature, not a real security boundary

The 60-second lockout is useful, but since it is client-side, a user or attacker with local control can usually reset storage or modify the app state. That does not make the feature useless, but it should not be presented as strong brute-force protection.

For AssetDesk and CommerceSuite, I’d also check:

• JWT storage strategy
• token expiration and refresh flow
• server-side RBAC enforcement, not only frontend route hiding
• parameterized SQLite queries
• password hashing details
• CORS locked to exact frontend origins
• request validation with a schema library
• audit logging for admin actions
• rate limiting on login and sensitive write endpoints
• CSP headers on the frontend, not only Helmet on the backend

Architecture feedback

The LocalStorage simulator mode is actually a good idea for demos. It removes friction and lets people try the app instantly.

I would just make the boundary very obvious:

• “Demo mode: data is local to this browser”
• “Backend mode: data persists through the API”
• maybe show a small environment/status badge in the UI

That prevents reviewers from misunderstanding which layer they are testing.

For code structure, the next step I’d look for is separation by domain rather than by file type only. For example:

• tickets
• assets
• users
• auth
• orders
• catalog
• admin

Each domain can own its components, API calls, validation, and types. That scales better than one large shared components/services folder.

Database/deployment

SQLite is fine for demos and small internal tools, but Render ephemeral storage means it should be treated as disposable.

For a public demo, that is actually a nice safety property. For anything production-like, I’d move to one of these:

• PostgreSQL on Render
• Supabase
• Neon
• Railway
• Turso / LibSQL
• Cloudflare D1, if the app shape fits

Also, adding migrations would make the projects feel more production-ready. Even a simple migration setup shows that you are thinking beyond seed data.

UI/UX ideas

For IT support tools, the most useful next features would probably be:

• audit history per asset/ticket/order
• CSV import/export
• ticket SLA indicators
• assignment history
• asset lifecycle states
• search and filters that survive reloads
• role-based UI states
• activity timeline
• bulk actions
• empty/loading/error states
• mobile technician view

For AssetDesk specifically, asset history would be valuable: who had the laptop, when it changed status, when it was repaired, when it was retired.

For CommerceSuite, approval workflows would make it feel more like a real B2B procurement system:

• requester creates order
• manager approves
• admin fulfills
• inventory updates
• order audit trail is preserved

README improvements

The repos already explain the idea, but I would add:

• screenshots or GIFs near the top
• architecture diagram
• security model section
• known limitations
• demo credentials
• environment variable table
• API route summary
• “production hardening checklist”
• testing instructions
• database schema overview

That would make the projects much easier for hiring managers or reviewers to evaluate quickly.

Overall

For first complete applications, this is a solid direction. The strongest part is that the projects solve realistic IT problems instead of just showing CRUD for its own sake.

My main advice would be: keep the practical IT focus, but be very precise with security claims. “Security-first” is a good goal, but things like localStorage key storage, client-side lockout, and demo JWT flows need clear threat-model notes so people understand what is production-grade and what is demo-friendly.

Useful references:

• OWASP HTML5 Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html
• OWASP JWT Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html
• MDN Web Crypto API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API
• OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html