Payroll formula variables (configured, not hardcoded)
9
Payroll formula variables (configured, not hardcoded)
Anomaly-detection rules
5
Anomaly-detection rules
⚡ Idea→ship
~9 days
2026-09-08
First prompt
+9 days
2026-09-17
First working build · Latest
2026-09-08
First prompt
+9 days
2026-09-17
First working build · Latest
Idea → core logic working ~9 days (~5–7 active days). In development, not yet deployed
01
Idea / Problem
First instruction: "Let's finish the full screen/feature design first for an NFC-tag + server attendance app. Flutter does both iOS and Android, right?"
Original (KO): "NFC 태그와 서버를 조합한 근태 앱을, 화면·기능 설계부터 디테일하게 끝내자. 플러터면 iOS·안드로이드 둘 다 되지?"
Small Thai dental clinics, cafes, and restaurants track attendance on paper, which invites buddy-punching and time fudging and makes payroll labor-intensive. The goal was an app that records attendance honestly via NFC tags and location checks, then calculates payroll automatically from those records.
02
The Plan & Bar I Set
For this project the design itself is the core. Before any code, I designed:
5 anomaly rules: reject only severe violations (e.g., device mismatch) immediately; log the rest for admin Manual Review
Payroll formulas as configuration, not code: admins set formulas on-screen and a safe parser computes them; variables fixed at 9 (base, overtime, night, lateness, etc.)
Privacy (PDPA): GPS and device ID for ephemeral verification only, never stored permanently
A multi-tenant structure (many companies in one system)
Fig. attennfc-02
Payroll as configuration, not code — the formula engine
AdminFormula set in the GUIStart from an industry template
9 fixed variables
Base payOvertimeNightLate…
ComputeSafe expression parserNo hard-coding
ResultPay + live estimate
Admins set the formula on screen and a safe parser computes it. Nine fixed variables, industry templates and live estimates. (The settings screen is still in development, so this shows the structure.)
03
Directing AI
Fig. attennfc-direction
Directing AI
01 First instruction
build the DB schema, state management (providers), and payroll engine from the bar above.
02 What I checked
reviewing the generated code, I found recurring problems — NFC library API mismatch, a missing company_id, duplicated folders, only 5 payroll variables instead of 9, and hardcoded GPS coordinates.
03 Correction
keep the SQL schema, RLS, and design decisions, but rewrite the problem code from scratch. After the rewrite I personally confirmed flutter analyze reported "No issues found."
Actual instructions (excerpts)
›Let's pull all the screens in design first, then start building — doing both at once gets tangled.Original디자인을 전 화면 다 뽑은 뒤에 개발을 시작하자 — 병행하면 꼬여.
›Rather than hard-blocking, let an admin review anything suspicious.Original완전히 막기보다, 이상하면 관리자가 검토하게 하자.
Fig. attennfc-03
Checking AI output against the bar — and correcting it
Before
Only 5 of 9 payroll variables
NFC library API mismatch
Hard-coded GPS · duplicated folders
My instruction (gist)
“Keep the design and data model; rewrite the broken code from scratch”
Original설계·데이터 모델은 유지하고, 문제 코드는 처음부터 다시 작성해
After
✓ All 9 payroll variables
✓ flutter analyze — No issues found
04
Where It Got Stuck & How I Resolved It
iOS Wi-Fi verification limits: iOS restricts Wi-Fi access, so the secondary check can fail. I directed a fallback to GPS range verification alone, logging "Wi-Fi check skipped" so it stays auditable.
Offline time tampering: To counter changing the device clock, I directed logic that estimates true time by combining the last server timestamp with elapsed time, escalating large discrepancies to admin review.
Fig. attennfc-05
Five anomaly rules — branch, don't just block
InputClock-in attempt
Check5 anomaly rules
NormalRecorded
AnomalyRecorded + admin reviewManual Review
SevereRejectede.g. device mismatch
“Rather than blocking everything, let an admin review anything odd.” Only severe violations are rejected outright.Original“완전히 막기보다, 이상하면 관리자가 검토하게 하자.”
Fig. attennfc-06
Offline time verification (TrueTime)
ALast server time
+
BElapsed device timeUnaffected by clock changes
=
A + BEstimated true time
vs device clock
Small gapRecorded
Large gapAdmin review
To catch a changed device clock, true time is estimated from the last server time plus elapsed time.
Case 01
Generated code fell short of the bar
!
Symptom
Generated code fell short of the bar — only 5 of 9 payroll variables, NFC library API mismatch, hardcoded GPS coordinates, duplicated folders.
›
How I described it
Pointed out each divergence against my bar (9 variables, dynamic-token API, coordinates as config).Original내가 세운 기준(변수 9종·동적 토큰 API·좌표 설정값)을 조목조목 대조해 어긋난 지점을 지적.
↺
AI’s first try
Partial fixes kept reproducing the same problems.
◎
What I caught
Keep the SQL schema, RLS, and design, but the problem code needed a rewrite, not patching.
✓
Fix
Directed a rewrite from scratch, then confirmed flutter analyze reported zero issues.
⟲
Prevention
I take AI output through a "bar checklist" and apply a rewrite rule when it diverges.
05
Results
Designed and built 4-layer security and 5 anomaly rules with an admin-review flow
A payroll formula engine with no hardcoding (9 variables, industry templates, real-time estimated pay)
Offline time-verification that catches clock tampering without internet
Core logic first pass complete (flutter analyze reports zero issues) — in development
06
Retrospective
The most important skill here was not trusting AI's output blindly — checking it against the bar and instructing a redo. The more "wrong isn't acceptable" the area (security, payroll), the more the answer was to set the bar in writing first. Next is wiring the designed screens and validating with pilot businesses.
More screens · 8
Onboarding — designed in Google Stitch
Industry templates
Payroll formula engine
Monthly settlement
Salary override
Anomaly review queue
Holiday calendar
Audit log
Admin screens designed with Google Stitch (AI design); the Flutter implementation is in progress.
(01) Review
Honest Review
If a developer had built it
●Strong2
Speed — in 7 days: stack locked, backend migrated, foundations built
Switched Firebase → Supabase and did one full rewrite within the first week, solo.
Documentation — design deeper than a typical spec at this stage
PDPA 90-day retention, 5 anomaly rules, 9 payroll variables, and platform limits written down before coding.
◐On par3
Architecture — clean-architecture layout
data / domain / presentation per feature, repository interfaces, dependency injection.
Readability — clean
Clear comments and naming, no debug prints left behind.
Performance — too early to measure
No real load yet; basics (disposing animations, constant widgets) are in place.
↗Next step (in progress)4
Feature completeness — implementation ~10–15% of the design
Designed deep first; 4 screens run on mock data so far.
Plan → Narrow to 'log in → one full check-in round trip, verified on the server', finish it, then expand.
Security — designed, not yet built
4-layer verification and minimal GPS storage (PDPA) are designed; the server-side checks are being built as part of the core flow.
Plan → Approval and verification move fully to the server before the pilot.
Testing & CI — none yet, remote repo pending
Payroll formulas move money, yet have no tests.
Plan → Payroll-formula tests first, then a private remote repo and CI.
Localization & accessibility — Thai-first design, no translation files yet
31 hard-coded English strings and no screen-reader labels.
Plan → Add translation files and labels screen by screen, not at launch.
