Managed services vs. running it yourself: what an early-stage Egyptian startup should actually pay for

Early-stage infrastructure arguments usually get framed badly. One side says "use managed everything, it is safer." The other says "we can run it ourselves, it is cheaper." Both can be true, and both can be reckless.

The real question for a founder in Egypt is more practical: revenue is often in EGP, cloud spend is often in USD, hiring senior infrastructure talent is expensive, and downtime still burns trust even when the company is young. So the decision is not purity. It is where to spend scarce money for operational leverage.

Taleb is a useful case study because it was not built by a large platform team. The stack used familiar pieces: EC2, RDS, S3, Cloudflare, CloudPanel, MariaDB, Netdata, hardening, backups and load balancing, with most of it stood up and operated by a very small team. That is a normal startup shape. The lesson is not "copy this stack"; it is how to decide what deserves a managed service and what can stay simple until scale proves otherwise.

The rule: pay for the things you cannot calmly recover

A managed service is not automatically better engineering. It is a trade: you pay more money so the provider absorbs some operational work. That trade is good when the operational work is rare, high-risk, easy to forget, and painful under stress.

Use three questions:

1. If this fails, does the business stop? User data, payments, login, uploaded files and production databases are in a different category from an admin dashboard or a staging server.
2. Can the team repair it calmly at 3am? Not "can one engineer maybe figure it out." Can the team restore service with a documented path while customers are waiting?
3. Is the managed premium cheaper than the attention it replaces? If a $70/month premium saves ten hours of senior engineering time and reduces restore risk, it is cheap. If a $600/month service replaces a cron job nobody depends on, it is vanity.

The output is not a moral answer. It is a responsibility map. Some things you pay AWS, Cloudflare or another provider to own. Some things your team owns directly. Anything owned by nobody will fail eventually.

The Taleb-shaped architecture

A practical early-stage architecture often looks less polished than a conference diagram and more like this:

What is worth paying AWS a premium for

1. Production databases

If the database contains real users, orders, payments, learning progress, invoices, subscriptions or anything the company cannot recreate, the default should be managed Postgres/MySQL/MariaDB through RDS or an equivalent service.

What you are buying:

• Automated backups and point-in-time recovery.
• Storage monitoring and safer storage expansion.
• Metrics that make incidents diagnosable.
• Read replicas and Multi-AZ options when you need them.
• Less manual work around patching and minor version upgrades.

Self-managed MariaDB can work. Taleb used that shape in parts of the stack because early-stage teams often have to be pragmatic. But the bar is higher than "the database starts". You need tested restores, disk alerts, slow-query visibility, upgrade ownership, replication knowledge and a written runbook. Without those, the cheap database is just deferred risk.

2. Backups and restore machinery

Backups are not a place to be clever. The managed premium is small compared with the cost of discovering, during an incident, that your nightly dump has been failing for three weeks.

Pay for automated database backups. Turn on retention deliberately. Store object data in S3, not on an instance volume. Use versioning when overwrites matter. Then schedule restore tests. A backup that has never been restored is an assumption, not a control.

3. Certificate handling, DNS and edge protection

Cloudflare is one of the easiest early-stage wins: DNS, TLS, caching, basic DDoS absorption, WAF rules, bot controls and an operational interface founders can understand. AWS Certificate Manager is also worth using wherever the AWS service supports it.

Manual certificate renewal is a classic small-team outage. It is avoidable, embarrassing and usually happens at the worst possible time. Automate it or let a provider own it.

4. Object storage

Do not store user uploads on the same server disk as your application unless the data is disposable. S3 exists for a reason: durability, lifecycle rules, access controls, event hooks, backups and simple integration with CDN delivery.

The self-managed alternative fails quietly. Disk fills up, backups balloon, deploys become scary, migrations take longer, and one day you realize application scaling is blocked by files sitting on a single machine.

What is fine to self-manage early

1. The web/application tier

A small team can run application servers on EC2 well enough for a long time if the workload is understood. A panel-managed web tier with CloudPanel, Nginx, PHP/Node services, systemd or Docker is not automatically amateur. It can be the correct early choice when it keeps the system inspectable and cheap.

The conditions are:

• Provisioning steps are documented, not tribal knowledge.
• Deploys are repeatable and reversible.
• Security updates have an owner and a cadence.
• Secrets are not scattered through panel fields and shell history.
• The instance can be recreated from notes, scripts or images.

If those are true, managed Kubernetes, ECS or a platform service may be premature. If they are false, the cheap server becomes a single-person dependency.

2. Lightweight monitoring

Netdata, simple uptime checks and provider metrics are enough at the start if alerts are routed to someone who will act. Early monitoring fails less because the graphs are bad and more because nobody receives the alert, or the alert says "CPU high" without context.

Start with the handful of signals that predict customer pain: app health checks, error rate, latency, disk usage, database connections, queue depth, CPU credits if using burstable instances, and backup success. You can buy Datadog or New Relic later. You cannot buy back the hours lost because disk filled up silently.

3. Basic load balancing

Not every MVP needs a managed load balancer from day one. Cloudflare in front of a single hardened origin can be enough before revenue and traffic justify more. Once the product has meaningful daily usage, put a proper load balancer in front of at least two application instances.

Be honest about what the load balancer solves. It helps with web tier failure and rolling deploys. It does not protect you from a single database, bad migrations, shared Redis, a full disk on all nodes, or a broken deploy that hits every instance.

The honest failure modes

Managed services fail differently from self-managed systems. The managed option is not "no risk"; it is "different risk".

The worst setup is a hybrid where the team believes AWS is managing something AWS is not managing. EC2 is managed hardware, not managed application operations. S3 is managed storage, not a permission model designed for you. RDS is managed database infrastructure, not managed schema design or query performance.

What I would choose by stage

Pre-MVP

Keep it brutally simple. One small application server, managed DNS, Cloudflare, S3 for files, automated database backups at minimum, and basic uptime monitoring. Do not build a platform before you have a product.

First real users

Move production data to managed RDS unless there is a strong reason not to. Add a restore runbook. Add disk, database and application alerts. Put logs somewhere you can search. Harden SSH, firewall rules, IAM access and backups. At this stage, the biggest risk is not lack of elegance; it is one preventable incident breaking user trust.

Traction

Introduce a load balancer and at least two application instances. Separate staging from production. Start infrastructure-as-code for the parts that change often. Add budget alerts because this is where cloud spend starts drifting. If you skipped managed database early, this is usually when the migration becomes worth the pain.

Growth

Pay for stronger observability, managed queues/caches where they remove operational risk, Multi-AZ databases where downtime is unacceptable, and formal incident response. This is also the point where the cost audit becomes recurring work, not a panic project.

The Egypt-specific constraint

Egyptian startups often feel cloud cost more sharply because the bill is usually denominated in USD while revenue, salaries and fundraising runway may be planned in EGP. That makes the managed premium psychologically harder to accept.

But the same market also makes good operational time expensive. Senior backend, cloud and security attention is scarce. If a managed database premium avoids a month of half-owned backup work, the premium may be financially rational even when the AWS line item looks high.

The right question is not "can we save $80 this month?" It is "what business risk did we buy by saving it, and who is now responsible for that risk?"

Founder checklist before you commit

1. For every production database, can we restore to a new environment today?
2. If our only application server dies, how long until service is back?
3. Who receives infrastructure alerts, and what happens if that person is asleep?
4. Are user uploads on object storage, or trapped on a server disk?
5. Are certificates renewed automatically?
6. Can a new engineer recreate production from documentation without guessing?
7. Which monthly cloud costs are deliberate, and which are defaults nobody reviewed?
8. Which parts are we self-managing because it is the right trade, and which parts are we self-managing because nobody made a decision?

If those questions have crisp answers, self-managed infrastructure can be a good business decision. If the answers are vague, managed services are not a luxury; they are a way to buy back operational control while the company is still small.