Little Something · Working document · November 2026

PRD

Working document, last updated November 2026. Most of it was written before the launch path was chosen; section 12 lists what that changes. Self-directed portfolio project. Every requirement traces back to the discovery research; anything that can't is marked as a design bet.

1. Summary

Little Something lets people give money as a gift that carries the giver's intent through a personal, creative presentation instead of a spending restriction. The receiver keeps full freedom to use the money however serves them best.

2. Problem

Giving money digitally feels awkward for both sides. Givers have no natural way to attach effort or intent to a digital money gift, and receivers often want money but rarely say so. So money gifts arrive feeling generic (57% say a digital gift can feel like no effort went into it, Wells Fargo/Ipsos, 2025, US sample), and people fall back on rigid workarounds like brand-locked gift cards.

How might we take the awkwardness out of giving money digitally, so givers can put real effort and intent into it, and receivers can feel and appreciate that effort?

3. Goals

1. Let a giver attach a stated intent to a money gift, so it doesn't feel generic.
2. Let the giver present the gift in a way that fits the relationship and the moment.
3. Keep the money visibly separate as a gift until the receiver chooses to move it to their own bank.
4. Give the receiver full freedom over how they spend it.
5. Help both sides keep track of the gift over time: the receiver so it isn't forgotten, the giver so they know where each gift they made stands.
6. Give giver and receiver confidence that their money is handled safely and transparently.

4. Non-goals for v1

• Group collection. Collecting money from several people is a mature category (Collection Pot, Kadonation, PayPal Pool, payment requests in bank apps). Little Something can sit after however the money was collected.
• Several people editing one gift. Revisit only if evidence supports it.
• Spending locked to brands. The product exists to avoid the rigidity of gift cards and brand-locked balances such as Hubble Money.
• AI-written personalization. An interviewee said it would undercut the effort the gift is meant to show. This is a product principle, not an unbuilt feature.
• Monetization. Covered in the separate business model doc. The one rule that affects the product: any fee is paid by the giver, never taken from the receiver's gift.

5. Users

Who it's for. Givers who have already decided money is the right gift and want it to carry effort. The moments that fit best: someone close but far away, putting money toward something specific, knowing what someone wants but not daring to pick it, or knowing someone well enough to give but not well enough to choose. Which moment to launch with is still open.

Not for givers who want to control how the money is spent (brand-locked gift cards already serve them), or people who love choosing a present and know exactly what to get.

6. Core flow for v1

The happy path through one gift. It sits on top of a home screen that is always there, where the giver can confirm a gift was created, resume a draft and see what they've sent (requirement group 7).

Platform. Mobile first by design. The demo is a responsive mobile web app, because a well-built mobile web experience is enough to show the product. Native iOS and Android apps are a real launch decision, deferred like card issuing and payment infrastructure.

1. Create the gift. The giver designs it first: title, note, look, effect and an optional photo. The title and note carry the intent; there is no separate intent field. They can start as a guest, without logging in.
2. Add money. The amount is set and paid after the gift is designed: intent before money. The giver verifies their identity and payment at this point, at the level the payment partner requires.
3. Add the receiver's contact (optional). A phone number or email, used only so the receiver can verify with a quick code when moving the money. The receiver's name is never collected.
4. Send. By link or QR code, through any messaging app, email or a printed card. The receiver doesn't need the app.
5. Open. Opened from the shared link, the gift starts on a sealed reveal ("[Giver] prepped this just for you"), then shows the look, the note and the amount. No account or verification is needed to open it. Opened again later from the Receiving tab, it goes straight to the opened gift.
6. Move it to the bank. Whenever the receiver chooses, the full amount moves at once to their own account. Light verification happens here, not at opening, so opening stays effortless. What they do with the money afterwards happens in their own bank.

7. Requirements

Each group traces to the goal with the same number. Where a rule needed judgment rather than direct evidence, the reasoning is written out so it can be challenged.

1. Attach a stated intent

1. The giver must be able to write a short title and a note. Together they carry the intent.
2. The giver must be able to add at least one image.
3. The giver must be able to choose the gift's look.
4. The system must not write or customize content for the giver. It may offer optional prompts.
5. The look, title, note and amount must be visible to the receiver when they open the gift.

2. Present the gift to fit the moment

1. The giver must be able to share the gift by link through messaging apps, social media and email, using the phone's native share sheet.
2. The system must be able to create a printable version of the gift for handing over in person.
3. The giver must be able to schedule a gift for a later date. Reasoning: apps can't send a message through WhatsApp on someone's behalf, so a scheduled gift means a reminder at the chosen time plus a one-tap send. In the demo the reminder shows as a status on the home screen. Sending a scheduled gift early cancels the schedule after a one-line confirm.
4. Rich link previews (title and image in the chat) need server-side tags and are left out of the demo.

3. Keep the money separate until the receiver moves it

1. It must be clear to the receiver that they can move the amount to their own bank account or card.
2. It must be clear what the gift can and can't do. The amount moves all at once, by design. Reasoning: once the money is in the receiver's own account, splitting it between a bill and a treat happens with their bank's tools, so the product doesn't need balance tracking and doesn't quietly become a bank. Money can't be moved back into a gift.
3. There is no holding limit or expiry for now, until the payment partner's terms are known.

4. Full freedom for the receiver

1. The system must not restrict, track or ask for justification of how the money is spent.
2. The receiver can move the money immediately or at any later point.
3. The giver is never told whether or when the money was moved. They only see that the gift was opened.

5. Keep track of the gift over time

1. The receiver must be able to save the gift as an image to their own device.
2. The receiver can set a reminder. An account is offered once, at that moment, and is never needed to open the gift or move the money.

6. Account, verification and funding

1. The giver must verify identity and payment before adding money. Reasoning: trust in a new app holding money is a precondition for adoption, and moving money for others is regulated. Competitors use a licensed partner rather than holding funds themselves.
2. Verification is light to view a gift and real only when money moves, the same pattern Tikkie, Venmo and PayPal use.
3. The system must enforce a maximum amount per gift, tiered by verification level. Thresholds depend on the payment partner.
4. The giver must be able to choose from more than one payment method (for example iDEAL, card, digital wallets). The demo uses Apple Pay only.
5. The payment screen must show trust and security information before payment.
6. The system must show when the money is expected to arrive in the gift.

7. Home screen and drafts

1. The giver has a home screen showing their latest gifts and the status of each. Giver statuses: Draft, Ready to send, Sent, Opened. Receiver statuses: New, Opened, In your bank.
2. A "see all" page shows every gift, including archived ones.
3. Tapping a draft opens it for editing. Tapping any other gift opens its full preview with a status card on top.
4. A clear action on the home screen starts a new gift.
5. A gift is saved as a draft automatically while it's being made, and survives logging out.
6. The giver can resume a draft, delete a draft, and archive a completed gift.
7. Deleting a gift that already holds money isn't offered until the cancel and refund rules are decided (open decision 1).

8. Success signals (draft)

Not yet a metrics framework. Targets will come with the go-to-market plan.

• Share of gifts with a stated intent, at any level, versus none
• Share of gifts personalized beyond an amount (note, photo, look)
• Whether receivers describe it as still feeling like a gift after they've used the money (qualitative)

9. Decisions made

Mostly from the October 2026 design review.

10. Open decisions

1. Cancel and refund rules. What happens to money in a gift that is deleted or never opened? Current proposal: drafts can be deleted anytime; a gift with money but not yet sent can be cancelled and refunded; a sent but unopened gift can be cancelled (refund, the link stops working); an opened gift is locked. Partly depends on the payment partner's rules.
2. Verification levels. How much identity checking adding and moving money requires, and the amount limits for each level. This has regulatory weight and depends on the partner.
3. Who controls notification timing, the giver or the receiver.
4. Wallet integration (Apple and Google Wallet), suggested by an interviewee as a way to stop gifts being forgotten. A wallet pass is a reminder only, not a way to pay. v1 or later?
5. Spending by card later. A tap-to-pay card in Apple or Google Wallet would let receivers spend the gift directly, without moving the money to a bank. It's a stronger experience but a real architectural fork, so it stays v2, following the same wallet first, card later path Lydia took with Treezor.
6. Thank you "note". Do we need to give receiver a way to say thank you in our app or will they use existing channels to do it. It is only worth adding if it will offer something more than their ways of doing. Similar to the reveal and the card. We can have customizable gif creator like Tikkie, animation or even a short note.
7. Receivers from other banks. How much identity checking can a receiver who banks elsewhere go through when moving the money before it becomes friction?
8. Brand freedom. How much of the playful brand and product decisions would a bank owner leave to the product team?
9. Giver fee. When to switch it on, at what level, and what has to be true first.

11. Prioritization

Two MoSCoW passes, kept separate on purpose: one for the demo built for this case study, one for what a real launch would need. Money movement is mocked in the demo, so the payment work only appears in the launch pass.

Demo

Real launch

The technical and risk memo covers the reasoning behind the launch pass.

12. What changes with the bank-owned launch

In November 2026 I chose to launch Little Something as a standalone app owned by a bank, the way Tikkie works for ABN AMRO (see the business model doc). Most of this PRD was written before that decision. The product itself doesn't change: the flow, requirements and demo priorities hold either way. These parts do:

1. The payment partner is the bank. It holds the licence and moves the money, so there is no separate payment provider. Treezor and the Lydia example in open decision 6 become background research, not the plan.
2. Verification depends on where people bank. Givers and receivers who already bank with the owner are verified. People from other banks still need checks when money moves (open decision 8).
3. Payment methods. With a bank behind it, iDEAL and bank transfers cost far less than cards, so they would likely come first after the demo.
4. New open decisions on brand freedom and the giver fee (open decisions 9 and 10).

If I had chosen the launch path earlier, I would have spent less time on payment vendors and looked at the rules for building inside a bank sooner.