# From prototype to production — hosting an app you built fast > A working build is not a hosted product. See what it takes to keep an app up, secure and improving, and who does each job. Source: https://customhosted.com/guides/from-prototype-to-production/ № 04 Field manual Launch · Updated 17 July 2026 · 7 min read Contents 1. The prototype problem 2. Hosting it properly 3. Where your app fits 4. Keeping it improving 5. When to rebuild The short version 1. 01 — A fast-built prototype works on your machine or a preview URL — production means TLS, uptime, tested backups, and security patches nobody budgeted time for. 2. 02 — A static build runs fastest and cheapest on the global edge network; anything with a server behind it gets dedicated compute at a flat rate. 3. 03 — Once it's hosted here and defined as code, CodeHerder's agents iterate on the real running app from a plain-language brief. 4. 04 — If the prototype needs real architecture, authentication, or a data model that scales, that's a rebuild, not a brief. ## The prototype problem You built something fast — with an AI coding tool, a contractor, or a weekend of your own time — and it works. It works on your machine, or on a temporary preview URL. Production is a different job: a real domain, TLS that renews itself before anyone notices it was close to expiring, uptime while you sleep, backups you could actually restore from, security patches applied on schedule, and a build that doesn't fall over the first time it gets real traffic. That gap is where fast-built apps stall. Not because the app is bad — because nobody budgeted time for the part that keeps it alive. ## What "hosting it properly" actually means None of this is what a build tool does for you, and none of it is optional once real people are using the thing: - **TLS + DNS**: Certificates issued and renewed automatically; records kept correct as the app changes. - **Daily backups**: Taken on a schedule, without a script someone has to remember to run. - **[Monitoring & alerts](https://customhosted.com/monitoring)**: Uptime and error rate watched continuously, not "when someone reports it." - **Security patching**: The runtime and operating layer kept current against known vulnerabilities. - **A human who answers**: Someone accountable when it breaks at an inconvenient hour — not a ticket queue. That's what CustomHosted runs underneath your app — the operational layer, without you staffing it yourself. ## Where your app fits A static build runs fastest and cheapest on the **global edge network**. Anything with a server behind it — an API, a database, a background job — gets **dedicated compute** at a flat rate. And because we're not limited to a fixed stack, a bespoke setup gets **quoted flat within a day**, not weeks of discovery. See [static site or dedicated server](https://customhosted.com/guides/static-site-vs-dedicated-server) for the decision itself, and [pricing](https://customhosted.com/pricing) for the numbers. ## Keeping it improving after launch — without becoming a dev shop This is the part a build tool or a one-off contractor engagement can't give you. Once your app is hosted here and defined as code, CodeHerder's agents iterate on the real, running thing: you brief a change in plain language, an agent opens a pull request against the actual repo, and the same pipeline already serving the site ships the merge — human-reviewed and versioned, not a stale export someone has to reconstruct first. It's a natural next step for anyone who started by building with an AI tool: the same kind of briefing, now running against production instead of a prototype. The full write-up is on the [loop](https://customhosted.com/loop) page, and [keep shipping without a dev team](https://customhosted.com/guides/keep-shipping-without-a-dev-team) covers how a change actually ships end to end. The pipeline itself is [CodeHerder](https://codeherder.com). ## When it needs a real rebuild Iteration isn't a substitute for a build. If the prototype needs proper architecture — real authentication, a data model that scales, anything that hinges on a genuine product decision — that's a rebuild, not a brief. CustomLabs builds the durable version and stays on the loop afterwards, so it's one team from brief to production, not a handoff between separate vendors. More at [customlabs.io](https://customlabs.io). If this is your team's situation specifically, [production-grade, without an ops hire](https://customhosted.com/for/founders) lays out the dedicated compute, managed database, and iteration add-on that usually fit it. Next in the manual ## Keep reading - [Flat-rate vs. usage-based hosting: why your bill keeps surprising you Usage-based pricing turns every visitor into a cost. See why bills spike, what a flat rate changes, and when each model wins.](https://customhosted.com/guides/flat-rate-vs-usage-based-hosting) - [Static site or dedicated server: which do you actually need? One question decides most of your hosting bill: does your site need a server? This guide gives you a checklist to answer it.](https://customhosted.com/guides/static-site-vs-dedicated-server) - [What “managed” actually means — and the hours it gives back See the work managed hosting takes off your week: patching, backups, monitoring and a human who answers. Each task comes with the hours it saves.](https://customhosted.com/guides/what-managed-hosting-includes) ## Ready to start? Tell us what you're running — one fixed monthly rate, within a business day. [Get a quote →](https://customhosted.com/contact)