Qela — a community app for iOS and Android where completing a quest has to be proven

01 Project passport

Verified Fields are confirmed by the project task tracker and the App Store and Google Play listings as of 6 Oct 2026; the stack and the team were confirmed by the agency owner on 13 Oct 2026.

02 The brief

The client came with an idea for the app and a basic design. They needed mobile apps through which a community member reads news, takes tasks, votes and collects rewards.

The main requirement came from the platform’s mechanics. A member’s voting weight depends on their activity, and rewards depend on completed quests. If a quest can be “completed” without leaving home, both the voting and the reward system break. So each quest type needed its own way to confirm completion.

Limitation How the client’s communities operated before the app is not described in the materials. The case has no before-and-after comparison.

03 Scope of work: what Chyzh Agency did and what the client did

Verified The split follows the task tracker and the previous case version.

04 How it works

The apps collect proof of completion on the phone and send it to the server; the administrator’s decision comes back as a notification.

05 The hardest decision: how to prove a quest was completed

The problem. There are ten quest types: survey, quiz, petition, donation, delivery, public speech, review, attending a meeting, online meeting, photo upload. They cannot be verified the same way: presence at a meeting and signing a petition are proven differently.

The solution. Verification was split into separate mechanisms.

• Presence at a point. The check-in button only works within the point’s radius. Outside it the app shows “Your location is out of check-in area” and does not count the step.
• An online meeting is confirmed with a QR code scanned at the matching step.
• Photos and screenshots: a quest with several uploads accepts several files at once.
• A human decision. Some quests, such as a petition, are reviewed by an administrator. The member sees that the quest is under review and gets a rejection as a notification.

The loophole that was closed. Testing found that a quest waiting for an administrator’s decision could be completed again. Repeat completion was blocked until there is a decision. Without that, one action could have earned a reward twice.

The trade-off. Administrator review costs the organisation moderators’ time, and the member waits longer for the reward. That is why some quests are verified by the app itself: the point radius and the QR code.

Limitation The client has not published verification statistics (the share of automatic versus manual checks, the share of rejected proofs), so the case does not include them.

06 What the app does

Verified The list follows the project task tracker and screenshots.

• Quests of ten types, with steps and progress shown on the quest badge.
• Voting, where a member’s weight depends on their activity; the profile shows what it is made of, and the rules.
• Talents — rewards with a description and a history of how they were earned.
• Branches — the organisation’s local units; a member learns about joining from a notification.
• Organisation news and a home page.
• Profile: password change, a message to support, profile verification.
• Four interface languages: Ukrainian, English, Czech, French.

Qela · app screens

Screenshots from the public App Store listing, snapshot 13 Oct 2026; English interface.

Limitation As of 13 Oct 2026 the client’s website mentions 18 quest templates on the web platform; the mobile app’s tracker records ten types. The client has not commented on the difference (web-platform templates versus proof types in the app).

07 How development went

The first task appeared in the tracker on 14 Jun 2023. Two native apps were written in parallel by two developers, one per platform: Android in Java and iOS in Swift, each with its own task queue. The first wave covered quests, sign-in, profile, home page, news, voting and the organisation page. Development then moved page by page for each platform: news and branches on iOS, pull-to-refresh lists on Android, profile verification on both.

The first version reached the App Store on 16 May 2024. The app has been updated since: version 1.31 shipped on 21 Jan 2026, and the Android build was updated on 9 Sep 2026. Some features were handled as additional work beyond the initial scope.

08 Quality and stability

The project tracker holds 782 bug reports: 331 for iOS and 365 for Android. 502 of them describe reproduction steps and the expected result. The platforms were tested separately, and most defects concerned only one of them.

09 Security and privacy

Only what the project materials confirm.

• Access token refresh on iOS: the session continues without signing in again (per the task tracker).
• Location and camera permissions: if the user declined earlier, the app asks again, because the quest cannot be completed without them (per the task tracker).

Corrected The previous version of this case said that data protection is guaranteed by Microsoft Azure and that Bluetooth and NFC were built into the app. Nothing in the project materials confirms this, so these claims are removed. The same version named the Android stack as Kotlin; the team confirms the Android app is written in Java.

10 Release and links

Verified Links and listing data checked on 6 Oct 2026.

11 Results

Product

• Separate native apps for iOS and Android are published and updated in 2026.
• Ten quest types, each with its own way of confirming completion.
• Voting, talents, branches and news in one app.
• Interface in four languages.

Technical

782 bug reports went through the tracker separately for each platform. Stability metrics from the store consoles are not included in the case.

Business

Public store data is summarised in the table in section 13. The client has not published the number of communities, active members or completed quests.

12 Limitations and what we would do differently

Design the proof of completion first. Repeat completion of a quest under review was found in testing, not at the design stage. The same with a declined location permission: at first it blocked the quest without asking again.

Scope grew along the way. Some features were handled as additional work. For a product like this it is better to plan a development stage after the first release from the start.

Store listings on different accounts. It is more convenient for the client when both listings belong to them: Google Play allows transferring an app between developer accounts without changing the package or the install history, and this belongs in the handover plan.

What was not measured. The case has no business or stability metrics.

13 In brief for a client with a similar app

What problem the app solved

A community gives its members real-world tasks and rewards them for completing them. The Qela app verifies completion on the phone: check-in works only within the point’s radius, an online meeting is confirmed by a QR code, photos are uploaded to the quest, and disputed quests are reviewed by an administrator. Rewards and voting weight rest on confirmed activity.

What Chyzh Agency did

• separate native apps: Android in Java, iOS in Swift;
• verification mechanisms: check-in radius, QR, photo upload, review status, blocking of repeat completion;
• notifications about the administrator’s decision and quest review statuses;
• QA on both platforms and support: tracker tasks run until February 2026.

Confirmed results

What to plan for in a similar project

First the way to prove an action, then the screens. If an app grants rewards for actions, each action type needs its own proof. Each proof has its own failure scenario: a person outside the zone, no camera permission, a quest under review. Describe them before development. Budget separate testing for each platform and a separate fix budget for each.