Cloud solutions, sized to the actual problem
Most business applications do not need a cluster. They need static assets on a CDN, a handful of functions that scale to zero, a managed database, and a deployment pipeline nobody has to think about. That architecture costs very little at low traffic and does not need replacing at high traffic. Every project on this site runs on it.
What cloud solutions mean in practice
Cloud development is building applications that assume managed infrastructure rather than servers you own. Instead of provisioning a machine, patching it, and hoping it is sized correctly, you assemble managed services static hosting on a global CDN, serverless compute that scales with requests, a managed database with backups handled for you and connect them with a deployment pipeline.
The engineering shift is that infrastructure becomes part of the codebase. Environments are defined in configuration, deployments are triggered by merges, and rebuilding the whole stack from an empty account is a documented procedure rather than an archaeology project. That is what makes an application recoverable, auditable and transferable and it is why "it runs on a server someone set up in 2019" is a risk rather than an architecture.
In practice that means Microsoft Azure for us: Azure Static Web Apps for hosting, Azure Functions for the API layer, GitHub Actions for the pipeline, and Azure's managed certificates and custom domain handling for the front door. It is a narrow slice of a very large platform, and it is the slice that covers most web and web-application workloads properly. We are not an Azure consultancy for identity governance, virtual network design, Kubernetes or data-platform engineering if your project needs those you want a Microsoft partner with that specialisation, and we would rather say so now than discover it in month three. The architecture principles here are portable, and we will work inside an existing AWS or Google Cloud footprint rather than insisting on a migration you have no reason to want.
What we provide
Cloud architecture
Choosing the services and the boundaries between them, sized against your actual traffic and your actual team not a reference architecture for a company a hundred times larger.
Static-first hosting
Pre-rendered HTML and assets served from a CDN edge on Azure Static Web Apps, so the common path never touches an origin server. Fastest, cheapest and most resilient option available for anything that can use it.
Serverless APIs
Azure Functions for the parts that genuinely need a server either the managed API that ships with Static Web Apps or a separate Function App where the workload warrants isolation scaling to zero between requests.
CI/CD pipelines
GitHub Actions building, testing and deploying on every push, a real preview URL per pull request with automatic teardown when it closes, and a rollback that is one action rather than one incident.
Routing and headers
staticwebapp.config.json done deliberately: navigation fallback that does not swallow real 404s, cache-control tuned per asset class, and security headers set at the edge rather than hoped for in the application.
Domains, DNS and TLS
Apex and subdomain configuration, validation records, managed certificates with automatic renewal, and a single canonical hostname with everything else redirected to it.
Storage and data
Blob storage for user uploads and generated assets, and managed database services connected through platform-managed identity rather than connection strings in a repository.
Migration and cutover
The new environment built and verified in parallel on a temporary hostname, then a DNS cut-over with a low TTL set in advance so the rollback is a DNS change rather than a rebuild.
Monitoring and cost control
Uptime and error monitoring wired in at launch, plus budgets and alerts so a misconfiguration surfaces as a notification rather than an invoice.
Who we do this for
Businesses on ageing hosting
Shared hosting or a virtual machine somebody configured years ago, with no pipeline, no backups you have tested, and no one who remembers how it was set up.
Teams whose cloud bill has drifted
Always-on capacity for bursty traffic is the most common cause, and it is usually an architecture question rather than a negotiation with the vendor.
Products that need to be fast globally
A single-region server is slow for most of the world. Edge delivery fixes that without a rewrite.
Microsoft-aligned organisations
Companies already invested in Azure and Microsoft 365 who want their web presence in the same tenant, under the same billing and access controls.
Teams deploying by hand
A Static Web App created through the portal and deployed by dragging a folder, with no pipeline and no reproducible configuration.
Projects with a platform mandate
Where the cloud is fixed by procurement or policy and the requirement is simply to build well within it.
What this solves
Refreshing a deep link returns 404
The single most common Azure Static Web Apps issue: a client-routed application with no navigation fallback configured. The fix is a few lines of routing config and the correct fix still lets genuinely missing paths return a real 404 rather than serving the homepage with a 200.
Deployment is a manual ritual
Files copied over FTP, or a build run on one laptop. Automating it removes both a bottleneck and a single point of failure.
The custom domain never validated
Apex domains need the right record type and the platform's validation token. It is a five-minute fix that has stalled plenty of launches for a week.
Assets are not cached
Default cache headers on fingerprinted build output waste the CDN entirely. Immutable caching on hashed assets and short caching on HTML is the correct split.
Nobody has tested the backups
A backup you have never restored is a hypothesis. Restore procedure and recovery time belong in the launch scope, not in the first incident.
Costs scale with time, not usage
Reserved capacity idling overnight, or deployment credentials and connection strings living in the repository because nobody set up secrets. Serverless and static delivery align spend with demand; managed identity removes the credential entirely.
How we work
- Step 01
Start from the traffic shape
Bursty, steady, global or regional, read-heavy or write-heavy. That shape, not fashion, decides the architecture.
- Step 02
Push work to build time
Anything that can be computed during the build should be. A pre-rendered page is faster, cheaper and more reliable than the fastest possible server-rendered one and it means crawlers get real HTML without waiting for JavaScript.
- Step 03
Configuration lives in the repository
Routing, headers, redirects and the workflow are versioned files, so the environment can be rebuilt from an empty subscription and reviewed like any other change.
- Step 04
Use the preview environments
Every pull request gets a real deployed URL. Reviewing a running build rather than a description removes most late surprises.
- Step 05
Set headers at the edge
Caching and security headers configured in platform routing rather than application code, so they apply to every asset including the ones nobody thought about.
- Step 06
Set the budget and the alarm
Spend limits and alerts configured before launch, so surprises arrive as warnings rather than bills.
What we build with
Hosting
- Azure Static Web Apps
- CDN / edge caching
- Managed TLS
Compute
- Azure Functions
- Node.js
- Scheduled jobs
Storage & data
- Azure Blob Storage
- Azure SQL
- Managed PostgreSQL
- Managed identity
Pipeline
- GitHub Actions
- Preview environments
- Automated rollback
This list is what we actually work in, not a catalogue. Where a project needs something outside it, we will say so rather than learn it on your budget.
The parts nobody demos
Security, performance, deployment, testing and maintenance decide whether a project is still working in two years. They are scoped in from the start rather than quoted as extras.
Security
TLS everywhere with managed certificate renewal, deployment tokens as repository secrets rather than committed values, managed identity in place of connection strings wherever the service supports it, least-privilege access on every resource, and security headers configured in platform routing rather than hoped for in the application.
Scalability
Static assets scale to any traffic level by definition. Serverless compute scales with request volume and back down again. The database is normally the first real limit, which is why connection handling and indexing get attention before anything else does.
Resilience
Global CDN distribution so a regional problem is not a total outage, automated backups with a tested restore procedure, health checks, and deployments that can be reversed immediately.
CI/CD
Every pull request builds, tests and gets its own preview URL, and is torn down when the pull request closes. Every merge to the main branch deploys. Nothing is deployed from a laptop, and no step in that chain depends on a specific person being available.
Routing and SPA behaviour
Navigation fallback configured so direct URL access and refreshes work on every route, with the fallback excluding asset paths so a missing file still returns 404 rather than an HTML page with a 200 status. Search engines are extremely sensitive to that distinction.
Cost
Static-first architecture means most requests are served from cache at near-zero marginal cost, and functions bill per execution. For most business sites and small applications the monthly cost is a rounding error compared with a virtual machine sized for peak. Budgets and alerts are configured at launch, and we size for the traffic you have with headroom, not for a hypothetical.
What people come to us with
- Migrating a site or application off ageing shared hosting or an unmanaged VM
- Deploying a React or static site to Azure Static Web Apps with a proper pipeline
- Fixing 404s on refresh, custom domain validation or caching on an existing Static Web App
- Adding a real CI/CD pipeline to a project deployed by hand
- Adding a serverless API to a site that is already hosted in the cloud
- Restructuring an application whose hosting costs have outgrown its traffic
- Global delivery for a product currently served from one region
- Configuring domains, DNS, certificates, redirects and security headers correctly for a launch
Where we have done this
Builds where this capability carried real weight. Each case study describes what was actually engineered.
Cloud Solutions questions we get asked
Microsoft Azure by default it is where our shipped projects run and where our operational depth is. The architecture principles are portable, and we will work with an existing AWS or Google Cloud footprint rather than insisting on a migration you have no reason to want.
Because the requested path exists in your client-side router but not as a file on disk, and no navigation fallback is configured. Adding a navigationFallback to staticwebapp.config.json fixes it. Configure the exclusion list carefully a fallback that catches everything will serve HTML with a 200 status for missing assets, which confuses both browsers and crawlers.
For bursty or low-to-moderate traffic, substantially you pay per request instead of per hour. For sustained high throughput a reserved instance can win. The larger saving is usually operational: no servers to patch, monitor or size.
Yes. The new environment is built and verified in parallel on a temporary hostname, then DNS is cut over with a low TTL set in advance. Rollback is a DNS change back.
We use Blob Storage, Azure SQL and managed identity as part of application delivery. We do not present ourselves as an Azure consultancy for networking, Kubernetes, identity governance or data-platform work that is a different specialisation and you should hire for it directly.
It serves static files and serverless functions. For search visibility the effective approach is pre-rendering routes at build time so real HTML is served from the edge, which is what this site does. Full per-request server rendering is a different hosting model.
You do. Infrastructure is built in your subscription under your billing, and we work inside it with scoped access. Ownership and continuity never depend on us, and you are never renting your own infrastructure back from us.
Thinking about cloud solutions?
A short conversation is usually enough to tell you whether this is a week of work or a quarter of it and whether you should be building it at all.