Building CORPO in Lovable

Making the game I want to play

Lovable helps me turn the game I want to make into something I can actually use and test. That’s where ideas start meeting practical problems.

I started with a working prototype, approved artwork, a campaign and a fairly opinionated idea of how all of it should feel. The job was to carry that into the next build without casually replacing the things that made it CORPO.

A new screen can look perfectly reasonable while changing something important underneath it. A reward can arrive in the wrong order. A character can look different. The Book can open to a mission the player hasn’t reached. My starting instructions were to preserve the existing game, then change the parts that needed to support accounts and a hosted build.

One piece at a time

The migration plan starts with the existing browser game and its approved media. It separates the work on accounts from the rules engine, campaign progression and rewards. That lets me check a change before building something else on top of it.

I also keep the game’s instructions with the project. Aya is the headline hero. The campaign follows five Corpos. The current palette is cream, petrol and copper. The art uses a mature graphic-novel style. Those details shouldn’t become suggestions just because the next prompt happens to be about a database.

The same goes for the mechanics. CORPO has its own rules for labor, assets, Control and Buyouts. There’s no reason to add a deck builder, a crypto wallet or multiplayer because those things sound plausible in a game pitch. The work is to build the game I’ve specified.

A saved reward has to stay saved

One of the biggest changes is moving important decisions out of the player’s browser. In the managed build, the browser asks to take an action. The server checks it, updates the game and records the result. The client doesn’t get to announce that it won or decide how much Copper it deserves.

That affects presentation, too. When a player earns a reward, the reward needs to exist before its reveal starts. Closing the game halfway through the animation should leave something to return to. Reopening the reveal shouldn’t pay out a second time. Those are small moments on screen with a lot of work behind them.

The testing has included a hosted campaign run, ordinary matches, a daily quest, buying a cosmetic with earned Copper, equipping it and playing again. A second test account was kept separate to check that its progress stayed its own. Those are useful checks because they follow the things a player will actually do.

A preview is still a preview

At the October 24, 2026 development checkpoint, the normal campaign and repeatable loop had completed a hosted test. Recovery for an older, exhausted Armory attempt still needed checking in the saved project. A fix needs to work there before I call it done.

Publishing is a separate step. Lovable provides a publishing flow for putting an app at a live address, but a working editor preview doesn’t establish that a release is ready. I still need the accepted source, the right public configuration and a checked player path. Native iPhone and Android delivery are also separate work; a browser build doesn’t prove either of them.

Backups

I keep source snapshots and approved assets outside the active build, along with a record of what was checked. That gives the project somewhere solid to return to when a change fails or the editor has a connection problem. The backup contains the build, not somebody’s account credentials or live player database.

A backup also lets me compare the new build with the game I brought into Lovable. If something changes unexpectedly, I want to be able to find out what changed and get back to the version that worked.