How do I put a business tool online and keep it running without a developer?

This page may contain affiliate links from which Blur Studio earns commissions.

This is one of the most common gaps I see, and it has nothing to do with whether the tool itself is any good. A freelancer, an agency, or an AI builder puts something together, it works in the demo, everyone moves on, and six months later nobody on staff can tell you where it actually lives, who has the login to change it, or what happens if the hosting bill doesn't get paid. The tool itself was never the risk. The silence around it was.

What hosting actually covers, and what it doesn't

Hosting means a server somewhere is running your app and serving it to whoever visits the URL. That's it. It does not mean anyone is watching for bugs, anyone is available if a feature breaks, or anyone has a plan for what happens if your builder stops answering emails. Those are three separate things, usually lumped together in people's heads as "it's hosted, so it's fine."

If your tool was built on Emergent, an AI app-building platform, hosting for a published project is included starting on its Standard plan ($20 a month, or $17 a month billed annually), which also includes GitHub integration so the underlying code can live in your own repository as well as on Emergent's servers. Neither Emergent's pricing page nor its public docs state an exact hosting limit or per-app cost beyond the plan price, so if you're relying on it for something revenue-critical, ask directly what happens if your app's traffic grows, rather than assuming the plan price covers any volume.

If your tool was built as fully custom code instead, by a freelancer or an agency, hosting usually means a separate account on a platform like Vercel, which has a free Hobby tier and a $20-a-month Pro tier, and someone, ideally you, needs to actually own that account rather than it sitting under your builder's personal login.

Option	Rough monthly cost	Covers uptime	Covers fixing a bug
Platform hosting only (Emergent Standard, Vercel Hobby/Pro)	$0-$20	Yes	No
Platform hosting + a named internal owner	$0-$20 plus that person's time	Yes	Only if that person has the skill and time
Managed support from a studio	Varies, get a specific quote	Yes	Yes, that's the point of paying for it

The middle row is where most small businesses actually sit, and it's the riskiest one precisely because it looks covered. "Someone on staff could probably figure it out" is not the same as "someone on staff has actually agreed to be responsible for this," and the gap between those two only becomes visible at the worst possible moment, mid-outage, with customers already noticing.

The step-by-step version

1. Find out exactly where the tool lives. Not "it's online somewhere," the actual platform name and account it sits under. Ask your builder directly: "What platform is this hosted on, and whose account owns it?"
2. Get the logins in writing, in your own password manager, not a sticky note or a message thread you'll never find again. This includes the hosting account, the domain registrar if you have your own domain, and the builder tool's account if one was used (like Emergent, Bubble, or similar).
3. Set up backups, or confirm whoever manages the platform is already doing this. A backup you've never tested is a backup you don't actually have; ask when the last one ran and whether anyone has ever restored from it.
4. Name one person, inside or outside your company, who gets called when something breaks. If the honest answer is "nobody," that's the gap to close before you rely on the tool for anything that matters.
5. Test a recovery once, deliberately, while nothing is actually broken. Have whoever's responsible walk through what they'd do if the site went down right now. If they can't answer in under a minute, you don't have a real recovery plan yet, you have a hope.

A concrete example: a property management company I worked with had a maintenance-request tool built by a freelancer two years earlier. The freelancer had since moved on to other work and stopped responding to emails. Nobody on staff knew the hosting platform's login existed until a routine server update broke a form, and it took four days to even locate who had access. The fix itself, once someone with access looked at it, took twenty minutes. The four days were entirely the cost of not knowing where the tool lived.

A second, smaller example: a solo tradesperson had a quoting tool built on an AI app platform and genuinely didn't know which plan the account was on. When the free plan's monthly credits ran out mid-month, the tool kept running, since hosting and credits are billed separately, but any further changes to the tool stopped working until the next billing cycle. That's a useful distinction worth knowing on its own: running out of build credits on a platform like Emergent doesn't usually take your already-published app offline, it just freezes your ability to keep changing it until credits refresh or you upgrade.

When platform hosting alone is not enough

If uptime genuinely matters to your revenue, meaning a few hours down costs you real money or real customers, ask directly who gets paged when the platform itself has an outage, separately from who fixes a bug in your specific app. Those are different failure modes. A platform outage is out of anyone's control and usually resolves on its own; a bug in your specific logic sits there until someone who understands the code looks at it, and platform hosting by itself does not guarantee that person exists or is available.

This is the gap "managed support from a studio" fills, at a price that varies by studio and scope, so it's worth getting a specific quote rather than assuming a flat rate. The honest tradeoff: a managed arrangement costs more than bare hosting, but it converts "hope someone notices" into "someone is actually on the hook," which is the thing most businesses are really trying to buy when they ask about hosting in the first place.

Common mistakes I see with this

• Assuming "it's hosted" means "it's safe." Hosting is one layer. Backups, access control and a named responsible person are three separate layers, and most of the actual disasters I've seen happen in the gap between layers, not from the hosting itself failing.
• Letting the builder's personal account become the permanent home. This is fine during the build, but it should move to a company-owned account before the project is called finished. I've seen this missed for years at a time, discovered only when the original builder's card expired and nobody could figure out why the site went down.
• Never actually testing the backup. A backup schedule that's "set up" but never tested is a belief, not a fact. The only way to know a restore works is to actually run one, ideally into a separate test copy, not your live site.
• Treating credits and hosting as the same thing. On credit-based platforms like Emergent, running out of monthly credits affects your ability to keep building, not necessarily whether the published app stays online. Confusing the two leads to panic that isn't warranted, or complacency that is.
• Waiting for a crisis to find out who's responsible. The cheapest version of all of this is a single conversation, today, where you ask out loud: "if this breaks tomorrow, who actually fixes it?" If nobody has a confident answer, that's the real finding, independent of anything technical.

How I'd approach this

When a client comes to me with a tool that's "fine for now," I don't start by rebuilding anything. I start by mapping exactly what's described above: where it lives, who can access it, whether backups exist and actually work, and who's genuinely on the hook if something breaks. More often than not, that mapping alone closes the real risk, and the tool itself didn't need to change at all. If the tool really is fragile or half-finished underneath, that's when I'd talk about a proper fix, but I'd rather tell you the cheap problem is the only problem than sell you a rebuild you don't need.

The one pattern I'd flag specifically for anything built on an AI platform like Emergent: the ease of building the first version tends to mean nobody treats the handover with the same seriousness they would for a traditionally-coded app, because it felt quick and informal to make. The tool itself can be perfectly solid. The informality is the risk, not the platform. Give it the same five minutes of "who owns this, where does it live" that you'd give any piece of business infrastructure, regardless of how it was built.

When this isn't worth doing yourself

If you've genuinely got nobody, internally or externally, who could execute the steps above even with clear instructions, that's the signal to bring in outside help rather than muddle through alone. A short paid engagement to document and stabilize an existing tool is almost always cheaper than the cost of an outage nobody can fix, and it's a different, smaller job than building something new from scratch.