Paslaugų teikimo sąlygos

Šios sąlygos taikomos interneto svetainių, klientų zonų, vidinių sistemų,
portalų ar kitų skaitmeninių sprendimų kūrimo, paleidimo, hostinimo,
palaikymo, konsultavimo ir migracijos paslaugoms, kai projektas sąskaitoje
faktūroje, pasiūlyme ar individualiame susitarime yra pažymėtas kaip
„A88“ tipo projektas.

Dokumento tikslas – aiškiai ir techniškai tiksliai paaiškinti, kaip veikia A88 projektai,
ką gauna Klientas, kaip veikia valdomas hostinimas, kokios yra perdavimo galimybės,
ir kuo šis modelis skiriasi nuo klasikinio nuo nulio kuriamo atskiro VPS sprendimo.

1. Bendros nuostatos

Šios paslaugų teikimo sąlygos reglamentuoja interneto svetainių ir kitų skaitmeninių
sprendimų kūrimo bei susijusių paslaugų teikimą tarp paslaugų teikėjo – Arnoldo
Songailos, vykdančio individualią veiklą (toliau – Teikėjas), ir
kliento (toliau – Klientas).

Šios sąlygos taikomos visiems projektams, kurie sąskaitoje faktūroje, pasiūlyme
ar individualiame susitarime pažymėti kaip „A88“ tipo paslaugos.

Jei konkretaus projekto pasiūlyme, sąskaitoje ar atskirame susitarime numatyta
kitaip nei šiame dokumente, individualaus susitarimo sąlygos turi viršenybę tiek,
kiek jos aiškiai pakeičia šio dokumento nuostatas.

Grįžti į pradžią

2. Paslaugų apimtis

A88 tipo paslaugos apima interneto svetainių, klientų zonų, vidinių sistemų,
portalų ar kitų skaitmeninių sprendimų kūrimą ir susijusius techninius veiksmus,
kurie pagal konkretų projektą gali apimti:

• struktūros, dizaino ir programavimo darbus;
• administravimo ar duomenų valdymo logikos paruošimą;
• domeno nukreipimą ir viešą paleidimą;
• bazines analitikos, sekimo ar SEO konfigūracijas, jei tai įtraukta;
• esamo turinio perkėlimą, jei tai buvo aptarta iš anksto;
• hostingo arba valdomos infrastruktūros paslaugą, jei ji aiškiai įtraukta;
• bazines konsultacijas dėl naudojimo, plėtros krypties ir tolimesnių etapų.

Tiksli paslaugų apimtis visada nustatoma pagal konkretų pasiūlymą, sąskaitą
faktūrą arba individualų susitarimą.

Grįžti į pradžią

3. Mokėjimo sąlygos

• 50% projekto sumos apmokama prieš darbų pradžią;
• likusi 50% projekto sumos apmokama prieš galutinį paleidimą, jei nesutarta kitaip;
• mėnesiniai ar periodiniai hostinimo, palaikymo ar infrastruktūros mokesčiai, jei taikomi, nurodomi atskirai.

Svetainė ar sistema laikoma perduota ir paslauga – pilnai suteikta, kai:

• sutarta projekto apimtis yra įgyvendinta;
• projektas paleistas sutartu būdu arba perduotas naudoti;
• Klientas apmoka galutinę sąskaitos dalį.

Po galutinio apmokėjimo laikoma, kad Klientas neturi pretenzijų dėl atliktų darbų
apimties ar kokybės, išskyrus atvejus, kuriems taikoma šiame dokumente numatyta garantija.

Jei Klientas pilnai neatsiskaito, Teikėjas pasilieka teisę apriboti prieigą prie
projekto, neįvykdyti galutinio perdavimo arba nepaskelbti projekto viešai iki
visiško atsiskaitymo.

Grįžti į pradžią

4. Projekto eiga ir terminai

• projekto darbai pradedami gavus pirmąjį apmokėjimą;
• terminai priklauso nuo Kliento pateikiamos informacijos, medžiagos ir atsakymų spartos;
• Klientui vėluojant pateikti reikalingą informaciją, projekto terminas gali būti pratęstas;
• terminai gali kisti, jei projekto eigoje keičiasi apimtis, prioritetai ar integracijų poreikis.

Teikėjas neatsako už termino nukėlimą, jei darbų eiga sustoja dėl Kliento delsimo,
neatsakymo, nepateiktos medžiagos ar naujų užklausų, kurios keičia pirminę projekto apimtį.

Grįžti į pradžią

5. Kas nėra įtraukta į paslaugas

Jei aiškiai nenurodyta kitaip, į paslaugas nėra įtraukta:

• tekstų kūrimas, copywriting ar teisinio turinio rengimas;
• papildomi dizaino ar struktūros keitimai po patvirtinimo;
• naujos funkcijos, papildomi puslapiai ar papildomos integracijos po projekto pradžios;
• nuolatinė techninė priežiūra po sutarto laikotarpio pabaigos;
• išplėstiniai SEO, reklamos, marketingo ar automatizavimo darbai, jei jie nėra aiškiai įtraukti;
• pilna nepriklausoma VPS architektūra, jei ji nebuvo užsakyta kaip atskiras etapas;
• projekto migracija į kitą infrastruktūrą, jei tokia paslauga nebuvo sutarta atskirai.

Tokie darbai gali būti atliekami už papildomą mokestį pagal atskirą susitarimą.

Grįžti į pradžią

6. Korekcijos ir pakeitimai

Į projekto kainą įskaičiuojami pagrindiniai pataisymai projekto eigoje, kurie
nekeičia pirminės projekto apimties, esminės logikos ar architektūrinio modelio.

Esminiai pakeitimai, papildomas funkcionalumas, nauji moduliai, nauji puslapiai,
išplėstinės integracijos ar papildomos peržiūros, kurios nebuvo aptartos pradžioje,
derinamos atskirai ir apmokestinamos papildomai.

Grįžti į pradžią

7. Hostingas ir infrastruktūra

Jei hostingo arba valdomos infrastruktūros paslauga yra įtraukta į konkretų
paslaugų paketą ar sąskaitą faktūrą, ji suteikiama pagal pasiūlyme arba
individualiame susitarime nurodytą laikotarpį.

Jei laikotarpis nėra nurodytas kitaip, hostingo ar valdomos infrastruktūros paslauga
laikoma suteikta 12 mėnesių laikotarpiui nuo projekto paleidimo dienos.

Pasibaigus šiam laikotarpiui, hostingo ar infrastruktūros paslauga gali būti pratęsta
už papildomą mokestį pagal tuo metu galiojančius Teikėjo įkainius arba atskirą susitarimą.

Jei hostingas ar infrastruktūros priežiūra nėra aiškiai įtraukta į pasiūlymą ar sąskaitą,
laikoma, kad ji į paslaugos kainą neįeina.

Teikėjas neatsako už trečiųjų šalių infrastruktūros, serverių, tinklų, domenų
registratorių, el. pašto tiekėjų ar kitų išorinių sistemų sutrikimus, tačiau
pagrįstai stengiasi padėti juos identifikuoti ir koordinuoti sprendimą.

Grįžti į pradžią

8. Garantija

Po projekto paleidimo suteikiama 2 mėnesių garantija, jei
individualiame susitarime nenustatyta kitaip.

Garantijos laikotarpiu Teikėjas nemokamai taiso technines klaidas ar neatitikimus,
kurie atsirado dėl jo atliktų darbų ir kurie patenka į pradinę sutartą projekto apimtį.

Garantija netaikoma, jei:

• Klientas ar trečiosios šalys keitė svetainės ar sistemos kodą, turinį, struktūrą ar nustatymus;
• problemos atsirado dėl trečiųjų šalių sistemų, integracijų, domeno ar išorinių paslaugų veikimo;
• atsirado naujų poreikių, kurie nebuvo įtraukti į pradinę projekto apimtį;
• veikimas pakito dėl Kliento įkeltų netinkamų duomenų ar konfigūracijų;
• pasikeitė naudojamos platformos, integracijų ar tiekėjų techniniai reikalavimai.

Grįžti į pradžią

9. Palaikymas ir priežiūra

Po projekto užbaigimo Klientui suteikiamas
1 mėnesio nemokamas palaikymas ir priežiūra, skaičiuojant nuo
projekto paleidimo dienos, jei pasiūlyme nenustatyta kitaip.

Šiuo laikotarpiu gali būti atliekami smulkūs techniniai pataisymai, konsultacijos
ir bazinė pagalba, susijusi su perduotu projektu.

Pasibaigus nemokamo palaikymo laikotarpiui, tolimesnis palaikymas, priežiūra,
papildomi darbai ar konsultacijos teikiami už papildomą mokestį arba pagal
atskirą mėnesinį susitarimą.

Grįžti į pradžią

10. Kliento atsakomybė

Klientas atsako už viso pateikto turinio teisėtumą, tikslumą ir naudojimo teises,
įskaitant, bet neapsiribojant:

• tekstais;
• nuotraukomis, vaizdo medžiaga ir kitais vizualiniais elementais;
• logotipais ir prekių ženklais;
• kontaktine, komercine ar kita viešinama informacija;
• teisinių tekstų, privatumo politikų ir kitų reguliacinių dokumentų turiniu.

Teikėjas neatsako už teisines pasekmes, atsiradusias dėl Kliento pateikto neteisėto,
klaidinančio ar neleistinai naudojamo turinio.

Grįžti į pradžią

11. Teikėjo atsakomybės ribojimas

Teikėjas neatsako už netiesioginius nuostolius, pajamų praradimą, reputacinę žalą,
verslo pertraukas ar kitus nuostolius, atsiradusius dėl projekto neveikimo,
trečiųjų šalių sistemų sutrikimų, laikino nepasiekiamumo, išorinių kibernetinių
incidentų ar kitų nuo Teikėjo tiesiogiai nepriklausančių veiksnių.

Bet kuriuo atveju Teikėjo civilinė atsakomybė negali viršyti Kliento faktiškai už
konkretų projektą sumokėtos sumos, išskyrus atvejus, kai taikytina teisė nustato kitaip.

Grįžti į pradžią

12. Baigiamosios nuostatos

Apmokėjus sąskaitą faktūrą, laikoma, kad Klientas sutinka su šiomis paslaugų
teikimo sąlygomis.

Visi ginčai pirmiausia sprendžiami derybų būdu. Nepavykus susitarti, ginčai
sprendžiami Lietuvos Respublikos teisės aktų nustatyta tvarka.

Šis dokumentas gali būti periodiškai atnaujinamas siekiant tiksliau atspindėti
teikiamų paslaugų modelį. Naujausia versija skelbiama Teikėjo nurodytu adresu
arba pateikiama Klientui kartu su nauju pasiūlymu ar sąskaita.

Grįžti į pradžią

13. A88 projekto modelis

Kai projektas yra įvardijamas kaip A88 tipo projektas, tai reiškia,
kad projektas kuriamas pagal valdomos platformos principą, kuris leidžia greičiau
paleisti sprendimą, sujungti kelis techninius sluoksnius į vieną darbo modelį ir
sumažinti techninę naštą pradžioje.

A88 modelio esmė – ne imituoti pilnai savarankišką serverinę architektūrą nuo pirmos
dienos, o suteikti Klientui praktišką, greitai įgyvendinamą ir aiškiai prižiūrimą
sprendimą su galimybe vėliau, esant poreikiui, pereiti į didesnės nepriklausomybės etapą.

Priklausomai nuo konkretaus projekto, A88 sprendime gali būti naudojami tokie sluoksniai
kaip valdomas hostinimas, duomenų modeliai, autentifikacija, backend funkcijos,
automatikos, integracijos ir administravimo logika.

Ką tai reiškia Klientui

Klientas gauna veikiantį, aiškiai prižiūrimą ir greičiau paleidžiamą sprendimą,
be poreikio nuo pradžių atskirai derinti frontendo, backendo, hostingo,
autentifikacijos ir duomenų infrastruktūros.

Ką tai reiškia ilgalaikėje perspektyvoje

Jei vėliau Klientui reikia didesnės nepriklausomybės ar pilnos serverio kontrolės,
toks perėjimas yra galimas, tačiau paprastai įgyvendinamas per atskirą migracijos
arba rebuild etapą, o ne per vieną techninį perjungimą.

Grįžti į pradžią

14. Techninė logika ir platformos ribos

A88 projektai gali būti statomi ant valdomos aplikacijų platformos, kuri vienoje
aplinkoje sujungia vartotojo sąsają, duomenų sluoksnį, autentifikaciją, backend
funkcijas, tam tikras automatikas ir hostinimą. Dėl to pradinis paleidimas yra
greitesnis nei kuriant ir diegiant viską atskirai.

14.1. Ką tai nereiškia

• tai nereiškia, kad projektas „automatiškai pats save tobulina“ ar atsinaujina be Teikėjo darbo;
• tai nereiškia, kad visos platformos dalys gali būti tiesiogiai perduotos kaip atskiras VPS serverio vaizdas;
• tai nereiškia, kad kiekvienas integracijos ar autentifikacijos modelis tinka visiems daugianaudotojiems scenarijams;
• tai nereiškia, kad visi projektai turi identišką eksportavimo ar perkėlimo kelią.

14.2. Eksportas ir techninis perdavimas

Priklausomai nuo naudojamos platformos plano, prieinamų funkcijų ir projekto sandaros,
gali būti prieinamas tam tikras projekto kodo, failų ar duomenų eksportas. Tačiau
toks eksportas nėra tolygus pilnai valdomos infrastruktūros, autentifikacijos sluoksnio
ar duomenų bazės infrastruktūros perdavimui kaip savarankiškai veikiančiai serverinei sistemai.

Dėl šios priežasties A88 projektų migracija į visiškai savarankišką VPS aplinką paprastai
vertinama kaip atskiras techninis projektas.

14.3. Tinkamumo principas

A88 modelis ypač tinka projektams, kuriems svarbu greitis, aiški pradžia, viena atsakomybės
linija ir mažesnis techninis sudėtingumas ankstyvoje stadijoje. Tuo pačiu jis turi būti
naudojamas sąmoningai, suprantant, kad kai kuriems labai specifiniams ar labai savarankiškiems
infrastruktūros scenarijams gali būti tinkamesnis atskiras VPS projektas nuo pradžių.

Grįžti į pradžią

15. Nuosavybė, prieigos ir valdymas

Klientui svarbu suprasti skirtumą tarp projekto naudojimo teisės, turinio,
domeno, duomenų, prieigų ir pačios infrastruktūros valdymo.

15.1. Kas priklauso Klientui

• Kliento pateiktas turinys, prekės ženklai, logotipai ir kiti jam priklausantys elementai;
• galutinė viešai naudojama svetainė ar sistema kaip verslo sprendimas pagal sutartą paskirtį;
• domenas, jei jis registruotas Kliento vardu arba jo užsakymu;
• teisė naudoti sukurtą projektą pagal jo verslo poreikius, kai projektas yra pilnai apmokėtas.

15.2. Kas gali likti Teikėjo valdymo srityje, jei nėra atskiro perdavimo

• valdomos infrastruktūros aplinka;
• diegimo, publikavimo ir administravimo darbo procesai;
• vidiniai techniniai šablonai, moduliai, struktūros ar komponentai, jei nesutarta kitaip;
• dalys, kurios priklauso nuo valdomos platformos paslaugų ir nėra perduodamos kaip nepriklausoma serverinė kopija.

15.3. Prieigos

Prieigų suteikimas priklauso nuo pasirinkto projekto modelio. Jei projektas veikia
valdomoje infrastruktūroje, kai kurios prieigos gali nebūti perduodamos pilna apimtimi
dėl saugumo, stabilumo, bendros aplinkos vientisumo ar techninės modelio logikos.

Jei Klientui reikalinga pilna infrastruktūros kontrolė, toks poreikis sprendžiamas
per atskirą perkėlimo, migracijos ar rebuild paslaugą.

Grįžti į pradžią

16. Perkėlimas ir išėjimo galimybės

Teikėjas aiškiai numato galimybę Klientui ateityje projektą perkelti arba pereiti
prie savarankiškesnio infrastruktūros modelio. Tai reiškia, kad Klientas nėra
„užrakinamas“ viename sprendime visam laikui.

Vis dėlto svarbu suprasti, kad A88 projekto perkėlimas nėra paprastas
hostingo adreso pakeitimas. Jei projektas remiasi valdomos platformos
funkcijomis, autentifikacija, duomenų sluoksniu ar kitais integruotais komponentais,
perkėlimas į pilnai savarankišką VPS paprastai vykdomas kaip
atskiras rebuild / migracijos projektas.

16.1. Kada Klientas gali inicijuoti perkėlimą

Klientas gali kreiptis dėl perkėlimo bet kuriuo metu, tačiau praktiškai tokie
sprendimai dažniausiai svarstomi po 12 arba 24 mėnesių, kai:

• verslas jau yra ištestavęs projektą rinkoje;
• atsiranda poreikis atskirai infrastruktūrai;
• reikalinga platesnė serverio kontrolė ar specifinė techninė logika;
• Klientas nori savo vidinio techninio valdymo arba kitos plėtros krypties.

16.2. Kaip vyksta perkėlimas

1. įvertinama esama projekto būklė, funkcionalumas, duomenys ir priklausomybės;
2. sutariama dėl naujo architektūrinio modelio, dažniausiai – atskiro VPS arba kitos pasirinktos aplinkos;
3. parengiamas atskiras pasiūlymas dėl rebuild / migracijos darbų;
4. projektas perstatomas arba pritaikomas naujai aplinkai pagal realias technines galimybes;
5. atliekamas testavimas ir suderinimas;
6. projektas paleidžiamas naujoje aplinkoje.

16.3. Ką svarbu suprasti apie perkėlimą

• perkėlimas nėra įtrauktas į pradinę A88 projekto kainą, nebent aiškiai sutarta kitaip;
• perkėlimas gali reikalauti dalinio arba pilno techninio perstatymo;
• perkėlimo kaina priklauso nuo projekto dydžio, funkcionalumo, duomenų modelio ir tikslinės infrastruktūros;
• Teikėjas pagrįstai bendradarbiauja, kad perėjimas būtų aiškus ir techniškai tvarkingas.

Svarbu: jei Klientas po 1 ar 2 metų nusprendžia pereiti prie
atskiro VPS ar kitos savarankiškesnės architektūros, tai yra įmanoma, tačiau
tokia paslauga vykdoma kaip atskiras mokamas rebuild / migracijos projektas.

Grįžti į pradžią

17. Veiklos tęstinumas ir nenumatyti atvejai

Vienas dažniausių Klientų klausimų yra:
„Kas bus, jei ateityje Teikėjas nebegalės tęsti veiklos?“

Nors Teikėjas planuoja tęstinę veiklą ir nėra pagrindo manyti kitaip, šiame
dokumente aiškiai numatoma bendroji logika nenumatytiems atvejams.

17.1. Pagrindinis principas

Jei Teikėjas dėl objektyvių priežasčių nebegalėtų tęsti paslaugų teikimo, būtų
siekiama protingu ir praktišku būdu:

• informuoti Klientą apie situaciją per protingą terminą, jei tai įmanoma;
• sudaryti sąlygas aptarti tolimesnius veiksmus;
• įvertinti galimą projekto perkėlimą, rebuild ar perdavimo planą;
• kiek leidžia aplinkybės, perduoti informaciją, reikalingą tolimesniam sprendimui.

17.2. Svarbus paaiškinimas

Jei projektas priklauso nuo valdomos infrastruktūros ar platformos funkcijų,
pilnas tęstinumas be jokio papildomo darbo ne visada yra automatinis. Tam tikrais
atvejais gali būti reikalingas atskiras projekto perkėlimas, perstatymas arba
infrastruktūros reorganizavimas.

17.3. Ką tai reiškia praktiškai

• Klientas nėra paliekamas be jokios išeities;
• nėra žadama techniškai neįmanoma „momentinė“ pilna nepriklausomybė, jei ji nebuvo sukurta iš anksto;
• yra numatyta reali logika, kad nenumatytais atvejais pereinama prie perdavimo ar rebuild sprendimo.

Grįžti į pradžią

18. A88 projekto tipo privalumai

A88 modelis parinktas ne atsitiktinai. Daugeliui verslų jis duoda daugiau praktinės
naudos nei nuo pirmos dienos atskirai komplektuojama ir pilnai individualizuota infrastruktūra.

18.1. Greitesnis paleidimas

Mažiau techninių blokatorių, trumpesnis startas ir aiškesnis kelias iki veikiančio rezultato.

18.2. Viena techninė kryptis

Klientui nereikia nuo pradžių atskirai koordinuoti kelių tiekėjų, kelių sluoksnių ir kelių skirtingų diegimo procesų.

18.3. Mažesnė klaidų rizika pradžioje

Kai techninę pusę koordinuoja vienas partneris, sumažėja neteisingų ankstyvų sprendimų tikimybė.

18.4. Patogesnis augimas etapais

Pirmiausia – greitas ir veikiantis sprendimas. Vėliau – papildomos funkcijos, atskiri moduliai ar rebuild į kitą architektūrą.

18.5. Tinkamas modelis verslo startui

Daugumai Klientų pradžioje svarbiausia ne serverio architektūros detalės, o tai,
kad projektas būtų greitai paleistas, atrodytų profesionaliai, veiktų stabiliai
ir padėtų generuoti užklausas, pardavimus ar vidinius procesus.

A88 modelis leidžia pirmiausia susikoncentruoti į rezultatą, o infrastruktūros
savarankiškumą spręsti tada, kai jis tampa realiai naudingas verslui.

Grįžti į pradžią

19. A88 ribojimai ir tinkamumo ribos

Siekiant skaidrumo, Klientui turi būti aišku, kad A88 modelis turi ne tik privalumų,
bet ir tam tikras ribas, kurios priklauso nuo pasirinkto techninio pagrindo.

19.1. Ne kiekvienas scenarijus vienodai tinkamas

• kai kuriems labai specifiniams enterprise ar individualios infrastruktūros projektams gali būti tinkamesnė atskira VPS architektūra nuo pradžių;
• kai kurioms daugianaudotojėms integracijoms gali reikėti individualiai kurto autentifikacijos ar OAuth sprendimo;
• kai kurie funkcionalumai gali reikalauti papildomo custom vystymo, jei jie nepatenka į naudojamos platformos standartinį modelį.

19.2. Migracija nėra „vienas mygtukas“

Jei projektas naudoja valdomus autentifikacijos, duomenų ar hostinimo sluoksnius,
savarankiška VPS aplinka paprastai reikalauja atskiro techninio perstatymo.

19.3. A88 yra sąmoningas pasirinkimas

A88 nėra pristatomas kaip „visiems atvejams vienintelis idealus modelis“. Jis yra
sąmoningas pasirinkimas tiems atvejams, kai svarbiausia yra greitis, aiškumas,
vientisas paleidimas ir mažesnė techninė našta ankstyvoje stadijoje.

Grįžti į pradžią

20. Duomenys, atsarginės kopijos ir saugumas

Teikėjas deda pagrįstas pastangas užtikrinti projekto techninį stabilumą,
atsakingą infrastruktūros administravimą ir, kai taikoma, atsarginių kopijų logiką.

20.1. Atsarginės kopijos

Jei projektui taikoma atsarginių kopijų praktika, ji vykdoma pagal naudojamos
infrastruktūros galimybes ir pasirinkto hostinimo ar priežiūros modelio ribas.

Jei Klientui reikalingi konkretūs atsarginių kopijų intervalai, išlaikymo terminai
ar specialūs atstatymo įsipareigojimai, tai turi būti aptarta atskirai.

20.2. Saugumas

Nors Teikėjas taiko protingas technines ir organizacines priemones, joks interneto
projektas negali būti laikomas absoliučiai nepažeidžiamu. Dėl to Teikėjas negali
garantuoti visiškos apsaugos nuo visų galimų išorinių kibernetinių grėsmių, tačiau
pagal galimybes reaguoja į nustatytus incidentus.

20.3. Kliento pareiga dėl prieigų

Jei Klientui suteikiamos administravimo prieigos, Klientas įsipareigoja saugoti
prisijungimo duomenis, naudoti stiprius slaptažodžius ir neperduoti prieigų
nepatikimiems tretiesiems asmenims.

Grįžti į pradžią

21. Papildomos konsultacijos ir užklausos

A88 tipo projektams Teikėjas gali atsakyti į papildomus Kliento klausimus apie:

• projekto veikimo logiką;
• hostingo modelį;
• tolimesnės plėtros galimybes;
• perkėlimo ar rebuild perspektyvą;
• palaikymo planus;
• praktines rekomendacijas augimui.

Trumpos bazinės konsultacijos gali būti įtrauktos į palaikymo laikotarpį, tačiau
išplėstinės konsultacijos, strateginiai pokalbiai, techninio audito darbai ar
papildomas planavimas gali būti apmokestinami atskirai.

Grįžti į pradžią

22. Dažniausiai užduodami klausimai

22.1. Ar A88 projektas pats automatiškai atsinaujina?

Ne. A88 nereiškia, kad projektas pats save tobulina ar automatiškai diegia naują
logiką be Teikėjo darbo. Projektas gali veikti valdomos publikavimo logikos pagrindu,
tačiau pakeitimai vis tiek priklauso nuo to, kas yra kuriama, testuojama ir publikuojama.

22.2. Ar mes esame „pririšti“ prie jūsų visam laikui?

Ne. Klientas gali ateityje inicijuoti projekto perkėlimą. Tačiau A88 projektuose
tai dažniausiai daroma kaip atskiras mokamas rebuild / migracijos projektas į VPS
ar kitą pasirinktą infrastruktūrą.

22.3. Kas nutinka, jei po 1–2 metų norime pilnos serverio kontrolės?

Tokiu atveju įvertinamas projektas, parenkama nauja architektūra ir parengiamas
atskiras pasiūlymas dėl perstatymo ar perkėlimo. Tai yra normalus ir numatytas kelias.

22.4. Kodėl iš karto nedaroma atskirame VPS?

Kai kuriems projektams taip galima daryti nuo pradžių. Tačiau daugeliu atvejų
praktiškiau pradėti nuo greitesnio ir paprastesnio modelio, ypač kai verslui
svarbiausia kuo greičiau paleisti kokybišką veikiantį sprendimą.

22.5. Ar perkėlimas įtrauktas į pradinę kainą?

Ne, nebent tai aiškiai nurodyta pasiūlyme ar atskirame susitarime. Standartiškai
perkėlimas ar rebuild į VPS apmokestinami atskirai.

22.6. Koks didžiausias šio modelio privalumas?

Greitis, aiškumas, mažesnė techninė našta pradžioje ir patogesnis kelias nuo
„reikia veikiančio sprendimo dabar“ iki „norime labiau individualizuotos
infrastruktūros vėliau“.

Paskutinis atnaujinimas: 2026-03-19

Ši versija pataisyta taip, kad nebeklaidintų dėl automatinių atnaujinimų,
eksportavimo ar tiesioginio serverinio perdavimo logikos.

Grįžti į pradžią