6. Delivery Plan, Terms & Scenarios
The build runs for 12 weeks across six phases, with checkpoints at weeks 4, 8 and 12. Late external inputs shift only the dates that depend on them; the build continues on sample data.
6.1 Phase plan
Six phases over 12 weeks. The phase order and duration are the same in all three delivery scenarios set out at §6.4.
| Ref | Weeks | Focus | Checkpoint |
|---|---|---|---|
| P-01 | 1–2 | Architecture decisions, application shell, authentication, database, role model, design system | — |
| P-02 | 3–4 | Wallet connection, token activation flow, campaign engine | Demo 1 |
| P-03 | 5–6 | Portfolio, pools, POMP and vesting views running on sample-data reads | — |
| P-04 | 7–8 | AI Operator cockpit, AI assistant, knowledge base | Demo 2 |
| P-05 | 9–10 | Admin console, CRM and export flows, exchange readiness centre, audit logs | — |
| P-06 | 11–12 | Responsive QA, security review, deployment, documentation, training | Handover |
- 1Checkpoints fall at the end of week 4, week 8 and week 12.
- 2Each checkpoint is a running build on a shared environment, not a written status report.
- 3Checkpoints are review points only. No payment instalment under §6.7 is tied to one.
6.2 Deliverables
Nineteen deliverables are handed over across the engagement. Each carries a reference code and the phase in which it is completed. Phases are cited in the P-0n form used by the phase plan at §6.1.
| Ref | Deliverable | Phase |
|---|---|---|
| D-01 | Platform repository | P-01 |
| D-02 | Production-ready application | P-06 |
| D-03 | Deployment configuration and handover | P-06 |
| D-04 | Database backup configuration and basic monitoring, with operational notes at handover | P-06 |
| D-05 | Language-ready structure: copy is externalised so further languages can be added without a rebuild | P-01 |
| D-06 | User dashboard | P-03 |
| D-07 | Wallet connection | P-02 |
| D-08 | Token activation and allocation flow | P-02 |
| D-09 | Views covering pools, POMP, service credits, bonds and allocations | P-03 |
| D-10 | Responsive desktop and mobile UI | P-06 |
| D-11 | Campaign engine | P-02 |
| D-12 | AI Operator cockpit | P-04 |
| D-13 | AI assistant with knowledge-base setup | P-04 |
| D-14 | Analytics integration | P-05 |
| D-15 | Admin console | P-05 |
| D-16 | Exchange readiness centre | P-05 |
| D-17 | CRM and export flow | P-05 |
| D-18 | Admin and user documentation | P-06 |
| D-19 | Final walkthrough and training session | P-06 |
6.3 Acceptance
The MVP is complete when all ten criteria below are met. Each criterion accepts one or more deliverables from the register at §6.2.
- 1The authenticated application is delivered (D-02 under §6.2).
- 2Login and wallet connection work end to end (D-07 under §6.2).
- 3Navigation and the core dashboard views are implemented (D-06 and D-09 under §6.2).
- 4A user can complete an activation, and a campaign can be run end to end (D-08 and D-11 under §6.2).
- 5The admin console is implemented (D-15 under §6.2).
- 6The AI cockpit and the AI assistant are implemented (D-12 and D-13 under §6.2).
- 7The exchange readiness centre is implemented (D-16 under §6.2).
- 8Production deployment is done, or the deployment package is ready to ship (D-03 under §6.2).
- 9Documentation and handover materials are delivered (D-18 under §6.2).
- 10The walkthrough and training session has been held (D-19 under §6.2).
6.4 Delivery scenarios
Three delivery scenarios. The phase plan at §6.1 is the same in all three; the data source and the switch-on dates differ.
- Scenario A
- Inputs arrive on schedule. Contract handoff, provider selections and content arrive on the agreed dates, and the platform launches with live contract reads. Impact: none.
- Scenario B
- Contract handoff is late. All views are built against structured sample data and delivered on the agreed date; live reads are enabled after handoff. Impact: the integration window moves by the length of the delay under §5.2. No other dates change.
- Scenario C
- Providers or content undecided. No KYC or payment provider selected, or legal texts and translations not delivered. Those flows ship as marked placeholders, in one language. Impact: those integrations are scheduled as follow-up work once the decisions are made.
6.5 Aerion inputs
None of these block the start of the build. Each one determines when a specific feature can be switched on.
- Domain & hosting
- Preferred domain, subdomain and hosting arrangements.
- Launch-site repo
- Access to the existing site repository, where it is needed.
- Allocation rules
- Token allocation and purchase rules to be enforced in product.
- Campaign rules
- Approved bonus, window and referral rules.
- Network details
- Wallet and network details coming out of the contract build.
- Provider decisions
- KYC and payment provider selection, if live processing is wanted.
- Listing inputs
- Exchange and listing contacts plus supporting materials.
- Legal texts
- Approved legal copy, ready to be implemented as-is.
- AI sources
- The approved documents the assistant is allowed to ground answers in.
- Admin users
- The list of people who get admin console accounts.
- Brand & URLs
- Brand assets and the final production URLs.
Dependency — Late inputs
A late input shifts the dates that depend on it by the same number of days. Polenist reports the delay and the revised dates in writing within 3 working days. Work on independent phases continues during the wait.
6.6 Exclusions
Included in the build: routes for terms and a privacy notice, a cookie consent prompt, a risk-disclosure acceptance step inside the activation flow, and disclaimer slots across investor-facing screens. Items in this clause are not covered by the fixed price at §6.7. Each can be quoted separately or handled by another party.
Exclusion — Legal responsibility
Polenist builds the pages. Drafting the wording, checking it against a jurisdiction, and approving it for publication remain with Aerion and its counsel. Approved text is published as received.
Exclusion — Excluded from the fixed price
- Legal opinion and the authoring of final legal copy
- KYC provider fees
- Payment processor fees
- Exchange listing fees
- Market-maker fees
- Liquidity provision
- Custody
- Any guarantee of sale approval or of a listing
- Fully automated mining control where site control APIs do not exist
- External penetration testing and bug bounty fees
- Smart-contract authorship and audits
- Translations and language QA, unless approved translations are handed over during the build
- A contractual SLA, round-the-clock ops cover, or advanced disaster-recovery tiers
- A custom-built support platform
6.7 Commercial terms
Summary of commercial conditions. The full legal agreement is a separate document signed alongside this proposal.
- Fixed fee
- 20,000 USDT, plus an ARN token component equivalent to 3,000 USDT. The vesting schedule for that component is agreed in writing at signature. If the token launch is cancelled or materially delayed, the token portion is renegotiated in good faith.
- Payment schedule
- 10,000 USDT on signature and 10,000 USDT on delivery.
- Post-launch care
- Three months of support after launch are included in the fixed fee. After that period, monthly updates and technical maintenance run at 400 USDT per month under a separate agreement. New features and feature updates are quoted separately.
- Change control
- Material scope changes require a written change order with its own price, or are moved to a later phase agreed separately. No scope change is accepted informally.
- Intellectual property
- On full payment, Aerion owns the custom code, screens, copy and configurations. Polenist retains its pre-existing tools, libraries and know-how.
- Confidentiality
- Confidentiality is mutual. Production credentials remain under Aerion's control during and after the engagement.
- No advice, no guarantee
- This proposal is not legal, tax or investment advice. It guarantees no liquidity, no exchange listing, no token price and no successful fundraise.
- Validity
- 14 days from the publication date. Valid until [date].
6.8 Open items
Eight items to confirm before kickoff. Each answer fixes a date or a switch-on decision. None of them block the project start.
| Ref | Open item | Effect once answered |
|---|---|---|
| Q-01 | Contract handoff date | Fixes the week live contract reads can be enabled, and so determines Scenario A or Scenario B. |
| Q-02 | Automatic timeline shift on a late handoff | Puts the dependency rule in the contract, protecting both sides instead of leaving it to interpretation. |
| Q-03 | Sample-data delivery counts as completion | Confirms Scenario B as an accepted delivery state. |
| Q-04 | KYC and payment provider | Determines whether those flows ship as live integrations or as marked placeholders under Scenario C. |
| Q-05 | Legal texts supplied by Aerion | Legal copy is implemented as received; Polenist does not author it. |
| Q-06 | Translations supplied by Aerion | Determines a single-language launch or a multi-language launch. |
| Q-07 | Source of the product design | Determines how Phase 1–2 effort is split between design and build. |
| Q-08 | Maintenance agreement | Activates the care plan and fixes the start date and scope of the maintenance agreement that follows the three included months. |
- Q-01 to Q-03 fix the delivery date and the schedule-risk terms.
- Q-04 to Q-07 determine how much ships as a live integration and how much as a marked placeholder.
- Q-08 fixes the start date and the scope of the maintenance agreement that follows the three included months.