Is AI-Focused Full-Stack Development a Good Career Path for a CS Student?

The project has solid engineering foundations: React with route-based loading, a real error boundary, a structured design system, and a reasonably compact production build. It looks like a legitimate project rather than a generated scaffold.

The main weaknesses are polish and public presentation. Check the product name everywhere—your public title appears to contain a spelling mistake while the internal code uses a different name. Remove or defer nonessential third-party scripts that block rendering, especially translation-related ones. Add Open Graph metadata, a social preview image, a canonical URL, and a useful description so shared links look professional. Also check image alternative text and loading states for accessibility.

A successful deployment is not proof that the correct files and configuration were shipped. Inspect the production artifact, verify the assets and environment variables being used, and test the deployed version on a clean browser and device. These checks catch problems that coding assistants and successful build commands often miss.

You can share the project now as a work in progress, but describe what you built and what you learned instead of presenting it as a finished commercial product. A portfolio project does not need to be perfect; it should show your decisions, architecture, trade-offs, and ability to improve it based on feedback.

For your career, focus less on chasing the newest label such as agents or agentic systems and more on solving complete problems reliably. Learn how to design APIs, store and retrieve data safely, evaluate AI outputs, handle failures, control costs, and monitor production systems. Those skills will remain valuable even as the popular tools change.

The direction makes sense, especially if you’re interested in building useful products rather than doing research into machine learning itself. Just be careful not to let n8n and coding assistants replace your understanding of programming. Build a few smaller projects without AI assistance so you can practice debugging, data structures, authentication, APIs, and backend design when something goes wrong.

Docker and basic cloud infrastructure would be useful additions. Vercel and Supabase are perfectly reasonable for small and medium projects, but understanding containers, deployments, logging, and at least one major cloud platform will give you more flexibility when working with different clients. I’d also add testing, Git workflows, monitoring, rate limiting, and secure secret management to your learning plan.

For the application itself, a public demo mode or screenshots would help. Most people viewing a portfolio project will not want to create an account before seeing what it does. You should absolutely showcase it once you clean up the presentation—the project demonstrates more than a basic frontend clone.

The most important Supabase check is Row Level Security. Go through every table and confirm that RLS is enabled and that the policies only allow users to read or modify the rows they are actually permitted to access. The browser’s public Supabase key is expected to be visible, so hiding that key is not the real protection; the database policies are.

Also review your Google OAuth flow carefully. Validate authentication on the server wherever necessary, never trust user IDs or roles supplied by the client, keep service-role credentials out of frontend code, and add rate limiting to your Flask endpoints. Test the application as two different users and try requesting each other’s records directly rather than relying only on the interface to hide them.