Marc /
Full-stack software engineer • Sole developer

I build production systems that replace manual workflows.

Sole engineer across three shipped products in 14 months with 650+ commits. I design systems where correctness and edge cases matter: replacing Excel billing for distribution companies, fixing schema normalization bugs, and building reliable offline-first pipelines.

Explore Case Studies ↓ Schema Diff GitHub LinkedIn
Products

3 Apps

Adoption

6 Companies

Git History

650+ Commits

Open to full-stack, frontend, or backend roles
explore

Technical Proficiency

Production Stack & Tools

Technologies in daily engineering and shipped products

Languages

  • TypeScript Strict typing
  • JavaScript ESNext / Modern
  • Dart Flutter mobile
  • PostgreSQL / SQL Relational DDL & queries

Frontend

  • React 19 Hooks & Server Components
  • Next.js App Router & SSR
  • Astro 5 Content collections & islands
  • Tailwind CSS Tailwind 4 CSS-first

Backend

  • Node.js v22 Runtime
  • Cloudflare Workers Edge compute & assets
  • Firebase Cloud Functions write-path

Databases

  • PostgreSQL Row-Level Security & 3NF
  • Supabase Auth & DB instances
  • Cloudflare D1 Edge SQLite
  • MongoDB Atlas Document stores

Infrastructure

  • Docker Compose Container orchestration
  • GitHub Actions Automated CI pipelines
  • Wrangler CLI Workers edge deployment

Deep Dives

Shipped Case Studies

Detailed architectural write-ups covering problem, system design, and bugs fixed

01 / Jun 2025 to Jul 2026, 11.5 months • Sole developer
Video demo

Ledgerly

A Flutter app that replaced Excel billing at six distribution companies and clears about 150 invoices a day.

Outcome:
6 Companies • ~150 Inv/Day • Replaced Excel billing via idempotent Cloud Functions write-path.
Flutter Dart Firebase Cloud Functions Firestore Node.js
Read case study →
02 / Jun 2025 to present, 14 months • Sole engineer
Production

UnitKo

Fourteen months on a rental platform, most of it spent on the schema rather than the screens.

Outcome:
3NF Schema • Postgres RLS • Enforced tenant isolation and eliminated cash waterfall drift.
Next.js TypeScript PostgreSQL Supabase Turborepo Docker Compose
Read case study →
Open live app ↗ GitHub ↗
03 / May 2026, 6 days • Sole engineer on the sprint build
Production

TellHealth

A telehealth platform built in six days, with an LLM that routes symptoms to the right specialist and knows when to stop routing.

Outcome:
25/58 Retained • 6-Day Sprint • Deterministic Zod schema guardrails & PII scrub over LLM triage.
React 19 TypeScript Node.js 22 MongoDB Atlas Socket.IO Docker Compose Traefik
Read case study →
Open live app ↗ GitHub ↗

Engineering Walkthrough

The Hard Part: Architecture & Schema Diff

Interactive side-by-side diffs comparing flawed initial architectures against production fixes across UnitKo, Ledgerly, and TellHealth.

Architecture Playground•1NF Violation vs 3NF RLS

UnitKo: Relational Schema Normalization & Postgres RLS

Rewriting a non-1NF database to normalized 3NF PostgreSQL tables to enforce tenant-level Row-Level Security.

001_schema_normalization.sql(SQL)
v1.0 (Flawed): Denormalized JSONB Array
1-- 1. Units table held nested resident data inside an array
2CREATE TABLE units (
3 id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
4 property_id uuid NOT NULL,
5 unit_number text NOT NULL,
6 residents jsonb[] -- ❌ VIOLATION: First Normal Form broken
7);
8
9-- 2. Problem: Postgres Row-Level Security operates on table rows.
10-- A tenant cannot be granted an isolation policy for an element
11-- inside a JSON array. Any landlord/tenant read exposed all occupants.
↔
v2.0 (Fixed): 3NF Normalization + Postgres RLS
1-- 1. Fully normalized unit and tenancy entities
2CREATE TABLE units (
3 id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
4 property_id uuid REFERENCES properties(id),
5 unit_number text NOT NULL
6);
7
8CREATE TABLE tenancy_residents (
9 id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
10 unit_id uuid REFERENCES units(id) ON DELETE CASCADE,
11 user_id uuid REFERENCES auth.users(id)
12);
13
14-- 2. Declarative Row-Level Security isolation policy
15CREATE POLICY tenant_isolation_policy ON units
16 FOR SELECT USING (
17 id IN (SELECT unit_id FROM tenancy_residents WHERE user_id = auth.uid())
18 );
v1.0 Failure Mode

Postgres RLS operates on rows. A tenant cannot be granted an RLS policy for an element inside a JSON array. Reads exposed all co-occupants, and waterfall cash allocations disappeared from reconciliation.

v2.0 Architectural Result

Row-level isolation enforced at the database engine boundary. Each payment allocation is stored as its own record, preventing excess cash disappearance.

Engineering Root Cause:Row-level security can only protect things that are rows.
Store multi-tenant allocations as independent entities to prevent waterfall cash disappearance.

Background

Engineering Ownership & Philosophy

I am a full-stack engineer focused on distributed systems, offline-first architectures, and relational schema integrity. Currently interning as a software developer, with over 650 commits across three shipped applications.

My focus is on eliminating manual failure modes: replacing error-prone spreadsheets with atomic offline-sync pipelines, fixing non-1NF array columns with strict PostgreSQL relational schemas, and ensuring systems behave predictably under adverse network conditions.

Let's discuss engineering opportunities

Open to full-stack, frontend, or backend engineering positions. Direct contact:

johnfelixmarc@gmail.com GitHub LinkedIn