Projekti on saatettu onnistuneesti valmiiksi, mutta se ei tarkoita, että sen voi työntää sivuun ja unohtaa. Verkkopalvelua täytyy myös ylläpitää. Mahdollinen toteutusvaiheessa otettu tekninen velka kannattaa mitä pikimmiten maksaa takaisin. Käytetyt komponentit kannattaa tietoturvasyistä päivittää, ja ajan saatossa löytyvät haavoittuvuudet paikata. Tämä vaatii ohjelmistokehittäjän sekä palvelinylläpitäjän tai DevOps-tiimin työtä.
Projektin päätyttyä verkkopalvelu saattaa jäädä palvelimelle pyörimään oman onnensa nojaan. Käytettyihin kolmannen osapuolen ohjelmistoihin tulee päivityksiä, mutta niitä ei syystä tai toisesta viedä kyseessä olevaan sovellukseen. Ajan kuluessa nämä päivitykset kumuloituvat isoksi kasaksi, ja niiden käyttöönotto muuttuu entistä hankalammaksi. Sovelluksen omistajan tulisi ymmärtää näiden jatkuvien töiden hyöty, vaikka niiden teko maksaa ja niistä ei uusia ominaisuuksia tai parannuksia yleensä tule. Näiden töiden laiminlyönnistä seuraavat haitat ja kustannukset tulevat monesti valitettavan myöhään ilmi. Välillä esimerkiksi tietoturvaskandaali kuitenkin havahduttaa sekä tekijät että omistajat näiden ongelmien äärelle. Toisinaan projekti, sen luonteesta riippuen, ei välttämättä tule koskaan valmiiksi. Joskus pelkät kriittiset päivitykset eivät riitä, vaan palvelulle on esimerkiksi tarve tehdä parannuksia kävijämäärien kasvattamiseksi tai konversion nostattamiseksi. Asiakkaiden kuunteleminen ja trendien seuraaminen on oleellinen osa jatkuvaa kehitysprosessia. Jotta havaittujen muutosten toteutus ja ongelmien huomaaminen olisi mahdollisimman nopeaa, kannattaa ylläpitovaiheessa projektia kehittää mahdollisimman pienellä iteraatiosyklillä.
Ylläpitoon kuuluu olennaisena osana myös palvelun valvonta. Nykyaikaiset valvontatyökalut mahdollistavat monipuolisten ja tarkkojen sääntöjen määrittelyn ja näille asetettavia toimenpiteitä. Esimerkiksi katko palvelun saatavuudessa tai yleisessä hidastumisessa voi lähettää vastuuhenkilölle sähköpostia tai tekstiviestin. Valvonta nojaa loppujen lopuksi kuitenkin ihmiseen, joten kellonajasta ja kriittisyydestä riippuen, voi valvontaa lähestyä monella eri toiminta- ja rahoitusmallilla.
Projektista riippumatta on lähes varmaa, että ongelmatilanteita esiintyy. Näitä voivat olla esimerkiksi sovelluksessa ilmenevä bugi, kolmannen osapuolen integraation rikkoutuminen tai fyysinen ongelma palvelimella tai verkossa. Ongelman korjaamisessa aloitetaan sen eristämisestä (mihin ja missä se vaikuttaa) ja toistamisesta (miten ongelmatilanteeseen päästään). Esimerkiksi sovelluksesta löytynyt virhe pyritään korjaamaan muutoksilla koodipohjaan, ja samalla ehkäisemään vastaavien ongelmien syntyminen tulevaisuudessa. Hyväksi havaittu prosessi vastaavan tilanteen ratkaisuun on luoda ensin testi joka todistaa ongelman olemassaolon, jonka jälkeen tehdään tarvittava muutos ja lopulta aikaisemmin luotu testi todistaa muutoksen korjaavan ongelman. Kattavalla testauksella ja/tai tarkistuslistalla todennetaan myös, ettei tehty muutos riko sovellusta muualla.
Valmis projekti voi ensimmäisen lanseerauksen jälkeen vaatia paljon työtä ja toimenpiteitä, mutta niiden määrän ei tarvitse yllättää. Ilman riittävää panostusta, ensiluokkainen verkkopalvelu saattaa lipsahtaa keskinkertaisuuden puolelle.
