Esiteks soovitaks semestri sees enne eksamisessiooni põhjalik eeltöö ära teha. Võimalusel ka enamus asju juba valmis või vähemalt testida, 
kas vajaminevad tehnoloogiad on mõistliku ajaga koostööd tegema võimalik panna.
Kui eeltöö käigus selgub, et kasutatavad tehnoloogiad ei ole piisavalt kiiresti õpitavad ja ei võimalda 2 nädala jooksul projekti valmis 
arendada, siis võimalusel leppida kliendiga muud tehnoloogiad kokku, mis annaksid sama tulemi või jõuda kliendiga kompromisslahenduseni.

Järgmisel korral teeks teisiti seda, et suvepraktika algul tuleks pöörata suuremat tähelepanu informatiivsusele: märksõnad "Mida?" ja 
"Kuidas?" Loovutades päeva või kaks oma praktikaajast, ent saades see-eest selge pildi soovitud projektist, laabub edasine töö palju 
paremini.

Alguses jagada töö väiksemateks osadeks ja teha neid tähtsuse järjekorras. 

Hinnake ülesandeid Planning Pokeriga ja üritage juba eos vältida liiga keerulisi ülesandeid. Suured ja keerulised ülesanded tuleb 
väiksemateks tükkideks laiali jagada mis on hoomatavad, vastasel juhul antud ülesande lahendamine jääb venima.

Samuti tuleks hoida kood võimalikult lihtne ja kohe kui mingi uus funktsionaalsus tööle saadakse tuleks mõelda, kuidas asja lihstamalt 
saaks. 

Kasulik teha igasuguseid prototüüpe, see aitab ka arendusprotsessis.(visuaalselt silme ees lõpp produkt)

Dokumenteerimist võiks proovida alustada kohe alguses. Pidada järge, mis juba tehtud, mis arengujärgus ja mis tegemata.

Ettevaatlik arendus, pigem töötada eraldi kui mitmekesi ühe asja kallal. Samas võiks olla mingid ühised põhimõtted, et pärast oleks 
lihtsam kõike kokku panna. Samas soovitatakse proovida ka paarisprogrammeerimist.

Hea oleks kohe algusest kommenteerida koodi säästmaks aega

Testida oma tehtud rakendusi. Äsja kirjutatud koodi on kindlasti lihtsam ette võtta ja parandada. Hiljem kui tekib üldine testiperiood 
ning programmeerija on sunnitud mingit uut osa veel kirjutama, soovitaksime lasta teiste leitud vead paberil/ kuskil üleskirjutatuna 
esitada. Kahte asja on keeruline korraga teha ning kui hõigatakse vahele, kus vead on ja mida peaks parandama, siis uue osa kirjutamine 
jääb tahaplaanile.

Testige pidevalt ja pange kirja, mida te testite, kuidas ja mis tingimustel viga tekkis. Testimisega tuleks alustada kohe projekti alguses, 
et leida vead ja parandada need.

Back-end ja front-end peaks tegema koostööd võimalikult varakult

Arendusprotsessis kasulik ülessandeid vahetada liikmete vahel(järgmine meeskonna liige näeb asja teise pilgu läbi ja võib parema lahenduse leida). Samuti meeskond õpib selle läbi rohkem.

Iga päeva lõpus tehke oma tehtud tööst backup, juhul kui peaksite järgmine päev oma töö kogemata ära kustutama.

Githubis eri ülesannete jaoks tuleks kasutada eri branche. Githubi tuleks igal juhul kasutada.