Prove the AirBag business - before scaling the platform.
AirBag is a peer-to-peer logistics platform designed to connect people who need to send small packages internationally with verified travellers already flying to the destination. The initial pilot is centred on the UK–Ghana corridor, with the longer-term ambition of building a trusted distributed passenger-logistics network.
The first version should not attempt to automate the entire global logistics model. It should prove the complete operational journey: a sender creates a delivery request, AirBag inspects and seals the package, a verified traveller transports it, the destination agent receives it, and the verified recipient collects it.
Keza Studio proposes a focused mobile application supported by a secure admin web application. The mobile app will serve senders, travellers and recipients through role-based journeys. The web app will give Max, Fred and approved collection-point agents the controls required to operate the pilot manually, safely and visibly.
The purpose of Version 1 is not to build the entire business. It is to prove the business.
AirBag should launch with strong operational control and deliberate manual intervention. Automation, advanced matching, live maps, multi-corridor logic and deeper insurance workflows can be introduced after the pilot generates real usage data.
Does this reflect the version of AirBag you believe should be proven first?
Personal international delivery already happens - informally. AirBag makes it structured.
- People already send items through travellers.
- Arrangements are often informal.
- Trust depends on personal relationships.
- Chain of custody and status visibility are limited.
- Structured delivery requests captured through the app.
- Inspected, sealed packages backed by a verified manifest.
- Verified participants across sender, traveller, agent and recipient.
- Recorded custody handovers with identity and condition checks.
- Founder operations portal to approve, match, resolve and control payments.
- Create a structured marketplace connecting senders, travellers and recipients.
- Use approved collection points to inspect, photograph, document and seal packages.
- Give travellers a verified manifest rather than asking them to carry an unknown parcel.
- Record each major custody handover through a scan, identity check and condition confirmation.
- Give founders an operations portal to approve packages, match travellers, resolve incidents and control payments.
Does this accurately reflect the problem AirBag is solving?
Start with operational control. Automate after learning.
- Focused UK → Ghana pilot corridor.
- Selected senders, travellers, recipients and collection-point agents.
- Manual approvals for packages, travellers and traveller matching.
- Collection-point inspection, photography, weighing, documentation and sealing.
- Custody records for each major handover, scan and identity check.
- Package status tracking with action-required notices.
- Admin operations centre to monitor bookings, packages, users and incidents.
- Manual hold/release of traveller payouts and payment status controls.
- Basic reports and operational settings.
- Automated marketplace matching and traveller assignment.
- Additional corridors and multi-corridor routing.
- Live maps and continuous GPS package tracking.
- Deeper insurance workflows and automated claims settlement.
- Airline, airport or government customs-system integrations.
- Advanced AI matching, dynamic pricing or fraud-scoring engines.
- Multi-language support.
- Large-scale courier, enterprise or multi-corridor management functionality.
The 4–5 week delivery is a focused pilot MVP. Complex regulatory automation, insurer integrations, airline integrations, continuous GPS tracking and fully automated marketplace matching are not included in this first build.
"Manual operations during the pilot are not a limitation. They are a strategic decision - the fastest way to learn where automation is actually justified before investing in it."
Is there anything you believe Version 1 must prove that is not represented here?
Five validation areas. One controlled pilot. Real evidence.
Senders are willing to create and pay for delivery requests.
Will senders create real, paid delivery requests on the UK → Ghana corridor?
Sender mobile app captures delivery requests, quotes and payments end to end.
Number of requests submitted, paid and completed during the pilot.
Verified travellers are willing to accept inspected packages for a clear reward.
Will verified travellers accept inspected packages for the offered reward?
Traveller registration, trip submission and offer accept/decline flows go live.
Traveller sign-ups, trips submitted, offers accepted and completed.
The collection-point, sealing, custody and handover process works end to end.
Does the collection-point, sealing, custody and handover process work end to end?
Collection-point web app captures inspection, seals, custody and destination release.
Custody records, exceptions raised and time taken at each handover step.
Payments, payout status and manual release can be managed reliably.
Can payments, payout status and manual release be managed reliably?
Stripe (or agreed provider) integration plus manual hold/release controls in admin.
Successful sender charges, refunds and traveller payouts recorded in admin.
All parties can see clear milestones and AirBag can investigate exceptions.
Do all parties get clear visibility, and can AirBag investigate exceptions?
Shared package-status timeline, notifications and admin incident management.
Milestone views, notifications delivered and incidents resolved in admin.
Which validation area matters most to you right now?
One package. Twelve controlled steps. Every custody handover recorded.
Delivery request created
Sender opens the app, declares package contents and selects the route.
- Action
- Sender creates a delivery request, declares contents, selects route, recipient, collection point and drop-off slot.
- Data captured
- Sender identity, package declaration, route, recipient details, collection point, drop-off slot.
- Verification
- Sender contact details verified at account setup.
- Notification
- Sender receives booking reference and QR code after payment.
- Admin visibility
- New booking appears in the admin operations queue awaiting review.
- Related scope item
- Sender delivery-request and package declaration flow.
Which part of the delivery journey carries the greatest operational risk?
Every role, every screen - one shared platform.
Sender objective
Send a small package internationally via a verified traveller, with clear visibility from booking to delivery confirmation.
- 1Create account and verify contact details.
- 2Create a delivery request and declare package contents.
- 3Select route, recipient, collection point and drop-off slot.
- 4Review quote and make payment.
- 5Receive booking reference and QR code.
- 6View inspection outcome and package timeline.
- 7Upload requested documents and report an issue.
- 8Receive delivery confirmation and receipts.
Is any role missing detail that would help your team commit?
What is included, what stays manual, what is deferred.
Review and consolidate the agreed user journeys, admin portal and user-story documentation.
Confirm the pilot roles, package statuses, permissions and operational handover points.
Prioritise the user stories required for the first UK–Ghana pilot.
Produce a final sprint-ready feature map before development begins.
Mobile-first sender, traveller and recipient journeys.
Responsive admin and collection-point web interfaces.
Wireframes, design direction and high-fidelity screens.
Clickable flows for review before full development.
A consistent AirBag interface, status language and visual hierarchy.
Shared sign-up, login and role-based onboarding.
Sender delivery-request and package declaration flow.
Traveller registration, trip submission, package offers and journey milestones.
Recipient tracking, collection instructions and secure collection confirmation.
Package tracking timeline and action-required notices.
Photo and document upload where needed.
Payment and payout status visibility.
Incident / report-a-problem submission.
Secure admin and agent login with role-based access.
Founder dashboard and attention-required queue.
Booking, package, traveller, trip and user management.
Package inspection, manifest, photographs, weight, dimensions and seal records.
Manual traveller matching and assignment.
Automated marketplace matching is intentionally deferred until the pilot generates real usage data.
Live operations board showing package status and exceptions.
Custody handover records and audit activity.
Incident management and internal notes.
Payment, refund and traveller-payout status controls.
Collection-point inventory and recipient-release workflow.
Basic reports and operational settings.
Shared database, API and role permissions.
Package-status and custody-event logic.
Secure media and document storage.
Payment-provider integration at the agreed MVP level (Stripe or agreed provider).
Basic notification infrastructure (email and in-app; SMS optional subject to provider costs).
Functional testing, device testing and bug fixing.
Deployment of the admin web app and pilot mobile builds.
Handover documentation and launch support.
Manual by design
These activities stay hands-on during Version 1 - for good reason.
Why manual: Approvals stay manual so AirBag can enforce pilot policy and prohibited-item rules before automating anything.
Supported by: Founder dashboard, attention-required queue, package and user management.
Future automation: Automated policy checks and matching can be introduced when pilot data justifies it.
Why manual: Manual inspection is central to trust and evidence collection during Version 1.
Supported by: Inspection, manifest, photograph, weight, dimensions and seal records in the web app.
Future automation: Some steps may be streamlined or partially automated as the process matures.
Why manual: Manual matching keeps founders close to eligibility, reward and risk decisions.
Supported by: Manual matching and assignment workflow in admin.
Future automation: Automated marketplace matching sits in the future platform, not Version 1.
Why manual: Manual release protects senders, travellers and AirBag during the pilot.
Supported by: Payment, refund and traveller-payout controls in admin.
Future automation: More automated payout flows can follow once payment volumes and rules are proven.
Why manual: Manual incident triage lets founders learn where the operational model needs strengthening.
Supported by: Incident management and internal notes in admin.
Future automation: Playbooks and partial automations can follow once incident patterns are known.
Not included in this MVP
These items are explicitly excluded from Version 1 and sit outside the four-to-five-week delivery.
Recommended technology & architecture
Is there any deferred feature you believe is essential to the pilot?
Four-to-five weeks. Weekly reviews. Predictable milestones.
Process at a glance
Confirmed MVP backlog and delivery plan.
Approve priorities and provide required accounts and content.
Wireframes and high-fidelity screens.
Consolidated design feedback.
Working sprint builds and demos.
Weekly review and prompt decisions.
Connected pilot workflow.
Provider access and test credentials.
Pilot-ready mobile builds and live web portal.
Acceptance testing and sign-off.
Week-by-week timeline
Estimated delivery: 4–5 weeks from project commencement, receipt of the initial payment, confirmation of scope and availability of required client materials. The schedule assumes feedback and required access are supplied promptly. Delays in approvals, content, payment-provider onboarding, app-store accounts or third-party verification may move the launch date.
- Week 1Sprint 1Final discovery, feature prioritisation, architecture, user flows and initial UI direction.Milestone: Scope and design direction approved.
- Week 2Sprint 2High-fidelity UI, backend foundation, authentication, role permissions and core data models.Milestone: Clickable design and working platform foundation.
- Week 3Sprint 3Sender, traveller and recipient mobile flows; admin booking, package and user modules.Milestone: Core journeys available for demo.
- Week 4Sprint 4Inspection, manifest, custody, matching, tracking, incident and payment-status workflows.Milestone: End-to-end pilot journey completed.
- Week 5Sprint 5Integration completion, QA, fixes, acceptance testing, deployment and handover.Milestone: Pilot-ready launch build.
What we need from AirBag
Mark each responsibility as ready, in progress or needs support. Nothing is submitted - this is your working checklist.
Assumptions
- The initial operational corridor is UK to Ghana, with the reverse direction supported only where included during final scope confirmation.
- Matching and package approval will be admin-managed during the pilot.
- AirBag will provide final prohibited-item rules, terms, pricing rules, collection-point details and operational content.
- AirBag will obtain its own legal, customs, insurance and regulatory advice.
- Identity checks may use basic document capture and manual admin approval unless a paid KYC provider is selected.
- The mobile app will be delivered from one shared cross-platform codebase.
Communication
- Slack or WhatsApp for day-to-day communication.
- Google Meet for scheduled progress reviews and demonstrations.
- Trello or an equivalent project board for task visibility.
- Figma for design review and feedback.
- At least one structured progress update or demo each week.
Risks & how Version 1 responds
Keza Studio is not providing legal, customs, insurance or regulatory advice. AirBag will obtain its own advice from qualified professionals.
Is the assumed cadence realistic on the AirBag side?
Two payment options. One MVP. Same scope.
Lowest total investment.
Lowest total project cost and immediate mobilisation.
Spread the investment across two milestones.
Split cash flow across commencement and completion.
What both options include
- Technical discovery and final MVP scope refinement.
- UX/UI design for the mobile app and responsive admin web app.
- Frontend and backend development.
- Core third-party integrations agreed for the MVP.
- Testing, bug fixing and deployment preparation.
- Source-code handover following full payment.
- Three-month post-launch warranty for defects within the delivered scope.
Third-party & operational costs
Hosting, domain names, app-store fees, SMS usage, identity-verification fees, payment-processing fees, cloud storage, mapping services and any other third-party subscriptions are not included in the development fee. These will be paid directly by AirBag or recharged only with prior approval.
Commercial terms
Handover
- Production or pilot deployment of the admin web application.
- Pilot mobile builds and agreed store-submission support where applicable.
- Source-code repository access after full payment.
- Basic technical and deployment documentation.
- Administrative walkthrough for Max, Fred and nominated operators.
Putting the investment aside for a moment, does this feel like the right first version of AirBag?
Questions
Anything you would like added to the FAQ before signing off?
The next decision is not whether to build the entire AirBag vision. It is whether this is the right Version 1 to prove it.
AirBag has the potential to formalise an existing cross-border behaviour and turn it into a safer, more visible and more accessible service. The right first step is a controlled MVP that proves the journey without overbuilding the platform.
Keza Studio will work with Max, Fred and the wider AirBag team to convert the existing product thinking into a clear, usable mobile application and a practical web-based operations centre. The focus will be on speed, trust, operational visibility and a successful UK–Ghana pilot.
We look forward to the opportunity to build AirBag with you.
A private read of the responses you've captured while going through this proposal. Nothing is sent anywhere unless you send it below.
What launching Version 1 unlocks
- A tangible, working product that can be demonstrated to senders, travellers, collection-point partners and investors.
- A complete UK–Ghana pilot workflow from booking to verified destination handover.
- Real evidence of sender demand and traveller participation.
- Operational learning around package intake, inspection, sealing, matching and collection.
- Data on matching success, completion time, incidents, payments and user behaviour.
- A technical foundation that can later expand into additional corridors, automation and partnerships.
The most important outcome is the shift from concept to an operational pilot. AirBag will be able to test the model with real users, identify where manual processes work, understand where automation is justified and build the next phase around evidence rather than assumptions.
Is there anything in the proposed approach that would prevent us from moving forward together?