Projects

Just the Next started from a simple observation: most task apps are overwhelming. They give you lists, sub-lists, tags, priorities, due dates, recurring schedules — and you end up spending more time organizing than doing. I wanted something that showed me one thing: the next item.

The philosophy is zen by design. You add items, and the app shows you only the next one. Complete it, and the next appears. No list anxiety, no decision fatigue. Just the next thing.

Technologies

• Python with FastAPI for the backend REST API
• SQLAlchemy ORM with AsyncPG for async database access
• PostgreSQL for persistence
• Alembic for database migrations
• FastAPI-Users for authentication
• Vanilla JavaScript, HTML, and CSS on the frontend — no frameworks
• Docker and Docker Compose for containerized deployment

Implementation Details

The backend is a FastAPI application with a clean separation between models, schemas, and routers. I chose FastAPI for its async-first design and automatic OpenAPI documentation, which made iterating on the API fast. The database layer uses SQLAlchemy with AsyncPG, giving full async support for PostgreSQL queries without blocking the event loop.

Authentication is handled by FastAPI-Users, which provides registration, login, and session management out of the box. This let me focus on the core app logic rather than rebuilding auth from scratch.

The frontend is intentionally simple — vanilla JavaScript with no build step, no bundler, no framework. The UI is a single-page app with separate views for the landing page, login, and the main list interface. Everything loads fast and stays lean.

The whole stack runs in Docker containers via Docker Compose, making local development and deployment consistent. The current roadmap includes a settings redesign with collapsible tabs and admin modal enhancements.

Easy Cash Flow was born from a real problem: I needed to track where my money was going across multiple Brazilian bank accounts, and no existing tool handled the variety of statement formats I dealt with. So I built one.

The app parses PDF bank statements from Bradesco, BTG, and Inter, extracts transactions, categorizes them using machine learning, and presents a clear picture of cash flow over time.

Technologies

• Python with FastAPI for the backend
• SQLAlchemy ORM with SQLite for local persistence
• PDFPlumber for parsing PDF bank statements
• Scikit-learn for ML-based transaction categorization
• OpenPyXL for Excel export functionality
• Resend for email notifications
• Alembic for database migrations
• Vanilla JavaScript frontend

Challenges & Solutions

Parsing Brazilian Bank Statements

Each bank has its own PDF format with different layouts, date formats, and transaction structures. I built dedicated parsers for Bradesco, BTG (personal and business), and Inter. Each parser uses PDFPlumber to extract tabular data from the PDFs, then normalizes everything into a common transaction format. The parsers had to handle edge cases like multi-line descriptions, split transactions, and varying date formats across statement periods.

Transaction Categorization

Manually categorizing hundreds of transactions each month was exactly the problem I wanted to avoid. I trained a Scikit-learn classifier on my historical data to automatically categorize new transactions. The model learns from my corrections over time, getting more accurate as it processes more data. Categories like groceries, transportation, and subscriptions are predicted on import, and I only need to review and correct the edge cases.

Data Export

Since this is a personal finance tool, having the data in spreadsheet format was important. The app can export categorized transactions to Excel via OpenPyXL, making it easy to do further analysis or share summaries.

Job Hunt Assistant is a webapp built to help with the process of looking for a job. It provides fast input sources and views that greatly improve the picture of the full job hunting process — from tracking leads to understanding where you stand.

The app has a dashboard view with relevant metrics, a kanban board for quickly assessing and updating the status of job leads, and a list view for more thorough analysis. It also automatically grabs employer ratings and shows office locations on a map to help choose the right opportunity.

Technologies

• Ruby 2.6 with Ruby on Rails 6.0
• PostgreSQL
• HTML, CSS, JavaScript, Sass
• Bootstrap 4 and FontAwesome 5
• Selectize.js for enhanced dropdowns
• Nokogiri for web scraping
• Google Maps Embed API

Implementation Details

To add listings, the app uses Selectize.js and Rails Ajax forms to allow quick and seamless creation of Company and Technology records without requiring the user to navigate away. The dropdown shows existing options or lets you create a new one on the fly, which is great for usability when you're rapidly adding job leads.

The kanban view uses Rails' UJS capabilities to process Ajax requests and return jQuery snippets to update the UI seamlessly. Dragging a card between columns triggers a background status update without a page reload.

For company ratings, I used the Nokogiri gem to perform a simple web search and scrape the first rating result. The scraping is intentionally naive — it assumes the first rating found is most accurate, but the app allows the user to override it with their own assessment.

The company detail view uses Google Maps Embed API to display the office location, making it easy to check commute times. The map is expandable and interactive.

The dashboard gathers important information into a compact view: application counts by status, response rates, and activity timelines. The project was developed with Test-Driven Development from day one, achieving 99%+ code coverage.

A full-featured marketplace application where buyers and sellers can list products, communicate securely, and process payments. This was the project that taught me how real web applications work end-to-end — from user authentication to payment integration to deployment on a Linux server.

Technologies

• Ruby on Rails with a JSON REST API
• PostgreSQL
• HTML, CSS, JavaScript, jQuery, Sass
• AWS S3 for file storage
• Redis and Sidekiq for background jobs
• Capistrano for automated deployment

Project Requirements

The marketplace needed to function as a centralized platform where sellers could list items with images and descriptions, and buyers could browse, search, and purchase. Secure communication between buyers and sellers was essential, as was integration with an external payment processor via XML and JSON APIs.

Implementation Details

Image uploads are handled via Ajax, with background processing through Sidekiq and Redis to resize and optimize images before storing them on AWS S3. This keeps the upload experience fast for users while ensuring images are properly processed.

The app integrates with an external payment processor, handling both XML and JSON API formats for different transaction types. The admin backend provides full visibility into listings, transactions, and user activity.

The application includes a complete administrative backend for managing the marketplace. Deployment is automated with Capistrano to both staging and production Linux servers, with provisioned environments for consistent deployments.

Code quality was maintained through Test-Driven Development and code reviews of pull requests from third-party developers who contributed to the project.

A complete, playable game built with vanilla JavaScript and HTML5 Canvas. No libraries, no frameworks, no game engines — just raw JS and the satisfaction of making pixels move on screen. The game was developed as a class assignment with strict constraints that made it a genuinely interesting challenge.

Technologies

• Vanilla JavaScript (ES6+)
• HTML5 Canvas API

Challenges & Solutions

Imposed Limitations

The assignment required the game to be built without any external libraries or frameworks. Everything had to be written from scratch: the game loop, sprite rendering, collision detection, score tracking, and input handling. This forced me to deeply understand how Canvas works at a low level.

I took a modular approach, breaking the game into distinct components: a game engine core, entity management, rendering pipeline, and input handler. This made the codebase manageable despite having no framework to lean on. Development was incremental — first a static scene, then movement, then collision, then scoring.

Canvas Performance

One unexpected challenge was rendering custom fonts on Canvas. The initial implementation caused significant frame drops because Canvas was recalculating font metrics on every frame. The fix was to pre-render text to an off-screen canvas and then draw the cached bitmap, which brought frame rates back to smooth 60fps gameplay.