You have a website and you pay for hosting. Now there is something you would like built: a booking tool, a customer portal, a small internal app. The natural assumption is that it can live where the website lives. Sometimes it can. Often it cannot, and the time to find out is before anyone writes a line of code.
This is not a reason to buy new hosting. Most of the time the right first step is to check what you already have, because it may well be enough.
Why a website and an app need different things
Most small business websites are built on WordPress or something similar, which runs on PHP with a MySQL database. Nearly every hosting plan in the world is built for exactly that combination, because it is what most of the web runs on.
Applications are often built differently. Many modern ones run on Node.js, and some on Python. They may need a database other than MySQL, such as PostgreSQL. They may need to run something in the background continuously, or on a timetable. A plan built for websites can be excellent at websites and simply unable to do some of these.
The five things to check
These are the questions that decide whether an app can live on your existing hosting. Your host’s support can answer all of them, usually in one reply.
- Which languages can it run? PHP is nearly universal. Node.js and Python are available on some shared plans, often through an option in the control panel, and missing on many others.
- Which databases does it offer? MySQL or MariaDB almost always. PostgreSQL less often. If an app needs one the plan does not have, that alone decides it.
- Can it run scheduled tasks? Most plans with a control panel can. Worth confirming, because many useful apps depend on a job running on a timetable.
- Can something run all the time? Some apps need a process that stays running to answer requests or do background work. Shared plans often limit how long processes run, how many there are, and how much memory each may use. These limits are the most common surprise.
- Where is it, and who can reach it? If the app holds personal data, knowing where the server is located and who on the hosting side can access it matters.
What the answers usually mean
Everything is available. The app can go on the existing hosting. No new bill, no new supplier, and one less account to keep track of. This happens more often than people expect.
Most of it is available, with tight limits. A small, low-traffic app often lives happily within shared hosting limits. A busy one, or one with heavy background work, may run into them under load rather than in testing, which is the worst moment to find out. Worth an honest estimate of how it will be used.
Key pieces are missing. The app needs a small server of its own, or a specialised platform that runs applications. That is a new cost and a new thing to look after, and it should appear as a line in the quote rather than as a surprise afterwards.
Building around the hosting you have
There is a second option that gets missed: choosing how to build the app so that it fits what you already pay for.
If the hosting runs PHP and MySQL well and nothing else, a small app built on that combination costs nothing extra to host and runs on infrastructure that is already maintained. That is not always the most fashionable choice, and it is often the most sensible one. A good builder asks about your hosting before choosing the technology, not after.
The reverse also applies. If the right app needs things your hosting cannot do, forcing it to fit creates a fragile application. The aim is the honest fit, not the cheapest bill.
Three situations, worked through
A physiotherapist wants a simple intake form that saves into a database and emails a summary. The existing hosting runs PHP and MySQL. Build to that. No new hosting, nothing extra to renew, and the form sits on the same domain as the website.
A training company wants a portal where clients log in, see their courses and download certificates. Their hosting supports Node.js through the control panel, has MySQL, and runs scheduled tasks. The app fits, and the remaining question is whether the plan’s limits hold at the busiest point of the year. Checked with an estimate of peak users before building, not after.
A logistics firm wants an app that tracks deliveries in real time and updates every few seconds. That needs a process running constantly and room to grow. Shared hosting is the wrong shape regardless of the language. A small dedicated server, sized to the job and managed by someone, is the honest answer, and it is costed as part of the build.
Five things worth doing
- Find out what your hosting is: the provider, the plan name and whose account it is in.
- Send your host the five questions above. Support teams answer them all the time.
- Give the answers to whoever is quoting before they choose the technology. It can change the cost of both the build and the running.
- Ask for hosting costs as a separate line in any app quote, including who looks after the server.
- Check whether the app and the website should share an account at all. Sometimes keeping them apart is worth a small cost, so that a busy app never slows the website.
Common misconceptions
- “Hosting is hosting.” Plans differ greatly in what they can run. A plan that is excellent for a website may be unable to run a particular app at all.
- “We need new hosting for any app.” Often not. Many small apps can live on what you already pay for, especially if they are built with that in mind.
- “Cloud means it scales automatically.” Only if it was built and paid for that way. Most small apps never need it.
- “The developer will sort the hosting.” They may, and it is worth knowing whose account that ends up in and who pays for it after the build.
The honest summary
Before anything is built, check what the existing hosting can run. Five questions to your host will usually settle it. Most of the time the answer is either “yes, it fits” or “yes, if it is built a particular way”, and both of those cost nothing extra to run.
When the answer is no, it is better to know at the quoting stage, with the extra hosting costed and its ownership agreed, than to discover it when the app goes live. Where your business software actually lives is worth knowing in any case, and an app is a good reason to find out.
If you have an app in mind and are not sure what your hosting can run, send the plan name and a line about the app. The answer is usually quick, and it is often that you already have what you need.
Common questions
Does my hosting support Node.js?
Check your control panel for an option to set up a Node.js application, or ask your host directly. Many shared hosting plans support it, often with limits on memory and running processes, and many do not support it at all. Your host can confirm in one reply.
Can I run an app on the same hosting as my WordPress website?
Often yes, if the hosting supports what the app needs and the app is not too busy. It can be worth keeping them on separate accounts, so a heavy app never slows the website down.
What is the difference between shared hosting and a server for an app?
Shared hosting puts many accounts on one machine with limits to keep them fair. That suits websites and small apps. A server of your own has no neighbours and allows long-running processes, at a higher cost and with more to maintain.
Should I choose the hosting or the app technology first?
Find out what your existing hosting can run first. A good builder can often choose technology that fits it, which saves a running cost. If the app genuinely needs more, that becomes part of the quote.