Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スモールスタートのための技術スタック検討
Search
Kawakami Natsumi
November 15, 2022
0
280
スモールスタートのための技術スタック検討
Kawakami Natsumi
November 15, 2022
Tweet
Share
More Decks by Kawakami Natsumi
See All by Kawakami Natsumi
個人開発サービスを使ってもらうための技術選定
natsumican63
1
1.3k
個人開発を加速させる効率アップ戦術
natsumican63
19
11k
がんばらない個人開発
natsumican63
1
1.3k
GraphQL with Apollo Client
natsumican63
0
460
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Git: the NoSQL Database
bkeepers
PRO
427
65k
For a Future-Friendly Web
brad_frost
176
9.6k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
30
4.6k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Thoughts on Productivity
jonyablonski
69
4.5k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
The Cult of Friendly URLs
andyhume
78
6.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Optimizing for Happiness
mojombo
376
70k
Transcript
スモールスタートのための技術スタック検討 川上 奈津美 2022/09/27 arcana meetup
自己紹介 • Kawakami Natsumi(@natsumican63) • モバイルアプリとWeb開発をやっています • 近況 ◦ 子供を寝かしつけた後よなよな個人開発中
◦ 休みの日は朝8:00から踏切の前で体育座り
スタートアップが失敗する理由ランキング 1位 市場ニーズがなかった (42%) 2位 資金の枯渇 (29%) 3位 適切でないチーム構成 (23%)
引用:スタートアップが失敗する理由トップ 20
プロダクトアウトとマーケットイン • プロダクトアウト ◦ 会社の方針や作りたいもの、作れるものを基準にプロダクト開発を行うこと。作ってからどうやって 売るか考える • マーケットイン ◦ ユーザーのニーズに基づいてプロダクト開発を行うこと。ユーザーの意見を取り入れながらプロダク
トを作る
まずはMVPを作って顧客の反応を確かめよう MVP (Minimal Viable Product — 最低限の価値を提供する製品)を作り、最速で顧客 に届ける。
どのような技術スタックを選べばいいか? • 慣れ親しんだ技術 ◦ アルカナにおけるLaravelとか ◦ ※リッチなUXやモバイルアプリ対応がマストでなければ • 低コスト・低実装で済む技術 今回は、モバイル優先とWeb優先の視点で
2つの技術スタックを紹介します
モバイル優先: Firebase + React Native Firebase • DB、認証、ストレージなどバックエンド開発に必要な技術スタック全部入なので最 小限の実装コストですむ •
FirestoreのセキュリティールールとCloud Functionsを組み合わせてロールベース なアクセス制限やバリデーションを書いていく ◦ テストコードもかけるよ • ロジックは基本的にクライアント側が持つ • Firestoreの設計がむずかしい ◦ RDB脳にNoSQLはつらい ◦ スキーマレスで型定義がない。 get()すると全データ`{[key: string]: any}`
React Native • ストア審査を通さずにアプリを更新できるOTAアップデート機能 • hooksでロジックを切り出せばWeb版へ資産を流用できる • Flutterの方がトレンドではあるが、OTAがあまりにも強力すぎる(と思う
Web優先:Next.js on CloudRun + PlanetScale • Next.jsのAPI Routes機能とPrismaでAPIも構築 • DBはPlanetScale
◦ 無料枠のあるMySQLマネージドサービス
Web優先:Next.js on CloudRun + PlanetScale デプロイ先 • Vercelは(商用の場合)最低でも$20 /1ユーザーあたり月額はかかってしまう •
CloudRunの無料枠+従量課金制がよさそう
まとめ:「はやい・やすい・ちいさい」ではじめよう • はやい ◦ 顧客の声を素早く反映できる • やすい ◦ 低コストに運用できるサービスを選ぶ •
ちいさい ◦ 意思決定に対し機動的に対処できる小さなチームを保つ
ありがとうございました