Raffi Windarto
Osaka / Remote
Internal tools, integrations, and workflows for real operations
Product-minded Software Engineer — Osaka / Remote
I build internal products, reliable integrations, and AI-assisted workflows for the parts of a business still held together by spreadsheets, handoffs, and manual checks.
Over 3+ years, I’ve worked where product and operations meet: making the next action clear, making failures visible, and keeping important data moving.
3+ years
shipping internal tools and workflow software
Ops-first
interfaces for teams working under pressure
Verification-led
automation that stays explainable and safe to trust
Quick Overview
Good fit when spreadsheets, manual handoffs, or a system that no longer fits have become the bottleneck.
Project focus
How I work
Quick proof
Eleven case studies are live, nine with interactive demos. Start with Travel Partner for local-first AI product judgment, Kakeibo for daily-use UX, and Record Sync for backend reliability.
Four public-safe product stories, with the decisions behind them.
A connected view of product judgment, integration reliability, and how I make private work safe to discuss in public.
The portfolio explains architecture, decisions, and outcomes. Private source code, client data, credentials, raw screenshots, and internal artifacts stay out of the public surface.
Document Template Studio flow
Enough technical detail to discuss the approach, without putting private project material on the public site.
Captured input
Browser export or runtime response sample, sanitized before public explanation.
Schema validation
zod validates the vendor-shaped payload and fails loudly on mismatch.
Normalization
Coordinates, style aliases, and page data become a stable internal shape.
Review studio
Humans compare output before rollout instead of reading raw JSON.
Generated output
Deterministic result can be tested, diffed, and rerun safely.
Products and systems I can walk through from problem to implementation.
A queue-first operations console for monitoring work, choosing runtimes, and keeping handoffs readable when AI tasks start to sprawl.
A webhook-driven sync service that fetches canonical records, resolves identity safely, and makes mismatches explainable instead of mysterious.
Private product work
A private product workspace for migrating report templates, validating vendor-shaped inputs, and reviewing normalized output before rollout.
A self-service analytics surface for operators who needed fast answers, stable filters, and views that made sense without a BI manual.
How I think about building systems that last.
Before adding another automation, make it clear what happened, what failed, and what someone should do next.
Small releases make it easier to see what changed, verify the result, and back out cleanly when the context changes.
If someone opens a tool halfway through a problem, they should see the current state, the next action, and enough context to continue.
A task is not done at a green checkmark. Run the important path, check the edge case, and leave a trail for the next person.
The thinking behind the work.
Operations team could not see enough across AI task execution to notice trouble early or hand work off cleanly.
Had to bridge multiple runtimes without dumping more raw system noise onto the people using it.
Normalized task state and routing context into one inbox, then treated trust signals and handoff continuity as product features.
Created a calmer path from task state to next action, especially when incidents were still unfolding.
Overlapping records across many systems made reconciliation repetitive, slow, and easy to get subtly wrong.
Legacy APIs, rate limits, and narrow write windows mattered more than clean greenfield architecture ideas.
Separated ingestion from reconciliation, then used canonical fetches, deterministic identity rules, and readable diagnostics.
Turned sync behavior into something support and operations teams could reason about without backend archaeology.
Operators needed better answers from live metrics, but every new view still required an engineering ticket and a wait.
The dashboard had to reconcile different schemas while staying fast and legible during daily operational use.
Focused on searchable views, guardrailed filtering, and labels that favored operator language over analytics jargon.
Moved routine reporting closer to the people doing the work instead of routing every question back to engineering.
Non-technical users couldn't create or publish record-system-connected forms without filing a developer ticket for every change.
record API tokens had to stay server-side, public form access couldn't require respondent login, and multi-tenant isolation had to hold at the database layer.
Magic link auth, token-based public URLs, server-side form rendering from source field schema, and RLS-enforced per-user isolation.
Form creation became fully self-service — no developer involvement after initial setup, and submissions flow directly into record system.
Sharing record data externally meant handing over admin credentials or building custom views every time — there was no middle ground.
Four different access modes had to work without ever exposing source credentials to the client, regardless of how a viewer was configured.
Server-side server-side record proxy for all access modes, schema cache in Supabase, per-request access logs, and viewer status independent of access mode.
Teams can now publish specific record system views externally with the right access model — public, password-gated, or login-required — without credential exposure.
Existing budgeting apps were too complex (bank connections, mandatory sign-up) or too simple — no multi-currency support, no fast-entry flow, no real spending reflection.
Had to work offline from day one, support native and web from one codebase, handle multiple currencies without becoming a bank app, and require zero sign-up before tracking the first transaction.
Guest mode with local Repository abstraction (SQLite / IndexedDB), per-account currencies with live rate conversion, Kakeibo groups for category discipline, OCR receipt scanning behind a credit system, and monthly reflection journaling.
A cross-platform, multi-currency budgeting app with OCR scanning, 5 account types, CSV import/export, and a daily habit loop that works offline, in-browser, or synced — without the sign-up friction that kills adoption.
No existing app handles the JP↔ID learning pair well — generic tools miss real-life Japanese scenarios and don't account for the structural differences Indonesian speakers face.
Had to work offline from day one, support bilingual direction switching as a first-class feature, and keep content extensible without a re-deploy.
Seeded quiz engine for reproducible encounters, review queue for missed-question tracking, Supabase content catalog behind a feature flag with bundled JSON fallback, and RPG mechanics to sustain the daily habit loop.
Live bilingual learning app with N5 quest progression, adaptive review, and a content pipeline that accepts new quests as database writes — no code change required.
Travel planning needed to feel useful before account creation, while still leaving room for cloud sync after auth is ready.
AI keys must stay server-side, anonymous drafts must stay local, and user-owned trip data should not be written to cloud tables before RLS is real.
Separated local draft mode, server-side generation, editable itinerary items, fake budget tracking, and authenticated-only cloud persistence.
Created a portfolio-safe product story that shows local-first UX, AI boundary discipline, and pragmatic MVP scope without exposing private trip data.
Operations staff needed real-time LINE notifications when source records changed, and users needed a way to respond via LINE — without accessing record system directly or exposing API tokens in the browser.
browser customization runs in the browser, so LINE tokens had to stay server-side. GCP Functions cold start added latency, and Reply API tokens expire in 30 seconds — wrong API mode causes silent failures.
Hard boundary between Reply API (user-initiated postbacks only) and Push API (all status change notifications). server-side proxy for browser-side LINE calls. HMAC signature verification before any payload processing.
Real-time status notifications flowing to LINE with two-way postback handling writing back to record system — messaging costs predictable, delivery reliable, no tokens in the browser.
Time-sensitive records in record system had no urgency signal in native views — every deadline looked the same. Staff also needed to pause records intentionally without breaking the status flow.
record system's 500-record API limit required cursor pagination. The pause mechanism had to be additive — no changes to existing process management rules or status field logic.
Separate stay flag field for intentional holds, days-remaining computed server-side as the primary sort key, urgency tiers driving row color coding, cursor-based pagination preventing silent truncation.
Operations teams got a morning triage queue sorted by actual urgency. Pause mechanics kept KPI counts clean, and the dashboard replaced direct record system access for daily deadline work.
Report templates needed to migrate from a vendor system with no official export API — the only data source was runtime proxy responses and browser traffic.
Input shapes were inconsistent across real-world samples, PDF assets weren't reliably obtainable, and the toolkit had to be reproducible offline by the whole team.
zod-validated input normalization at the boundary, a pure deterministic transformer with no side effects, and HAR-based extraction as the fallback path.
Proved the migration path end-to-end — vendor API responses in, normalized internal JSON out — without reverse engineering or a live vendor connection.
I like software that helps someone make the next good decision.
Most of my work has lived in the unglamorous middle of a business: internal tools, operator workflows, integration layers, and the systems people depend on when something has already gone a little sideways.
That kind of software needs a different quality bar. It has to stay legible when someone is tired, rushed, or inheriting context from another teammate. A useful interface is not the one with the most state. It is the one that makes the next step obvious.
So I tend to work across product and engineering at the same time: clarify the workflow, cut noise, make failure states explainable, and ship the verification steps that let people trust automation without hand-waving.
Open to automation & systems projects
Best fit: scoped internal tools, workflow automation, Web/API integrations, and AI-assisted operator experiences.
