PHP un Laravel: ko šī izvēle nozīmē uzņēmumam, kas pasūta sistēmu

Piedāvājums pienāk piektdienas pēcpusdienā, un tā tehniskajā daļā ir divas rindas, kuras sanāksmē neviens neizlasa skaļi: „PHP 8.4“ un „Laravel 13“. Cena ir saprotama, termiņš ir saprotams, un šīs divas rindas izskatās pēc piegādātāja iekšējās virtuves — apmēram tikpat svarīgas kā tas, ar kuru urbi tiks izurbts caurums sienā, un tāpēc tās parasti pārlaiž kā tehnisku detaļu, par kuru atbild kāds cits. Paraksts tomēr nāk zem visa dokumenta, un tieši šīs divas rindas nosaka, cik ilgi sistēma vispār saņems drošības labojumus, kas tajā izrakstīs ikmēneša rēķinu papildus izstrādes cenai un cik dārga pēc trim gadiem būs tās nodošana kādam citam.

Šis raksts nav par to, vai PHP ir laba valoda un vai Laravel ir labs ietvars, jo uz šo jautājumu izstrādātāji atbild savā starpā un pircējam no tās sarunas nav nekāda praktiska labuma. Tas ir par četrām lietām, kuras pircējs var pārbaudīt pats un bez tehniskām zināšanām: atbalsta kalendāru, licenci, darba tirgu un nodošanas nosacījumiem. Visas četras ir publiskas, trīs no tām ir vai nu datumi, vai naudas summas, ceturtā ir tas, ko par tirgu var un nevar zināt, un neviena no tām nav atkarīga no tā, cik pārliecinoši piedāvājums ir uzrakstīts — tāpēc tās der pārbaudīt tieši tajā nedēļā, kad par cenu vēl var runāt.

Kas ir valoda, kas ir ietvars, un kāpēc tā nav viena izvēle

PHP ir programmēšanas valoda, kurā uzrakstīta sistēmas servera puse — tā daļa, kas strādā pie piegādātāja vai Jūsu mitinātāja un ko lietotājs nekad neredz. Laravel savukārt ir ietvars, tas ir, PHP valodā jau uzrakstīta koda bāze, kura atrisina to, kas atkārtojas gandrīz katrā projektā: lietotāju pieteikšanos, datubāzes vaicājumus, rindas, failu glabāšanu, e-pastu sūtīšanu. Piedāvājumā tie stāv blakus kā viena izvēle, taču tie ir divi atsevišķi produkti, kurus divas dažādas komandas uztur ar diviem dažādiem atbalsta kalendāriem, un tieši tāpēc tos ir vērts izlasīt atsevišķi.

Cik izplatīta ir valoda, izrādās grūtāk pateikt, nekā gaidītu. W3Techs, kas regulāri skenē vairāk nekā divdesmit miljonus vietņu, 2026. gada 1. septembra datos norāda, ka PHP izmanto 70,2 % no visām vietnēm, kuru servera puses programmēšanas valodu šis rīks zina. Pēdējais nosacījums ir tas, kas parasti pazūd, kad skaitli pārraksta prezentācijā: runa nav par 70 % no visām pasaules vietnēm, bet par 70 % no tām, kuras šis konkrētais rīks vispār spēj atpazīt, turklāt daļu no atpazīšanas tas pats apraksta kā izsecinātu netieši — ja lapa ir WordPress, tad tā ir PHP.

Pircējam noderīgāks ir cits skaitlis no W3Techs PHP versiju vēstures. Saskaņā ar 2026. gada 1. septembra datiem starp vietnēm, kurām W3Techs nosaka arī PHP versiju, 63,3 % strādā uz astotās, 28,7 % uz septītās un 7,9 % joprojām uz piektās, lai gan septītās versijas pēdējais zars 7.4 zaudēja pat drošības labojumus jau 2022. gada 28. novembrī. Tas nozīmē, ka aptuveni trešdaļa no izmērāmā PHP interneta tobrīd darbojās uz koda, kuram vairs neviens netaisīja ielāpus, un tas nav noticis tāpēc, ka valoda būtu slikta vai ka kāds būtu izdarījis kļūdu izstrādē. Tas ir noticis tāpēc, ka neviens nav pasūtījis un apmaksājis versijas maiņu, un šī ir tieši tā riska daļa, kuru pircējs var gan ieraudzīt, gan vadīt.

PHP atbalsta kalendārs ir pirmais dokuments, ko vērts atvērt

PHP izstrādātāju grupas noteikums ir īss un publisks: katrs versiju zars saņem pilnu atbalstu divus gadus no pirmā stabilā laidiena, pēc tam vēl divus gadus tikai kritiskus drošības labojumus, un pēc četriem gadiem tas vairs netiek uzturēts vispār. Šajā noteikumā ir viena detaļa, kuru pārstāstos gandrīz vienmēr izlaiž: patiesie beigu datumi tabulā ir pieskaņoti gada pēdējai dienai, nevis laidiena gadadienai novembrī, tāpēc „divi gadi no laidiena“ un tas, kas rakstīts php.net tabulā, atšķiras par mēnesi vai diviem.

Praktiski tas nozīmē šādu kārtību. Versija 8.2 saņem tikai drošības labojumus, un tās atbalsts beidzas 2026. gada 31. decembrī. Versija 8.3 pilno atbalstu zaudēja 2025. gada beigās un drošības labojumus saņems līdz 2027. gada beigām. Versija 8.4 pilno atbalstu saņem līdz 2026. gada beigām un drošības labojumus līdz 2028. gada beigām, savukārt 8.5, kas iznāca 2025. gada novembrī, pilnu atbalstu saņem līdz 2027. gada beigām un drošības labojumus līdz 2029. gada beigām.

Versijas 8.1 atbalsts beidzās 2025. gada 31. decembrī, un tieši šis gadījums ir uzmanības vērts, ja Jums jau ir sistēma, nevis piedāvājums. Ja piegādātājs pirms trim gadiem uzrakstīja to uz 8.1 un kopš tā laika neviens neko nav mainījis, tad tā šodien strādā uz zara, kuram drošības ielāpi vairs nenāk, un par to nebrīdina ne serveris, ne pārlūks, ne pati sistēma. Lapa atveras tieši tāpat kā vakar, klienti neko nepamana, un vienīgā vieta, kur to var ieraudzīt, ir šī pati publiskā tabula, kuras atvēršana aizņem mazāk laika nekā piedāvājuma titullapas izlasīšana.

Laravel kalendārs ir īsāks nekā PHP kalendārs

Laravel savu politiku formulē vēl īsāk: kļūdu labojumi astoņpadsmit mēnešus, drošības labojumi divus gadus, un jauna galvenā versija katru gadu aptuveni pirmajā ceturksnī. Ilgtermiņa atbalsta laidiena, ko nozarē sauc par LTS, šodien vairs nav — vecajās versijās tāds tiešām bija, taču 2026. gada tabulā tādas ailes nav vispār, tāpēc piedāvājums, kurā rakstīts „LTS Laravel“, apraksta laidienu, kāda šobrīd nav. Tas ir īsāks solījums, nekā daudzi pircēji sagaida no ietvara, uz kura tiks būvēta sistēma nākamajiem pieciem gadiem.

Skaitļos, pēc pašas Laravel dokumentācijas, kārtība ir šāda. Laravel 13 iznāca 2026. gada martā, kļūdu labojumus saņems līdz 2027. gada trešajam ceturksnim, bet drošības labojumus — līdz 2028. gada 17. martam. Laravel 12 kļūdu labojumu logs aizvērās 2026. gada 13. augustā, un tā drošības labojumi beigsies 2027. gada 24. februārī. Laravel 11 drošības atbalsts beidzās 2026. gada 12. martā, tātad sistēma, kas šodien strādā uz vienpadsmitās versijas, jau strādā bez ielāpiem, lai cik labi tā izskatītos no ārpuses.

Pievērsiet uzmanību tam, ka Laravel 13 kļūdu labojumu beigas ir norādītas kā ceturksnis, nevis kā konkrēts datums. Tā ir pašu Laravel formulējuma neprecizitāte, un tā nav problēma, kamēr to pārraksta tieši tā, kā tur stāv; problēma sākas brīdī, kad piegādātājs vai pircējs noapaļo to līdz konkrētai dienai un pēc tam plāno budžetu pēc skaitļa, kura avotā nav. Vēl viena robeža, kas jāzina, pirms tiek izvēlēta versija: Laravel 13 prasa vismaz PHP 8.3, tāpēc sistēmu uz trīspadsmitās versijas nevar atstāt uz 8.2 pat tad, ja pati 8.2 vēl kādu laiku saņemtu drošības labojumus.

Ko abi kalendāri kopā nozīmē sistēmai, kuru pasūtāt šodien

Ja sistēma tiek nodota uz Laravel 13 kopā ar PHP 8.4 vai 8.5, tad pirmais datums, kurā kaut kam obligāti jākustas, ir 2028. gada 17. marts, kad beidzas Laravel drošības labojumi. PHP šajā salikumā nav ierobežojums, jo abi šie zari drošības labojumus saņem ilgāk nekā ietvars, tāpēc pirmais, kas noveco, ir Laravel, nevis valoda. Tas ir arī vienīgais godīgais veids, kā atbildēt uz jautājumu „cik ilgi šī sistēma nostāvēs bez papildu ieguldījuma“ — nevis ar sajūtu, bet ar agrāko no diviem publiskiem datumiem.

Ja tā pati sistēma tiek nodota uz Laravel 13, bet PHP 8.3, tad kārtība apgriežas otrādi un pirmais termiņš pienāk 2027. gada 31. decembrī, kad beidzas šī PHP zara drošības labojumi. Ja piegādātājs raksta uz Laravel 12, kas esošam projektam joprojām ir pilnīgi normāla izvēle, tad drošības labojumi beidzas 2027. gada 24. februārī, un līdz šim datumam sistēma jāpārceļ uz atbalstītu galveno versiju. Starpība starp pirmo un trešo variantu ir gads, ko var nopelnīt vienā sarunā pirms līguma un ko pēc paraksta vairs nopirkt nevar.

Divas kļūdas šajā rēķinā ir tik izplatītas, ka tās ir vērts nosaukt atsevišķi. Pirmā ir sajaukt pilno atbalstu ar drošības atbalstu, tāpēc, dzirdot, ka „PHP 8.4 atbalsts beidzas gada beigās“, ir vērts pajautāt, kurš no diviem logiem ir domāts: beidzas parasto kļūdu labošana, bet drošības labojumi nāk vēl divus gadus. Otrā ir noticēt pašu Laravel teikumam, ka pāreja uz jaunu galveno versiju parasti aizņemot dienu vai mazāk; tas ir izstrādātāju formulēts mērķis, nevis izmērīts vidējais, un līgumā to kā termiņu ierakstīt nevar.

Licence maksā nulli, un tas ir patiesība tikai par valodu un ietvaru

Laravel ietvars tiek izplatīts ar MIT licenci, kas ir viena no vienkāršākajām atvērtā pirmkoda licencēm un ļauj kodu izmantot, mainīt un pārdot tālāk, prasot vien saglabāt autortiesību paziņojumu un licences tekstu. Ar PHP ir nedaudz sarežģītāk, un šī sarežģītība tieši šobrīd ir aktuāla, jo licence mainās: versijas līdz 8.5 ieskaitot iznāk ar PHP licences 3.01 redakciju, bet, sākot ar 8.6, PHP pāriet uz ceturto redakciju, kuru php.net pats apraksta kā „Modified BSD“ licenci un kura praktiski sakrīt ar BSD-3-Clause. Nevienā no šiem variantiem maksa nav paredzēta.

Tas nozīmē, ka par pašu valodu un pašu ietvaru uzņēmums nemaksā ne par lietotāju, ne par procesora kodolu, ne par gadu, un šī nulle nav akcija, kas kādreiz beigsies. Salīdzinājumam der modelis, kuru Microsoft izmanto SQL Server licencēšanai: tur licencē vai nu pēc kodoliem, vai pēc servera kopā ar klientu piekļuves licencēm. SQL Server 2025 standarta izdevums ir ierobežots ar četrām procesoru ligzdām vai trīsdesmit diviem kodoliem atkarībā no tā, kura robeža tiek sasniegta pirmā, bet bezmaksas Express izdevums — ar vienu ligzdu vai četriem kodoliem. Precīzas summas šeit nerakstām, jo cenrādis mainās un tas ir jālasa pie Microsoft; pircējam salīdzināms ir modelis, nevis skaitlis — viens produkts rēķina pēc aparatūras apjoma, otrs nerēķina vispār.

Iepirkumā tam ir divas sekas, kuras der ierakstīt uzreiz. Pirmā ir patīkama: nav licenču audita, nav gada pārrēķina par lietotāju skaitu, kas gada laikā ir pieaudzis, un nav situācijas, kurā programmatūras piegādātājs pēc trim gadiem atnāk ar rēķinu par pārsniegtu limitu. Otrā ir tā, kuru mēdz aizmirst: atvērtais pirmkods noņem atkarību no ietvara īpašnieka, bet nenoņem atkarību vispār. Atkarība pāriet uz citām vietām — uz aģentūru, kura vienīgā zina, kā projekts ir salikts, uz maksas produktiem, kuri stāv līdzās kodam, uz pamestu pakotni, kuru neviens vairs neuztur, un uz galveno versiju, kurai beidzies atbalsts. Šīs četras vietas ir tās, kuras pircējam ir jāpārbauda, jo licences rindiņa par tām neko nepasaka.

Kur Laravel tomēr sāk maksāt: produkti, kas nav ietvars

Tā pati komanda, kas uztur Laravel, pārdod arī vairākus produktus, un piedāvājumā tie mēdz stāvēt vienā rindā ar ietvaru, it kā būtu tā sastāvdaļa. Laravel savā mājaslapā šīs divas lietas nodala pats: pakotnes — Horizon, Telescope, Pulse, Scout, Sanctum, Octane un citas — ir MIT licencētas un bez maksas, savukārt produkti ir Cloud, Forge, Nightwatch, Vapor un Nova, un tie maksā naudu katru mēnesi vai katru gadu. Envoyer joprojām tiek pārdots atsevišķi. Vapor vairs neļauj reģistrēt jaunus kontus. Neviens no šiem produktiem nav vajadzīgs, lai Laravel sistēma strādātu, un tieši tāpēc to klātbūtne piedāvājumā ir izvēle, nevis nepieciešamība.

Cenas 2026. gada augustā izskatījās šādi. Forge, ar kuru pārvalda serverus, maksā 12, 19 vai 39 ASV dolārus mēnesī atkarībā no plāna. Nova, kas ir administrācijas panelis, maksā 99 dolārus vienreiz par vienu projektu kopā ar gada atjauninājumiem un 79 dolārus gadā par atjauninājumu turpināšanu, bet neierobežotā licence maksā attiecīgi 299 un 249 dolārus, turklāt tā sedz licences turētāja paša projektus, nevis viņa klientu projektus. Nightwatch, kas savāc sistēmas notikumus, piedāvā bezmaksas plānu un trīs maksas plānus par 20, 60 un 300 dolāriem mēnesī, pieskaitot piemaksu par notikumiem virs iekļautā limita. Laravel Cloud sākas ar 5 dolāriem mēnesī, kam pieskaita maksu par patēriņu, un Envoyer maksā no 10 līdz 50 dolāriem mēnesī.

Jautājums pircējam nav, vai šie produkti ir labi, jo parasti tie ir labi un ietaupa izstrādātājam vairākas dienas mēnesī. Jautājums ir, kuri no tiem ir iekļauti nosauktajā cenā, kura kontā tie ir reģistrēti un kas ar tiem notiek, ja Jūs pēc diviem gadiem mainīsiet piegādātāju. Abonements, kurš ir reģistrēts aģentūras kontā un līgumā nav pieminēts, ir tieši tā atkarība, ko MIT licence nenoņem, jo MIT runā par kodu, nevis par kontu, kurā tas tiek izvietots un uzraudzīts.

Kas notiek, ja izstrādātājs pazūd

„Kodu var pārņemt jebkurš Laravel izstrādātājs“ ir teikums, kas ir juridiski patiess tikai tad, ja līgums to paredz, un praktiski nepilnīgs, un mēs to esam rakstījuši arī paši. MIT licence tiešām ļauj citam uzņēmumam strādāt ar pašu ietvaru, neprasot atļauju ne mums, ne Laravel komandai. Vai cits uzņēmums drīkst mainīt tieši Jums izstrādāto kodu, nosaka līgumā piešķirtās tiesības. To skaidro raksts par to, kas Jums pieder, kad sistēma ir gatava. Vai jaunais izstrādātājs būs noderīgs jau pirmajā nedēļā, nosaka četras pavisam citas lietas, un visas četras var pārbaudīt, pirms līgums vispār ir parakstīts.

Pirmā ir galvenā versija. Laravel 11 sistēmas nodošana jaunai komandai nav nodošana, bet versijas maiņas projekts, jo drošības atbalsts tur jau ir beidzies un pirmais darbs būs nevis jauna funkcionalitāte, bet nokavētās versijas maiņa līdz atbalstītam laidienam. Otrā ir attālums no ietvara noklusētās struktūras: Laravel dokumentācija pieņem noteiktu mapju un klašu izkārtojumu, un jo tālāk projekts no tā ir aizgājis, jo dārgāka ir iepazīšanās. Skaitļa šeit nav un nevienā avotā tāda nav, ir tikai virziens; toties pircējs var pilnīgi konkrēti pajautāt, kas projektā ir uzrakstīts pretēji noklusējumam un kāda vajadzība to prasīja.

Trešā ir atkarības, tas ir, svešās pakotnes, uz kurām sistēma paļaujas. Composer, kas Laravel pasaulē tās pārvalda, glabā failu ar precīzām versijām, un tas ir vērtīgs tieši tāpēc, ka jauns izstrādātājs var uzstādīt tieši to pašu, ko iepriekšējais izmantoja, nevis to, kas šodien ir jaunākais. Ko šis fails negarantē, ir divas lietas: ka pakotne joprojām būs pieejama lejupielādei un ka tajā kopš tā laika nav atrasta ievainojamība. Komanda composer audit vienā izsaukumā parāda zināmās ievainojamības un pamestās pakotnes, un tā ir īsākā jautājuma forma, kādu vispār var uzdot par svešu koda bāzi.

Ceturtā ir pamesta pakotne, un šeit vārdi maldina. Packagist, Composer publiskais katalogs, atzīmē pakotni kā pamestu, ja tās uzturētāji ir paziņojuši, ka to vairs neuztur, taču tas nenozīmē, ka pakotne pazūd vai pārstāj strādāt: swiftmailer joprojām ir pieejams uzstādīšanai, un 2026. gada 31. augustā tam bija 449 miljoni reģistrētu uzstādīšanu, pēdējais laidiens ir no 2021. gada, un vienlaikus tam ir trīs zināmas ievainojamības. Mūsu pašu šīs vietnes koda bāzē, kas ir Laravel 13 kopā ar Filament administrācijas paneli, ir 109 ražošanas pakotnes un neviena pamesta — tas ir mūsu skaitlis par mūsu projektu, nevis nozares vidējais, jo publicēta nozares vidējā nav nekur.

Cik liels ir darba tirgus, un kāpēc precīzu skaitli neviens nepateiks

Uz jautājumu, vai Latvijā ir viegli atrast cilvēku, kas sistēmu pārņem, godīgā atbilde ir, ka publiska statistika par PHP vai Laravel izstrādātājiem Latvijā nepastāv. Ir netieši dati, un tie ir vērtīgi tieši tik, cik precīzi tos apraksta. JetBrains 2025. gada PHP aptaujā starp 1720 cilvēkiem, kuriem PHP ir galvenā valoda, 64 % strādā ar Laravel, 25 % ar WordPress un 23 % ar Symfony; lauka darbs notika no aprīļa līdz jūnijam, rezultātiem var būt neliela nobīde par labu JetBrains rīku lietotājiem, ko uzņēmums atzīst pats, un lielākās respondentu grupas nāk no Japānas, ASV, Krievijas, Ķīnas un Francijas, nevis no Baltijas.

Eiropas līmenī Eurostat 2026. gada maijā ziņo, ka 2025. gadā Eiropas Savienībā strādāja 10,45 miljoni informācijas un komunikācijas tehnoloģiju speciālistu, kas ir 5,0 % no visiem nodarbinātajiem un par 2,6 % vairāk nekā gadu iepriekš. Par Latviju tā paša avota agrākajā apkopojumā ir cits skaitlis, kurš pircējam ir noderīgāks par kopējo pieaugumu: 2023. gadā tikai 4,48 % Latvijas uzņēmumu meklēja vai mēģināja pieņemt darbā šādus speciālistus, un tas bija zemākais rādītājs visā Savienībā, savukārt starp tiem Eiropas uzņēmumiem, kuri meklēja, 57,5 % bija grūtības aizpildīt šīs vakances.

Šie skaitļi ir par nozares speciālistiem kopumā, nevis par PHP, un tos nedrīkst pārrakstīt kā apgalvojumu par Laravel darba tirgu Latvijā — ne mums, ne piegādātājam, kurš tos citē Jūsu piedāvājumā. Tāpēc mēs šeit neapgalvojam, ka izstrādātājus, kuri darbu pārņem, atrast ir viegli. Gatavojot šo rakstu, avotu šādam apgalvojumam neatradām. Pircējam praktiskais secinājums tāpat ir cits: nevis ticēt tirgus lielumam, bet panākt, lai koda bāze būtu tāda, kurā jauns cilvēks ienāk lēti neatkarīgi no tā, cik tādu cilvēku ir.

Kur mēs paši velkam robežu piedāvājumā

Mēs rakstām uz Laravel kopš 2013. gada, kad iznāca tā ceturtā versija, un tas praktiski nozīmē, ka esam vairākas reizes gājuši cauri tieši tam, par ko šis raksts brīdina — galvenās versijas maiņai, kas nav vienas dienas darbs un ko nevar izdarīt starp citiem uzdevumiem. Mūsu Laravel sistēmu izstrādes lapā ir cena un termiņi, un tā ir atsevišķa saruna; šajā rakstā ir tikai tas, ko piedāvājumā var pārbaudīt neatkarīgi no tā, kurš to ir uzrakstījis un cik labi tas ir uzrakstīts.

Ko mēs neapgalvojam, ir tas, ka jebkurš izstrādātājs pārņem jebkuru koda bāzi vienlīdz viegli, jo sadaļā „Kas notiek, ja izstrādātājs pazūd“ skaidrots pretējais. Ko mēs apgalvojam, ir konkrētāk un pārbaudāmāk: repozitorijs ir klienta no pirmās dienas, tajā ir gan atkarību fails, gan dokumentācija, gan izvietošanas konfigurācija, un nodošanas brīdī versija ir tā, kura tobrīd vēl saņem drošības labojumus. Ja Jums šķiet, ka izvēle patiesībā ir starp gatavu produktu un pasūtījuma sistēmu, tad tā ir cita saruna, kuru esam uzrakstījuši atsevišķi, un, ja jautājums ir tieši par interneta veikalu, tad WooCommerce un Laravel salīdzinājums atbild precīzāk nekā šis raksts.

Praktiski nodošanas komplektā ietilpst repozitorijs ar visu vēsturi, atkarību fails ar precīzām versijām, README ar palaišanas soļiem, izvietošanas konfigurācija un piekļuves dati visiem kontiem, kuros sistēma darbojas. Tas ir tas, ko var apsolīt un pārbaudīt. Ko apsolīt nevar, ir tirgus: cik cilvēku Latvijā šo darbu paņems un par kādu cenu, nav mūsu rokās un nav nevienā publiskā statistikā, tāpēc mēs uz šo jautājumu neatbildam ar pārliecinošu skaitli. Vienīgais, kas šeit patiešām strādā pircēja labā, ir tas, ka koda bāze ir parasta, versija ir atbalstīta un dokumentācija ir rakstīta izstrādes gaitā, nevis atlikta uz nodošanas nedēļu.

Ko pajautāt, pirms parakstāt

Pirmais jautājums ir par datumiem: kura Laravel galvenā versija un kurš PHP zars būs sistēmā tieši nodošanas dienā, un kad beidzas to drošības labojumi. Atbilde ir divi datumi, tos abus var pārbaudīt divās publiskās lapās piecās minūtēs, un tie ir jāieraksta vai nu līgumā, vai vismaz sarakstē. Ja piegādātājs nosauc versiju, kuras atbalsts beidzas agrāk nekā garantijas termiņš, tas nav aizliegts un dažreiz ir pat pamatots, bet tad tas ir jāzina abām pusēm, un cenā ir jābūt saprotamam, kurš maksās par pāreju.

Otrais jautājums ir par abonementiem: kuri maksas produkti — Forge, Cloud, Nova, Nightwatch, Vapor vai Envoyer — sistēmas darbībai ir vajadzīgi, cik tie kopā maksā mēnesī un kura kontā tie ir reģistrēti. Trešais ir par repozitoriju: no kuras dienas tas ir Jūsu, vai tajā ir atkarību fails un vai automātiskajā pārbaudē ir iekļauta composer audit komanda. Ceturtais ir naudas jautājums, kuru parasti atliek uz vēlāku laiku un pēc tam pārsteigumā atrod budžetā: kurš maksās par galvenās versijas maiņu pēc pusotra gada un vai tā ietilpst uzturēšanas līgumā vai būs jauns pasūtījums.

Neviens no šiem četriem jautājumiem neprasa, lai Jūs saprastu kodu, un neviens no tiem nav uztverams kā neuzticēšanās piegādātājam. Tie visi ir par to, kas notiks pēc tam, kad projekts būs pabeigts un rēķins samaksāts, un labs piegādātājs uz tiem atbild uzreiz, jo pats šos datumus zina no galvas. Ja atbilde uz kādu no tiem aizņem nedēļu vai pārvēršas par paskaidrojumu, kāpēc jautājums nav svarīgs, tad tā jau ir atbilde.

Šie četri jautājumi neaizstāj tehnisko izvērtējumu un neatbild uz to, vai piedāvātā arhitektūra ir laba, bet tie novērš lielāko daļu no nepatīkamajiem pārsteigumiem, kuri parasti pienāk otrajā vai trešajā gadā, kad sākotnējais entuziasms ir beidzies un sistēma vienkārši strādā. Ja Jums ir piedāvājums rokās un neesat pārliecināts, ko tajā rakstītās versijas nozīmē Jūsu termiņiem un budžetam, uzrakstiet mums — atbildi uz šiem četriem jautājumiem var sagatavot, neatverot kodu.