DEV Community: Youngjun Yoon

The last 20% of an AI-built app: nine things that actually block launch

Youngjun Yoon — Sat, 14 Nov 2026 06:56:51 +0000

I keep hearing the same story from people who built something real with Cursor, Lovable, Bolt, v0 or Replit: the app exists, the demo works, and it has been "almost ready" for two months.

The 20% they are missing is rarely a feature. It is a set of integration seams that a generator will happily write code around and never solve. Here are the nine that block launches most often, in the order I check them, with the symptom and the fix.

1. Sessions that only exist in memory

Symptom: you can log in, and a refresh logs you out. Or you can log in on desktop and not on the deployed domain, but it works on localhost.

What's happening: the auth code stores a token in a module-level variable, or sets a cookie without Secure/SameSite, or signs with a secret that is regenerated on each cold start because it is generated at boot instead of read from the environment.

Fix: persist the session in an HttpOnly, Secure, SameSite=Lax cookie (or a refresh token in storage for mobile), keep SESSION_SECRET in the environment, and test after a hard reload, a tab restore, and a cold start. If your serverless function signs the token, it must use a stored secret — the same one, every time.

2. Auth that trusts the client

Symptom: everything works, and any user can read another user's records by changing an id.

What's happening: the generated code checks if (user) in the UI and never checks ownership on the server. With a hosted database, the row-level rules were never written at all.

Fix: every read and write on the server (or in the database rules) must be scoped to the authenticated subject. Not WHERE id = $1 but WHERE id = $1 AND user_id = $subject. On Postgres with row-level security, the policy is the product; test it with two accounts, not one.

3. Payments that only pass in test mode

Symptom: Stripe checkout redirects and returns, but the order never appears, or appears twice, or appears in test mode and not in live mode.

What's happening: the "success" page is treated as proof of payment. No webhook, no signature verification, no idempotency key.

Fix: the redirect page is for the user, not for the database. Grant access in a webhook handler that verifies the signature against the raw body, and write the event id before doing anything so a retried delivery cannot double-credit. Test with the Stripe CLI, then in live mode with a real card and a real refund.

4. Environment variables that only exist on your machine

Symptom: the deploy builds, then the first request that touches a third-party API returns 401 or undefined.

What's happening: .env is not committed (good), the platform's environment is empty (bad), and the code fails at the first network call instead of at boot.

Fix: validate the environment at startup and crash loudly if something is missing. Keep a .env.example in the repo. Treat "works locally" as unverified until it works on the deployed URL.

5. Database schema without migrations

Symptom: you changed a column two weeks ago and the deployed database does not have it. Nobody knows what the live schema is.

What's happening: the schema was applied by hand, or by a generator that ran once.

Fix: one source of truth, applied by a migration tool, run automatically in deploy. Seed data separate from schema. This is also the step that makes a staging environment possible at all.

6. CORS, cookies and the domain triangle

Symptom: the API works from localhost:3000 and fails from https://app.yourdomain.com with a CORS error or a dropped cookie.

What's happening: the API allows *, and a wildcard origin cannot carry credentials. Or the cookie was set on the API's host and the front end lives on another.

Fix: allow-list exact origins, credentials: include on the client, Access-Control-Allow-Credentials: true plus an explicit origin on the server, and put front end and API on the same registrable domain when you can.

7. Deploy that is not a deploy

Symptom: the preview URL works, the custom domain shows an old build, www and the apex behave differently, and half the traffic is HTTP.

What's happening: DNS records were added once and never verified, the platform is serving a cached build, and SSL was issued for one hostname only.

Fix: decide the canonical host, redirect everything else to it, force HTTPS, verify both apex and www, and check a hard reload on a phone on cellular data — not just your laptop on the same network.

8. No error visibility

Symptom: a user says "it broke". You have nothing. No stack trace, no request, no timestamp.

What's happening: generated code has console.log and no error boundary, no server logging, no alert.

Fix: a client error boundary that reports, server logging with request ids, and one alert channel you actually read. You cannot operate what you cannot see, and "operate" is the difference between a demo and a product.

9. Mobile reality

Symptom: fine in a desktop browser, broken on a phone: keyboard covers the input, fixed footers overlap the content, 100vh is wrong, taps are 12px tall.

What's happening: layout was never checked on a device. 100vh was used instead of dynamic viewport units, and safe areas were ignored.

Fix: test on a real phone with the keyboard open. Use dvh, env(safe-area-inset-*), and touch targets of at least 44px. Then test a slow connection, because your users are not on your Wi-Fi.

If the product is a mobile app, add a tenth

Store review is its own integration seam: privacy manifest, permission strings, a real account-deletion path, and a build that does not depend on a debug keystore. Most rejections I see are not about the product at all.

Why generated code stalls exactly here

A generator is excellent at the parts that are visible in a single file and weak at the parts that span files, environments and time: secrets, webhooks, migrations, domains, ownership checks. None of those are hard individually. All of them are invisible until you try to ship, and each one looks like "just one more bug".

That is why the honest answer to "how long until launch?" is not a feature list. It is a checklist of seams, each verified in the environment it will actually run in.

I do this for a living now. I take over half-finished AI-generated codebases as they are, run a free review against this list, and quote only the work that is actually blocking launch — then finish it through deploy and store release, usually in three to five days.

Checklist-based free review of your repo: https://cpcai-studio.netlify.app/en/
I write about operating a one-person studio at https://dev.to/cpcai_studio

If you only take one thing from this: stop asking "what feature is missing?" and start asking "which seam has never been verified outside my laptop?" That question is what a launch is made of.

Turn-based multiplayer that survives bad networks: the state model I use in Flutter

Youngjun Yoon — Sat, 14 Nov 2026 04:08:43 +0000

I ship a turn-based artillery game — one player shoots, the other waits, then they swap. Turn-based sounds like the easy version of multiplayer. It is not; it just moves the difficulty from frame timing to state.

Here is the model I ended up with after shipping to Android and iOS, with a small player base on mobile networks that drop constantly. It is not clever. It is boring on purpose.

1. Sync inputs, not state

The temptation is to send the world state after every turn: tank positions, HP, terrain deltas. That works until two clients disagree by a rounding error and then diverge forever.

Instead the server keeps an append-only event log: shot(angle, power, itemUsed), surrender, turnTimeout. Each client replays the log locally and computes the outcome itself.

Two benefits:

Payload is tiny (a shot is a few dozen bytes, not a terrain diff).
A reconnecting client can be caught up by replaying events, not by rebuilding the world.

2. Determinism is the contract, so remove everything that isn't

The event log only works if every device computes the same result from the same event. That means:

Fixed timestep physics. Never integrate with delta from the frame clock — a 120Hz phone and a throttled one must step the same number of times.
Seeded RNG. Wind, spread, and any crit roll come from a seed stored in the match, indexed by turn number. No Random() anywhere in gameplay code.
No time-based effects. A "3 second fuse" is 180 fixed steps, not now + 3s.

I enforce this with a single deterministic lint rule and a scripted match replay in CI: same log in, same log out.

3. Terrain is content plus deltas

Destructible terrain is where determinism breaks quietly, because terrain edits accumulate. I keep the base map as static content (a heightmap per map id) and store destruction as a small list of crater events. Crater radius and falloff are constants, so the resulting heightmap is identical everywhere.

This also makes replays cheap — a match is a map id, a seed, and a list of events.

4. Reconnect: ask for what you missed

On reconnect the client sends its last applied sequence number. The server replies with the events after it. Because the client can recompute anything from the log, a full world snapshot is only needed when the gap is huge (I use 200 events, which never happens in a 5-minute match).

No "resync state" code path means no second source of truth to keep in sync.

5. Shots must be idempotent

Mobile clients time out and retry. Without protection, a retry fires the same shot twice — which players absolutely notice.

Every action carries a client-generated eventId. The server rejects a duplicate eventId and returns the original result. The client then treats "already applied" as success. This one rule removed the entire class of double-fire bugs.

6. What I deliberately gave up

No rollback netcode. Turn-based does not need it; only one player acts at a time.
No host migration. The server is the authority from turn zero, so there is no host to lose.
No real-time interpolation. The shell animation is cosmetic; the result is already decided by the log.

7. Test it without humans

The most useful thing I built is not the netcode, it is the harness: a bot that plays full matches offline through the same event path as a real client, on a simulated 400ms / 5% packet loss link. It found three determinism leaks that no amount of manual testing found.

If you are building something turn-based, start with the log. The netcode gets simpler every time you remove a source of truth.

I build and ship apps, games, and client MVPs from Seoul as a one-person studio: https://cpcai-studio.netlify.app/en/

Shipping a production-ready MVP in 3-5 days as a solo developer: the pipeline I actually use

Youngjun Yoon — Sat, 14 Nov 2026 01:55:45 +0000

I run a one-person software company. No team, no agency, no project manager — just me and a terminal. People usually assume that means small scope: a landing page, a prototype, something that "works for now".

In practice the last few months shipped a crypto market-analysis web app, a cross-platform turn-based artillery game (Android + iOS + a Toss mini-app), and client MVPs for small businesses. Client projects go from kickoff to a deployed URL in 3–5 days.

This is the pipeline that makes that possible — the parts that actually matter, and the parts people get wrong.

1. Define the one loop the product must close

Before touching code I write one sentence: "A user can do X, get Y, and come back." Everything else is out of scope.

For a client MVP the first loop is usually: sign up → do the one valuable action → see the result saved. If a feature does not touch that loop, it goes on the v2 list. Being able to say no to scope on day one is the biggest speed factor — bigger than any framework choice.

2. The stack I reuse instead of rebuilding

Frontend: Next.js (App Router) + Tailwind CSS
Backend: FastAPI (Python) when there is data, scraping or AI work; Next.js route handlers when there is not
DB + auth: Supabase (Postgres, row-level security, email and OAuth auth)
Mobile: Flutter for cross-platform builds, or a Toss mini-app when the user will never install an app
Background work: one Playwright / ffmpeg worker process, not a queue cluster

Every choice here exists to remove a decision. I do not want to spend day two comparing auth providers; I want to spend it on the loop.

3. Deploy on day one, not day five

The first deploy happens before the second feature: empty page, real domain, environment variables wired. Deploying early turns integration risk into a non-event.

I also keep a fixed layout shell per project type — dashboard, marketing page plus app, admin table. The client clicks a real URL on day one, and the conversation moves from "when will it be done" to "what should this screen say".

4. Automate the work a one-person team cannot afford to repeat

A solo team cannot absorb meetings and manual repetition, so the boring parts get scripted:

Data collection: Playwright scripts with retries and conservative throttling, writing into a typed schema. Respecting rate limits is cheaper than fighting them.
Content pipeline: for the crypto app, a confirmed headline triggers an HTML template render to a 27-second vertical video through ffmpeg — unattended, from headline to final file.
Release: push, build, deploy to Netlify or Vercel. One command, same for me and the client.

The rule: if I click the same thing twice in a week, it becomes a script.

5. Where AI agents actually help, and where they do not

I use an agent for the well-specified, parallel work: writing the CRUD layer for a schema I designed, turning an API response into typed models, drafting a migration, generating form UI, and a first pass at release notes. That is real time saved.

Agents are weak exactly where the product is decided — the data model, what the first loop is, which edge case will hurt the client's business. Handing those off is how you get a fast, wrong product.

Two rules I keep:

Give the agent the schema and the exact file, not the whole repo and a wish.
Never merge output you cannot explain line by line to the client.

6. The last 10% is the whole product

A deployable MVP is not a shippable one. The 3–5 day budget always keeps a fixed block for: error states, empty states, a real 404, loading skeletons, one scheduled database backup, password reset, and a smoke test right after deploy. Clients never notice when these exist. They notice within a minute when they do not.

What this is not

It is not "AI builds your app". It is a small set of boring decisions reused until they are fast, with automation around the parts a human should not repeat. The speed comes from refusing to re-decide things that are already decided.

I run this as a one-person studio in Seoul — case studies and what I build for clients are at https://cpcai-studio.netlify.app/en/. If you are sitting on a half-built repo and a deadline, ask in the comments; I am happy to talk specifics about scope, stack or estimates.