Tee San.

Full Stack Developer

Request CV ↗
Explore the work directly, or step into the galaxy when it is ready.

Projects / 06 projects

Selected work

Production systems built in-house and independent product builds.

6 projects shown

01

Application / In-house system

IEMS

Production planning and execution for heavy-equipment manufacturing.

React · Express · Python · FastAPI · PostgreSQL · Docker · SAP

A heavy-equipment manufacturer needs labor time, machine hours and bay schedules in one system, with confirmed work posted to SAP S/4HANA instead of being keyed in by hand.

  • Designed and built the whole system: React frontend, Express API, PostgreSQL schema and migrations, Python workers and the Docker deployment.
  • Labor timesheets with NFC-card login, per-job check-in and check-out, and hierarchical validation.
  • Machine-hour ETL from factory SQL Server sources, bay scheduling, early-warning alerts and SAP posting through SAP CPI.

Runs daily at four plant sites. Timesheet and machine-hour records reach SAP through a staged posting queue with retry and correction, guarded by unique source keys so nothing is posted twice.

Trade-off

Chosen
One stack per plant, on the plant network. Shop-floor screens keep working without internet access, and SAP posting runs in its own workers so a slow or unavailable integration never blocks data capture.
Cost
Four deployments to configure, migrate and monitor instead of one. Posting is asynchronous, so the operations queue has to show what is pending, failed or retried.
Repository ↗
02

Application / In-house system

HadirOps

Attendance, leave and shift operations that keep working offline.

React Native · React · TypeScript · FastAPI · MongoDB · Docker

Field and plant employees check in from phones with weak signal, while admins and supervisors manage sites, shifts, assignments, overtime and leave. When the app or the network fails, nobody should end up marked absent with nothing on record.

  • Check-in with face verification and an accuracy-aware geofence; doubtful records go to a supervisor review queue instead of being refused.
  • An on-device outbox with client event ids, so a check-in queued without signal arrives once, in order, with its original time.
  • Leave requests, a per-employee attendance recap and overtime approval, with object-level access rules per role.
  • Moved the data layer from PostgreSQL to MongoDB without changing the API, rebuilding each guarantee explicitly.

69 tests run against a real MongoDB replica set in CI. In a morning-rush load test, 2,000 employees with about 30% of requests resent ended with exactly one record each.

Trade-off

Chosen
MongoDB, with the relational guarantees rebuilt on purpose: partial unique indexes for one check-in per day, a transaction against overlapping leave, conditional updates so an approval happens once, and integer ids allocated in blocks so both clients keep numeric ids.
Cost
Those rules live in indexes and repository code rather than in a schema the database enforces by itself. Transactions need a replica set even on one server, and a partial index is only used when the query states its filter, which took a load test and explain() to expose.
Repository ↗
03

Workflow tools / In-house system

Power Apps workflows

Five workflow apps on Power Apps, SharePoint and Power Automate.

React · TypeScript · Power Apps · SharePoint · Power Automate

Manufacturing teams run 5R audits, training requests, vehicle trips, material unblock tickets and overtime orders on SharePoint lists, and each workflow needs proper forms, approval routing and reporting.

  • Five React 19 and TypeScript code apps that run inside the Power Apps host.
  • Multi-step approval routing, notifications and file uploads through Power Automate flows.
  • Client-side photo compression for audits, keyset pagination over large lists, and overtime limit rules covered by unit tests.

Each app builds and publishes on its own. CI runs lint, unit tests, type checks and a production build for all five on every change.

Trade-off

Chosen
No custom backend. Power Platform handles sign-in, permissions and connections, and Power Automate carries the approval steps. Five separate builds keep each workflow small and independently deployable.
Cost
SharePoint list schemas become part of the contract: a column change means regenerating the typed services. Access is enforced by SharePoint and flow permissions, so the tenant setup matters as much as the code.
Repository ↗
04

Application / Product build

StockFlow

Warehouse inventory with a consistent stock ledger.

Java · Spring Boot · Angular · PostgreSQL · Flyway

Receipts, issues, transfers and count adjustments all change the same stock balances, and the ledger has to stay correct when requests are retried or run at the same time.

  • Purchase-order receiving, stock issues, transfers and physical-count adjustments.
  • One posting service that writes balances and the immutable movement ledger.
  • Two-person approval for count adjustments and linked reversals for corrections.

Integration tests on real PostgreSQL cover concurrent posting, rollback, two-person approval, reversals and role-based access.

Trade-off

Chosen
A single writer for all stock changes. Every balance and ledger update happens in one transaction, and idempotency keys, ordered locks and linked reversals make retries and corrections safe by design.
Cost
Throughput is bounded by lock scope on hot items, and every new workflow has to be built on top of the posting service instead of touching balances directly.
Repository ↗
05

Application / Product build

Print Approval System

Versioned print proofs with customer approval.

Java · Spring Boot · Angular · PostgreSQL · Docker

A print shop needs a clear customer decision on one specific preview and its print specifications before production, without asking the customer to create an account.

  • A shop workspace for jobs, versioned previews and private review links.
  • A mobile review page where the customer approves or requests a revision.
  • Printable approval records, with approved jobs locked against further changes.

Shop workspace and customer review ship as one Spring Boot service, verified with JUnit, PostgreSQL integration tests, Playwright browser journeys and axe accessibility checks.

Trade-off

Chosen
Preview images live in PostgreSQL next to the job, so every read goes through authorization and one backup restores everything. One service and one database keep the deployment to a single Compose file.
Cost
The database grows with every preview, which storage quotas keep in check. Request throttling is in-process, so running several instances would move it to the edge.
Repository ↗
06

Application / Product build

Service Verification

Per-unit service evidence, owner review and approved reports.

Kotlin · Spring Boot · Angular · PostgreSQL · Docker

An AC servicing business needs each unit documented with notes and before-and-after photos, reviewed by the owner, and attached to the invoice as a report that cannot change later.

  • Technician jobs with per-unit checklists and before-and-after photos, built for mobile.
  • Owner review with correction requests and printable, revisioned reports.

The full flow from assignment to approved report is covered by backend integration tests on real PostgreSQL and Playwright browser tests.

Trade-off

Chosen
One deployable service with plain JDBC keeps authorization queries and locking explicit. Photos are saved in the same transaction as the job, and approval writes a snapshot, so a later revision never changes a report that was already sent.
Cost
SQL and response mapping are written by hand, and photos grow the database over time. The design serves one business on one instance rather than many tenants.
Repository ↗

About me

Tee San

Full Stack Developer

I enjoy understanding how systems work end to end, from the applications people use to the backend services, databases, and integrations behind them.

I've worked across software development, data engineering, and system integration, primarily building and improving internal systems that support daily business operations. I like solving practical problems, simplifying processes, and making different parts of a system work together reliably.

My work has given me hands-on experience across different technologies, and I'm always interested in learning better ways to build and improve things.

Tools I work with

  • Python
  • SQL · PostgreSQL / SQL Server
  • JavaScript / TypeScript
  • React
  • Node.js
  • FastAPI
  • Docker
  • Power Apps
  • Power Automate
  • Power BI
Request CV GitHub ↗

You can request my CV by email.

Contact

Get in touch

The easiest way to reach me is by email.

teesanfajar@gmail.com
Request CV
Field notes /

Tee San.

Preparing the universe