2026年9月15日、ハンドメイド作家さん向けの原価・在庫・売上管理ツール「Linora Works」を正式リリースしました。 もともとは自分のハンドメイド活動で感じていた不便を解消するために作り始めたツールでした。 それが少しずつ形になり、最終的には月額課金のWebサービスとして公開するところまでたどり着きました。 今回は、Linora Worksを作ろうと思ったきっかけから、技術選定、課金・認証まわり、リリース前のテストまで、個人開発の裏側を書いてみます。
実際に使ってみる
Linora Works
この記事が良かったら
さいとうレタス さんへの応援になります
私はWeb開発の仕事をしながら、「Linora」という名前でデニムリメイク作品の制作・販売もしています。
ハンドメイド販売を続けていると、
「この作品の原価はいくら？」
「今、材料はいくつ残っている？」
「このイベント、本当に利益が出ていた？」
「委託販売とイベント販売で価格を変えたい」
といった管理が少しずつ増えていきました。
最初はスプレッドシートなどで管理していましたが、材料・商品・売上・イベントを別々に管理していると、だんだん面倒になってきます。
そこで、
ハンドメイド販売に必要な管理を一つにまとめたツールが欲しい
と思ったのが開発の始まりでした。
当初は、SaaSとして公開する予定はありませんでした。
単純に、自分が使いやすいツールを作ろうと思っていました。
ただ、開発を進めながら調べてみると、ハンドメイド作家さんの多くがExcelやスプレッドシート、手書きなどで管理していることが分かりました。
「もしかして、自分だけの悩みではないのでは？」
と思い始め、途中から一般公開を前提に設計を見直しました。
自分専用ツールなら多少雑でも使えますが、他の人に使ってもらうとなると、認証・課金・退会・データ保護・エラー処理まで考える必要があります。
ここから一気に“個人用アプリ”から“サービス開発”になりました。
Linora Worksでは、主に以下の技術を使っています。
フロントエンドとバックエンドを分けず、Next.jsでまとめて開発できる構成にしました。
個人開発なので、できるだけ「運用するものを増やさない」ことを重視しています。
データベースはPostgreSQLを使い、Neon上で管理。
認証はClerk、決済はStripeに任せています。
全部自前で作るよりも、認証や決済のような重要部分は既存サービスに任せる方が、安全性と開発スピードの両方でメリットが大きいと判断しました。
Linora Worksの中心機能の一つが原価計算です。
一見すると単純ですが、作り始めると意外と複雑でした。
例えば、ある商品に
を使う場合、それぞれの材料単価と使用量から原価を計算します。
ここまでは簡単です。
しかし実際には、
材料価格が途中で変わったらどうするか。
固定費を原価に含める場合、過去の売上まで再計算するのか。
販売後に商品情報を編集したら、過去の利益はどう扱うのか。
といった問題が出てきます。
特に会計系・売上系のツールでは、現在の設定だけを見て再計算すると、過去の数字まで変わってしまいます。
そのため、固定費については履歴を持たせるなど、後から数字が変わらないように設計を調整しました。
「数字が出ればいい」ではなく、
あとから見返しても意味のある数字になっているか
をかなり意識しました。
在庫管理でも悩みました。
例えば在庫3個の商品を、売上登録で5個売ったことにした場合。
そのまま在庫をマイナスにするのか。
売上登録自体を拒否するのか。
警告だけ出すのか。
Linora Worksでは、在庫不足の場合は登録を拒否し、不足している商品と数量を表示するようにしました。
便利機能を増やすよりも、
間違ったデータを作らせない
ことを優先しています。
こうした細かい挙動は、実際に自分がイベント販売をしているからこそ想像しやすかった部分でもあります。
認証にはClerkを採用しました。
ログイン、アカウント作成、セッション管理などを自前実装せずに済むのは、個人開発ではかなり助かります。
一方で、実際にサービスとして公開すると、
ログイン後の遷移先
アカウント削除
退会後の扱い
Stripeとのユーザー紐付け
など、アプリ側で考えることも多くありました。
特に退会処理は、
「アカウントを消した瞬間に全部削除していいのか？」
という問題があります。
Linora Worksでは、Stripeの契約状態とアプリのユーザー状態を連携させ、退会後もしばらくデータを保持する形にしました。
料金は月額900円です。
最初の31日間は無料で利用できます。
決済にはStripeを使っています。
課金サービスを作る上では、
Checkout
Customer Portal
Webhook
契約開始
解約
支払い失敗
サブスクリプション状態
などを一通り考える必要がありました。
特にWebhookは重要でした。
Stripe上で契約状態が変わったときに、アプリ側のDBにも正しく反映しなければいけません。
テスト環境では動いていても、本番用のSecretやPrice ID、Webhook Secretが正しく設定されているかなど、リリース直前まで何度も確認しました。
個人的には、UIを作っているときよりも、決済まわりを触っているときの方が「本当にサービスを作っている感」が強かったです。
開発途中から、develop / staging / mainを分けて運用するようにしました。
個人開発だと最初は
「mainに直接入れてもいいかな」
と思いがちですが、課金やDBマイグレーションが絡み始めると、かなり怖くなります。
特にPrismaのmigrationは、
どの環境で実行されるのか
本番DBに誤って適用されないか
Vercelのビルド時にどう実行するか
を整理しました。
正式リリース前には、staging環境で一通り確認してからmainへ反映する流れにしました。
このあたりは、開発そのものより運用設計の勉強になりました。
自分で作ったアプリは、自分ではなかなか壊せません。
「ここを押したらこうなる」と知っているので、無意識に正しい操作をしてしまうからです。
そこでリリース前に、外部のテスターさんへ総合テストを依頼しました。
テストケースは最終的に150〜200程度。
材料登録、商品登録、在庫、売上、イベント、決済など、主要機能を一通り確認してもらいました。
幸い重大なバグは見つかりませんでしたが、
自分では気づかなかったUI上の違和感や細かな挙動を修正できました。
個人開発でも、お金を取るサービスとして公開するなら、第三者テストはやって良かったと思っています。
「よし、完成した」
と思っても、最後まで何か出ます。
正式リリース当日にも、ユーザーさんからログインまわりの不具合報告をいただきました。
調べてみると、ログインURLの文字列が一部間違っていました。
かなり単純なミスです。
でも、開発期間が長くなるほど、
難しいロジックより、こういう小さなミスの方が残っていたりします。
リリース後にユーザーさんから直接フィードバックをもらえるようになって、ようやく「開発」から「運用」にフェーズが変わった感覚がありました。
2026年9月15日に正式リリース。
初日は4名の方が登録し、そのうち2名がStripeで決済登録まで進んでくださいました。
もちろん、大きな数字ではありません。
でも、自分が一人で企画して、設計して、開発して、テストして、公開したサービスに、実際にユーザーが登録してくれる。
これはかなり嬉しい経験でした。
Webアプリは、コードを書いている間はただのデータと画面です。
誰かが使い始めた瞬間に、ようやく「サービス」になるのだと感じました。
Linora Worksを作って感じたのは、
個人開発で大変なのは、コードを書くことだけではないということです。
機能設計
UI
料金設定
利用規約
決済
テスト
SEO
LP
広告
問い合わせ対応
リリース告知
全部自分でやります。
開発者であり、デザイナーであり、QAであり、マーケターであり、カスタマーサポートでもあります。
逆に言えば、
自分でサービス全体を作れること
が個人開発の一番面白いところでもあります。
現在は、原価・在庫・売上管理が中心ですが、今後はユーザーさんの反応を見ながら機能を追加していく予定です。
候補として考えているのは、
など。
ただ、機能数を競うサービスにはしたくありません。
ハンドメイド作家さんが、
「管理に時間を取られず、制作や販売に集中できる」
ことを一番大切にしたいと思っています。
Linora Worksは、
「自分が欲しい」
という、とても小さな理由から始まりました。
でも個人開発では、そのくらいの始まり方がちょうどいいのかもしれません。
自分自身がユーザーなので、困っていることが分かる。
必要な機能が分かる。
使いにくい部分にも気づける。
そして、その問題を同じように感じている人がいれば、サービスになる可能性があります。
まだLinora Worksは始まったばかりです。
これからユーザーさんの声を聞きながら、少しずつ育てていきたいと思っています。
