Η επιλογή εταιρείας για mobile app στην Αθήνα γίνεται συνήθως ανάποδα. Ζητάτε προσφορά από τρία ή τέσσερα γραφεία, συγκρίνετε τα portfolio, συγκρίνετε τις τιμές, και αποφασίζετε με βάση τα δύο πράγματα που σας λένε τα λιγότερα για το τι θα ακολουθήσει. Ένα portfolio δείχνει τι μπόρεσε να σχεδιάσει μια ομάδα μία φορά. Μια τιμή δείχνει τι πιστεύει ότι θέλετε να ακούσετε. Κανένα από τα δύο δεν λέει τι γίνεται τον δεύτερο χρόνο, εκεί όπου βρίσκεται το μεγαλύτερο μέρος του κόστους ενός app και σχεδόν όλος ο κίνδυνος.
Καλύτερος τρόπος είναι να κάνετε τις ίδιες λίγες ερωτήσεις σε όλους, στην πρώτη συνάντηση, και να προσέξετε λιγότερο την απάντηση και περισσότερο τον τρόπο που δίνεται. Μια ομάδα που έχει βγάλει και συντηρήσει apps απαντά γρήγορα, συγκεκριμένα και μερικές φορές άβολα. Μια ομάδα που κυρίως τα έχει πουλήσει απαντά με επίθετα.
Η πρώτη ερώτηση είναι αν χρειάζεστε καν app. Κάντε την ευθέως, και περιμένετε να ακούσετε και αντιρρήσεις. Αν το προϊόν είναι περιεχόμενο, μια κάρτα επιβράβευσης ή μια φόρμα που συμπληρώνεται δύο φορές τον χρόνο, ένα γρήγορο website ή ένα web app που εγκαθίσταται στο κινητό κάνει το μεγαλύτερο μέρος της δουλειάς, χωρίς να εξαρτάστε από τους κανόνες δύο stores. Μια εταιρεία που δεν έχει αποτρέψει ποτέ έναν πελάτη από ένα app δεν σας συμβουλεύει. Σας δίνει προσφορά. Η καλή απάντηση ακούγεται σαν ερώτηση προς εσάς: πόσο συχνά θα το ανοίγουν οι άνθρωποι, και τι θα κάνει που δεν μπορεί να κάνει ο browser;
Η δεύτερη είναι ποιος φτιάχνει το backend. Κάθε app μιλά με ένα API. Τα περισσότερα προβληματικά έργα app έχουν μία κοινή αιτία. Μια ομάδα mobile χρησιμοποιεί ένα API γραμμένο για website, ανακαλύπτει την τρίτη εβδομάδα ότι επιστρέφει δεδομένα σε λάθος μορφή, και διαπραγματεύεται αλλαγές με μια άλλη ομάδα που έχει άλλες προτεραιότητες. Ρωτήστε ποιος γράφει το API, ποιος το φιλοξενεί, και αν θα είναι κοινό με το website σας ή ένα δεύτερο δίπλα του. Η καλή απάντηση είναι μία ομάδα και ένα API, με το website και το app ως δύο χρήστες του.
Η τρίτη είναι native ή cross-platform, και γιατί. Καμία από τις δύο απαντήσεις δεν είναι λάθος από μόνη της. Λάθος είναι μια απάντηση που δίνεται πριν γίνουν γνωστές οι λειτουργίες. Native σημαίνει χωριστός κώδικας για iOS και Android. Cross-platform σημαίνει ένας κοινός κώδικας για τα δύο. Μια σοβαρή εταιρεία mobile app στην Αθήνα θα ρωτήσει τι πρέπει να κάνει το app που αγγίζει το λειτουργικό σύστημα: συνεχή τοποθεσία στο παρασκήνιο, Bluetooth, app για ρολόι, βαριά γραφικά, ένα SDK προμηθευτή που υπάρχει μόνο σε native κώδικα. Και θα αποφασίσει από αυτή τη λίστα. Αν η απάντηση έρθει στα πρώτα πέντε λεπτά και θα ήταν ίδια για οποιοδήποτε έργο, είναι συνήθεια, όχι σύσταση.
Η τέταρτη είναι ποιος δημοσιεύει το app, και με ποιο όνομα. Ρωτήστε ποιος ετοιμάζει τις σελίδες στα stores, ποιος απαντά στον έλεγχο του App Store και του Google Play, και σε ποιον λογαριασμό developer θα βρίσκεται το app. Η απάντηση που πρέπει να σας ανησυχήσει είναι ο λογαριασμός της ίδιας της εταιρείας χωρίς πλάνο μεταφοράς. Το app, η σελίδα του, οι κριτικές του και οι χρήστες του ανήκουν στον δικό σας λογαριασμό, με την εταιρεία προσκεκλημένη ως μέλος της ομάδας. Η μεταφορά ενός app από λογαριασμό σε λογαριασμό αργότερα γίνεται, αλλά είναι αργή. Και κανείς δεν θέλει να την κάνει μέσα σε μια διαφωνία.
Η πέμπτη είναι τι γίνεται μετά το λανσάρισμα, και οι περισσότερες προτάσεις την αφήνουν κενή. Δύο νέες εκδόσεις λειτουργικού τον χρόνο. Η ετήσια απαίτηση του Google Play για την έκδοση API στόχου. Οι περιοδικοί κανόνες της Apple για την ιδιωτικότητα και τη σύνδεση. Εξαρτήσεις που παλιώνουν και πιστοποιητικά που λήγουν. Ρωτήστε πώς παρακολουθεί η ομάδα τα crashes, πώς βγαίνει μια έκδοση πρώτα σε ένα μικρό ποσοστό χρηστών, και πώς διορθώνεται ένα bug όταν ο έλεγχος του store είναι το εμπόδιο. Μια καλή απάντηση ονομάζει εργαλεία και διαδικασία: αναφορές crashes ανά έκδοση, σταδιακή διάθεση, διορθώσεις over-the-air (χωρίς νέα έκδοση στο store) για το κομμάτι JavaScript ενός app σε React Native. Μια αόριστη απάντηση σημαίνει ότι τη συντήρηση θα την ανακαλύψετε, και θα την πληρώσετε, αργότερα.
Η έκτη είναι τι σας ανήκει όταν τελειώσει η συνεργασία. Ο κώδικας, τα αρχεία του design, τα δεδομένα, οι λογαριασμοί developer και οι σελίδες στα stores πρέπει να είναι γραπτώς δικά σας. Το ίδιο και μια απλή περιγραφή του πώς φεύγετε, αν χρειαστεί. Ζητήστε τα σε χαρτί πριν από το πρώτο τιμολόγιο. Μια εταιρεία σίγουρη για τη δουλειά της δεν έχει λόγο να κάνει δύσκολη την αποχώρηση. Όσες την κάνουν δύσκολη συνήθως το εξηγούν στα ψιλά γράμματα, όχι στη συνάντηση.
Μετά, μερικά σημάδια που αξίζουν περισσότερο από κάθε παρουσίαση. Ζητήστε να εγκαταστήσετε κάτι που έχει βγάλει η ομάδα και συντηρεί ακόμη, όχι ένα βίντεο case study. Κατεβάστε το από το App Store ή το Google Play και χρησιμοποιήστε το για δέκα λεπτά. Ρωτήστε ποιος θα γράψει πραγματικά τον κώδικα, και γνωρίστε τον. Ρωτήστε τι πήγε στραβά στο τελευταίο έργο και πώς το χειρίστηκαν. Μια ομάδα που δεν μπορεί να ονομάσει τίποτα είτε είναι καινούργια είτε δεν είναι ειλικρινής μαζί σας. Και προσέξτε αν η πρόταση έχει σαφές γραπτό αντικείμενο και πλάνο εκδόσεων, ή μόνο μια τιμή και μια ημερομηνία παράδοσης.
Η τοποθεσία μετράει λιγότερο απ' ό,τι παλιά, αλλά μετράει ακόμη. Μια εταιρεία στην Αθήνα μπορεί να κάθεται στο ίδιο τραπέζι μαζί σας στα workshops όπου αποφασίζεται το προϊόν. Ξέρει ότι οι Έλληνες πελάτες περιμένουν δόσεις και τιμολόγιο με ΑΦΜ. Και δουλεύει τις ίδιες ώρες με τους ανθρώπους που θα αναφέρουν τα bugs. Τίποτα από αυτά δεν αντικαθιστά τις έξι ερωτήσεις. Για ένα προϊόν όμως που θα αλλάζει κάθε μήνα για χρόνια, το να μπορείτε να βρεθείτε ένα απόγευμα Τρίτης είναι πρακτικό πλεονέκτημα, όχι συναισθηματικό.
Αν σας ενδιαφέρει, αυτές είναι οι ερωτήσεις που θα θέλαμε να μας κάνουν. Φτιάχνουμε apps για iOS και Android στην Αθήνα, σε React Native και Expo ως βάση και σε native κώδικα όπου το απαιτεί το προϊόν, πάνω στην ίδια πλατφόρμα Node.js και PostgreSQL που τρέχει το website του πελάτη. Έτσι είναι φτιαγμένο και έτσι συντηρείται το app TRVL AIR, που βρίσκεται και στα δύο stores από τον Σεπτέμβριο του 2026. Αν η ειλικρινής απάντηση στην πρώτη ερώτηση είναι ότι δεν χρειάζεστε app, θα σας το πούμε στην πρώτη συνάντηση.
Common questions
- Πώς διαλέγω εταιρεία κατασκευής mobile app στην Αθήνα;
- Κάντε σε κάθε υποψήφιο τις ίδιες ερωτήσεις στην πρώτη συνάντηση: αν χρειάζεστε καν app, ποιος φτιάχνει και φιλοξενεί το backend, πώς θα αποφασιστεί αν θα είναι native ή cross-platform, σε ποιον λογαριασμό developer θα βρίσκεται το app, πώς θα συντηρείται μετά το λανσάρισμα, και τι σας ανήκει όταν τελειώσει η δουλειά. Μετά εγκαταστήστε ένα app που συντηρεί ακόμη η ομάδα και γνωρίστε τους ανθρώπους που θα γράψουν τον κώδικα.
- Το app πρέπει να δημοσιευτεί στον δικό μας λογαριασμό developer ή της εταιρείας;
- Στον δικό σας. Οι λογαριασμοί developer στο App Store και στο Google Play, οι σελίδες στα stores, οι κριτικές και οι χρήστες πρέπει να ανήκουν στην επιχείρηση που έχει το app, με την εταιρεία προσθεμένη ως μέλος της ομάδας. Η μεταφορά ενός app από λογαριασμό σε λογαριασμό αργότερα γίνεται, αλλά είναι αργή και αναστατώνει.
- Τι πρέπει να περιλαμβάνει μια πρόταση για app εκτός από την τιμή;
- Γραπτό αντικείμενο, τις πλατφόρμες και πώς επιλέχθηκαν, ποιος φτιάχνει το API, πλάνο εκδόσεων αντί για μία ημερομηνία παράδοσης, πώς παρακολουθούνται τα crashes και πώς βγαίνουν διορθώσεις μετά το λανσάρισμα, την ετήσια συντήρηση που θα χρειαστεί το app, και τι ανήκει γραπτώς στον πελάτη: κώδικας, αρχεία design, δεδομένα και λογαριασμοί στα stores.
- Έχει σημασία αν η εταιρεία είναι στην Αθήνα;
- Λιγότερη από τις ερωτήσεις για την κυριότητα, το backend και τη συντήρηση, αλλά βοηθά. Μια εταιρεία στην Αθήνα μπορεί να είναι παρούσα στα workshops του προϊόντος, δουλεύει τις ίδιες ώρες με την ομάδα που αναφέρει τα bugs, και ξέρει ήδη τι περιμένουν οι Έλληνες πελάτες στο checkout, όπως δόσεις και τιμολόγια με ΑΦΜ.
The service behind it
Mobile App Development
Native και cross-platform εφαρμογές για iOS και Android, με την ίδια φροντίδα στον σχεδιασμό του interface όση και στον κώδικα.