Sheet A-01 · Schedule
Schedule
of work
Each service is written like a schedule entry: scope, what you receive, and the criteria you use to accept the work.
Mobile development
Native (Swift, Kotlin) or cross-platform (React Native, Flutter) apps. Local database, operation queue, sync with conflict resolution.
Acceptance criteria
- App works offline in agreed scenarios
- Resubmission never creates duplicates
- Cold start on a reference device measured and reported
- Builds signed, keys handed to you
Web development
Client portals, internal tools, APIs. Transaction boundaries, zero-downtime schema migrations, change logs.
Acceptance criteria
- Core Web Vitals in the “good” range on key pages
- WCAG 2.2 AA for primary flows
- Every migration has a rollback plan
- API documented in OpenAPI
UI/UX design
Journey research, prototypes, design system. We design the states separately: pending, error, conflict, offline.
Acceptance criteria
- Every screen has empty, loading and error states
- Text contrast ≥ 4.5:1
- Prototype tested with at least 5 participants
- Components handed over with tokens
Publishing assistance
Developer accounts setup, bilingual store listing, privacy policy, data safety declarations, responses to review feedback.
Acceptance criteria
- App Privacy / Data safety forms matching actual behaviour
- Screenshots in all required sizes
- Staged rollout plan
- Resubmission checklist
Data integrity review
A two-week survey of an existing system: where data can diverge, duplicate or get lost.
Acceptance criteria
- Data flow map
- Risk register with likelihood and impact
- Prioritised remediation plan
- Reproducible tests for findings
Specialisation
Our focus is a positioning, not a track record claim: we deliberately take projects where data consistency matters more than screen count. We treat distributed ledgers as one tool among many, not a goal — and we do not issue or sell tokens.