Humanitarian systems case study · approved demo data
Private ClientAid for Palestine
A two-sided aid platform coordinating public stories, donor action, beneficiary verification, wallet state, withdrawals, and direct communication.
- Ownership
- Full build
- Platforms
- iOS + Android
- Domain
- Humanitarian Aid · Fundraising · Beneficiary Management · Payments
Project snapshot
The production surface at a glance.
- Role / ownership
- End-to-end Flutter build
- Product type
- Humanitarian fundraising and beneficiary-management platform
- Platforms / status
- iOS + Android · Private Client
- Primary responsibility
- End-to-end Flutter delivery across donor, beneficiary, verification, donation, wallet, withdrawal, messaging, and support journeys.
- Engineering areas
- Multi-actor state, REST integration, real-time chat, fundraising, identity verification, wallet and bank-account workflows.
- Verified technology
- Flutter · REST API · Real-Time Chat · Fundraising
The system challenge
Different actors share one high-consequence state machine.
Beneficiaries need to create and maintain a credible story, complete identity verification, receive donations, and manage withdrawal details. Donors need to understand stories, follow updates, and act with confidence. Support and messaging connect the two sides when static state is not enough.
The engineering challenge is coordination: identity, story status, fundraising progress, wallet activity, and withdrawal readiness must remain understandable across several roles and product surfaces.
Ownership and responsibility
Full-build mobile ownership across the actor and state model.
The canonical manifest records end-to-end Flutter ownership. Publication remains restricted to selected, re-encoded derivatives of audit-approved demo screenshots; no original AFP file, archive, APK, credential, or client implementation detail is public.
Beneficiary journey
Connect story creation, updates, identity verification, wallet status, bank details, and withdrawal review.
Donor journey
Support story discovery, detail comprehension, donation context, QR fundraising, and visible progress.
Communication
Integrate real-time messaging and technical-support surfaces into the wider aid workflow.
Cross-platform delivery
Carry the private-client Flutter product across its recorded iOS and Android scope.
Systems approach
Organize the product around actors, gates, and recoverable states.
The mobile surface is legible when each actor can see what they may do now, which gate remains, and where completed state can be recovered later.
- 01
Beneficiary
Creates a story, verifies identity, receives support, and manages withdrawals.
- 02
Donor
Discovers stories, reviews progress, donates, follows updates, and communicates.
- 03
Trust gates
Identity and bank-account steps separate story visibility from withdrawal readiness.
- 04
Shared state
Fundraising progress, wallet entries, updates, and messages carry context over time.
Evidence boundary. Flutter, REST API, real-time chat, fundraising, the named product workflows, and full mobile ownership are supported. Payment-provider, backend-topology, security-control, and operational-impact details are not documented.
Beneficiary system flow
A public story becomes verified, funded, and withdrawable state.
The sequence focuses on system responsibility rather than a decorative screen tour. Every image is a renamed WebP derivative of approved demonstration data.
- 01
Create the story
Capture the need, funding goal, and supporting image while allowing a draft state.
Story creation begins the beneficiary-side state model. - 02
Complete the identity gate
Provide identity-document and selfie inputs before donations can be withdrawn.
Verification is an explicit prerequisite, not an invisible side effect. - 03
Recover wallet state
Review incoming support and withdrawal entries with distinct transaction status.
Wallet entries retain fundraising and withdrawal context. - 04
Review the withdrawal
Collect bank-routing context, acknowledgements, fees, and remaining balance before submission.
Financial details and deductions are reviewed before commitment.
Systems decisions
Make trust gates and durable state visible across actors.
The decisions are tied to approved interface evidence and deliberately avoid undocumented backend or security claims.
Separate story publication from withdrawal readiness
- Context
- A beneficiary can communicate a need before every financial prerequisite is complete.
- Decision
- Represent identity verification as a visible gate for receiving withdrawals.
- Why
- The user can understand both the value already available and the requirement still blocking the next financial action.
Keep fundraising progress recoverable
- Context
- Stories, donations, updates, and wallet events evolve over time.
- Decision
- Retain progress and transaction state in dedicated story and wallet surfaces.
- Why
- Neither actor has to rely on a one-time confirmation to understand the current state.
Review financial commitments explicitly
- Context
- Withdrawal details include identity, routing, fee, balance, and responsibility implications.
- Decision
- Show acknowledgements and a deduction summary before submission.
- Why
- The beneficiary can inspect the consequence of the action before committing.
Provide a communication escape hatch
- Context
- Humanitarian cases and support needs cannot always be resolved through static forms.
- Decision
- Include messaging and technical-support routes alongside structured workflows.
- Why
- Users retain a direct path when the prescribed state flow is insufficient.
Privacy and publication
Deep product evidence without exposing private-client source material.
The AFP privacy audit confirms the supplied screenshots use intentional demo/test data. Publication is still minimized to the exact screens needed for this case study.
Immutable originals
All files under source-assets/AFP remain private source material.
Curated derivatives
Only renamed, resized, re-encoded WebP outputs live in the public project directory.
Demo-data disclosure
Captions and alt text identify demonstration values where that context matters.
Private-client framing
No public product link, client system detail, archive, APK, or credential is exposed.
Not claimed. No real beneficiary identity, live bank detail, secret, payment-provider implementation, security certification, donation metric, or humanitarian-impact metric is claimed.
Verified technology
Only the stack supported by the evidence.
- Mobile product
- Flutter · Dart
- Integration
- REST API · Real-Time Chat
- Product domain
- Fundraising · Beneficiary Management
- Delivery
- iOS · Android
Communication evidence
Structured state is supported by a direct conversation path.
The approved messages screen adds evidence for the real-time communication responsibility without exposing a conversation transcript.
Private-client boundary
Demonstrable, but not publicly distributed here.
Aid For Palestine is recorded as a private-client iOS and Android Flutter product with full-build mobile ownership and no authorized public product link.
This page publishes only a minimal, audited derivative set. The source directory and non-image artifacts remain outside the public application.
Factual outcome
A multi-actor aid system carried across its critical mobile states.
The defensible result is a cross-platform Flutter product connecting beneficiary onboarding and verification with donor discovery, fundraising state, wallet withdrawals, and communication.
- Confirmed end-to-end Flutter ownership
- Beneficiary and donor journeys
- Identity, wallet, bank, and withdrawal workflows
- Audit-approved demo-only publication
Continue from here
Explore the work or start a conversation.
The deep-story sequence ends here. The full project index and direct contact path remain one step away.