Founder story · 2017–2018 · US, AUS, UK, EU · iOS. A group-authorship social product with rare built-in distribution that never reached a public launch.
Henry — branded *Henri* in its own materials — was a social product built on group authorship. The pitch was one line: make stories together.
The mechanic:
That premise is the whole story of what went wrong. Assembling one video timeline from several contributors, on a phone, in 2017, was not an app feature. It was a specialist engineering problem — and the built product proves it: 88 designed screens covering a full story timeline editor, per-clip speed control, music layering, contributor attribution on every post, and search by user, hashtag, and location.
The July 2018 investor deck is specific, and the numbers in it are what make this case worth publishing. They show exactly how far the product was from viable — in the founders' own arithmetic, at the time.
| From the deck | |
|---|---|
| Team needed | 5 full-time staff, $230k/year in salaries |
| Marketing plan | $100k through PR firms in New York and London |
| Operating cost | $13k per 100,000 active users |
| Revenue assumption | $4 per active user per year, against Facebook's ~$50 and Instagram's ~$20 |
| Break-even | 93,000 monthly active users |
| Ask | $2M for 25% of the company |
Set the last numbers against reality: the product had about 100 users in closed beta and needed 93,000 to reach positive cash flow. The bridge between those two numbers was the $2M round, and it never closed.
$500,000 from angel investors who were also the distribution. The angels were professional athletes and fashion models with a combined audience of roughly 4.25 million. They did not just write cheques — they used the product themselves and pushed it to their own audiences.
About 100 people in closed beta who used the product fully. Not a trial cohort that opened the app once. They used it the way it was designed to be used.
For a consumer social product, that is close to the ideal starting position. Distribution is normally the last thing you get and the hardest thing to buy. Henry had it before launch, and it had evidence the product worked for the people who had it.
Eighty-eight designed screens. The parts that made it hard are the parts you can see.
Stories carried a participant list with owner, participants, and joiners as distinct roles. A published story credited every contributor, and the feed showed it — *Daniel W. & 17 more*. Joining was its own flow, including joining by location.
The clip timeline assembled footage from several people into a single story, with a music track laid across the whole thing and per-clip trimming. This is the component that needed a Swift developer fluent in video multi-processing — the role that turned over three or four times.
Clip editing carried filters, pen and text overlays, crop, and thumbnail selection. Stories supported 360° content, and the camera roll allowed multi-select so a contributor could add several clips at once.
Henry never left closed beta. The market never rejected it, because the market never saw it.
The binding constraint was hiring for one role. Video multi-processing in Swift, in 2017–18, was a narrow specialty, and good people in it were almost impossible to find. The key developer was replaced three or four times. Every replacement stopped development while the next person learned a codebase built around the hardest part of the product.
The rest followed from that:
Running out of money was the last event, not the cause. The cause was that the single hardest technical component depended on a role we could not keep filled, and nothing in the plan accounted for that.
| Claim | Evidence |
|---|---|
| Distribution was not the constraint | Investors were the distribution: ~4.25M combined audience, using and sharing the product |
| The product worked for the people who had it | ~100 closed-beta users using the app fully over 4 months |
| The product was built, not sketched | 88 designed screens: timeline editor, per-clip speed, music, contributor attribution, search |
| Capital was not the first constraint | Funding burned over ~12 months; many follow-on attempts |
| The constraint was a specialist hiring market | Key engineering role turned over 3–4 times; each turnover halted development |
| Team durability is a real failure mode | The fundraise ended when the co-founder left under sustained stress |
Not start building with the first developer who is available.
The riskiest assumption in Henry was never *will people want this* — the beta answered that. It was *can we staff the one component this product cannot exist without.* That question was answerable before any money was raised, and it was never asked.
This is why Proof Engine now names the riskiest assumption first and builds the smallest asset that tests it. On Henry, the riskiest assumption sat on the supply side of our own team, and it went untested until it was fatal.
Not shipping is a decision. It just does not feel like one while it is happening.
The core capability — assembling one video timeline from several contributors — required a Swift developer experienced in video multi-processing. That role turned over three or four times between 2017 and 2018, and each turnover stopped development. The product worked for its closed-beta users but was never finished enough to launch.
The money lasted about a year, spent against a schedule that restarted every time the key engineering role had to be refilled. Capital does not compensate for a role you cannot staff.
It was never used. The angel investors were athletes and models with roughly 4.25M combined following. They invested, used the product, and were ready to distribute it — but there was never a public version to distribute.
Its own investor deck put break-even at 93,000 monthly active users, on $4 of revenue per user per year. The product had about 100 users in closed beta. Closing that gap depended on a $2M round that never happened.
If your product depends on one scarce specialty, that dependency is your riskiest assumption — not your market. Test whether you can staff and keep the role before you raise against a timeline that assumes you can.
If you would rather talk it through before sending a brief, book a short routing call and we will point you to the right next step.
