Infrastructure you can hand to an on-call engineer.
Azure and AWS architecture, Kubernetes, CI/CD, and observability — built so the team that inherits it can operate it without calling the people who wrote it.
How we treat this work.
Most infrastructure problems are not capacity problems. They are handover problems: one person knows why the cluster is configured that way, the deploy is a set of steps in someone's head, and nobody can say what "healthy" means without opening a dashboard and squinting.
We build the boring version. Infrastructure as code so the environment is reproducible, pipelines with preview deploys so a change is reviewable before it is live, and observability with named SLOs so on-call has a definition of broken that does not depend on judgement at 3am.
Arabvesta runs .NET on Azure Container Apps serving a Flutter app and a React dashboard from one backend. The point of that setup is not that it is clever — it is that a small team can operate it.
What actually lands.
Architecture that fits the team
Azure or AWS designed against the size of the team that will run it — microservices where they earn their keep, a well-built monolith where they do not.
Kubernetes and Dapr where warranted
Container orchestration, service meshes, and distributed application runtimes — with an honest conversation first about whether you need them yet.
CI/CD with preview deploys
Every pull request gets a real environment, so review happens against the running thing rather than a description of it.
Observability and SLOs
Metrics, traces, and logs that answer questions, with named service objectives and alerts that fire on user impact rather than on CPU.
Runbooks and handover
Written procedures for the failures we can predict, and an environment your engineers can rebuild from the repository.
Cost work
Right-sizing, reserved capacity, and killing the things nobody remembers provisioning — usually the fastest return on a cloud engagement.
The markets we ship into.
- Saudi Arabia and the Gulf — including workloads with data-residency requirements that constrain which regions and services are on the table.
- Egypt — cost-sensitive production infrastructure for teams scaling on thin margins.
- UAE — enterprise migration and modernisation.
- United States — production workloads on Azure and AWS.
Work we shipped with it.
What gets asked before signing.
- Azure or AWS — which should we use?
- Usually whichever your team already knows, or whichever your enterprise agreement makes cheaper. Both will do the job. The decision matters far less than whether the setup is reproducible and someone other than the author can operate it. We build on both and will not push you toward the one we prefer.
- Do we need Kubernetes?
- Probably not yet, if you are asking. It earns its complexity at a certain scale and team size, and below that it is an operational tax paid for an option you are not using. Managed container services cover a lot of ground first. We will tell you when you have crossed the line.
- Can you help with data residency in Saudi Arabia or the UAE?
- Yes, and it is a design constraint rather than a checkbox — it determines which regions, which managed services, and sometimes which third-party APIs are available to you at all. We establish those limits before the architecture, because discovering them afterwards means rebuilding.
- Will you operate it for us, or hand it over?
- Either. Some clients want us on-call indefinitely; others want a clean handover to their own team, which is why the runbooks and infrastructure-as-code exist. We build for the handover in both cases — a setup only we can run is a liability you are paying for.
- Mobile app developmentMobile apps that pass review and keep shipping.
- Web developmentWebsites and web platforms that load fast and read natively.
- Applied AIAI that moves a number, not a demo.
- Product designDesign that survives contact with Arabic.
- Technical leadershipSenior judgement, for the phase that needs it.
Have an RFP? Have an idea? Let's build it.
We reply to every inquiry within one business day. Tell us about your project, timeline, and what success looks like.