Cloud & Data Platform

We set up and look after the infrastructure that everything else has to stand on, AI included: cloud setup and ongoing management, firewalls and TLS certificates, the path a release takes into production and how it scales, data pipelines and ETL, IoT, and the internal platforms a team works in every day. What running our own estate has taught us is that the job is not finished on the day a system goes live. It is finished when the system comes back on its own after a restart, renews its own certificates without anyone remembering to, and someone knows where to look when it stops.

What the work covers

The work at this layer splits in two: getting systems up and keeping them up, and keeping data arriving on its own without anyone going to fetch it. We take on both, along with the internal tooling a team uses to see the whole picture.

• Cloud setup and ongoing management on GCP, Azure, AWS or DigitalOcean: environments kept apart, access rights, a backup plan, and someone still looking after it once it is handed over.
• Security at the edge: firewall rules, a reverse proxy as the single public entrance, and TLS certificates that renew themselves.
• Deployment and scaling: a release path that runs the same way every time, health checks at the port level, and capacity added as the workload grows.
• Data Pipeline and ETL Automation: extracting, transforming and loading from several sources so that everything lands in one place on a set schedule.
• Data Scraping: collecting from websites and public documents, turning unstructured material into tables that are ready for analysis.
• IoT Solution: connecting devices and cameras to the processing systems, so readings and alerts arrive in near real time.
• Platforms and internal tooling such as BuildOS, which puts the running services, the ports in use and the client work in progress on a single screen.
• Top-up and payment: a credit wallet showing the balance and every transaction, accepting both PromptPay QR and credit cards.

We run our own estate the same way

The way we set up a client's systems is the way we run our own machine, where around twenty independent web applications sit side by side. Everything below is here because we ran into it ourselves, not because a cloud vendor's guide recommends it.

• Every app has its own loopback port, its own virtual environment and its own Python version, so upgrading one of them cannot drag the other nineteen down with it.
• nginx is the only public entrance. Each domain is reverse-proxied to its own app, with certificates from Let's Encrypt that renew automatically, one certificate covering several names.
• Apps bind to loopback rather than to every interface, on purpose. Anything listening on every interface is reachable directly, without TLS, however carefully the proxy is configured.
• The same deny rules go into every virtual host, because a scanner once pulled framework API docs and stray dot-files off neighbouring sites.
• Each service runs in its own process group, with its process id persisted and its status reconciled on boot, alongside port-level health checks. Restarting the supervisor does not take the services down with it.
• Deployment is scripted rather than done by hand, and an external reachability probe runs before every certificate request, because the certificate authority has to reach the host from the internet, not from the same network.
• The tools in regular use: Python, FastAPI, nginx, SQLite, PostgreSQL, Node and Next.js, on GCP, Azure, AWS and DigitalOcean, with Twilio, n8n and Make.com where automation has to be joined up.

How we work with you

Work at this layer shows results more slowly than anything front-of-house, so we set it out in phases with a clear deliverable at each one. We always begin by surveying what is already there, because almost every organisation is running systems that nobody holds a complete map of.

• 1. Survey what exists: what is running where, on which ports and domains, who owns each set of data, and how often it is refreshed.
• 2. Design the architecture: the cloud, the storage model and the network boundary, chosen to fit the workload, the budget and your organisation's data requirements.
• 3. Build and test: pipelines that move data to schedule, with quality checks and alerts when something is wrong, plus a repeatable path for getting a release out.
• 4. Go live: firewall and certificates in place, reachability confirmed from outside, then health checks and alerting ready before users are let in.
• 5. Hand over with a runbook: who has access, how to restart each service, and the first place to look when something stops.

What you get

The result of work at this layer comes down to two questions: does the team still merge files by hand every month, and when something falls over at two in the morning, does anyone know where to look first? The platform is also the base the rest of our work stands on. Data arriving on a steady schedule is what the dashboards in Data Strategy Analytics read, and what the chatbots and forecasting models in AI Solutions draw on.

• A central data source that the analytics team and the AI team both work from.
• Ingestion that runs itself to schedule, cutting out the manual gathering and copying of files.
• Cloud infrastructure that scales with use, with access control in place.
• Every domain served over HTTPS, with certificate renewal handled automatically rather than written in someone's diary.
• A deployment path written down as a script, so a release goes out the same way whoever runs it.
• Architecture documentation and an operations runbook, so your own team can genuinely take it over.