Sofetch
Sofetch は、Armenia で customers、technicians、rentable salon space をつなぐ beauty-services marketplace でした。
元のストーリーを見るプロダクト概要
何だったか
Sofetch は beauty customers、technicians、rentable salon space を one marketplace で match する構想でした。
誰のためか
課題 / 価値
beauty services を book しやすくし、technicians と salon owners が space をより効率よく使えるようにすること。
中核ワークフロー
customer が beauty service を book し、technician が提供し、salon or space capacity が platform を通じて coordinated される workflow でした。
中核依存
marketplace の両側が local payment、tax、offline-service constraints の中で repeat transactions する必要がありました。
プロダクト形態
価格モデル
planned model には customer bookings の flat transaction fees と stylists booking spaces 向け payment tiers が含まれていました。product が launch しなかったため revenue には到達していません。
競合または代替手段
何が起きたか
概要
Sofetch は Armenia の beauty-services marketplace でしたが、launch 前に closed しました。
結果
Sofetch は launch せず、no revenue で、grant と about $10,000 personal funds を spent しました。
中核リスク
marketplace app が transaction と local operating constraints の証明前に built されました。
終了理由
COVID が main shutdown trigger でしたが、founder は custom development 前の prototype testing 不足も指摘しました。
需要シグナル
source には stylists、salon owners、customers、influencers との positive conversations が示されていますが、COVID が market を変える前に Sofetch は launch も transactions も記録していませんでした。
集客上の問題
launch は Armenian beauty influencers と local service behavior に依存していました。一方で payment processing、tax handling、cash habits、COVID restrictions が transaction flow を fragile にしました。
タイムライン
- salon scheduling と space-utilization problems を観察して idea が formed されました
- team は early に engineer を hire しました
- legal、payment、tax constraints に取り組みました
- $25,000 Neruzh innovation grant を won しました
- Armenian beauty influencers と launch を prepared しました
- COVID が in-person beauty services を disrupted しました
- repeated pivots がうまくいかず closed しました
作る前に確認すること
なぜ重要か
beauty-service marketplaces は local habits、payment rails、taxes、offline capacity、both-sided commitment に依存します。positive feedback は marketplace liquidity を証明しません。
主な確認事項
custom marketplace app に資金を使う前に、real two-sided transactions、local payment constraints、offline service resilience を検証してください。
チェックリスト
- 10 paid bookings を manually run できるか。
- technicians と space providers は founder intervention なしに workflow を repeat できるか。
- target market で payments と taxes が機能するか。
- temporary offline-service slowdown に model は耐えられるか。
- custom software なしで real bookings は何件起きたか。
- customers、providers、space owners が同じ transaction から benefit を得るか。
- payment、taxes、refunds、cancellations は誰が handling するか。
- in-person demand または capacity が急に変わったらどうなるか。
参考になる場合
- local services marketplace を作っている。
- customers と providers が offline で coordinate する必要がある。
- market に local payment、tax、cash-behavior constraints がある。
参考になりにくい場合
- offline fulfillment のない single-sided software である。
- build 前に repeated paid transactions がすでにある。
開発前テスト
- small group of technicians and salon spaces で concierge bookings を run する。
- marketplace app を build する前に payment を collect する。
- developers を hire する前に failed booking reasons をすべて document する。
応用できる学び
- marketplace behavior を manual または no-code で先に prototype する。
- compliments ではなく completed transactions で両側を validate する。
- workflow を設計する前に local payment と tax constraints を test する。
- in-person services に依存する product では external shocks を想定する。
今作るなら
まず few technicians and spaces で no-code または concierge bookings を使い、real paid transactions を collect してください。両側が workflow を repeat してから custom software を build してください。