PROJECTS

Software Engineer

.NET & C#

Two projects on this track. Vela Commerce works through the parts of e-commerce that are actually hard: money that must not lose a cent, stock two shoppers are racing for, and a checkout that gets submitted twice. Stockroom is the classic line-of-business stack — SQL Server, ASP.NET Core MVC, jQuery and Power BI. In both, the rules are enforced by the database, not only by C#.

Integration Java .NET Python AI/ML Data React Angular
Back to Projects

Vela Commerce Live

A working ship-chandlery storefront, built to show how I use .NET 10 end to end — domain model, EF Core, Blazor WebAssembly, and a real PostgreSQL database behind it. It is a demo rather than a shop: nothing is charged, and no card is ever asked for.

  • The shop works while the backend is asleep. Browsing, search, filtering and sorting all run in your browser, so the catalogue is instant. Only the cart and checkout talk to the server.
  • The hard cases are settled by the database, not by C#. Fifty shoppers racing for the last five units, a double-clicked checkout, a payment notification that arrives twice — each one handled where it can actually be made safe.
  • Money is whole numbers, never a float. Prices, totals and refunds are integer minor units with a currency attached, and overflow throws rather than silently wrapping.
  • Tested properly. 415 tests, including real PostgreSQL running in containers, all of it on every push — plus a Demo Lab in the shop itself where you can fire those failure cases and watch what happens.
.NET 10 C# 14 Blazor WebAssembly EF Core 10 PostgreSQL 18 xUnit Testcontainers ArchUnitNET GitHub Actions CodeQL

Live since 6 September 2026

Give the first click about 35 seconds. The demo shuts itself down when nobody is using it, so the first visitor has to wait for it to wake up — measured at 32 seconds typically, 37 at worst. After that everything is instant. Browsing is immediate either way; the wait only applies to the cart and checkout.

It is the real thing running, not a mock-up — a real database, real background workers, and a payment simulator standing in for a card processor. Sleeping when idle is deliberate: it is what keeps the demo online for years instead of months.

Open the live shop Repository

  • How it is put together: a domain layer that depends on nothing, EF Core 10 over PostgreSQL 18 for storage, a minimal API host, and a Blazor WebAssembly front end. Tests enforce those boundaries rather than a convention that people forget.
  • The catalogue: 288 products generated at build time into a single file the browser fetches once, then searches and sorts in memory. The shop and its data can never disagree, because they are the same file.
  • Payments: an in-repo simulator rather than a real processor, so anyone can clone the project and complete a purchase with no account and no network. It signs its notifications properly, which gives the receiving code something genuine to verify.
  • Testing and CI: 415 tests on every push — unit tests, architecture rules read from the compiled code, and integration tests against a real PostgreSQL in a container. Coverage and mutation scores are enforced as floors that fail the build, not badges.

The whole catalog is one static file the browser fetches once — search, sort and category filtering then run in memory, with no API call behind them.

Product page

Product pages render from the same snapshot: per-variant price and SKU, a quantity stepper, and a spec sheet under the fold.

Recorded run

Recorded against the shop actually running: catalog, search, a product page, add to cart, the cart drawer, checkout with an address, then order VELA-PPTNK4G moving Placed → Paid → Packed → Shipped and the page stopping its polling at the terminal state. Real PostgreSQL, real background workers. It plays only when pressed, so the megabyte is not spent on anyone who did not ask for it.

Stockroom Live

A small internal inventory app on the stack a lot of line-of-business software runs on: SQL Server, ASP.NET Core MVC, jQuery and Power BI. Stock across three warehouses: add products, transfer and adjust stock, receive purchase orders — with a Power BI report on top.

  • The rules live in SQL Server. Stock can’t go negative, every ledger entry updates the balances through a trigger, and a transfer or a purchase-order receipt happens completely or not at all — whatever calls the database.
  • The web app can’t go around them. Its database user can read, and can run the app’s four stored procedures, and nothing else. A direct INSERT, UPDATE or DELETE is refused with permission denied.
  • Errors people can act on. When SQL Server refuses a transfer, the page says why — “Insufficient stock at WH-EAST: have 60, need 9999” — under the Quantity field, where jQuery validation shows its own messages.
  • A Power BI report kept as code. A star-schema reporting layer with its own read-only user, 25 DAX measures, and the model and report stored as text in git. Every total was checked against SQL.
.NET 10 C# ASP.NET Core MVC jQuery SQL Server T-SQL Dapper Power BI DAX Azure GitHub Actions

Live since 26 September 2026

Give the first page up to a minute. The database pauses when nobody is using it and takes up to a minute to resume. After that, pages load in under a second. The demo is shared, so transfer some stock or receive an order and watch the numbers change.

Open the live app Repository Report (PDF)

  • How it is put together: T-SQL scripts for the schema, views, triggers and stored procedures; ASP.NET Core MVC (.NET 10) controllers and Razor views reading through Dapper; jQuery for the forms. No Entity Framework — Dapper only maps the rows — so every query runs unchanged in DataGrip.
  • Ported from PostgreSQL: SQL Server fires a trigger once per statement, not once per row, so the triggers are set-based; procedures are made all-or-nothing with SET XACT_ABORT ON. The verify script checks every line of a received purchase order, so a row-at-a-time trigger that stocks only the first line fails it.
  • Hosting: Azure SQL Database on the serverless free offer and Azure Container Apps scaling to zero. The .NET SDK builds the image in GitHub Actions — no Dockerfile — each deploy pins an exact commit, and a $5 budget alert stands guard.
  • Power BI: Import mode, because DirectQuery would wake the paused database on every click. Low stock uses the web app’s exact rule, so after each refresh the report and the app flag the same balances. Built in Power BI Desktop in a Parallels Windows 11 VM.

SQL Server refuses a transfer bigger than the stock on hand. The stored procedure’s own message appears under Quantity, and nothing is written.

Power BI report

An Import-mode model over six star-schema views. The cards match SQL exactly: 2,781 units, $220,008 at cost, 7 balances below their reorder point.

Purchase orders

Fill rate counts only orders that were placed, so a draft doesn’t drag it down: 92 of 365 units received, 25.2%.