Project 3: Internal Dashboard ขนาดเล็ก | Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ | Vibe Coding Thailand$ cat 08-project-internal-dashboard.md บทที่ 8Project 3: Internal Dashboard ขนาดเล็ก
แก่นของบทนี้
Dashboard เป็น optional เพราะ access control สำคัญกว่า UI
ถ้าตอบไม่ได้ว่าใคร login ได้และเห็นข้อมูลอะไรได้ ให้ยังไม่ deploy dashboard public
หลังจากมี waitlist form แล้ว คำถามต่อไปคือ:
เราจะดู lead ที่เข้ามาได้ยังไง
คำตอบที่น่าทำคือ internal dashboard
แต่คำตอบที่อันตรายคือทำ dashboard ใหญ่เกินไปเร็วเกินไป
บทนี้เราจะสร้าง dashboard ขนาดเล็กที่เน้น ดูข้อมูลและจัดการเบื้องต้น เท่านั้น
ไม่ใช่ระบบ CRM เต็มรูปแบบ
ไม่ใช่ admin panel ครอบจักรวาล
เป้าหมายคือ:
ดู lead
ค้นหา/กรองเบื้องต้น
อัปเดตสถานะง่าย ๆ
ไม่เปิดข้อมูลให้คนที่ไม่ควรเห็น
นี่เป็นจุดที่ต้องคิดเรื่อง access และ permission จริงจังขึ้น
เพราะ dashboard คือหน้าที่แสดงข้อมูลที่ user กรอกเข้ามา
บทนี้เป็น optional / bonus project ไม่ใช่ทางบังคับของหนังสือ ถ้าคุณยังไม่มั่นใจเรื่อง login, permission, RLS หรือ secret key ให้ข้ามบทนี้ชั่วคราว แล้วใช้ Supabase dashboard ดูข้อมูลไปก่อน
กฎตัดสินใจง่าย ๆ:
Landing page public ได้ง่ายกว่า
Waitlist form public ได้ถ้า RLS ถูก
Internal dashboard ห้าม public ถ้ายังไม่มั่นใจเรื่อง access control
ทำไม internal dashboard ถึงน่าทำ
Internal tool เป็น use case ที่ดีมากสำหรับ non-coder
เพราะมันแก้ปัญหาใกล้ตัว เช่น:
- ดู lead ที่เข้ามา
- จัดลำดับคนที่ควร follow-up
- track status ว่าติดต่อแล้วหรือยัง
- ดูปัญหาที่ลูกค้าสนใจซ้ำ ๆ
- export insight ไปวางแผน content หรือ sales
internal ไม่ได้แปลว่าปลอดภัยโดยอัตโนมัติ
ถ้า URL หลุด หรือ permission เปิดผิด คนอื่นอาจเห็นข้อมูล lead ได้
ดังนั้น dashboard แรกต้องเล็กและถูกจำกัดการเข้าถึง
Project ที่เราจะสร้าง
เราจะต่อยอดจาก table waitlist_submissions
- หน้า
/admin หรือ /dashboard
- list รายการ lead
- field ที่แสดงเท่าที่จำเป็น
- search/filter ง่าย ๆ
- status เช่น
new, contacted, qualified, not_fit
- manual refresh หรือ reload ได้
- role หลายระดับ
- team management
- audit log เต็มระบบ
- CRM sync
- bulk action
- email automation
- delete lead ผ่าน dashboard
- public sharing
ถ้า version แรกยังไม่มี login ที่แข็งแรงพอ ให้ dashboard นี้ยังไม่ควร deploy public
หรือควรจำกัดด้วยวิธีอื่นที่คุณเข้าใจและตรวจได้
Spec สำหรับ Dashboard version แรก
# Spec: Waitlist Internal Dashboard v1
## Goal
สร้าง internal dashboard สำหรับดู waitlist submissions และติดตามสถานะ follow-up เบื้องต้น
## Target user
เจ้าของ project หรือทีมเล็ก ๆ ที่ต้อง follow-up lead
## Version 1 scope
- แสดงรายการ waitlist submissions
- แสดง name, email, company, main_problem, status, created_at
- ค้นหาด้วย email/company/main_problem ได้แบบง่าย
- เปลี่ยน status ได้
- แสดง empty state และ error state
## Out of scope
- No public access
- No multi-role permission
- No bulk delete
- No CRM integration
- No email automation
- No payment
- No file upload
## Data fields
Existing:
- name
- email
- company
- main_problem
- created_at
New:
- status: new/contacted/qualified/not_fit
- notes: optional internal note
## Acceptance criteria
- Dashboard ไม่ควรเปิดให้ public user เห็นข้อมูล lead
- แสดงรายการ lead ได้ถูกต้อง
- Search/filter ใช้ได้เบื้องต้น
- เปลี่ยน status ได้
- ไม่แสดง secret หรือ key ใน browser
- มี manual test plan ก่อน deploy
- Claude อธิบาย permission/RLS ที่เกี่ยวข้องเป็นภาษาคน
สังเกตว่า acceptance criteria ข้อแรกคือเรื่อง access
เพราะ dashboard ที่ทำงานได้แต่เปิดให้คนทั้งโลกเห็นข้อมูล คือความล้มเหลว ไม่ใช่ความสำเร็จ
Authentication vs Authorization แบบง่าย
Supabase docs แยกสองคำนี้ชัด:
Authentication = คนนี้คือใคร
Authorization = คนนี้มีสิทธิ์ทำอะไร
Authentication: คุณ login แล้ว เป็น [email protected]
Authorization: คุณมีสิทธิ์ดู dashboard นี้ไหม
เขาคิดว่า “มี login แล้ว” แปลว่าปลอดภัย
login แล้วเห็นข้อมูลอะไรได้บ้าง
ใคร update status ได้
ใคร delete ได้
ถ้าไม่ login จะเห็นอะไรไหม
สำหรับ dashboard แรก ให้ทำสิทธิ์ให้น้อยที่สุด
ถ้ายังไม่แน่ใจเรื่อง auth/permission ให้ทำ dashboard สำหรับ local-only หรือยังไม่ deploy public
อย่าใช้ service role key ใน browser
Dashboard มักทำให้คนเผลอใช้ key สิทธิ์สูง
เพราะอยากอ่านข้อมูลทั้งหมดง่าย ๆ
กฎเดิมยังใช้เหมือนบทที่แล้ว:
secret key / service role key ห้ามอยู่ใน browser
ถ้าคุณต้องอ่านข้อมูล lead ทั้งหมด ต้องมีวิธีที่ปลอดภัยกว่า เช่น server-side route, auth, หรือ policy ที่จำกัดเฉพาะ user ที่ควรเห็น
สำหรับ non-coder ถ้า Claude เสนอให้ใส่ service role key ใน frontend ให้หยุดทันที
วิธีนี้ใช้ secret หรือ service role key ใน browser ไหม
ถ้าใช่ ห้ามทำ
ช่วยเสนอวิธีที่ปลอดภัยกว่า และอธิบายเป็นภาษาคน
RLS สำหรับ dashboard ต้องคิดใหม่
Permission table ก่อนสร้าง dashboardก่อนเขียน policy ให้ทำตาราง permission ว่า public, authenticated และ admin ทำอะไรได้บ้าง
ในบท waitlist เราอยากให้ public user insert ได้ แต่ไม่อ่านข้อมูลทั้งหมดได้
สำหรับ dashboard เราต้องมีผู้ใช้บางคนอ่านข้อมูลได้
ดังนั้น policy ต้องชัดกว่าเดิม
ใครคือ admin
admin login ยังไง
admin อ่าน rows ทั้งหมดได้ไหม
admin update status ได้ไหม
public user อ่านอะไรได้ไหม
public user update อะไรได้ไหม
ถ้าคุณตอบไม่ได้ อย่าเพิ่ง deploy dashboard public
ให้ Claude ช่วยแปล permission เป็นตารางก่อน
ช่วยทำ permission table สำหรับ dashboard นี้
แถวคือ role: public, authenticated user, admin
คอลัมน์คือ select, insert, update, delete
ใส่ allowed/denied และอธิบายเหตุผลแบบ non-coder
อย่าเพิ่งเขียน SQL
| Role | Select | Insert | Update | Delete |
|---|
| public/anon | deny | allow เฉพาะ form | deny | deny |
| admin | allow | optional | allow status/notes | deny ใน v1 |
ตารางแบบนี้ช่วยให้คุณเข้าใจก่อนเห็น SQL
Step 1: เพิ่ม field ให้น้อยที่สุด
Dashboard version แรกอาจต้องเพิ่มแค่ 2 field:
อย่าเพิ่ม field เยอะตั้งแต่แรก
lead_score
owner
utm_source
last_contacted_at
deal_value
pipeline_stage
บางอย่างมีประโยชน์ แต่ยังไม่จำเป็น
status = ตอนนี้ lead อยู่สถานะไหน
notes = ข้อความสั้น ๆ สำหรับทีม
ช่วยเสนอ migration หรือ SQL สำหรับเพิ่ม field status และ notes ใน waitlist_submissions
กติกา:
- อย่าเพิ่งรัน SQL
- status ควรมี default เป็น new
- notes เป็น optional
- อธิบายว่าการเปลี่ยนนี้กระทบข้อมูลเดิมไหม
- เสนอ manual test หลังเปลี่ยน schema
Step 2: ออกแบบ dashboard UI แบบเรียบง่าย
Dashboard v1 ควรเล็กและอ่านง่ายdashboard แรกควรเน้นดู lead, search/filter และ update status เท่านั้น ยังไม่ต้องมี bulk/export/delete
Dashboard แรกไม่ต้องสวยมาก
- title ชัด ๆ
- จำนวน lead ทั้งหมด
- filter/search
- table หรือ card list
- status badge
- ปุ่มเปลี่ยน status
- empty state
- error state
- chart เยอะ ๆ
- animation หนัก ๆ
- export public link
- delete button ถ้ายังไม่จำเป็น
- bulk action ถ้ายังไม่เข้าใจ risk
ช่วยออกแบบ dashboard UI สำหรับ waitlist submissions v1
เน้นเรียบง่าย ใช้ได้จริง ไม่ต้องสวยอลังการ
ต้องมี:
- list/table ของ lead
- search/filter เบื้องต้น
- status badge
- เปลี่ยน status ได้
- empty state
- error state
ยังไม่ต้องมี:
- chart
- export
- delete
- bulk action
- CRM integration
อย่าเพิ่งแก้ไฟล์ ให้เสนอ layout และ user flow ก่อน
Step 3: ให้ Claude build แบบถามก่อนเรื่อง auth/permission
ก่อน build dashboard ต้องมี rule ชัด:
ถ้าเกี่ยวกับ auth, RLS, secret, service role, env ต้องถามก่อน
ฉันต้องการสร้าง internal dashboard v1 จาก spec นี้:
[paste spec]
กติกา:
- อย่าใช้ service role/secret key ใน browser
- ถ้าต้องแก้ RLS policy ให้เสนอและอธิบายก่อน อย่ารันเอง
- ถ้าต้องเพิ่ม auth ให้เสนอทางเลือกก่อน
- ห้ามเพิ่ม delete/bulk action/export ใน v1
- ก่อนแก้ไฟล์ ให้เสนอ implementation plan
- หลังแก้ไฟล์ ให้สรุป diff, permission assumptions, และ manual test plan
ถ้า Claude บอกว่า “ทำได้ง่าย ๆ ด้วย service role key ใน frontend” ให้หยุด
นั่นไม่ใช่ง่าย นั่นคือเสี่ยง
Step 4: Manual QA สำหรับ dashboard
Dashboard ต้อง test มากกว่า landing page
เพราะมีข้อมูลจริงและ permission
ให้ Claude ช่วยสร้าง test plan:
ช่วยสร้าง manual QA checklist สำหรับ internal dashboard นี้
แยกเป็น:
1. access control
2. data display
3. search/filter
4. status update
5. error/empty states
6. security checks
7. production checks
Step 5: อย่าลืม ownership
Owner note กัน internal tool ถูกลืมinternal tool ต้องมี owner, purpose, access rule และ review cadence ไม่อย่างนั้นจะกลายเป็นของที่ไม่มีใครดูแล
OWASP พูดถึง asset management failure ใน citizen development: app ที่สร้างง่ายอาจถูกลืม ถูกทิ้ง หรือไม่มีเจ้าของดูแล
Internal dashboard เป็นตัวอย่างที่เจอได้ง่าย
คุณสร้างไว้ใช้เอง
ทีมเริ่มใช้
เวลาผ่านไปทุกคนพึ่งมัน
แต่ไม่มีใครเป็นเจ้าของ
ไม่มีใครดู dependency
ไม่มีใครรู้ว่าปิดได้ไหม
ดังนั้นทุก internal tool ควรมี owner note
# Owner Note
## Tool name
Waitlist Internal Dashboard
## Owner
[ชื่อ/ทีม]
## Purpose
ดูและ follow-up waitlist submissions
## Data used
- name
- email
- company
- main_problem
- status
- notes
## Access
[ใครเข้าได้]
## If something breaks
[ใครรับผิดชอบ / rollback ยังไง]
## Review cadence
ตรวจทุกเดือนว่า tool นี้ยังใช้ไหม และ access ยังถูกไหม
Step 6: Deploy หรือยังไม่ deploy?
สำหรับ dashboard คำถามนี้สำคัญกว่า landing page
ถ้าคุณตอบคำถาม 3 ข้อนี้ไม่ได้ ให้ยังไม่ deploy:
ใคร login ได้?
คนที่ login แล้วเห็นข้อมูลอะไรได้?
ถ้า link หลุด คนทั่วไปเห็นข้อมูล lead ได้ไหม?
ถ้า dashboard ยังไม่มี auth/access control ที่คุณมั่นใจ อย่า deploy public
- ใช้เฉพาะ local ก่อน
- deploy แต่ป้องกันด้วย auth ที่เข้าใจและ test แล้ว
- ให้ developer ช่วย review ก่อนเปิดใช้จริง
- ยังไม่ทำ dashboard ใช้ Supabase dashboard ดูข้อมูลก่อนชั่วคราว
อย่า deploy เพราะ “AI ทำเสร็จแล้ว”
deploy เพราะคุณตรวจแล้วว่า risk อยู่ในระดับรับได้
Prompt รวมท้ายบท
ใช้ prompt นี้สำหรับ dashboard
ฉันต้องการสร้าง internal dashboard v1 สำหรับ waitlist submissions
Spec:
[paste spec]
กติกา:
- Dashboard ต้องไม่ public โดยไม่มี access control
- ห้ามใช้ service role/secret key ใน browser
- ห้ามเพิ่ม delete, bulk action, export, CRM integration หรือ email automation ใน v1
- ถ้าต้องแก้ RLS/auth/env ให้เสนอและอธิบายก่อน อย่ารันเอง
- ก่อนแก้ไฟล์ ให้เสนอ implementation plan
- หลังแก้ไฟล์ ให้สรุป diff, permission assumptions, และ manual QA checklist
Output ก่อนเริ่ม build:
1. implementation plan
2. files likely to change
3. permission table: public / authenticated / admin
4. risks
5. questions before build
หลัง build ใช้ prompt review:
ช่วย review internal dashboard นี้ก่อน deploy
ตรวจเฉพาะสิ่งสำคัญ:
1. ตรง spec ไหม
2. มี feature เกิน scope ไหม
3. access control ทำงานยังไง อธิบายเป็นภาษาคน
4. public user อ่านข้อมูล lead ได้ไหม
5. มี secret/service role key ใน browser ไหม
6. RLS policy อนุญาตอะไรบ้าง
7. manual QA ที่ต้องทำก่อนเปิดใช้จริงคืออะไร
8. ถ้ายังไม่ควร deploy ให้บอกตรง ๆ ว่าทำไม
อย่าแก้ไฟล์ก่อน รายงานก่อน
สรุป
Internal dashboard มีประโยชน์มาก แต่เสี่ยงกว่า landing page และ waitlist form
เพราะมันแสดงข้อมูลที่ user ส่งมา
- dashboard แรกควรเล็ก
- อย่าเปิดข้อมูล lead ให้ public
- อย่าใช้ service role/secret key ใน browser
- ทำ permission table ก่อนเขียน policy
- มี manual QA เรื่อง access control
- ต้องมี owner note ไม่ให้ tool กลายเป็นของถูกลืม
บทต่อไป เราจะพูดเรื่อง debug แบบ non-coder: เวลา build พัง, deploy fail, form submit ไม่ได้ หรือ dashboard error ต้องเก็บหลักฐานยังไง แล้วให้ Claude Code แก้แบบไม่มั่ว
อัปเดตล่าสุด: 25 พ.ค. 2569
ความคิดเห็น
ยังไม่มีความคิดเห็น
เป็นคนแรกได้เลย