Most first-time cloud setups go wrong in the same way. Someone opens an AWS or DigitalOcean account, starts clicking around, and two weeks later has a running server and an unexpected monthly bill. They also have an architecture that already needs rethinking.
I’ve helped untangle enough of these situations to know that the decisions made before logging in matter more than the ones made afterward. This is what I’d want any small team to work through first.
What are you actually moving to the cloud?
This sounds obvious. It isn’t.
Depending on your situation, “moving to the cloud” can mean a dozen different things. It could be a single web application and its database. It could be a set of internal tools your team uses. It could be a customer-facing API with a separate front end. It could be a mix of things that grew organically, and nobody has fully mapped it out.
Before contacting a provider, write down every component that needs to run, including what it is, what it depends on, and what breaks if it goes down. Not a technical architecture diagram. Just a plain list. This exercise almost always reveals something forgotten or assumed: a cron job that sends invoices, a file storage location that three things write to, or a dependency on a third-party service that requires outbound network access.
If you can’t make this list, you’re not ready to start provisioning. The cloud doesn’t simplify an incomprehensible system. It just moves the confusion to a place that costs money.
What does “good enough” reliability look like for you?
Cloud providers sell availability in “nines.” 99.9% or 99.99%. What they don’t tell you is that achieving these numbers requires architectural decisions that increase cost and complexity. Most small teams don’t need these numbers.
For example, a startup with a hundred users could handle twenty minutes of downtime at 2 a.m. However, a business processing payments probably can’t. An internal tool used from nine to five on weekdays has different requirements than a customer-facing product that runs around the clock.
Determine your actual tolerance for downtime before designing anything. This will determine whether you need a single server or multiple servers, whether you need automated failover or a manual recovery process, and how much you should spend on infrastructure versus other things.
Be honest about this. I’ve seen small teams spend three times their necessary budget on redundancy for a product with fifty users. The money would have been better spent elsewhere.
Where is your data, and what are the rules around it?
Data residency matters more than most first-time cloud builders anticipate, and discovering this fact too late can be costly.
If you’re serving customers in Europe, the General Data Protection Regulation (GDPR) has something to say about where their data lives and how it’s handled. If you’re in healthcare, finance, or legal services, specific compliance requirements may affect which providers and regions are available to you. Enterprise customers may have their own requirements that you’ll need to satisfy before signing a contract.
None of this is insurmountable, but it shapes decisions from the start. Choosing a provider or region without considering these constraints may mean rebuilding your choice later.
At a minimum, answer these questions before you start: Where are your customers located? What kind of data are you storing? Are there any industry-specific regulations that apply to your business?
Who is going to manage this after it’s built?
Most first-time setups skip this question, and it’s the one that causes the most problems six months later.
Cloud infrastructure is not a one-time project. Servers need monitoring. SSL certificates expire. Dependencies have security vulnerabilities. Costs increase if not monitored. Backups need to be tested, not just configured.
If you’re a two-person startup, at least one of you is going to be doing this occasionally. It’s important to be clear about who will be doing this and whether they have the time and knowledge to do it properly. If neither person does, it’s a retainer conversation, not a build-it-and-forget-it situation.
Setups that age well are those designed with the person who will maintain them in mind. A simpler architecture that one person understands completely will outperform a sophisticated one that no one fully understands.
Which provider, and does it actually matter?
For most small teams, the honest answer is less than you think.
AWS, Google Cloud, and Azure are all mature platforms with similar capabilities. For an initial small-scale cloud setup, differences in raw infrastructure rarely determine the best option. What matters more are your existing tools and integrations, whether your team has experience with a particular platform, and the pricing at your expected usage level.
DigitalOcean, Hetzner, and similar providers are worth serious consideration for straightforward setups. They’re simpler to navigate, often cheaper on a small scale, and more than sufficient for applications that don’t require the full range of services offered by hyperscalers. Managed options, databases, object storage, and container platforms have improved considerably, removing a lot of operational work.
Choose a provider that fits your team’s knowledge and budget, not the one with the most impressive brand name.
The decisions worth writing down
Before opening a cloud console, it’s helpful to have the following items on paper:
- A plain list of every component that needs to run and what it depends on
- Your actual downtime tolerance, separate from what sounds good in a pitch deck
- Where your customers are, and whether any compliance requirements apply
- Who will maintain this after it’s built, and how much time it will require
- A rough monthly budget, including a buffer for surprises
None of this takes long. It just takes a few hours of conversation or a whiteboard session with whoever is involved in the decision. However, it improves the quality of everything that follows.