The institution's mobile apps

The problem

The institution serves three audiences: visitors buying tickets, travel agencies buying in bulk and staff following sales. All three needed information and transactions on their phones.

My role

Sole developer: building the three apps, connecting them to the shared API layer and publishing them on the stores.

The apps

Milli Saraylar: Saray Müzeleri

Official app for visitors: palaces, pavilions and museums with opening hours and location; e-ticket purchase with 3D Secure payment and the QR ticket kept on the phone; sales of National Palaces publications. Turkish and English.

App Store · Google Play

Milli Saraylar Acente

Ticket and account operations for travel agencies working with the institution. Available to authorised agencies only.

Milli Saraylar Yönetim

Reporting app for the institution's staff. Available to authorised staff only.

Outcome

• Visitors buy tickets in the app and carry the QR code on their phone; agencies handle balance and tickets without visiting the box office; managers reach reports away from their desks.

Decisions I made

• Three apps, one API: the apps carry no back end of their own; they connect to the institution's shared API layer, so every rule that applies on the web and at the box office applies in the apps too.
• A separate app per audience: visitors, agencies and staff need very different things. Instead of one complicated app, each audience gets a simple app focused on its own job.
• The QR code on the phone: visitors buy in the app and scan the same screen at the turnstile, with no printout or email to look for.

Technologies

• Mobile: iOS and Android
• Backend: The institution's shared REST API layer