Java, Python and TypeScript engineering for systems that run on data.
What it is
Cloudtech develops software for companies whose requirements are not met by packaged products: back-end services, data processing, integrations, applications and database code. The work follows the same engineering discipline at any size, from a connector to a complete system: a defined scope, version control, automated tests, a reproducible build and an owner who keeps it running after delivery.
Software development is a Cloudtech service line of its own. It is delivered on its own or as part of a data platform or managed-services engagement, and the scope is set per engagement: a single connector, a stream-processing job, or a complete application. The engineers who write the code also operate it, so maintainability is a requirement from the first commit, not a hand-over concern.
What we do
- Applications. Complete business applications developed to requirements: back ends in Java or Python and SQL, front ends in TypeScript, performance-critical components in Rust.
- Database programming. SQL and PL/SQL on Oracle and PostgreSQL: database logic, versioned migrations with Liquibase or Flyway, query and index work, and the stored code that many enterprise systems still depend on.
- Back ends, APIs and integration services. Java and Python, designed contract-first: REST APIs described in OpenAPI, event streams in AsyncAPI and Avro schemas held in a registry, so producer and consumer are built against the same definition and a change is checked for compatibility before it ships.
- Stream-processing jobs. Java on Apache Flink: keyed state, joins across change streams, windowed aggregation and period close by event time, so late data lands in the right period. Kafka producers and consumers around them.
- Tooling and automation. Python for data tooling, operational tooling for platforms and clusters, monitoring agents, and the code around AI integration: model serving, retrieval, agents and evaluation harnesses.
- Integration and connectors. Interfaces to plant systems, legacy databases, file drops and APIs. Where an off-the-shelf connector is missing or unsuitable, it is written, tested and maintained like any other component.
- Modernisation of legacy systems. Moving logic out of ageing applications and databases in steps rather than in one cut-over. The old system is first wrapped behind an interface and then replaced piece by piece, with tests captured from its behaviour guarding each step. The new system runs beside the old one until their results agree, and the comparison is kept as sign-off evidence.
What you get
The scope is set per engagement, from one connector to a complete application. What you receive follows the practice the industry has settled on for bespoke software: your code in your repository, a build anyone can reproduce, tests that gate every change, a contract for every interface and a supply chain you can audit.
- Your code, in your repository. Source, build configuration, pipeline definitions and infrastructure code in version control under your account, with a reproducible build. Rights to the code are set in the contract; the default is that software written for you is yours.
- Tests that gate every change. Unit, integration and contract tests run in CI on every commit. Acceptance criteria are agreed before the work starts and tested before it is accepted.
- A contract for every interface. OpenAPI for APIs, AsyncAPI and Avro schemas for message streams, held where producer and consumer both read them and checked for compatibility on every change.
- A supply chain you can audit. Dependencies pinned and scanned on every build, a software bill of materials in CycloneDX or SPDX with every release, and signed builds whose provenance records what was built from which source. Development follows the NIST Secure Software Development Framework.
- Deployment through your CI/CD. Build, test and deploy pipelines in GitLab CI or Bitbucket CI, configuration applied by Ansible and Helm, every release versioned and reversible.
- Documentation that outlives the project. The architecture and the decisions behind it as architecture decision records, API documentation generated from the contracts, and runbooks for deployment, configuration, failure modes and recovery.
- Measured delivery. Change lead time, deployment frequency and change failure rate reported for the engagement, the way the DORA research measures software delivery.
- Defect correction and operations. Defects found after acceptance are corrected under the warranty set in the contract. After that the software runs under the same 24/7 service as the platform beneath it, with a P1 reaction within the hour.
Where software development fits
Some engagements are pure software: an application, an integration, a migration tool. More often, the software is part of something larger. Data platform engineering needs connectors and jobs that encode the business rules. Analytics, reporting and decision support needs APIs that answer in milliseconds and the KPI applications on top of them. AI integration needs model serving, retrieval and evaluation code. DevOps, automation and observability needs tooling that stops and starts a platform in the right order, and Managed platform and database services runs what is written here, 24/7. In each case the same engineers design the platform, write the software and operate both.