Every mission.
One managed marketplace.
A review worksheet for the web portal and Android / iOS apps. Agree the behaviour, discuss the tradeoffs, and record what needs to change before implementation.
2 · Review every item, direction and budget.
Choose Okay, Needs change or Defer. Explain any change or deferral. For open directions you can choose Discuss in meeting.
Complete these answers
Other options · export, import and display
After Submit review, look for “Submitted by…” and your reference to confirm SPATICS received it. Print / Save PDF opens your browser’s print window; choose Save as PDF for your own copy. A PDF is optional.
This is a requirements review. Answers, comments and the submission receipt form the review record.
Vihangam (working name)
The marketplace accepts many mission types. Each service still needs a feasible provider, service-specific scope, pricing, deliverables, and acceptance evidence.
Buyers & providers
Farmers, individual customers, institutions and enterprises. Drone Didis, independent operators and provider organisations. SPATICS runs dispatch, quality, support and payments.
An open mission catalogue
Spraying · survey & mapping · inspection · monitoring · photo & video · solar & tall-building cleaning · custom missions. Unsupported or incomplete scope enters review.
Multiple ways to request
Web / app, WhatsApp, IVRS calls and SMS feed one request and booking system. The customer can continue through a booking reference without installing an app.
Arrange capacity. Then collect payment.
Payment approves the booking. The required amount can be full payment, a deposit or a milestone, depending on service policy.
Request & scope
Site, mission, dates, attachments and missing-field follow-up.
Freeze the terms
Scope, price, due-now amount, milestones and timing consent.
Commit & hold
Eligible provider provisionally commits; reserve all resources.
Pay & verify
Razorpay capture verified by backend; valid hold converts once.
Execute & record
Stage gates, offline checklists, evidence and quality review.
Acknowledge & settle
Delivery acceptance, balances, refunds and separate provider payout.
Resolve any in-progress payment within a bounded grace period. Late capture triggers current-offer, obligation and capacity revalidation. Obsolete offers cannot reconfirm; all received funds are reconciled.
Preserve the existing booking until the replacement is ready. Apply paid credit to revised deposit / milestone obligations. Fixed appointments and changes outside a flexible window require consent.
One resource calendar across all channels: crew + drone + payload + supporting equipment + travel / setup / cleanup time. Automation cannot bypass payment authenticity, access control, qualification or double-booking checks.
Illustrative WhatsApp conversation
Keep these records separate
| Record | What it answers |
|---|---|
| Quote / offer version | What scope and terms did the customer pay to approve? |
| Reservation & assignment | Which qualified resources are held or confirmed, and when? |
| Payment obligation & attempt | What is due for this stage, and what captured credit satisfies it? |
| Reschedule / change | Which old and new terms apply, with what consent? |
| Refund / provider payout | What money is owed, authorised, pending or actually processed? |
What the product must do
Each row has a stable ID for later discussion. The small acceptance example explains how we will tell whether the requirement works.
How reliably it must work
Security, recoverability, performance and usability are part of the product. Numeric service levels below are proposed discussion targets and need a launch workload and operating owner.
Proposed pilot targets: 99.5% monthly availability · ordinary API p95 under 1 second · usable portal within 3 seconds on an agreed connection · recovery point within 24 hours · recovery within 4 hours. These exclude slow external responses and large uploads only if that boundary is explicitly agreed; measure both core and end-to-end experience.
Own the core. Isolate integrations.
Start with one modular backend and a worker rather than many separately deployed services. Technology choices and server capacity remain meeting decisions.
Core under SPATICS control
Identity, bookings, resource calendar, finance ledger, geometry, private evidence, backups and audit records. Hosting location, operator access and restore process must be agreed. No Firebase database, auth or storage dependency.
Decisions at the boundary
Farun is preferred; Mappls is an alternative. Offline-map rights and private deployment require verification. Standard iOS push uses APNs. Android push without Firebase needs an explicit delivery approach. Ground maps do not authorise airspace or define drone flight routes.
Automation is the default; SPATICS chooses the mode
| Stage | Default supported behaviour | Admin choice |
|---|---|---|
| Intake & quote | Complete fields and apply configured service rules; ambiguous work enters review. | Automatic / Review / Manual |
| Matching & holds | Find qualified, available resources and finish discretionary review before checkout. | Automatic / Review / Manual |
| Rescheduling | Find replacement within paid terms and customer consent. | Automatic / Review / Manual |
| Finance & communication | Apply approved policies; reconcile outcomes and handle exceptions. | Automatic / Review / Manual |
Per-stage settings can have service / region overrides. Policy changes are audited and apply prospectively. Manual actions use the same mandatory safeguards.
The team and the cost to get started
Akshay is providing one developer and one tester. The calculator covers the remaining funding needs with editable allowances; the three-month scenario is not a delivery commitment.
All INR inputs are internal planning allowances. ₹100 / USD is an editable planning conversion, not a live exchange rate. Use actual regional checkout and invoices before approving spend. Developer and tester are supplied by Akshay, so their cost is excluded from this funding request.
3 months · initial store registrations · equipment
| Item | Basis / ownership | Scenario cost |
|---|---|---|
| Apple Developer Program | US$99 / year · SPATICS organisation account | ₹9,900 |
| Google Play Console | US$25 once · SPATICS organisation account | ₹2,500 |
| Store checkout adjustment | Editable allowance for local price / tax differences | ₹0 |
| Developer + tester | 1 developer + 1 tester · provided by Akshay | Provided · no funding requested |
| Infrastructure / channels / maps / AI | Incremental allowances, even when existing servers are reused | ₹30,000 |
| Payment processing | 2% fee + 18% GST on fee; merchant terms / methods may differ | ₹0 |
| Device / Mac / setup gaps | Reuse existing equipment first; editable one-time allowance | ₹45,000 |
Account prices checked 6 October 2026: Apple enrollment · Google registration. Regional pricing and taxes can vary. Apple renews annually; Google registration is one-time. The calculator includes each registration once for a 1–12 month scenario.
Payment fee reference: Razorpay pricing. Standard domestic illustration: ₹1,000 collected → ₹20 fee + ₹3.60 GST = ₹23.60. Provider earnings / payouts, refunds, field delivery costs and working capital are outside this software funding model.
Publishing setup: Apple organisation requirements · Google organisation requirements · Xcode / Mac compatibility. D-U-N-S applications are free through the standard application route; allow verification lead time.
Existing assets: Coolify, GitHub SPATICS and OmniRoute can be reused. Confirm available capacity, residency, backups and incremental billing. ₹0 in an input means reuse / no allowance in this scenario; it does not establish a free vendor entitlement.
Your budget answer (required)
Review the amounts above, including the developer and tester provided by Akshay.
Budget comment · required for Needs change / Defer
What the meeting should resolve
Answer every direction. If more information is needed, choose Discuss in meeting. Add constraints, owners and due dates in the optional notes below. Review the budget separately.