# AWS consulting in Sydney

> Cloud-native systems built for AWS, platforms moved onto it without stopping them, every release automated, and a clear answer on what you bought after an acquisition. Designed, built and run by the person you talk to.

- A service of Cloudless Labs (Sydney), founded by Nicolas Dao (https://nicolasdao.com)
- How it starts: a free 30-minute call to talk through a project: email nic@cloudlesslabs.com; then a written proposal with a fixed price for each piece of work
- Web page: https://cloudlesslabs.com/services/aws-consulting/

## What we do

- **Cloud-native solutions**: Systems designed for the cloud from the start: serverless functions, managed databases, queues and events, so they scale with demand, recover on their own and cost little when idle.
- **Migrations to AWS**: Off a single server, a data centre or another cloud, live: AWS in front first, both systems in parallel, then the switch, with almost no downtime.
- **Automation and CI/CD**: Pipelines that test and deploy every change on their own, and automations that take the manual work out of releases, infrastructure and day-to-day operations.
- **Serverless and modernisation**: Legacy code and slow databases rebuilt on Lambda, queues and managed databases: faster, cheaper when idle, and something a modern team can work on.
- **Infrastructure as code**: Every account, network, database and pipeline defined in Pulumi, so any environment can be rebuilt from the repository and reviewed like code.
- **Security and accounts**: AWS Organizations, IAM Identity Center and least-privilege roles, so people and pipelines get exactly the access they need, and nothing lives in a laptop.
- **Due diligence after an acquisition**: The systems you inherited, reverse-engineered and documented: architecture, dependencies, running costs and risks, with a plan to integrate them.
- **Rescues**: A late, fragile or insecure platform taken over, stabilised and made safe to change again.

## Who it's for

Small businesses and larger companies whose software runs, or should run, on AWS: a platform that outgrew its server, a legacy system nobody dares touch, a bill that grew faster than the business, or an acquisition that came with technology nobody on the buyer's side has seen. Most of my clients are growing Australian businesses in agriculture, finance and technology, and the decision-maker is an executive who needs it done right, not explained in acronyms.

## How an engagement works

1. **A free 30-minute call.** You explain where the business needs to go; I ask the questions that change the design.
2. **A written proposal with a fixed price.** What I'll build, how, what it will cost to run, and the price for each piece of work, before anything starts.
3. **I build it.** With tests, telemetry and infrastructure as code from the first day, and a running system you can see at every step.
4. **You keep it, or I run it.** Everything is in your AWS accounts and your repositories, documented, so your team can take it over or I keep it running.

## What it costs

The first call is free, and so is the written proposal that follows it. The proposal breaks the work into pieces, each with a fixed price set from its scope: what gets built, the systems it touches, and the risk in changing them. You approve each piece before it starts, and the price doesn't move once it's agreed. That's our default, not a rule: if a retainer or hourly billing suits your project better, we'll work that way.

## Why me

You talk to the engineer. There's no account manager and no junior team: I design the system, write it with Claude Code under my review, ship it and keep it running. I've been building software for two decades, the last 15 years of them in the cloud, and I've run three businesses of my own, so I start from the business problem, not the brief.

What I build with, and why, is public: [The Stack](https://cloudlesslabs.com/stack/brief.md) lists every AWS service I use or avoid, with prices and the gotchas that bit my clients. The projects below are real, with the client described rather than named.

## Questions

**Do you only work with Sydney companies?** No. I'm in Sydney and most clients are in Australia, but the work is remote-first, and AWS regions are the same from anywhere.

**Can you work with our team rather than instead of it?** Yes. I often design and build the hard parts, then hand over a codebase, the infrastructure as code and the runbooks, and coach the team to ship with Claude Code or Codex.

**What does it cost?** It depends on the work, so the first step is the free call, then a written proposal with a fixed price for each piece. You know the cost before you commit.

## See it in practice

- [Off a fragile VPS and onto AWS, with almost no downtime](https://cloudlesslabs.com/work/vps-to-aws/index.md): An Australian agriculture-technology company with a large IoT sensor network. A growing agtech platform ran on a single server that could neither scale nor be secured. I moved all of it to AWS, live, with almost no downtime: AWS in front of the devices first, then both systems running in parallel, then a cut-over that lost no data.
- [From legacy ASP.NET and stored procedures to Node.js on serverless](https://cloudlesslabs.com/work/dotnet-to-serverless/index.md): An Australian agriculture-technology company with a large IoT sensor network. A legacy stack of ASP.NET, C# and slow SQL stored procedures, modernised into Node.js on serverless AWS: faster, cheaper to run, and something a modern team can work on.
- [Technology due diligence and integration after an acquisition](https://cloudlesslabs.com/work/acquisition-due-diligence/index.md): Acquiring companies, after an acquisition. When a company buys another, it buys its technology too, often undocumented. I reverse-engineer the inherited systems, document their architecture, dependencies and costs, and plan how to modernise, consolidate and integrate them. One engagement delivered, a second under way.
- [Rescuing a stalled modernisation, then handing routine changes to AI](https://cloudlesslabs.com/work/rescue-and-ai-delivery/index.md): An established Australian organisation in the agriculture sector. An organisation consolidating its legacy systems into one portal hired a large outsourced team, and got a late, fragile, insecure platform. I took it over alone, am cleaning it up, and am now building the process that lets non-technical staff ship routine changes through AI.
- [Real-time ingestion for a large farm-sensor network](https://cloudlesslabs.com/work/realtime-iot/index.md): An Australian agriculture-technology company with a large IoT sensor network. Thousands of field devices reporting around the clock, processed as the data arrives instead of hours later, on infrastructure that scales with the network.

## Related

- [Every service](https://cloudlesslabs.com/services/index.md)
- [Contact](https://cloudlesslabs.com/contact/index.md)
- [How we work](https://cloudlesslabs.com/about/how-we-work/index.md)
- [Map of every Markdown file on cloudlesslabs.com, with what each one answers](https://ask.cloudlesslabs.com)