AI Developer · Full-stack systems

AI systems that show what broke, then ship the fix.

I’m Rifqi Sigwan Nugraha, a developer in Bandung who builds inspectable AI products across Next.js, Supabase, durable workflows, Python, and Flutter. I follow failures through traces and data boundaries until the real cause is clear.

View flagship build GitHub Download CV
Based in
Bandung
Focus
AI systems
Status
Open to roles
Based in
Bandung · UTC+7
Focus
AI systems
Stack
Next.js · Python
Work
Remote-ready
Status
Open to roles

Best-fit problems

  • Trace-driven debugging
  • AI API integration
  • Supabase boundaries
  • Systematic QA
  • Mobile support
01

Selected work

Two systems you can open and run.

CareCanvas is a human-gated AI illustration pipeline. NALAR is a role-based operations prototype. Both ship with a public URL and a public repository, so nothing here rests on my description of it.

Each case study separates three things: the working product, the engineering evidence behind it, and the boundary of what has been verified.

Live portfolio prototype

02 / 02

NALAR cooperative decision-support prototype landing page
Live interface · synthetic portfolio data

Role-based decision support

NALAR

A cooperative operations prototype spanning sales, POS, customers, receipt verification, national mapping, and optional grounded AI assistance. The core workflow still works when providers do not.

Open live app Inspect source
24 / 24
tests passing
Strict
TypeScript
Safe
degradation

Disclosure: NALAR uses synthetic portfolio data. It is not presented as a production cooperative or a claim of live users.

01

Server-owned access

Supabase service-role calls remain behind server APIs; elevated credentials never reach public clients.

02

Optional AI

Grounded Gemini responses use application context and deterministic fallbacks when the provider is unavailable.

03

Verified paths

Tests cover forecasting, tamper detection, fail-closed APIs, rate limits, and safe degradation.

  • Next.js 16
  • React 19
  • Supabase
  • PostgreSQL
  • Gemini
  • Vitest
02

Incident review

The video worked. Everything around it failed.

The two builds above are mine from the first commit. This one was someone else’s codebase running on someone else’s cloud project, and the fault sat on both sides of that line. Most production work looks like this.

An anonymised remote-client engagement. No private source, identifiers, screenshots, or raw logs are reproduced.

Flutter · Firebase · live streaming

Separating a cloud blocker from app-owned defects.

Playback succeeded while comments, likes, gifts, and viewer synchronisation failed. One visible symptom hid two different failure domains.

  1. 01

    Reproduce the split

    Confirmed stream transport worked while Firestore-backed interactions did not.

  2. 02

    Read the evidence

    Compared repeated device failures instead of inferring the cause from UI symptoms.

  3. 03

    Find the boundary

    Logs showed Firestore was disabled for the client cloud project. An environment blocker, not a rules defect.

  4. 04

    Separate the fixes

    Documented the external blocker, then removed an app-owned Firestore write from the render path.

  5. 05

    Verify honestly

    Added deduplication and freshness guards; analysis returned zero errors and the APK built successfully.

03

Working system

How a change gets verified before I call it done.

The same five steps produced everything on this page: the test counts in the case studies, the incident trace above, and the smaller systems below.

Claude Code is in my daily workflow, but traces, diffs, tests, builds, security checks, and human review decide whether the work is done.

  1. 1

    Observe

    Reproduce the failure and collect the smallest useful trace, log, or test.

  2. 2

    Decompose

    Split independent analysis, frontend, backend, data, and QA work where parallelism helps.

  3. 3

    Implement

    Keep ownership boundaries explicit and change only what the supported hypothesis requires.

  4. 4

    Challenge

    Test permissions, error paths, security assumptions, and regression risk.

  5. 5

    Verify

    Run tests and builds, inspect the user path, and record remaining uncertainty.

04

Supporting evidence

Four more systems with the same verification habit.

Smaller than the two flagship builds, and each one carries evidence you can open: a peer-reviewed paper, two public repositories, and one running app.

Where a project has a limit, a retired deployment or credit shared with a team, the card says so.

First-author research · IEEE Xplore

Synthetic IoT data for smart agriculture

Evaluated Monte Carlo simulation alongside Gaussian mixture models and kernel density estimation for generating synthetic IoT sensor data in smart agriculture.

  • Monte Carlo
  • GMM
  • KDE
  • IoT data
View IEEE record

Public repository · 24 tests

Shariah Trading Assistant

A role-scoped multi-agent research and analysis system with evidence handling and explicit QA gates.

  • Multi-agent
  • Orchestration
  • QA gates
Inspect source

Team build · project lead

Protein RADAR

A Next.js and PostgreSQL dashboard integrating more than twenty public data sources, authentication, RBAC, and audit logging. My contribution was within a documented team.

  • Next.js
  • Prisma
  • PostgreSQL
  • RBAC
Open live app

Computer vision · archived deployment

Qoffea

A coffee-bean assessment workflow with Flask, YOLO inference, confidence filtering, non-maximum suppression, API tests, and container configuration.

The former deployment is retired; this links to source evidence only.

  • Python
  • Flask
  • YOLO
  • Docker
Inspect source

Available for a conversation

Send me a failing trace.

I’m open to AI product, full-stack engineering, and research-driven collaborations. If you have a system that needs to be built, investigated, or made more reliable, let’s talk.

Email Rifqi LinkedIn
Email
rifqisigwannugraha@gmail.com
Based in
Bandung, Indonesia
Focus
AI systems + full stack
Status
Open to opportunities