看板にしていた機能が、いちばん使われていなかった

I created a photo-sharing service for events and have been offering it for free for about two months.

Since it doesn't make sense to just list numbers that look good for promotion, I'll start with the most inconvenient parts.

Let me be clear upfront: the sample size is small.

18 actual events, of which photos were collected for 7. This is not a quantity that can be treated as statistics.

Still, I think it's better than nothing as material for judgment, so I'm sharing it.

(All figures are actual measurements as of September 6, 2026)

The flagship feature was used the least

photoba was built around "photos posted by participants from a QR code appear on the venue's screen in seconds." That's also the headline on the top page.

The feature I spent the most technical effort on was there, with real-time distribution built using Durable Objects.

Here's what the 30-day actual measurement showed.

Moreover, of the 7 sessions, only 1 was confirmed to have been used at an actual event. Even the event where 54 photos were collected had no record of the screen being opened.

It wasn't that there was no interest. Looking at the number of times the FAQ on the top page was clicked during the same period, the second most common was "How do I display it on the venue's large screen?" (8 times). First place was "Can I use it now? What's the cost?"

There was interest, but it wasn't used. When I list the reasons, they were all design problems on my end.

① To display it, a separate PC and internet connection are needed. Some venues also have restrictions on brought-in equipment.

② 6-7 out of 10 organizers use smartphones for the management screen. Even if they have the URL on hand, there's no way to pass it to the venue's PC.

③ The explanation was text-only, with no diagrams of the steps.

The third one is clearly my mistake, so I fixed it by adding screenshots of the actual screen. For the second one, I made it so that if you register an email address, the screen URL is sent to that email, and you can open it on the venue's PC.

The feature I spent the most time on was used the least. In personal development, if your "what I want to make" and the user's "what they want to use" are misaligned, no one stops you, so I couldn't notice until I saw the numbers.

My formula was deleting photos the day before a wedding

This was a dangerous bug. The calculation for the storage deadline was like this:

・If an event date is set, delete 7 days after the event date

・However, cap it so it doesn't exceed 90 days from creation

It looks reasonable at first glance, but it breaks if you create an event early for a wedding scheduled months ahead.

The 90-day cap comes first, and the deletion date ends up before the wedding. This actually happened with 2 events, and one was set to be deleted the day before the ceremony.

The cap should have been on the input side of the event date, not on the calculated date.

I fixed it and extended the existing data in the extension direction only.

If you're on the receiving end of a similar service, "what is the starting point for the storage period?" is something you should check. Whether it's "from the event date," "from creation," or "from the last photo" makes a completely different meaning, and it becomes a problem when you create early for a future event.

When I prohibited pre-event testing, the same event was created 4 times in 5 minutes

One more thing. When an event date was set, posts were rejected with a 403 on any other day. I thought that made sense since it's a "same-day, on-site" service.

What happened as a result? Organizers couldn't do pre-event testing.

Looking at the operation logs, someone created 4 events with the same name in 5 minutes. On another day, they also created 2 events with the same name just 33 seconds apart.

There were two reasons. The event name couldn't be changed later, and there was no way to get back if you lost the management screen URL. If you just wanted to fix the name, you had to create a new one.

For this type of service, the management URL is typically the key itself. If you know the URL instead of a password, you can operate it. If it can't be reissued, you're stuck once you forget to bookmark it.

I fixed both. I made it so posts can be made before and after the event date, made the name changeable, and set it up so that if you optionally register an email address, the management URL is sent to you.

Looking at the events that came after, 2 out of 4 events where photos were collected showed "delete some after posting" behavior (9 photos → 7 photos, 6 photos → 2 photos). Whether it's cleanup after test shots or photo selection is unclear, but at least the fact that I made it possible to touch it beforehand is being used. The operation I prohibited was actually a necessary one.

The shape of the data determined the design

One technical point. Photos don't arrive at an average pace.

Actual measurements from the event where 54 photos were collected.

Most arrive in concentrated bursts lasting a few minutes, with long gaps in between. The 36-photo event had the same pattern (about 7 hours, median 49 seconds, maximum 7 photos in 3 minutes).

The peaks come at turning points in the program like "toasts" and "group photos." In other words, if you design for average throughput, it will break on the day. You need to build for peak load. This worked because I used Durable Objects with one instance per event, but if I'd built it with database polling initially, it would have bottlenecked.

Another thing: the 21-hour span was important. This includes preparation time and later additions. A design that "only accepts on the event day" would miss these. Exactly the 403 failure I mentioned earlier.

About the number of photos (they don't accumulate as much as you'd expect)

The breakdown of the 7 events where photos were collected.

You can't say "roughly this many photos accumulate." It's either photos accumulate or almost none do—a bimodal distribution.

With 104 photos posted against 50 people who opened the participation page, that's 2-3 photos per person. It's not "one person sends a lot" but "many people send a few each." So the number of participants directly translates to the number of photos, meaning placing QR codes at each table is more effective than putting one in one place.

Also, the album wasn't just for the day of the event. Day of: 6 sessions → next day: 5 (13 views) → day after: 2. People are busy taking photos on the day and look through them leisurely later. If you set the storage period to "day-of only," you'd be taking away that time.

Architecture

For reference.

・Cloudflare Workers … Main body. Static HTML + Worker with no build

・Durable Objects … Real-time distribution. One instance per event

・R2 … Images

・D1 … Metadata

・Workers AI … Inappropriate image detection (held before display)

・Cron Triggers … Automatic deletion at storage deadline, daily snapshots

Zero servers, no build process. Personal development and personal operation. EXIF location data is stripped on the device side before sending.

Limitations of the numbers

・The sample size is 7 events where photos were collected. This is not an industry average.

・Most of the photo count discussion comes from the top 2 events. One more event and the numbers shift.

・Since it's a free beta, the usage patterns of a paid service might be different.

・The use cases are skewed toward company-related events. There isn't enough data yet for weddings.

I'll release more detailed numbers (how many days album viewing continues, what percentage of posted photos are deleted by organizers, etc.) on September 17 on my own site.

・photoba (Photo Ba)

　https://photoba.app/?src=tsukutta-story

・How to use at weddings

　https://photoba.app/wedding?src=tsukutta-story

・Column

　https://photoba.app/blog/?src=tsukutta-story

If this helps anyone else who has "features they built that don't get used."

イベントの写真共有サービスを個人で作って、2ヶ月ほど無料で公開しています。

宣伝になる数字だけを並べても仕方がないので、いちばん都合の悪いところから書きます。

先に断っておくと、母数は小さいです。

実イベント18件、そのうち写真が集まったのは7件。 統計として扱える量ではありません。

それでもゼロよりは判断の材料になると思って出します。

（数字はすべて2026年9月6日時点の実測値です）

看板にしていた機能が、いちばん使われていなかった

photoba は「参加者がQRから投稿した写真が、数秒で会場のスクリーンに映る」を中心に据えて作りました。トップページの見出しもそれです。

技術的にいちばん手をかけたのもそこで、Durable Objects でリアルタイム配信を組んでいます。

30日間の実測はこうでした。

しかも7セッションのうち、実際のイベントで使われたと確認できたのは 1件 です。54枚集まったイベントですら、スクリーンを開いた記録がありませんでした。

関心が無いわけではありませんでした。 同じ期間にトップページのFAQで押された回数を数えると、2番目に多いのが「会場の大画面にはどう映しますか？」（8回）です。1位は「いま使えますか？費用は？」。

関心はあるのに、使われない。理由を並べると、全部こちらの設計の問題でした。

①　映すには パソコンとネット回線が別に必要。会場によっては持ち込み機器に制限もある

②　主催者の管理画面の利用は 6〜7割がスマートフォン。手元にURLがあっても、会場のPCに渡す手段がない

③　説明が文字だけで、手順の絵がなかった

3つ目は明確にこちらの落ち度なので、実際の画面のスクリーンショットを載せる形に直しました。2つ目は、登録したメールアドレスにスクリーンURLを入れて、会場のPCでメールを開けば済むようにしました。

いちばん時間をかけた機能が、いちばん使われない。 個人開発だと自分の「作りたい」と利用者の「使いたい」がズレていても誰も止めてくれないので、数字を見るまで気づけませんでした。

自分の書いた式が、結婚式の前日に写真を消していた

これは危うい不具合でした。保存期限の計算が、こうなっていました。

・開催日が設定されていれば「開催日の7日後」に削除

・ただし「作成から90日」を超えないように上限をかける

一見それらしいのですが、半年先の結婚式のために早めにイベントを作ると壊れます。

90日の上限が先に来て、削除予定日が結婚式より前になる。実際に2件がその状態で、片方は式の前日に消える設定になっていました。

上限は「入力できる開催日」の側にかけるべきで、計算結果の日付にかけてはいけませんでした。

修正して、既存データも延長方向にだけ直しました。

同種のサービスを使う側に立つと、「保存期間の起算点は何か」 は確認したほうがいい項目です。「イベント日から」「作成から」「最後の写真から」で意味がまったく違い、先の予定のために早めに作るときに事故になります。

事前テストを禁止していたら、同じイベントが5分で4件できた

もうひとつ。開催日を設定すると、その日以外は投稿を403で弾く仕様にしていました。「当日その場」のサービスなので、そのほうが筋が通ると思っていたのです。

結果どうなったか。主催者が事前の動作確認をできませんでした。

操作ログを見ると、ある方が同じ名前のイベントを 5分間に4件 作っていました。別の日には同じ名前で 33秒差の2件 も。

理由は2つありました。イベント名を後から変更できなかったことと、管理画面のURLを見失ったら戻る手段がなかったことです。名前を直したいだけなのに、作り直すしかない状態でした。

この手のサービスの管理URLは、たいていそれ自体が鍵です。パスワードの代わりにURLを知っていれば操作できる。再発行できない設計だと、ブックマークを忘れた時点で戻れません。

どちらも直しました。開催日の前後でも投稿できるようにして、名前も変更できるようにして、メールアドレスを任意で登録すれば管理URLが届くようにしました。

その後に来たイベントを見ると、写真が集まった4件のうち2件が「投稿してから一部を削除する」動きをしています（9枚→7枚、6枚→2枚）。試し撮りの後片付けなのか写真の選別なのかは区別できませんが、少なくとも 事前に触れる状態にしたこと自体は使われています。 禁止していた操作が、実は必要な操作でした。

データの形が、設計を決めた

技術寄りの話をひとつ。写真は平均的なペースでは届きません。

54枚集まったイベントの実測です。

大半が数分の集中した塊で来て、その間に長い空白があるということです。ということです。36枚のイベントも同じ形でした（約7時間・中央値49秒・3分で最大7枚）。

山は「乾杯」「集合写真」など進行の節目に来ます。つまり 平均スループットで設計すると当日に破綻します。 ピークに合わせて組む必要がある。ここは Durable Objects で1イベント1インスタンスにしてあるので耐えましたが、最初にDBのポーリングで作っていたら詰まっていたはずです。

もうひとつ、21時間という幅が重要でした。これは準備中や後日の追加を含んでいます。「イベント当日しか受け付けない」設計だと取りこぼす。まさに上で書いた403の失敗です。

枚数の話（期待するほど集まりません）

写真が集まった7件の内訳です。

「だいたい何枚集まる」という言い方ができません。集まるか、ほとんど集まらないかの二極でした。

参加ページを開いた50人に対して投稿は104枚なので1人あたり2〜3枚。「1人が大量に送る」のではなく「多くの人が数枚ずつ送る」形です。つまり参加者の頭数がそのまま枚数になるので、QRを1か所に置くよりテーブルごとに置いたほうが効きます。

あと、アルバムは当日だけのものではありませんでした。 当日6セッション→翌日5（13閲覧）→翌々日2。当日は撮るのに忙しく、ゆっくり見るのは後日ということだと思います。保存期間を「当日限り」にすると、この時間を奪うことになります。

構成

参考までに。

・Cloudflare Workers … 本体。ビルドなしの静的HTML＋Worker

・Durable Objects … リアルタイム配信。1イベント1インスタンス

・R2 … 画像

・D1 … メタデータ

・Workers AI … 不適切画像の判定（表示前に保留）

・Cron Triggers … 保存期限切れの自動削除、日次スナップショット

サーバーは0台、ビルド工程もなし。個人開発・個人運営です。Exifの位置情報は 送信前に端末側で 落としています。

数字の限界

・母数は写真が集まった7イベント です。業界の平均値ではありません

・枚数の話の大半は 上位2件 から来ています。1件増えれば数字は動きます

・無料ベータ版なので、有料サービスの利用実態とは違う可能性があります

・用途が会社関係のイベントに偏っています。結婚式の実データはまだ十分にありません

もう少し細かい数字（アルバムの閲覧が何日続くか、投稿された写真の何%が主催者に消されるかなど）は、9月17日に自分のサイトのほうで全部出します。

・photoba（フォトバ）

　https://photoba.app/?src=tsukutta-story

・結婚式での使い方

　https://photoba.app/wedding?src=tsukutta-story

・コラム

　https://photoba.app/blog/?src=tsukutta-story

同じように「作ったけど使われない機能」を抱えている方の役に立てば。