Project Process
How I build projects after Fullstack Academy.
Fullstack Academy gave me a foundation. The next step has been learning how to turn that foundation into projects that solve clear problems, use real data, and keep improving after the first working version.
From exercises to applications
After Fullstack Academy, I started thinking differently about projects. Completing an exercise proves that I can follow a requirement. Building an application asks more of me: define the user workflow, choose the data model, handle edge cases, organize the repository, and document what the project does.
I still use the fundamentals I learned in the program, but I try to connect them to practical project decisions. A route should exist because the application needs it. A component should make the interface easier to understand. A database table should support the workflow instead of becoming an afterthought.
How I plan before I build
I usually start with the problem, not the stack. For Cutz By Casper, the problem was a booking workflow with scheduling, deposits, messaging, and admin needs. For Jukebox Pro, the focus was a protected playlist API with authentication and relational data. For Book Buddy, the workflow was browsing, account actions, reservations, and returns. For Sturgis Options, the problem was organizing rental choices with filters, voting, and comments.
Planning this way helps me avoid building disconnected features. I want each part of a project to answer a simple question: what does the user need to do next, and what does the system need to remember?
Building, testing, and documenting
My project work combines front-end structure with backend behavior. I have worked with JavaScript, TypeScript, React, Next.js, Node.js, Express, PostgreSQL, Supabase, REST APIs, authentication, and deployment workflows. The exact stack depends on the project, but the process stays consistent: build the core path, test the behavior that matters, and document the result so the project is easier to understand later.
Field operations also influences how I build. In water treatment, documentation and repeatable steps matter because real systems need dependable handling. I bring that same mindset into software by writing clearer project notes, checking assumptions, and improving the parts of an application that create confusion.
Projects I am continuing to improve
Cutz By Casper remains my strongest full-stack project because it connects a polished interface to scheduling, payments, messaging, and admin workflow. Jukebox Pro shows backend authentication and protected API routes. Book Buddy shows React and API-driven account workflows. Sturgis Options shows how a small tool can organize choices for a specific planning problem.
I am also developing the Isaac Wright Jr. Advocacy Website with his knowledge and approval. That project is marked In Development and focuses on presenting advocacy work, public initiatives, and related resources clearly and accessibly using HTML, CSS, and JavaScript.
What I am focused on next
My next focus is improving the quality of each project instead of simply adding more repositories. That means cleaner documentation, stronger screenshots, better testing where it fits, clearer deployment notes, and more direct explanations of why each project exists.
I am interested in junior software, full-stack, front-end, web, and technical operations opportunities where I can keep learning, contribute to real projects, and combine software thinking with the reliability habits I have built in field operations.
Related links
View my project portfolio · Read the Cutz By Casper case study · Open my developer resume · View GitHub · Back to the blog