Videreudvikling af en app, der allerede er i drift
Jeg hjælper virksomheder, der har en eksisterende app og skal have en ny udvikler ind. Første forløb består af en teknisk gennemgang af kode, byggeproces, konti, backend og testmiljø, efterfulgt af én afgrænset rettelse eller funktion. Målet er at bevise, at appen kan bygges, testes og leveres sikkert, før et større roadmap aftales.
Send repository og første opgave · Se prisberegner
- Udgangspunkt
- App i drift
- Første leverance
- Gennemgang + én ændring
- Kontrol
- Reproducerbar build og test
- Pris
- Tilbud efter kode og adgang
Begynd med en kontrolleret overtagelse
En app i App Store eller Google Play kan stadig være svær at bygge lokalt, afhængig af en tidligere leverandørs konto eller mangle dokumentation om backend og certifikater. Derfor starter jeg ikke med at love et langt katalog af nye funktioner. Først etablerer vi et sandt billede af, hvad virksomheden ejer, hvad der kan reproduceres, og hvilke risici der skal løses.
Efter gennemgangen vælger vi én ændring, som både har forretningsværdi og kan fungere som leverancetest. Det kan være en konkret fejlrettelse, en mindre skærm eller en afgrænset API-ændring. Kunden godkender scope og accepttest, før implementeringen begynder.
- Repository og historik kan hentes
- Appen kan bygges med dokumenterede trin
- Testmiljø og backendafhængigheder er kendt
- Virksomheden kontrollerer relevante konti
- Første ændring kan frigives eller overleveres kontrolleret
Kode, build, konto og testmiljø
| Område | Det kontrolleres | Muligt fund | Næste beslutning |
|---|---|---|---|
| Kode | Repository, branches, afhængigheder og hemmeligheder | Kode findes kun hos leverandøren eller kræver udgået pakke | Få ejerskab eller afgræns opgradering |
| Build | Dokumenteret lokal/CI-build og versionskrav | Kun én gammel maskine kan bygge | Genskab build før nye funktioner |
| Konti | Apple/Google, cloud, domæne, analyse og fejlrapportering | Leverandør ejer konto eller certifikat | Overfør eller opret kundeejet adgang |
| Backend | API, database, miljøvariabler, jobs og integrationer | Ukendt drift eller ingen staging | Kortlæg ansvar og backup før ændring |
| Testmiljø | Testbrugere, data og tredjepartssandboxes | Test rammer produktion | Etabler sikker testvej |
| Udgivelse | Signering, release-noter, review og rollback | Ingen dokumenteret releaseproces | Aftal første kontrollerede release |
Fra overtagelse til én afgrænset rettelse
Eksemplet er illustrativt og beskriver ikke et bestemt kundeprojekt eller et bestemt tidsforbrug.
Virksomheden inviterer
En kunde giver tidsbegrænset adgang til repository, testkonto, appkonti og fejlrapportering. Den tidligere leverandør afleverer buildinstruktion og kendte driftsafhængigheder.
Build reproduceres
Projektets dokumenterede versioner installeres i et isoleret miljø. Appen bygges, åbnes med testdata og forbindes kun til det aftalte miljø.
Fejlen genskabes
En konkret fejl i kvitteringsskærmen beskrives med trin, forventet adfærd og faktisk adfærd. Log og relevante API-svar gemmes uden unødige persondata.
Rettelsen afgrænses
Ændringen omfatter kun skærmens fejltilstand og den nødvendige datakontrol. Et ønske om et helt nyt ordreflow lægges i et senere scope.
Test og levering
En automatiseret eller manuel regressionstest dækker fejlen. Kunden godkender i testmiljøet, og release/overlevering følger den aftalte proces.
Det skal virksomheden have adgang til
Kildekode og design
Repository med relevant historik, branches og release-tags samt designfiler og aktive assets, som virksomheden har ret til at bruge.
Appkonti
Virksomhedens Apple Developer- og Google Play-konti, roller, bundle/package-id, signering og nuværende produktionsversion. Kontooverførsel kan kræve leverandørens handling.
Backend og drift
Cloudkonto, API, database, domæner, DNS, storage, køer, cronjobs, backups og overvågning. Hemmeligheder roteres ved leverandørskifte.
CI og release
Build-pipeline, miljøvariabler, certifikater, profiler, release-noter og dokumenteret rollback. Kundens konto bør eje den endelige proces.
Tredjepart
Betaling, push, e-mail, analyse, kort, login og øvrige leverandører med kontrakt, administrator og testadgang.
Jura og data
Rettigheder til kode og materiale, databehandleraftaler, privatlivstekst, slettekrav og kontaktperson ved sikkerhedshændelser.
Den første opgave skal bevise leverancevejen
| Leverance | Godkendt når |
|---|---|
| Overtagelsesnotat | Ejerskab, adgang, miljøer, kendte risici og åbne spørgsmål er samlet uden at gemme hemmeligheder i dokumentet |
| Build | En ny udviklingsmaskine eller CI kan bygge den aftalte version efter dokumenterede trin |
| Testmiljø | Ændringen kan prøves uden utilsigtet påvirkning af produktionsbrugere eller produktionsdata |
| Første ændring | De aftalte scenarier består, og ikke-aftalte ønsker er holdt ude af scope |
| Regression | De berørte eksisterende flows er kontrolleret på relevante enheder/versioner |
| Levering | Kunden kan se commit, testbevis og status for release eller overlevering |
Hvis build, ejerskab eller sikker test ikke kan etableres, stopper udviklingsdelen med en konkret risikoliste og næste handling.
Hvad hører ikke automatisk med?
En teknisk gennemgang betyder ikke, at al gammel kode kan fortsætte uændret. Større frameworkopgraderinger, redesign, ny backend, compliancearbejde, kontooverførsler og oprydning i historiske data kan blive selvstændige projekter, hvis gennemgangen viser behovet.
Jeg arbejder med app, backend, API og UI/UX inden for det dokumenterede arbejdsområde på sitet. Den konkrete platformsstack, kodekvalitet og adgang afgør, om jeg kan tage opgaven. Hvis den ligger uden for stack eller kræver en specialist, får kunden det at vide før et udviklingstilbud.
Spørgsmål om videreudvikling af app
Kan du overtage en app fra et andet bureau?
Ja, når virksomheden har rettigheder og adgang til kode, konti og drift. Første skridt er en gennemgang og en lille leverancetest, ikke et løfte om at overtage alt uset.
Hvad hvis appen ikke kan bygges?
Så dokumenteres den første brudte grænse, fx manglende dependency, certifikat eller miljøvariabel. I beslutter derefter, om buildreparation skal være den første opgave.
Skal den tidligere leverandør være med?
Ofte er en struktureret aflevering den hurtigste vej til repository, konti, drift og kendte problemer. Virksomheden bør selv være ejer af de centrale konti.
Kan du begynde direkte i produktion?
Nej, ikke som normal fremgangsmåde. Vi etablerer en reproducerbar build og en sikker testvej, før en ændring planlægges til produktion.
Hvad koster første forløb?
Der er ingen godkendt fast pris på overtagelse af vilkårlig eksisterende kode. Du får et tilbud efter stack, repository, konti, miljøer og den første afgrænsede ændring.
Hvad skal jeg sende?
Send platform og stack, links til appen, repository-status, hvem der ejer Apple/Google/cloudkonti, seneste fungerende build og én prioriteret fejl eller funktion.
Ny version, MVP eller appplatform
- App-udvikling – Den brede ydelse til et nyt appprojekt.
- App-udvikling pris – Prototype, MVP og de vigtigste prisdrivere.
- iOS-app-udvikling – Når Apple-platformen og native funktioner er centrale.
- MVP-udvikling – Når en ny første version skal afgrænses fra bunden.
Send appen, adgangsstatus og den første opgave
Send links til den nuværende app, stack og repository-status, hvem der ejer app- og cloudkonti, hvordan seneste release blev bygget, og én prioriteret rettelse eller funktion. Så kan jeg vurdere overtagelsesrisikoen og give et afgrænset tilbud.
Direkte til mig: +45 20 71 02 89 · ow@oscarwinther.dk