Which Cloud Provider for a Small SaaS Application

A small SaaS application has a distinctive profile. The technical
requirements are modest, the growth is unpredictable, the uptime expectations
are high because customers are paying, and the team is usually too small to have
anyone whose job is infrastructure. Those four facts, taken together, point
fairly clearly.

What the workload actually looks like

Typically: an application server, a relational database, somewhere to put
uploaded files, background job processing, and transactional email. That is the
whole architecture for a very large share of SaaS products, and it stays that
way for longer than founders expect.

What it is not, at this stage, is a distributed system. Reaching for
Kubernetes, service meshes or multi-region replication before you have customers
is building for a scale problem you do not have, at the cost of the velocity you
do need.

The two requirements that matter more than price

The database must be properly backed up and recoverable.
Losing customer data is the one failure a small SaaS does not recover from
commercially. This single requirement justifies a managed database for most
teams, because managed backups actually happen and self-managed ones frequently
do not.

Uptime must be respectable. Not five nines. But a service
that is down for a working day while someone restores it by hand will lose
customers. This argues for something you can rebuild quickly, which in practice
means infrastructure defined in code or at least thoroughly documented.

Where to start

For most early-stage SaaS products,
DigitalOcean or
Linode is the right starting
point. Both offer managed databases, object storage and load balancers, which
covers the entire architecture above, with pricing that is predictable and
documentation aimed at exactly this situation. Linode’s $100 credit for new
users covers a meaningful evaluation period.

If cost pressure is severe and your customers are in Europe,
Hetzner gives you
substantially more capacity per unit of spend. The trade is a narrower managed
service catalogue, so you will take on more operational responsibility,
particularly around the database.

When to start on a hyperscaler instead

Three honest cases.

If your team already knows AWS, Azure or Google Cloud well, use it. The
familiarity is worth more than the price difference, and an unfamiliar platform
during an incident is a genuine risk.

If you are selling into enterprises or regulated sectors, procurement may
effectively require a provider whose certifications your customers’ auditors
already accept. This is a commercial requirement rather than a technical one and
it is not negotiable by argument.

If a specific managed capability is core to the product, such as a data
warehouse or machine learning platform, buy the platform that has it rather than
assembling it yourself.

What to defer

Several decisions feel urgent and are not:

• Autoscaling. Until you have traffic patterns, there is
  nothing to scale against. A slightly oversized instance is cheaper than the
  engineering.
• Multi-region. Solve latency with a CDN first. Genuine
  multi-region is a large undertaking with real consistency trade-offs.
• Kubernetes. Worth it when you have many services and
  several people deploying. For one application and two engineers it adds a
  control plane fee and a substantial amount to learn.
• Reserved capacity. Committing for a year assumes a usage
  pattern you do not yet have. See
  on-demand, reserved and spot.

What not to defer

• Backups, tested by actually restoring one.
• Billing alerts, before the first
  deployment.
• Multi-factor authentication on the provider account, which protects the
  thing that controls everything else.
• Separate staging and production environments, which is much easier to
  arrange at the start than to retrofit.
• Writing down how to rebuild the system, because the person who knows will
  be on holiday when it matters.

Planning for the move you may never make

The useful hedge is not choosing a platform you can leave easily. It is
keeping the portable parts portable: run your application in containers, keep
configuration in environment variables, and use a standard relational database
rather than a proprietary one. Do that, and moving later is a weekend rather
than a rewrite, which removes most of the pressure from this decision.

Which is the real point. For a small SaaS, this choice is far less permanent
than it feels, and the cost of deciding slowly is higher than the cost of
deciding adequately.