Κόστος web εφαρμογής: οι παράγοντες που το καθορίζουν

Το κόστος μιας web εφαρμογής καθορίζεται κυρίως από τους ρόλους των χρηστών και τις ροές εργασίας, τις διασυνδέσεις με άλλα συστήματα, τις απαιτήσεις ασφάλειας και δεδομένων και τη φροντίδα μετά την παράδοση. Αν αυτά οριστούν πριν ζητήσετε προσφορά, οι προτάσεις που θα λάβετε γίνονται συγκρίσιμες και το έργο χωρίζεται σε φάσεις με σαφές αποτέλεσμα.

Τι κάνει μια web εφαρμογή πιο απαιτητική από μια ιστοσελίδα;

Μια ιστοσελίδα παρουσιάζει πληροφορίες. Μια web εφαρμογή εκτελεί δουλειά: δέχεται αιτήματα, ελέγχει δικαιώματα, αποθηκεύει δεδομένα, εφαρμόζει κανόνες και ειδοποιεί ανθρώπους. Παραδείγματα είναι ένα portal πελατών, ένα σύστημα κρατήσεων, ένα εσωτερικό εργαλείο παραγγελιών ή μια πλατφόρμα για συνεργάτες.

Η διαφορά φαίνεται στο πού πηγαίνει ο χρόνος. Σε μια ιστοσελίδα, το μεγαλύτερο μέρος της δουλειάς είναι ο σχεδιασμός και το περιεχόμενο. Σε μια web εφαρμογή είναι η λογική: τι γίνεται όταν δύο χρήστες αλλάζουν το ίδιο στοιχείο, όταν μια πληρωμή αποτυγχάνει ή όταν ένα αίτημα μένει αναπάντητο για μέρες. Αυτές οι περιπτώσεις δεν φαίνονται σε ένα σχέδιο οθόνης, αλλά καθορίζουν τον χρόνο ανάπτυξης και ελέγχων.

Αν χρειάζεστε κυρίως παρουσίαση της επιχείρησης, μια εταιρική ιστοσελίδα είναι μικρότερο και πιο προβλέψιμο έργο. Αν όμως το σύστημα θα δουλεύει για την ομάδα ή τους πελάτες σας, δείτε πώς οργανώνουμε την κατασκευή web εφαρμογών και custom λογισμικού.

Ρόλοι χρηστών και ροές εργασίας

Κάθε ρόλος χρήστη πολλαπλασιάζει οθόνες, δικαιώματα και ελέγχους. Ένας διαχειριστής, ένας υπάλληλος, ένας πελάτης και ένας συνεργάτης βλέπουν διαφορετικά δεδομένα και κάνουν διαφορετικές ενέργειες. Όταν προστίθενται εξαιρέσεις, όπως ένας υπάλληλος που βλέπει μόνο τους πελάτες του δικού του καταστήματος, τα δικαιώματα γίνονται ξεχωριστό κομμάτι του έργου.

Οι ροές εργασίας είναι ο δεύτερος πολλαπλασιαστής. Ένα αίτημα μπορεί να περνά από τις καταστάσεις «νέο», «σε έλεγχο», «εγκρίθηκε», «ολοκληρώθηκε» και «ακυρώθηκε». Για κάθε μετάβαση ορίζετε ποιος την κάνει, ποιος ειδοποιείται και τι καταγράφεται στο ιστορικό.

Πριν ζητήσετε προσφορά, ετοιμάστε:

• τη λίστα των ρόλων και τι επιτρέπεται σε καθέναν
• τις βασικές ροές, με τις καταστάσεις τους
• τις εξαιρέσεις που συμβαίνουν συχνά στην πράξη
• ποιος ειδοποιείται σε κάθε βήμα και με ποιον τρόπο

Δεν χρειάζεται τεχνική γλώσσα. Ένα διάγραμμα στο χαρτί ή μια λίστα με τα βήματα όπως γίνονται σήμερα αρκεί για να φανεί το μέγεθος του έργου.

Ποιες διασυνδέσεις ανεβάζουν την προσπάθεια;

Οι διασυνδέσεις είναι συχνά το πιο αβέβαιο κομμάτι, γιατί εξαρτώνται από ένα σύστημα που δεν ελέγχετε εσείς. Ο πίνακας δείχνει τι ρωτάτε για την καθεμία:

Για κάθε διασύνδεση ρωτήστε και τι γίνεται όταν το άλλο σύστημα δεν απαντά. Μια σωστή υλοποίηση κρατά τα αιτήματα σε ουρά, ξαναδοκιμάζει και ειδοποιεί κάποιον όταν κάτι αποτύχει οριστικά, αντί να χάνει σιωπηλά μια παραγγελία.

Η ηλεκτρονική τιμολόγηση θέλει ιδιαίτερη προσοχή. Η απόφαση Α.1128/2025 της ΑΑΔΕ ορίζει τη σταδιακή υποχρεωτική έκδοση ηλεκτρονικών τιμολογίων στις συναλλαγές μεταξύ επιχειρήσεων. Αν η εφαρμογή σας εκδίδει παραστατικά, η σύνδεση με πάροχο ηλεκτρονικής τιμολόγησης είναι μέρος του έργου και όχι λεπτομέρεια για αργότερα.

Αναφορές, δεδομένα και μεταφορά από το παλιό σύστημα

Οι αναφορές μοιάζουν απλές μέχρι να οριστούν. Η φράση «θέλουμε στατιστικά» μπορεί να σημαίνει έναν πίνακα με εξαγωγή σε Excel ή έναν πίνακα ελέγχου με φίλτρα, συγκρίσεις περιόδων και γραφήματα. Η διαφορά στην προσπάθεια είναι μεγάλη, γι' αυτό γράψτε ποιες ερωτήσεις πρέπει να απαντά κάθε αναφορά και ποιος τη διαβάζει.

Η μεταφορά δεδομένων υποτιμάται εύκολα. Αν σήμερα δουλεύετε με αρχεία Excel ή με παλιό πρόγραμμα, τα δεδομένα θα χρειαστούν καθάρισμα: διπλές εγγραφές, κενά πεδία, διαφορετικές μορφές ημερομηνίας, ο ίδιος πελάτης γραμμένος με τρεις τρόπους. Η μεταφορά θέλει δοκιμαστικές εισαγωγές, έλεγχο από τους ανθρώπους που ξέρουν τα δεδομένα και σχέδιο για την ημέρα της αλλαγής.

Ρωτήστε επίσης πού αποθηκεύονται τα δεδομένα, πόσο συχνά παίρνονται αντίγραφα ασφαλείας και πόσο γρήγορα μπορεί να γίνει επαναφορά μετά από ένα πρόβλημα. Οι απαντήσεις επηρεάζουν άμεσα τη φιλοξενία, την ασφάλεια και τη συντήρηση της εφαρμογής.

Τι ζητούν η ασφάλεια, ο GDPR και η προσβασιμότητα;

Η ασφάλεια δεν είναι πρόσθετο. Το OWASP Top 10 καταγράφει τους πιο κρίσιμους κινδύνους για web εφαρμογές και είναι καλή βάση για να ρωτήσετε πώς ελέγχεται η πρόσβαση, πώς φυλάσσονται οι κωδικοί και πώς ενημερώνονται οι βιβλιοθήκες. Ρωτήστε επίσης αν οι διαχειριστές συνδέονται με έλεγχο ταυτότητας δύο παραγόντων και αν καταγράφονται οι ενέργειές τους.

Αν η εφαρμογή επεξεργάζεται προσωπικά δεδομένα, ο Γενικός Κανονισμός για την Προστασία Δεδομένων ζητά προστασία ήδη από τον σχεδιασμό (άρθρο 25) και μέτρα ασφάλειας ανάλογα με τον κίνδυνο (άρθρο 32), όπως κρυπτογράφηση και δυνατότητα έγκαιρης επαναφοράς. Στην πράξη αυτό σημαίνει ρόλους, καταγραφή ενεργειών και διαδικασίες που σχεδιάζονται από την αρχή.

Για υπηρεσίες προς καταναλωτές, όπως το ηλεκτρονικό εμπόριο, η οδηγία για την προσβασιμότητα προϊόντων και υπηρεσιών ισχύει για όσες παρέχονται μετά τις 28 Ιουνίου 2025, με εξαίρεση τις πολύ μικρές επιχειρήσεις που παρέχουν υπηρεσίες. Οι οδηγίες WCAG 2.2 του W3C είναι το πιο διαδεδομένο σημείο αναφοράς για τους σχετικούς ελέγχους.

Φιλοξενία και συντήρηση μετά την παράδοση

Μια web εφαρμογή τρέχει σε server που πρέπει να παρακολουθείται, να ενημερώνεται και να έχει αντίγραφα ασφαλείας. Η φιλοξενία εξαρτάται από τον αριθμό των χρηστών, τον όγκο των δεδομένων, τις εργασίες που τρέχουν στο παρασκήνιο και το πόσο κρίσιμη είναι η διαθεσιμότητα για τη δουλειά σας.

Ο κώδικας χρειάζεται κι αυτός φροντίδα, γιατί τα frameworks έχουν περιορισμένη περίοδο υποστήριξης. Για παράδειγμα, η πολιτική υποστήριξης του Laravel δίνει σε κάθε έκδοση διορθώσεις σφαλμάτων για 18 μήνες και διορθώσεις ασφαλείας για 2 χρόνια, ενώ νέα μεγάλη έκδοση κυκλοφορεί κάθε χρόνο. Μια εφαρμογή που δεν ενημερώνεται μένει κάποια στιγμή χωρίς διορθώσεις ασφαλείας.

Γι' αυτό η συντήρηση και υποστήριξη συμφωνείται μαζί με την ανάπτυξη: τι περιλαμβάνει, πόσο γρήγορα αντιμετωπίζεται ένα πρόβλημα και πώς γίνονται οι μικρές αλλαγές. Αν το αφήσετε για μετά την παράδοση, θα το συζητάτε τη στιγμή που κάτι δεν λειτουργεί. Ζητήστε επίσης δοκιμαστικό περιβάλλον (staging), όπου κάθε αλλαγή ελέγχεται πριν φτάσει στους χρήστες σας.

Πώς χωρίζεται το έργο σε φάσεις;

Ένα έργο χωρισμένο σε φάσεις έχει μικρότερο ρίσκο από ένα ενιαίο, γιατί κάθε φάση τελειώνει με κάτι που λειτουργεί και μπορείτε να το ελέγξετε. Μια συνηθισμένη σειρά είναι:

1. Ανάλυση και πρωτότυπο οθονών, για να συμφωνήσετε στο τι θα φτιαχτεί.
2. Πρώτη έκδοση με τη βασική ροή, τους κύριους ρόλους και τις απαραίτητες διασυνδέσεις.
3. Πιλοτική χρήση από λίγους χρήστες και διορθώσεις.
4. Επεκτάσεις, αναφορές και αυτοματισμοί, με προτεραιότητες από την πραγματική χρήση.

Η ίδια λογική ισχύει και στις εφαρμογές για κινητά, όπως εξηγούμε στον οδηγό για το κόστος κατασκευής εφαρμογής κινητού, όπου θα βρείτε και τα βήματα ενός MVP.

Ζητήστε για κάθε φάση ξεχωριστό εύρος, χρόνο και παραδοτέα. Έτσι μπορείτε να σταματήσετε ή να αλλάξετε κατεύθυνση μετά από κάθε φάση, χωρίς να χάσετε όσα έχουν ήδη γίνει. Για την πρώτη φάση, ένα σταθερό εύρος δίνει βεβαιότητα. Για τις επόμενες, που εξαρτώνται από την πραγματική χρήση, ταιριάζει συχνά μια πιο ευέλικτη συμφωνία με προτεραιότητες ανά διάστημα.

Τι ρωτάτε πριν υπογράψετε;

Πριν υπογράψετε, βεβαιωθείτε ότι έχετε γραπτές απαντήσεις στα εξής:

• Σε ποιον ανήκει ο κώδικας και σε ποιο repository φυλάσσεται.
• Σε ποιον ανήκουν οι λογαριασμοί φιλοξενίας, domain και υπηρεσιών τρίτων.
• Ποια τεκμηρίωση παραδίδεται, ώστε να μπορεί να συνεχίσει και άλλη ομάδα.
• Ποια είναι τα κριτήρια αποδοχής κάθε φάσης.
• Πώς ζητάτε αλλαγές και πώς εκτιμάται η επίδρασή τους στο χρονοδιάγραμμα.
• Τι καλύπτει η εγγύηση για σφάλματα μετά την παράδοση.
• Πώς προστατεύονται τα δεδομένα και ποιος έχει πρόσβαση σε αυτά.
• Ποιος κάνει τις ενημερώσεις ασφαλείας και πόσο συχνά.
• Τι παραλαμβάνετε (κώδικα, δεδομένα, κωδικούς πρόσβασης) αν η συνεργασία σταματήσει.

Οι απαντήσεις δεν αλλάζουν μόνο την προσφορά. Δείχνουν αν ο συνεργάτης σκέφτεται την εφαρμογή και μετά την παράδοση ή μόνο μέχρι αυτήν. Μια πρόταση που απαντά καθαρά σε όλα αυτά είναι συχνά πιο χρήσιμη από μια πιο σύντομη που τα αφήνει ανοιχτά.

Πώς το προσεγγίζουμε στη DarkLabs

Στη DarkLabs φτιάχνουμε web εφαρμογές με Laravel στο backend και Vue ή React με Inertia στο frontend. Με το Inertia, οι οθόνες συνδέονται απευθείας με τη λογική του Laravel χωρίς ξεχωριστό API, οπότε ο κώδικας που χρειάζεται συντήρηση μένει μικρότερος. Κάθε έργο περνά από πέντε στάδια:

1. Γνωριμία και ανάλυση: καταγράφουμε ρόλους, ροές και διασυνδέσεις.
2. Σχεδιασμός οθονών: βλέπετε τις βασικές ροές πριν γραφτεί κώδικας.
3. Ανάπτυξη και έλεγχοι, φάση προς φάση.
4. Παράδοση και δημοσίευση.
5. Υποστήριξη και εξέλιξη, με ενημερώσεις, διορθώσεις και τις επόμενες φάσεις.

Αν σχεδιάζετε πλατφόρμα, portal ή εσωτερικό σύστημα, στείλτε μας τη λίστα με τους ρόλους και τις ροές σας. Είναι η πιο χρήσιμη αφετηρία για μια εκτίμηση που μπορείτε να συγκρίνετε. Περισσότερους οδηγούς θα βρείτε στην κατηγορία web εφαρμογές.