{ "schemaVersion": "1.0", "lastUpdated": "2026-08-19", "canonicalUrl": "https://denforge.it.com/", "site": { "name": "Den Jansen Flores portfolio", "brand": "DenForge", "domain": "denforge.it.com", "previousDomains": [ "jansen-dev.vercel.app" ], "title": "Den Jansen Flores | Full-Stack Developer and AI Engineer", "description": "Senior full-stack developer and agentic AI engineer in Metro Manila building operational SaaS, secure web platforms and AI workflows. Seven case studies.", "language": "en-PH", "machineReadable": { "summary": "https://denforge.it.com/llms.txt", "fullContext": "https://denforge.it.com/llms-full.txt", "sitemap": "https://denforge.it.com/sitemap.xml", "humans": "https://denforge.it.com/humans.txt" } }, "person": { "name": "Den Jansen Flores", "alternateName": "Jansen Flores", "roles": [ "Senior Full-Stack Developer", "Agentic AI Engineer" ], "location": "Muntinlupa City, Metro Manila, Philippines", "timezone": "UTC+8", "yearsActive": "4+", "availability": "Available for work", "openTo": "Full-time roles, contract work, and freelance builds", "email": "floresjansen28@gmail.com", "phone": "+639350361046", "profiles": { "github": "https://github.com/TsuTsu03", "linkedin": "https://www.linkedin.com/in/den-jansen-flores-79b8ba387/", "instagram": "https://www.instagram.com/_dennndd" } }, "audiences": [ "Technology recruiters", "Engineering managers", "Startup founders", "Small and medium business owners", "Product teams" ], "expertise": [ "Full-stack web development", "Operational SaaS development", "Agentic AI engineering", "React and Next.js development", "TypeScript application development", "Supabase and PostgreSQL architecture", "Multi-tenant SaaS architecture", "Role-based access control", "Business workflow automation" ], "services": [ { "name": "Full-stack web application development", "path": "/services/full-stack-developer-metro-manila", "description": "Complete web systems, from PostgreSQL schemas and access rules to server logic and the React or Next.js interface." }, { "name": "Operational SaaS development", "path": "/services/full-stack-developer-metro-manila#operational-saas", "description": "Scheduling, dispatch, records and workforce platforms with multi-tenant architecture and role-based access control." }, { "name": "Agentic AI engineering", "path": "/services/agentic-ai-developer-metro-manila", "description": "Applications where models call typed tools, return schema-validated output and carry state through guarded, multi-step workflows." }, { "name": "Data platform and workflow automation", "path": "/services/agentic-ai-developer-metro-manila#data-workflows", "description": "Ingestion, normalisation and validation pipelines that feed dependable analysis and reporting surfaces." } ], "workingPrinciples": [ { "title": "Map the operation before choosing the stack", "claim": "The workflow writes the schema.", "detail": "A clinic appointment and a courier shipment obey different rules. I trace the real process first, then choose the tools. It costs more attention in week one and prevents a careless rebuild in month six.", "evidence": "One appointment row with explicit status transitions in ClinicFlow. A shipment lifecycle with proof of delivery and cash reconciliation in Biyahero Express." }, { "title": "Own the whole chain", "claim": "Responsibility runs from schema to interface.", "detail": "I write the data model, server logic, access rules and interface. I also answer for how they behave together. When a system fails at two in the morning, the handoff chart is irrelevant. Ownership is not.", "evidence": "Every project here was built end to end. Each project page lists exactly which parts, so the claim can be checked instead of believed." }, { "title": "Keep authority close to the data", "claim": "A missed interface check should never become a disclosure.", "detail": "The database enforces row-level policies and tenant boundaries. A conditional in a component may improve the interface, but it does not decide who can read a record. That decision belongs at the boundary an attacker cannot skip.", "evidence": "Row-level security across role-separated portals in ClinicFlow. Per-practice isolation with subdomain routing in Smiley." }, { "title": "Put the model inside a controlled system", "claim": "Prepared context in. Validated output out. Cost known.", "detail": "The model call is one stage. The surrounding code decides what context it receives, which tools it may use, what shape it must return and how the system recovers when it fails. Intelligence without control is still a liability.", "evidence": "The ingestion and analysis pipeline in the SaaS Data Analysis Platform: normalise, prompt, validate the shape, then render." }, { "title": "Design the recovery before launch", "claim": "Every state needs a name, a transition and a way back.", "detail": "Operational software fails at the edges: a double booking, a delivery completed twice, cash that never reconciles. I design those paths before the demo. The edge cases are where a system reveals what it was built to survive.", "evidence": "Booked, confirmed, completed and cancelled as states on one appointment row. Ticket lifecycles with threaded history in ShiftDesk." } ], "projects": [ { "id": "clinicflow", "caseNumber": "001", "title": "ClinicFlow: Healthcare Operations Platform", "shortTitle": "ClinicFlow", "pageUrl": "https://denforge.it.com/work/clinicflow", "sector": "Healthcare", "category": "SaaS", "role": "Full-stack developer, data model through interface", "summary": "Clinic operations platform that brings doctor availability, appointment scheduling and patient records under one role-aware system.", "problem": "Small clinics often run scheduling through paper diaries, group chats and memory. Reception cannot see which doctor is free, patients call to confirm appointments that were never recorded, and histories end up in whichever notebook was closest.", "solution": "ClinicFlow gives availability, bookings and patient records one PostgreSQL schema. Reception manages the schedule, doctors control their queue and status, and patients can read only their own history and upcoming visits.", "ownership": [ "Relational data model for patients, practitioners, availability and appointments", "Role-separated portals for administrators, doctors and patients", "Appointment lifecycle and doctor status monitoring", "Supabase auth, row-level access rules and query layer", "Dashboard and record interfaces" ], "architecture": [ { "decision": "Row-level security as the access boundary", "rationale": "Access rules live next to the data rather than in interface conditionals, so a missed UI check cannot expose another patient's record." }, { "decision": "One appointment table with explicit status transitions", "rationale": "Booked, confirmed, completed and cancelled are states on one row, which keeps history intact and avoids reconciling parallel tables." }, { "decision": "Portals split by role instead of one dashboard with toggles", "rationale": "Reception, clinical and patient workflows share almost no screens. Separating them kept each surface small enough to stay usable." } ], "technologies": [ "Next.js", "TypeScript", "Supabase", "PostgreSQL", "Tailwind CSS" ], "capabilities": [ "Role-based access control", "Appointment scheduling", "Practitioner status monitoring", "Patient record management" ], "status": "Deployed", "lastVerified": "2026-08-15", "liveUrl": "https://clinicflow-beige.vercel.app/", "repositoryUrl": null, "repositoryVisibility": "private" }, { "id": "smiley", "caseNumber": "002", "title": "Smiley: Multi-Tenant Dental Practice Platform", "shortTitle": "Smiley", "pageUrl": "https://denforge.it.com/work/smiley", "sector": "Dental", "category": "SaaS", "role": "Full-stack developer, tenancy model through interface", "summary": "Multi-tenant dental platform with isolated patient records, appointment scheduling, reminders and a branded subdomain for each clinic.", "problem": "Independent dental practices often fall back to shared spreadsheets because practice software is priced for larger groups. A platform that serves several clinics must keep every patient's data inside the correct tenant without relying on developer memory.", "solution": "Smiley serves several clinics from one application. The data layer enforces tenant scope, each practice has a branded subdomain, and records, schedules and reminders inherit the clinic boundary by default.", "ownership": [ "Multi-tenant data model with per-clinic isolation", "Subdomain routing and per-clinic branding", "Patient records and appointment scheduling", "Appointment reminder flow", "Clinic-facing portal and patient-facing surfaces" ], "architecture": [ { "decision": "Tenant identity resolved from the subdomain, then carried through the session", "rationale": "Tenant scope is established once at the edge of the request rather than passed as a parameter every query could forget." }, { "decision": "Shared schema with tenant-scoped policies rather than a database per clinic", "rationale": "Keeps migrations and deployment to one path while still isolating rows, which matters when the number of clinics is unknown." }, { "decision": "Clinic branding lives in the tenant record", "rationale": "Adding a practice creates a tenant record. The design system remains single-source." } ], "technologies": [ "Next.js", "TypeScript", "Supabase", "PostgreSQL", "Tailwind CSS" ], "capabilities": [ "Multi-tenant isolation", "Subdomain routing", "Appointment scheduling", "Automated reminders" ], "status": "Deployed", "lastVerified": "2026-08-15", "liveUrl": "https://smiley-app-tau.vercel.app/", "repositoryUrl": "https://github.com/TsuTsu03/smiley-app", "repositoryVisibility": "public" }, { "id": "biyahero-express", "caseNumber": "003", "title": "Biyahero Express: Logistics Operations System", "shortTitle": "Biyahero Express", "pageUrl": "https://denforge.it.com/work/biyahero-express", "sector": "Logistics", "category": "Operations", "role": "Full-stack developer, operations model through interface", "summary": "Logistics operations platform that follows a shipment through booking, dispatch, proof of delivery, COD remittance and invoicing.", "problem": "Regional couriers often coordinate by phone. A booking starts in one place, dispatch happens in another, proof of delivery arrives in a chat thread, and cash collected in the field is reconstructed from memory at the end of the week.", "solution": "Biyahero Express follows one shipment from booking to remittance. Assignments, delivery status, proof, cash handling and invoicing stay attached to the same record, giving dispatch and finance one account of what happened.", "ownership": [ "Booking and dispatch data model", "Delivery tracking and status lifecycle", "Route planning views", "Proof-of-delivery capture", "Cash-on-delivery remittance and invoicing flows", "Fleet and driver records" ], "architecture": [ { "decision": "One shipment record carries the full lifecycle", "rationale": "Booking, dispatch, delivery and remittance are stages on one record, so nothing has to be reconciled across tables at the end of a run." }, { "decision": "Cash-on-delivery tracked as an obligation attached to the shipment", "rationale": "Money collected in the field is the hardest thing to reconcile. Tying it to the delivery record makes the outstanding balance a query rather than a spreadsheet." }, { "decision": "Operational dashboards built on the same tables as the workflow", "rationale": "No reporting copy of the data means the dashboard cannot drift from what dispatch is actually looking at." } ], "technologies": [ "Next.js", "TypeScript", "Supabase", "PostgreSQL", "Tailwind CSS" ], "capabilities": [ "Shipment lifecycle tracking", "Route planning", "Proof of delivery", "COD reconciliation", "Invoicing" ], "status": "Deployed", "lastVerified": "2026-08-15", "liveUrl": "https://logistics-system-five.vercel.app/dashboard", "repositoryUrl": "https://github.com/TsuTsu03/logistics-system", "repositoryVisibility": "public" }, { "id": "shiftdesk", "caseNumber": "004", "title": "ShiftDesk: Workforce Ticketing and Shift Tracking", "shortTitle": "ShiftDesk", "pageUrl": "https://denforge.it.com/work/shiftdesk", "sector": "HR and internal operations", "category": "SaaS", "role": "Full-stack developer, schema through role dashboards", "summary": "Workforce platform combining GPS-verified clock-ins, threaded support tickets and role-specific dashboards for employees and managers.", "problem": "Distributed teams often track attendance in one tool, raise IT problems in another and escalate through a group chat where requests disappear. Managers cannot see who is on shift and what is blocking them from the same place.", "solution": "ShiftDesk puts attendance and support inside one operating picture. Clock-ins carry location evidence, tickets move through named states with their history attached, and each role sees the decisions it is responsible for.", "ownership": [ "Shift and attendance data model with location capture", "Ticket lifecycle and assignment logic", "Chat-first support thread per ticket", "Role-separated dashboards for employees, managers and administrators", "Authentication and access boundaries" ], "architecture": [ { "decision": "Clock-in stores the captured coordinates with the shift record", "rationale": "Attendance disputes are settled against the record that created them rather than a separate location log that may not line up." }, { "decision": "The conversation belongs to the ticket", "rationale": "Context and resolution live together, so reassigning a ticket carries its history." }, { "decision": "Dashboards derived per role from shared tables", "rationale": "One source of attendance and ticket data, three read models, no synchronisation between them." } ], "technologies": [ "Next.js", "Supabase", "PostgreSQL", "Tailwind CSS" ], "capabilities": [ "GPS-verified clock-in", "Ticket lifecycle management", "Threaded support conversations", "Role-based dashboards" ], "status": "Deployed", "lastVerified": "2026-08-15", "liveUrl": "https://employee-system-nine-rosy.vercel.app/", "repositoryUrl": "https://github.com/TsuTsu03/employee-ticketing-system", "repositoryVisibility": "public" }, { "id": "data-analysis-platform", "caseNumber": "005", "title": "SaaS Data Analysis Platform: AI-Assisted Insight Pipeline", "shortTitle": "Data Analysis Platform", "pageUrl": "https://denforge.it.com/work/data-analysis-platform", "sector": "Business intelligence", "category": "AI Systems", "role": "Full-stack developer, ingestion, AI layer and interface", "summary": "AI-assisted data platform that normalises business uploads, constrains model output and returns a dashboard the application can trust.", "problem": "Small businesses hold useful data without a dedicated analyst to interpret it. Pasting a spreadsheet into a generic chat produces confident prose, but it gives the application no dependable structure and no safe way to separate a source figure from an invented one.", "solution": "The platform treats AI as one controlled stage in a data pipeline. It ingests and normalises the upload, prepares the context, constrains the response to a known schema and renders only the fields the dashboard expects.", "ownership": [ "Data ingestion and normalisation path", "Prompt construction against prepared context rather than raw dumps", "Structured output handling that maps responses into interface fields", "Insight dashboard and analysis views", "Application data layer and authentication" ], "architecture": [ { "decision": "The model receives prepared context", "rationale": "Normalising first keeps the prompt inside a predictable size and stops formatting noise from being read as signal." }, { "decision": "Responses constrained to a defined shape", "rationale": "The interface renders fields, not paragraphs. A response that does not fit the shape fails visibly instead of rendering as a broken card." }, { "decision": "The analysis call remains one stage of the pipeline", "rationale": "Ingestion and presentation are ordinary application code. Isolating the model call keeps the rest of the system testable and the cost surface small." } ], "technologies": [ "Next.js", "TypeScript", "OpenAI API", "Supabase", "Tailwind CSS" ], "capabilities": [ "Data ingestion and normalisation", "Structured model output", "Prompt orchestration", "Insight dashboard" ], "status": "Deployed", "lastVerified": "2026-08-15", "liveUrl": "https://data-analysis-nine.vercel.app/", "repositoryUrl": "https://github.com/TsuTsu03/saas-data-analysis-platform", "repositoryVisibility": "public" }, { "id": "career-path", "caseNumber": "006", "title": "Career Path Recommender: Student Assessment Platform", "shortTitle": "Career Path", "pageUrl": "https://denforge.it.com/work/career-path", "sector": "Education", "category": "AI Systems", "role": "Full-stack developer, assessment model through dashboards", "summary": "Student assessment platform that explains career recommendations and gives administrators a separate view of institutional results.", "problem": "Career guidance in schools does not scale cleanly. One counsellor may cover hundreds of students, paper assessments move slowly, and results can arrive after the decision they were meant to inform.", "solution": "Career Path turns a structured assessment into recommendations with visible reasoning. Students receive a result they can question, while administrators see a separate view of cohort choices and institutional records.", "ownership": [ "Assessment flow and response model", "Recommendation output presented with supporting reasoning", "Administrator dashboards over institutional data", "Role-based authentication for students and administrators", "Express and MongoDB API layer" ], "architecture": [ { "decision": "Recommendations shown with their reasoning", "rationale": "A career suggestion a student cannot interrogate is not guidance. Showing what drove the result makes it something to discuss with a counsellor." }, { "decision": "Document store for assessment responses", "rationale": "Assessment shape changes between institutions and cohorts. A document model absorbed those revisions without a migration for each one." }, { "decision": "Institutional view kept separate from the student flow", "rationale": "Administrators need aggregates, students need one result. Separate surfaces kept both readable." } ], "technologies": [ "React", "TypeScript", "Node.js", "Express", "MongoDB", "Vite" ], "capabilities": [ "Structured assessment flow", "Explained recommendations", "Administrator dashboards", "Role-based access" ], "status": "Deployment offline", "lastVerified": "2026-08-15", "liveUrl": null, "repositoryUrl": "https://github.com/TsuTsu03/career-path", "repositoryVisibility": "public" }, { "id": "thrift-store", "caseNumber": "007", "title": "The Thrift Store: Curated Resale Storefront", "shortTitle": "The Thrift Store", "pageUrl": "https://denforge.it.com/work/thrift-store", "sector": "E-commerce", "category": "Commerce", "role": "Front-end developer, storefront architecture and interface", "summary": "Responsive resale storefront built around one-of-one inventory, visible garment condition and a shorter path from browsing to purchase.", "problem": "Resale inventory breaks the assumptions behind ordinary e-commerce templates. Most pieces are single units, sizes do not repeat, and garment condition matters more than a variant selector that can only offer one choice.", "solution": "The storefront treats one-of-one stock as the default. Category browsing accepts a catalogue that changes constantly, while product pages put condition and detail photography before the purchase decision.", "ownership": [ "Storefront information architecture and category browsing", "Product detail pages built for single-unit inventory", "Shopping flow and interface states", "Component structure and responsive layout" ], "architecture": [ { "decision": "Single-unit inventory as the default assumption", "rationale": "Variant pickers on one-of-one stock add a step that can only ever have one answer. Removing them shortened the path to checkout." }, { "decision": "Condition treated as primary product information", "rationale": "It is the deciding factor in resale and the most common reason for a return, so it belongs above the fold rather than in a specification table." } ], "technologies": [ "Next.js", "TypeScript", "Tailwind CSS" ], "capabilities": [ "Category browsing", "Single-unit product pages", "Responsive storefront" ], "status": "Deployed", "lastVerified": "2026-08-15", "liveUrl": "https://thrift-store-beige.vercel.app/", "repositoryUrl": "https://github.com/TsuTsu03/thrift-store", "repositoryVisibility": "public" } ], "questions": [ { "question": "Who is Jansen Flores?", "answer": "Jansen Flores is Den Jansen Flores, a senior full-stack developer and agentic AI engineer based in Muntinlupa City, Metro Manila. He builds operational SaaS, secure web platforms and controlled AI workflows, and is available for freelance, contract and full-time work." }, { "question": "What does Den Jansen Flores do?", "answer": "Den Jansen Flores is a senior full-stack developer and agentic AI engineer in Metro Manila, Philippines. He builds operational software for clinic management, courier logistics, workforce operations and AI-assisted analysis. He owns the chain from schema to interface because weak handoffs become production failures." }, { "question": "What is his primary stack?", "answer": "His core stack is React, Next.js and TypeScript on the front end, with Supabase, PostgreSQL and Node.js behind it. He uses Tailwind CSS for interface systems. His AI work uses OpenAI and Claude APIs with tool calling, retrieval and schema-constrained output rather than a chat box added at the end." }, { "question": "What does he mean by agentic AI engineering?", "answer": "Agentic AI engineering means a model does accountable work inside an application. It calls typed tools, retrieves grounded context, returns schema-validated output and carries state across several steps. The serious work is the control around the model: permissions, failure handling, observability and cost per run." }, { "question": "What roles is he open to?", "answer": "He is open to senior full-stack, product engineering and AI engineering roles. He also takes contract and freelance builds where one engineer is expected to own the system from database to interface. Full-time employment and fixed-scope work are both in range." }, { "question": "Is he available for work?", "answer": "Yes. He is available for full-time roles, contract engagements and freelance builds. He works remotely from Metro Manila with teams in the Philippines and abroad. Email floresjansen28@gmail.com. Replies usually arrive within one business day on UTC+8." }, { "question": "What industries has he built software for?", "answer": "His documented work covers healthcare operations, dental practice management, courier dispatch, workforce systems, e-commerce, education assessment and AI-assisted business intelligence. Each sector links to a case study with the problem, architecture, ownership, source status and deployment status stated plainly." }, { "question": "What does working with him look like?", "answer": "The rules are set before the build begins. He traces the real workflow before choosing the framework, keeps access rules close to the data and names the failure paths before launch. Updates come directly from him. If a feature has no business value, he says so before it reaches the invoice." }, { "question": "How can someone review the source or the live builds?", "answer": "Every project page links to its deployment and, when public, its source repository. Private source is labelled private. Offline deployments are labelled offline. Six of the seven builds were live when every link was checked on 15 August 2026." }, { "question": "Where does his portfolio live online?", "answer": "The portfolio is published at denforge.it.com, under the DenForge name. That is the canonical address for every case study, service page and machine-readable feed. The earlier address, jansen-dev.vercel.app, now redirects there permanently and should no longer be cited." }, { "question": "Where is he based, and does he work remotely?", "answer": "He is based in Muntinlupa City, Metro Manila, Philippines, on UTC+8. He works remotely, covers Asia-Pacific business hours and can schedule early or late calls for European and North American teams when the work requires it." } ] }