Alex Jordan Portfolio

Introduction

A lot of people asked me why I chose to build this site from scratch. When I set out to build this site, I could have gone the easy route — spun up a template on GoDaddy or Wix, clicked a few buttons, and called it a day. But that wasn't the point. I wanted something more than just a digital business card. I wanted a project that would not only showcase who I am, but also demonstrate that I can design, structure, and deploy a complete full-stack application from scratch.

I want this site to be a useful teaching tool for anyone who wants to understand how to create their own modern React-Next website, or how to create a Java-Spring Boot backend. I will try to explain the choices I made and how the pieces fit together, so someone just getting into this ecosystem can follow along and see how a real project comes together.

I think it's also important that I include this how-to page specifically. I wanted to explain that these concepts aren't out of reach. Anyone can understand the high-level ideas behind how a site like this works, and anyone can learn to code if they approach it step by step. Too often, people in software talk in jargon that makes technology feel inaccessible. I believe we can do better. Explaining complex systems in plain language isn't dumbing things down — it's proof that you really understand them.

Building it this way gave me full control over every detail — from the structure of the components in React, to the flow of data between the backend and the SQL database, to the color palette and layout that make the site feel approachable. That control means the final product is stronger, more maintainable, and more flexible than anything I could have thrown together with an out-of-the-box website builder.

Design Decisions

From the beginning, I wanted this site to feel approachable and modern without being overwhelming. The design choices reflect that balance.

Soft color palette: I leaned into softer tones rather than harsh contrasts. This makes the site easier to read, creates a calmer mood, and avoids the sterile "corporate" look.
Card-based layout: Each section is wrapped in a card, giving the content its own container. This makes information modular and scannable — visitors can easily jump between projects, jobs, or skills without being buried in text.
Tabs on the Resume page: Instead of cramming everything into a single scroll, I split the content into tabs (Education, Jobs, Projects, Startups). It keeps things clean, interactive, and more aligned with how people actually explore resumes.
Animations on scroll: Subtle transitions as sections appear keep the site feeling alive and polished without distracting from the content.
Component reusability: I designed with React components so the same building blocks (like cards, buttons, or titles) could be reused across pages. This keeps the look consistent and makes the codebase much easier to maintain.

In short, the design isn't just about looks — it's about readability, maintainability, and showing that I can think about user experience at the same time as technical structure.

Design illustration showing creative process with colors, cards, and user interface elements

Technologies Used

I didn't just pick these technologies at random. Each one was chosen because it solved a specific problem and, together, they create a full-stack system that's modern, scalable, and maintainable.

Frontend: React + Next.js (with TypeScript)

For the user-facing side, I went with React because it's fast, component-based, and the standard for modern web development. Next.js adds routing, server-side rendering, and a cleaner structure for pages. Using TypeScript keeps everything strongly typed, which helps catch bugs early and makes the codebase more reliable.

All of these tools fit together naturally: the React frontend makes API calls, the Spring Boot backend serves those requests, and the PostgreSQL database persists the data. AWS ties it all together in one cloud environment. The stack not only works well technically, but also demonstrates that I can work with the same technologies professional teams use every day.

File & Component Structure

A big part of building a site like this isn't just writing code that works — it's organizing it in a way that stays clean and maintainable as the project grows. I paid a lot of attention to how both the frontend and backend are structured so that the code makes sense, is easy to extend, and follows common industry patterns.

Frontend (React + Next.js)

app/ → Each page of the site lives here. For example, the Resume page has its own folder with a page.tsx file, which keeps routing simple and predictable.
components/ → Reusable building blocks like Cards, Sections, Navbar, and Footer. This keeps the look and feel consistent while avoiding duplicated code.
components/resume/ → Tabs and sections specific to the Resume page, so everything related to that feature stays in one place.
styles/ → SCSS files split into categories (components, pages, utilities). This makes the design modular and easy to update without breaking the whole site.

The end result is that I can add new features (like another tab or a new page) without rewriting existing components — I just compose the pieces I already built.

Backend (Spring Boot with MVC)

controllers/ → Handle incoming requests (the "receptionists" of the system).
services/ → Contain the business logic (the "managers" who decide what needs to happen).
core/entities/ → Define the database models (like the Skill entity).
core/repositories/ → Handle database access (the "filing cabinets" where data lives).
scripts/ → Utilities like PopulateSkills, which seeds the database with starter data.

This structure means each layer has a single responsibility. If I want to change how data is stored, I update the Repository. If I want to adjust logic, I edit the Service. If I want to expose a new endpoint, I add a Controller. Each piece is clear and isolated, which makes the whole system easier to work with.

How It All Connects

A good way to think about this site is like a restaurant. The frontend is the menu — it's what you see, click on, and interact with. The backend is the kitchen — it takes your requests and does the real work. The database is the pantry — where the raw ingredients (data) are stored. And AWS is the building itself — the infrastructure that makes sure the lights stay on and the doors stay open.

Menu (Frontend)

Kitchen (Backend)

Pantry (DB)

Building (AWS)

How It Works in Practice

1. Frontend Request

When you click on something in the site — for example, the Resume tabs — the React + Next.js frontend makes an API call.

2. Controller

That request goes to the Spring Boot backend, where a Controller receives it.

3. Service

The Controller passes the work to a Service, which contains the business logic.

4. Repository/Database

The Service talks to a Repository, which queries the PostgreSQL database on AWS RDS to fetch or save data.

5. Response

The data flows back through the Service and Controller to the frontend, where it's displayed inside a styled component.

This layered design isn't just for show. It makes the system easier to maintain and extend. If I need to change how the database works, I don't have to touch the frontend. If I want to redesign a page, I don't have to rewrite backend logic. Each part is responsible for a clear role, and they connect through well-defined boundaries.

Conclusion

I hope that this page has helped to show that I am capable of building robust and complex websites. From creating a high-level plan to architecting the system, and then executing on the technical details, my goal was to demonstrate that I can take an idea from concept to production.

This explanation is also meant to highlight that I can competently use technologies like React, TSX, Java, and AWS, while applying high-level object-oriented design principles. These are the same tools and approaches used by professional teams every day, and I would like employers to see that I could easily contribute to — or integrate with — any design or engineering team working with this stack.

At the same time, I wanted this site to serve a bigger purpose: to make the process of building software less intimidating. By breaking down the architecture into clear sections and metaphors, I've tried to show that these systems aren't magic boxes — they're just organized layers of logic, data, and design. Anyone can learn this with the right guidance, and as developers we should be doing a better job explaining how things work.

Finally, my aim is for this page to give a sense of the kind of architectural thinking necessary for a lead engineer. That means I could step into a role as a team lead, or independently create and maintain a website for a smaller company end-to-end. I would also like this site to act as a roadmap for anyone making their own project — helping beginners see not just the what, but the how to think like an engineer.