Hi, I'm Daniel.
I build full-stack & connected systems.

Case study

Bullion Tracker

Vanilla JS (ES modules) · Firebase · Chart.js · Netlify

Overview

A web app for tracking a gold and silver bullion portfolio in AUD. It pulls live spot prices, works out cost basis and unrealised profit/loss, and keeps your holdings synced across every device you sign in on. Built with plain JavaScript ES modules: no framework and no build step.

My role

I designed and built the whole thing end to end on my own: the front-end, the data and auth layer, the live price integration and the deployment pipeline.

What I built

• Live spot prices from a metals API, converted USD→AUD with a live FX rate and auto-refreshed every 5 minutes
• Google sign-in with real-time cross-device sync via Firebase Auth + Firestore, falling back to local storage when signed out or offline
• Cost-basis and break-even maths with blended average $/oz and profit/loss per metal
• Charts for allocation, cost vs current value, and portfolio value over time (Chart.js)
• CSV import/export, inline editing, and oz/gram weight entry stored canonically in troy ounces
• Continuous deployment to Netlify with CI on GitHub Actions

Outcome

Shipped a live, production app I use myself, and got hands-on with authentication, real-time databases, third-party API integration and CI/CD, all without reaching for a framework.

License & disclaimer

Open source under the MIT License, free for anyone to use, modify and build on, with attribution. Provided "as is", with no warranty; used at your own risk and cost. It's a personal tracking tool, not financial advice.

Case study

Job Tracker

React 18 + TypeScript · Supabase (Postgres) · Scheduled AI agent · Node · Netlify

Overview

A job application tracker in two halves: a React web app backed by Postgres, and a scheduled AI agent that reads my inbox and the job boards every evening, works out what has changed and writes it to a seed file, which a second scheduled job then pushes into the database. It currently holds 106 roles across five pipeline stages. I built it because the spreadsheet I was using could tell me what I had applied for, but not what I needed to do today.

My role

Solo project, built end to end: the agent brief, the sync bridge, the database and auth layer, the interface and the deployment.

How the pieces fit

• The agent. A scheduled task fires each evening into a fresh session with no memory of the last one, so all of its context comes from a standing brief in the repo. It classifies replies from the usual applicant tracking systems into pipeline moves, searches Seek, Indeed and GradConnection through a real browser because plain fetches get a 403, and reads every ad before recording it. Its output is an updated seed file rather than a live write, and a push notification tells me what changed.
• The sync bridge. The agent runs in a sandbox whose network policy blocks Supabase, so rather than working around that I split the pipeline at the boundary. The agent produces the seed file; a nightly Node script pushes it the last hop, logging to a file, because a scheduled job that fails silently is worse than no job at all.
• The app. React 18 and TypeScript in strict mode, built with Vite, styled with Tailwind and deployed on Netlify. It reads from Supabase Postgres and subscribes to realtime changes, so an edit on my phone shows up on my laptop, and it falls back to local storage when no database is configured, which keeps it working offline. The Today view works out the action queue in the browser, and writes are optimistic, so the interface updates straight away and reconciles with the server afterwards. Every push runs the CI pipeline on GitHub Actions: typecheck, then the unit tests, then a production build. If any of the three fails, nothing deploys.

Outcome

I use it every day, and the pipeline keeps itself current instead of me maintaining it by hand. The more useful outcome was what building it forced me to learn: row level security, realtime sync, a storage layer that degrades cleanly to offline, and where the sensible boundary sits between what a scheduled agent should decide and what I should.

Case study

BugBox AI Tutor Bot

React · OpenAI API · Firebase · Team project

Overview

BugBox is a chat-based tutoring bot that helps students learn through lesson-aware conversations. It answers questions in the context of a specific lesson, accepts file uploads for richer help, and keeps a history of past chats.

My role

I led the front-end and UI/UX as part of an Agile team, and contributed to planning and documentation. Accessibility was a priority, so I worked to meet WCAG standards.

What I built

• Chat interface that sends prompts to the OpenAI API and returns tutoring responses
• File upload system so students can share work for feedback
• Lesson-specific responses so answers stay on topic
• Persistent chat history stored in Firebase
• Accessible, clean UI following WCAG guidelines

Outcome

Delivered a working tutoring tool in a team setting and strengthened my React, API integration and accessibility skills.

Case study

Smart Home Lighting (IoT)

Arduino Nano 33 IoT · MQTT · Node-RED · AWS

Overview

A scalable smart lighting system where several lighting nodes are controlled in real time from a central dashboard. It supports automatic and manual modes and senses ambient light to adjust brightness.

My role

I designed and built the full system end to end: the embedded firmware, the messaging layer and the dashboard.

What I built

• Arduino Nano 33 IoT nodes that publish and subscribe over MQTT (PubSubClient)
• Node-RED dashboard for brightness and colour control
• Automatic mode driven by an ambient light sensor, with a manual override
• AWS EC2 hosting the MQTT broker so more nodes can be added
• Event-driven architecture for fast, real-time response

Outcome

Learned event-driven design, real-time messaging and how to connect embedded devices to the cloud.

Case study

Robot Simulator API

ASP.NET Core · C# · REST

Overview

A REST API that drives a simulated robot, exposing endpoints for maps and robot commands with authentication and authorization built in.

My role

I designed and implemented the API using a clean N-tier architecture, then tested every endpoint in Postman.

What I built

• REST endpoints for maps and robot movement commands
• Authentication and authorization to protect the routes
• N-tier design that separates controllers, services and data
• A full Postman collection to test the endpoints

Outcome

Deepened my understanding of API design, layered architecture and securing endpoints in C#.

Case study

Farmyard Racing

Unity · C# · Team Agile project

Overview

A farm-themed racing game built by a team using Agile. Players race around a track with a lap system and power-ups.

My role

I helped coordinate the Agile process and contributed to gameplay development.

What I built

• Lap system that tracks each player's progress around the track
• Power-ups that change the flow of the race
• Core racing mechanics and supporting UI
• Continuous integration set up on GitHub

Outcome

Practised Agile teamwork, version control and game development in Unity.

Case study

Automatic Dog Feeder

Arduino · Load Cell · Servo · Raspberry Pi

Overview

An automatic feeder that dispenses food until a target weight is reached, with a simple Raspberry Pi interface and feed telemetry.

My role

I built the hardware control and the interface that sets targets and monitors each feed.

What I built

• Load cell that weighs the food in real time
• Servo-driven dispenser that stops at the target weight
• Raspberry Pi GUI to set targets and watch progress
• Telemetry to record each feed

Outcome

Combined sensors, actuators and a GUI into one reliable embedded system.

Case study

Parallel Programming Study

C++ · std::thread · OpenMP · MPI

Overview

A study comparing three ways to parallelise compute-heavy work in C++, measuring how each approach scales as the workload grows.

My role

I implemented the same workload three different ways and benchmarked them against each other.

What I built

• Multithreaded version using std::thread
• Shared-memory version using OpenMP
• Distributed version using MPI
• Benchmarks comparing speed and scaling across the three

Outcome

Learned the trade-offs between threading models and how to measure real performance gains.