Näin siirryt Lovablesta tuotantoon

Lovablella pääset nollasta prototyyppiin nopeasti. Mutta kun sinulla on maksavia käyttäjiä ja roadmappi, huomaat, ettei sinulla ole tyyppiturvallisuutta, testejä, eikä CI/CD:tä. Näin korjaat tilanteen.

Miksi siirtyä?

Lovable generoi koodia joka toimii, mutta se optimoi luomisen nopeutta, ei pitkän aikavälin ylläpidettävyyttä:

• Ei tyyppiturvallisuutta: kaikki on any tai löyhästi tyypitettyä, joten bugit livahtavat läpi huomaamatta
• Ei testejä: jokainen uusi ominaisuus voi rikkoa edellisen
• Monoliittinen rakenne: kaikki logiikka tungettu muutamaan suureen tiedostoon
• Ei CI/CD:tä: julkaisut ovat manuaalisia ja virhealttiita
• Kovakoodatut asetukset: ympäristökohtaiset arvot upotettu koodiin

Vaihe 1: Versionhallinta kuntoon

Jos exporttasit Lovable-projektisi, sinulla on todennäköisesti litteä hakemisto tiedostoja. Aloita alustamalla kunnollinen Git-repositorio puhtaalla committihistorialla.

git init
git add .
git commit -m "Initial export from Lovable"

Vaihe 2: TypeScript strict mode käyttöön

Lovable-projektit käyttävät usein TypeScriptiä, mutta löyhillä asetuksilla. Tiukenna konfiguraatio:

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true
  }
}

Saat 100+ virhettä. Se on hyvä asia. Jokainen virhe on tuotantobugi, jonka sinä nappaat eikä käyttäjäsi.

Vaihe 3: Pura ja rakenna uudelleen

Pilko suuret tiedostot:

• Yksi komponentti per tiedosto: max 150 riviä
• Erota datan haku renderöinnistä: käytä server-komponentteja tai hookkeja
• Ryhmittele ominaisuuden, ei tyypin mukaan: features/billing/ eikä components/, hooks/, utils/

# Ennen (tyypillinen Lovable-export)
src/
App.tsx          # 800 riviä, reititys + tila + UI
utils.ts         # sekalainen kokoelma apufunktioita
api.ts           # kaikki API-kutsut yhdessä tiedostossa

# Jälkeen (jäsennelty)

src/
features/
billing/
billing-form.tsx
billing-api.ts
billing.test.ts
dashboard/
dashboard-page.tsx
dashboard-widgets.tsx

Vaihe 4: Lisää testit kriittisille koodille

Et tarvitse 100% kattavuutta. Aloita poluista jotka sattuisivat eniten rikkoutuessaan:

• Autentikaatio
• Maksujen käsittely
• Ydinliiketoimintalogiikka

test("billing calculates pro-rated amount correctly", () => {
  const result = calculateProration({
    plan: "pro",
    daysRemaining: 15,
    totalDays: 30,
  });
  expect(result.amount).toBe(4950); // $49.50 in cents
});

Vaihe 5: CI/CD-putken pystytys

Automatisoi turvaverkot. Jokaiselle muutokselle pitää ajaa:

1. Tyyppitarkistus (tsc --noEmit)
2. Linttaus (eslint)
3. Testit (vitest run)
4. Build-varmistus (next build)
5. AI-koodikatselmointi, esimerkiksi Greptile tai CodeRabbit

name: CI
on: [push, pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pnpm install --frozen-lockfile
      - run: pnpm typecheck
      - run: pnpm test
      - run: pnpm build

Vaihe 6: Infrastruktuuri koodina

Korvaa manuaaliset julkaisut deklaratiivisella infrastruktuurilla. Työkalut kuten Pulumi tai Terraform mahdollistavat koko stackin määrittelyn koodina:

const api = new aws.lambda.Function("api", {
  runtime: "nodejs20.x",
  handler: "index.handler",
  code: new pulumi.asset.AssetArchive({
    ".": new pulumi.asset.FileArchive("./dist"),
  }),
});

Nyt julkaisut ovat toistettavia, katselmoitavia ja peruttavia. Voit tutustua infrastruktuuriin koodina tarkemmin: Infrastruktuuri koodina ja vibe-koodaus.

Lopputulos

Siirron jälkeen tiimisi voi:

• Julkaista ominaisuuksia nopeammin AI-työkaluilla (Cursor, Claude Code), koska turvaverkot nappaavat virheet
• Perehdyttää uusia kehittäjiä ilman "älä koske tuohon tiedostoon" -varoituksia
• Julkaista perjantaina ja lähteä kotiin

Näin pääset prototyypistä ensimmäiseen 1 000 maksavaan käyttäjään.