CLOUDLESS LABS

The standard for every system we build

How we work.

The standards every system we build is held to: a spec the business signs, telemetry that explains failures, tests that prove it works, and infrastructure that exists only as code.

In short

  • Vision to spec

    We turn what the executives want into a specification, a technical design and an architecture, before a line of code.

  • Observable by design

    Every system ships with structured logs, traces and audit trails, so failures explain themselves.

  • Tested end to end

    Unit tests and end-to-end tests on everything we ship. Full coverage is the goal, not a nice-to-have.

  • Infrastructure as code

    If it isn't in code, it doesn't exist. Every environment can be rebuilt from the repo.

  • Event-driven, carefully

    Queues and events where they earn their place, with retries, dead letters and idempotency designed in.

  • Agentic, with a human in charge

    Claude Code writes much of the code. A senior engineer owns the spec, the design, the review and the result.

From a vision to a specification

The most valuable thing we do happens before any code. An executive describes where the business needs to go: serve twice the customers, stop losing money on a process, make the data usable. Our job is to capture that at the business level, then translate it into something an engineer can build and a board can approve: a specification of what the system must do, a technical design of how, and an architecture that shows what it will cost to run and how it will grow.

Getting this right is most of the battle. A clear spec is also what makes AI useful: an agent given a precise specification builds the right thing quickly, and an agent given a vague one builds the wrong thing even faster.

Analysis comes first, too. Before we automate a process, we map how it really works today, find where the time and money are lost, and remove the waste. Automating an inefficient process only makes the inefficiency faster.

Observable by design

An OK system works on launch day. A great system tells you, after launch, what went wrong, where and why, often before a customer notices. The difference is telemetry, and we design it in from the start rather than bolting it on after the first incident.

Logs and traces are not the same thing:

  • A log is the tip of the iceberg. It says something happened: an error, a timeout, a failed payment.
  • A trace is the iceberg. It follows one request or one event across every function, queue and database it touched, with the timing of each step, so you can see the chain of causes that led to the error, not just the error.

So every system we build has structured logs, distributed traces and clear audit logs of who did what and when. With that in place, mistakes are detected proactively, from alarms on the signals that matter, instead of reported by users. Keeping all that telemetry without a shocking bill is a craft of its own, covered in our logging use case.

Tested end to end

Every system we ship has unit tests for its logic and end-to-end tests for the journeys that matter: a user signs up, an order is paid, a sensor reading reaches the dashboard. We aim for full coverage, and treat the tests as part of the product, not an extra. Tests are also what make AI-written code safe to ship: an agent can write a thousand lines in minutes, and the test suite is how we know those lines are right.

Infrastructure as code, or it doesn't exist

Every bucket, function, queue, database, DNS record and permission we create is defined in code, mostly with Pulumi, and reviewed like the application. A staging environment is a copy of production with different numbers. A change is a pull request. When something breaks, the whole environment can be rebuilt from the repository instead of from someone's memory. Builds and deployments run through CI/CD: GitHub Actions, and our own build servers where we need more speed or control.

Event-driven, learned the hard way

Queues, events and asynchronous workers are how a system absorbs spikes and survives failures. They're also how it loses messages, processes the same payment twice or retries a broken request forever. We've learned each of those the hard way, so now they're designed in from the first diagram: idempotent consumers, deliberate retry and timeout windows, dead-letter queues with alarms, and back pressure so a spike never flattens the database behind it.

Data first

Good decisions come from data, so a lot of our work is data science: collecting the data a business already has, wrangling it into shape, and extracting the insight hiding in it. Agriculture sensor streams, financial markets, operational records: the method is the same, and AI now makes each step faster.

Agentic programming, with a human in charge

We've been all-in on agentic AI since 2024, and Claude Code is how we build for every client. It has massively increased what one senior engineer can deliver. But the agent is a power tool, not the engineer: we write the spec, design the architecture, set the standards above, review what it produces and own the result. We also build the tools around it, from MCP servers to a large library of agent skills, and the package manager that distributes them, HappySkills.

See it in practice

  1. 04 Deep neural networks that forecast the weather An Australian agriculture-technology company with a large IoT sensor network · Agriculture technology Machine-learning models and deep neural networks, trained on the company's own sensor data with GPUs on Amazon SageMaker, to predict the weather where its customers farm.
  2. 03 Real-time ingestion for a national farm-sensor network An Australian agriculture-technology company with a large IoT sensor network · Agriculture technology Thousands of field devices reporting around the clock, processed as the data arrives instead of hours later, on infrastructure that scales with the network.
  3. 02 Cutting an AWS bill from US$240k a year to under US$40k An Australian agriculture-technology company with a large IoT sensor network · Agriculture technology · In progress An agtech platform was paying about US$240,000 a year for AWS. The programme under way takes it under US$40,000: roughly US$200,000 a year back in the business, for the same workload.

Want a system built like this?

Tell us where the business needs to go. You'll talk to the engineer who will design and build it, not a salesperson, and get an honest answer on whether we're the right fit.

Contact Us

For general inquiries, please contact us at:

nic@cloudlesslabs.com

For e-learning capabilities, please contact:

lin@shirleenwong.com