เมื่อหนึ่งผลิตภัณฑ์กลายเป็นสอง: วิธีแยกแอปที่สร้างด้วย AI โดยไม่ต้องเริ่มใหม่

คุณเริ่มจากไอเดียเดียว คุณอธิบายมันให้ตัวสร้างแอป AI ของคุณฟัง เฝ้าดูมันสร้างหน้าจอ ปรับขอบที่ยังหยาบๆ แล้วปล่อยอะไรที่จริงออกมา ผู้คนเริ่มใช้มัน แล้วก็ค่อยๆ มีรูปแบบหนึ่งปรากฏขึ้นในฟีดแบ็ก: ผู้ใช้ของคุณครึ่งหนึ่งอยากได้อย่างหนึ่ง อีกครึ่งอยากได้อีกอย่าง พวกเขาไม่ได้แย่งฟีเจอร์เดียวกัน พวกเขากำลังขอผลิตภัณฑ์สองอย่างที่ต่างกัน

นี่คือช่วงเวลาที่ผู้ก่อตั้งหลายคนตื่นตระหนกและเริ่มโปรเจกต์ที่สองจากศูนย์ พวกเขาไม่ควรทำ มีวิธีที่หมดจดกว่าในการแยกแอป AI เมื่อผลิตภัณฑ์เดียวของคุณกลายเป็นสอง — และโดยปกติมันจะเก็บสิ่งที่คุณสร้างไว้แล้วไว้ส่วนใหญ่ บทความนี้เกี่ยวกับวิธีสังเกตการแยก ว่าจะแยกเมื่อไหร่ และสามรูปแบบที่การแยกมักจะออกมา

คุณรู้ได้อย่างไรว่าคุณมีสองผลิตภัณฑ์

สัญญาณแทบไม่เคยดูเหมือนคำขอฟีเจอร์ มันดูเหมือนแรงเสียดทาน

แอปเพิ่มประสิทธิภาพการทำงานตัวหนึ่งที่ผมเฝ้าดูมันผ่านเรื่องนี้มามีเรื่องราวที่ชัดเจน มันถูกขายในฐานะ “ตัวจัดตารางส่วนตัว” ผู้ใช้เริ่มปรากฏตัวในสองแบบ กลุ่มหนึ่งใช้มันจัดตารางสัปดาห์ของตัวเองและปฏิบัติกับมันเหมือนสมุดโน้ตส่วนตัว อีกกลุ่มหนึ่งบริหารทีมเล็กๆ และอยากมอบหมายงานให้คนอื่น ทั้งสองกลุ่มมีความสุขพอที่จะใช้ผลิตภัณฑ์เดียวกันต่อไป แต่ทุกครั้งที่ปล่อยอัปเดต กลุ่มหนึ่งพอใจ อีกกลุ่มหนึ่งรำคาญ ทีมงานคิดว่าพวกเขามีปัญหาเรื่องการจัดลำดับความสำคัญของฟีเจอร์ แต่จริงๆ แล้วพวกเขามีปัญหาเรื่องแบรนด์ พวกเขามีแอปส่วนตัวและแอปสำหรับทีมที่ใช้โค้ดเบสเดียวกัน หน้าแรกเดียวกัน และหน้าราคาเดียวกัน

คุณจะรู้ว่าคุณข้ามเส้นนั้นมาแล้วเมื่อหนึ่งในข้อต่อไปนี้เริ่มเป็นจริง:

• แลนดิงเพจของคุณต้องซ่อนพิตช์ที่แท้จริงของมันไว้หลังภาษากลางๆ เพราะผู้ชมสองกลุ่มจะไม่เชื่อคำพูดเดียวกัน
• ทุกฟีเจอร์ใหม่มีข้อแม้ว่า “แต่สำหรับผู้ใช้อีกประเภทหนึ่ง มันควรทำงานต่างออกไป”
• การตอบซัพพอร์ตของคุณเริ่มแตกแขนง: “ถ้าคุณใช้มันเพื่อตัวเอง…” กับ “ถ้าคุณกำลังบริหารทีม…”
• ผู้ใช้จำนวนไม่น้อยมีบัญชีแยกกันสองบัญชีเพื่อให้สองโหมดแยกกัน

ถ้าคุณกำลังเห็นสองข้อขึ้นไปจากนี้ คุณไม่ได้มีปัญหาเรื่องฟีเจอร์ คุณมีการแยกผลิตภัณฑ์ที่รอจะเกิดขึ้น

สามรูปแบบของการแยก

คุณไม่ต้องเลือกรูปแบบตั้งแต่วันแรก โดยปกติคุณลองรูปแบบที่เบาที่สุดก่อนแล้วค่อยยกระดับได้ แต่มันมีประโยชน์ที่จะรู้เมนูก่อนที่คุณจะเริ่มอธิบายมันให้ตัวสร้างแอป AI ของคุณฟัง เพราะคำที่คุณใช้จะกำหนดสิ่งที่ถูกสร้างขึ้นมา

รูปแบบที่ 1: หนึ่งแอป สองประตู

เวอร์ชันที่เบาที่สุด คุณเก็บโค้ดเบสเดียวไว้ คุณเพิ่มคำถามตอนเปิดใช้ครั้งแรก — “คุณมาที่นี่เพื่อตัวเองหรือเพื่อทีม?” — แล้วใช้คำตอบเพื่อแสดงชุดหน้าและเมนูนำทางที่ต่างกัน ที่เก็บข้อมูลเดียวกัน ล็อกอินเดียวกัน การเรียกเก็บเงินเดียวกัน แค่พื้นผิวต่างกัน

ตัวสร้างแอป AI ส่วนใหญ่จัดการเรื่องนี้ได้ดีถ้าคุณอธิบายมันว่าเป็น “แอปสองโหมด” สิ่งที่ต้องระวังคือสองโหมดไม่ควรใช้หน้าจอร่วมกันโดยมีการแสดง-และซ่อนแบบมีเงื่อนไขเต็มไปหมด แบบนั้นจะกลายเป็นแอปที่รกหนึ่งตัวที่แกล้งทำเป็นสอง บอกตัวสร้างว่าสองประตูนั้นแยกกัน — หน้าแรกต่างกัน หน้าตั้งค่าต่างกัน สถานะว่างเปล่าต่างกัน ส่วนหน้าจอไม่กี่หน้าที่ทับซ้อนกันจริงๆ (การตั้งค่าบัญชี การเรียกเก็บเงิน) ใช้ร่วมกันได้

เมื่อใดที่วิธีนี้ใช้ได้: เมื่อผู้ชมสองกลุ่มอยากได้การจัดวางที่ต่างกัน แต่ใช้อ็อบเจกต์พื้นฐานเดียวกัน ตัวอย่างตัวจัดตารางส่วนตัวกับทีมเข้ากับรูปแบบนี้ สิ่งที่คุณกำลังจัดตารางก็ยังเป็นงาน (task) อยู่ดี แค่กฎเกี่ยวกับการมอบหมาย การแชร์ และการแจ้งเตือนเท่านั้นที่เปลี่ยน

เมื่อใดที่วิธีนี้ใช้ไม่ได้: เมื่อผู้ชมสองกลุ่มคาดหวังอ็อบเจกต์ที่ต่างกันโดยสิ้นเชิง “พอร์ทัลลูกค้า” กับ “เครื่องมือแอดมินภายใน” แทบไม่มีส่วนทับซ้อนกันเลย แม้ว่ามันจะดูเหมือนเกี่ยวกับธุรกิจเดียวกัน

รูปแบบที่ 2: สองแอป หนึ่งแบ็กเอนด์

รูปแบบกลาง คุณแยกส่วนหน้าของผลิตภัณฑ์ออกเป็นสองแอปแยกกัน — สอง URL สองแลนดิงเพจ สองโฟลว์ออนบอร์ดดิง สองตารางราคา — แต่ทั้งคู่อ่านจากฐานข้อมูลเดียวกันด้านล่าง ลูกค้ามีบัญชีในทั้งสองได้ แอดมินเห็นข้อมูลจากทั้งสองได้

นี่คือสิ่งที่เราเพิ่งทำที่บริษัทที่ดูแลบล็อกนี้ เรามีแอปหนึ่งตัวที่พยายามให้บริการผู้ชมสองกลุ่ม: วิศวกรที่กำลังประเมินแพลตฟอร์มเอเจนต์ของเรา และนักสร้างที่ใช้ตัวสร้างแอป AI ของเรา แบ็กเอนด์เดียวกัน auth เดียวกัน ฐานข้อมูลเดียวกัน — แต่ส่วนหน้ามันงอกออกมาสองหัว และข้อความก็สับสน เราแยกมันออกเป็นสองแอปฝั่งหน้า หนึ่งตัวสำหรับผู้ชมแต่ละกลุ่ม แบ็กเอนด์ยังคงเหมือนเดิมเป๊ะ

รูปแบบนี้คือคำตอบที่ถูกต้องเมื่อ:

• ผู้ชมสองกลุ่มซื้อด้วยเหตุผลที่ต่างกัน
• พวกเขาจะสับสนหรือเบือนหน้าหนีเมื่อเจอข้อความการตลาดของผู้ชมอีกกลุ่มหนึ่ง
• ข้อมูลที่พวกเขาสนใจมีรูปร่างคล้ายกันเป็นส่วนใหญ่ แต่ถูกจัดวางต่างกัน
• คุณไม่อยากดูแลฐานข้อมูลสองชุดหรือการตั้งค่าการเรียกเก็บเงินสองชุด

บอกตัวสร้างแอป AI ของคุณว่าคุณต้องการ “แอปฝั่งหน้าตัวที่สองที่ใช้ API ที่มีอยู่ร่วมกัน” ตัวสร้าง AI สมัยใหม่ส่วนใหญ่สามารถวางโครงโปรเจกต์พี่น้องและชี้มันไปยังแบ็กเอนด์ที่มีอยู่ของคุณได้ กับดักที่ต้องหลีกเลี่ยง: การก๊อปปี้แปะคอมโพเนนต์ของแอปแรกแบบเป๊ะๆ แล้วต้องมาแก้ทั้งสองชุดไปตลอดกาล ขอให้ตัวสร้างดึงส่วนที่ใช้ร่วมกัน (หน้าจอ auth วิดเจ็ตฟอร์มทั่วไป) ออกมาเป็นไลบรารีเล็กๆ ที่ทั้งสองแอปใช้ คุณจะประหยัดเวลาแก้ของซ้ำซ้อนไปได้หลายเดือนในภายหลัง

รูปแบบที่ 3: สองแอป สองแบ็กเอนด์

การแยกที่หนักที่สุด จริงๆ แล้วคุณมีสองผลิตภัณฑ์ พวกมันไม่ใช้ข้อมูลร่วมกัน ไม่ใช้ผู้ใช้ร่วมกัน และไม่ควรใช้แผนงาน (roadmap) ร่วมกัน ทางออกที่ถูกต้องคือการแยกพวกมันออกจากกันโดยสิ้นเชิง: คนละโค้ดเบส คนละฐานข้อมูล คนละโดเมน

นี่คือทางออกที่ถูกต้องน้อยกว่าที่ผู้คนคิด มันน่าดึงดูดเพราะดูหมดจดดี แต่ความเป็นจริงคือ สองแอปที่แยกกันโดยสิ้นเชิงหมายถึงต้องมีทุกอย่างเป็นสองชุดเพื่อให้ทั้งคู่ทำงานต่อไป — สองไปป์ไลน์การดีพลอย สองรอบเวรเฝ้าระวัง สองระบบเชื่อมต่อการเรียกเก็บเงิน สองชุดเอกสารช่วยเหลือ อย่าเอื้อมไปหารูปแบบนี้เว้นแต่ผลิตภัณฑ์จะไม่ทับซ้อนกันจริงๆ บททดสอบที่ดี: ถ้าผู้ใช้ของผลิตภัณฑ์ A ไม่มีทางเป็นผู้ใช้ของผลิตภัณฑ์ B เลย คุณก็น่าจะต้องใช้รูปแบบที่ 3 ถ้าผู้ใช้ส่วนใหญ่ของคุณอาจอยากได้ทั้งสองอย่าง คุณก็แทบจะแน่ใจได้เลยว่าต้องการรูปแบบที่ 2

เมื่อคุณทำสิ่งนี้กับตัวสร้าง AI ทางที่ง่ายที่สุดคือก๊อปปี้โปรเจกต์ที่มีอยู่เป็นจุดเริ่มต้นสำหรับตัวที่สอง แล้วขอให้ตัวสร้างเอาฟีเจอร์ที่ไม่เกี่ยวออก และเพิ่มฟีเจอร์ที่เกี่ยวเข้าไป อย่าเริ่มโปรเจกต์ที่สองจากหน้ากระดาษเปล่า คุณได้เรียนรู้อะไรมากมายตอนสร้างตัวแรก และตัวสร้าง AI จะเก็บบริบทนั้นไปใช้ถ้าคุณยอมให้มันทำ

สิ่งที่ต้องทำก่อนแยกอะไรก็ตาม

ก่อนที่คุณจะอธิบายการแยกให้ตัวสร้างแอป AI ของคุณฟัง ทำสามสิ่งเล็กๆ มันมีค่ามากกว่าที่ฟังดู

อย่างแรก เขียนหน้าแรกใหม่สำหรับแต่ละฝั่ง สองย่อหน้าต่อฝั่ง พิตช์ ผู้ชม และสิ่งหนึ่งอย่างที่คุณอยากให้พวกเขาทำ ถ้าคุณเขียนหน้าแรกสองหน้าที่ต่างกันไม่ได้ แสดงว่าคุณยังไม่มีสองผลิตภัณฑ์จริงๆ — คุณแค่มีสองกลุ่มของผลิตภัณฑ์เดียว และคุณควรแก้มันด้วยข้อความ ไม่ใช่ด้วยสถาปัตยกรรม

อย่างที่สอง ทำรายการว่าหน้าจอไหนใช้ร่วมกันและหน้าจอไหนไม่ใช้ ซื่อสัตย์เข้าไว้ “ล็อกอินใช้ร่วมกัน ออนบอร์ดดิงต่างกัน แดชบอร์ดต่างกัน การตั้งค่าใช้ร่วมกันเป็นส่วนใหญ่ การเรียกเก็บเงินใช้ร่วมกัน” รายการนี้จะกลายเป็นบรีฟที่คุณส่งให้ตัวสร้าง AI มันช่วยลดการไปกลับไปมาได้เยอะ

อย่างที่สาม ตัดสินใจว่าอะไรเหมือนกันด้านล่าง ผู้ใช้เดียวกันไหม? ข้อมูลเดียวกันไหม? การชำระเงินเดียวกันไหม? ทุก “ใช่” ดึงคุณไปทางรูปแบบที่ 1 หรือ 2 ทุก “ไม่” ดึงคุณไปทางรูปแบบที่ 3 ไม่มีคำตอบที่ถูกต้อง — มีแค่คำตอบที่ตรงกับวิธีที่ผลิตภัณฑ์ของคุณทำงานจริงๆ

อะไรเปลี่ยนไปหลังการแยก

สองสิ่งง่ายขึ้น และหนึ่งสิ่งยากขึ้น

การตลาดง่ายขึ้น แต่ละแอปได้พิตช์ที่ชัดเจนของตัวเอง แต่ละแลนดิงเพจพูดกับผู้ชมหนึ่งกลุ่มได้โดยไม่ต้องอ้อมค้อม อัตราการแปลงของคุณมักจะสูงขึ้นอย่างน้อยหนึ่งฝั่ง บางทีก็ทั้งสองฝั่ง

ออนบอร์ดดิงง่ายขึ้น ผู้ใช้ครั้งแรกมาเจอหน้าที่เกี่ยวกับพวกเขา ไม่ใช่หน้าที่พยายามจะเกี่ยวกับทุกคน

สิ่งที่ยากขึ้นคือการรักษาส่วนที่ใช้ร่วมกันให้ตรงกัน ถ้าคุณแก้บั๊กในโฟลว์ล็อกอิน คุณอยากให้มันถูกแก้ในทั้งสองแอป ถ้าคุณเปลี่ยนหน้าตาของหน้าจอการเรียกเก็บเงิน คุณอยากให้ทั้งสองแอปสะท้อนมัน วินัยที่คุณต้องมี — และเรื่องนี้จริงไม่ว่าคุณจะ vibe coding ด้วยตัวสร้าง AI หรือสร้างด้วยทีมนักพัฒนาที่เป็นมนุษย์ — คือการรักษาส่วนที่ใช้ร่วมกันให้ใช้ร่วมกันจริงๆ อย่าทำซ้ำ อย่าฟอร์ก ไม่ก็ดึงหน้าจอที่ใช้ร่วมกันออกมาเป็นไลบรารีเล็กๆ ที่ทั้งสองแอปใช้ ไม่ก็ยอมรับว่าคุณมีสองแอปที่แยกกันจริงๆ แล้วรับผิดชอบมัน

คำถามเล็กๆ ทิ้งท้าย

ถ้าคุณเอาพิตช์ของแอปปัจจุบันของคุณไปให้คนแปลกหน้าห้าคนฟัง แล้วแต่ละคนอธิบายมันต่างกัน — แต่อยู่ในสองกลุ่มที่ชัดเจน — คุณก็น่าจะกำลังอยู่กับการแยกอยู่แล้ว คำถามเดียวคือ คุณจะจ่ายค่าภาษีของการมีผลิตภัณฑ์เดียวที่สับสนต่อไป หรือลงมือทำงานเพื่อซื่อสัตย์กับการเป็นสอง

คุณไม่ต้องตัดสินใจวันนี้ แต่ครั้งหน้าที่ตัวสร้างแอป AI ของคุณถามว่า “ฉันควรสร้างอะไรต่อไป?” ลองพิจารณาว่าคำตอบที่มีประโยชน์ที่สุดอาจไม่ใช่ฟีเจอร์ใหม่ มันอาจเป็นประตูหน้าบานใหม่

ถ้าเรื่องนี้โดนใจคุณ คุณอาจชอบบทความก่อนหน้าของเราเกี่ยวกับ การสร้างเพื่อทีมของคุณ กับ การสร้างเพื่อลูกค้า — การตัดสินใจแบบเดียวกัน แต่อยู่ก่อนหน้านี้หนึ่งก้าวในช่วงชีวิตของผลิตภัณฑ์คุณ