01
Application engineering
Backend services, web and mobile clients, and internal tooling built with modern typed languages and mature frameworks.
Vol. I · Engineering PracticeSoftware / Cloud / Security / Data / AIbrookreal.com
Engineering
infrastructure
for serious
systems.
Positioning
We are a small, senior engineering practice. Our clients are teams building products, platforms, and internal systems where reliability, security, and maintainability are not optional and cannot be assembled from templates.
We do not sell abstractions. Every engagement produces code, infrastructure, documentation, and operational knowledge that continues to hold value after we have stepped back.
We work directly with technical and business decision-makers. The distance between a decision being taken and being implemented is short by design.
We publish nothing we cannot support. Diagrams, deliverables, and estimates are grounded in what has been built, not in aspiration.
02 — Expertise
Breadth across the stack, depth where it counts.
Our team spans application engineering, distributed systems, cloud infrastructure, information security, and applied machine learning. We size the engagement to the problem, not the other way around.
02
Cloud & platform
Cloud architecture, multi-account governance, container platforms, Kubernetes, service meshes, and platform engineering.
03
Data & analytics
Warehouses, lakehouses, streaming pipelines, transformation frameworks, and reporting for analytical and operational use.
04
Security engineering
Threat modelling, identity and access, secrets, vulnerability management, secure SDLC, and incident readiness.
05
AI & automation
Retrieval systems, model integration, workflow orchestration, and business process automation grounded in real evaluation.
06
Reliability & operations
Observability, SLOs, on-call practice, capacity planning, and cost engineering for production systems.
03 — Services, index
See page: Services
- 01
Custom software development
Applications engineered around specific business logic and long lifecycles.
- 02
Cloud architecture and migration
Reference architectures, landing zones, and safe migrations at pace.
- 03
Cybersecurity engineering
Programs, controls, and reviews that reduce concrete risk.
- 04
Data engineering
Trusted pipelines, models, and warehouses that analytics can rely on.
- 05
AI and automation
Model-assisted features and end-to-end workflow automation.
- 06
DevOps and platform
Delivery platforms that make releasing changes routine.
- 07
System integration
APIs and event flows between systems that were never meant to talk.
- 08
Technical support and maintenance
Steady operation of what has already been built.
04 — Digital transformation
Modernisation as an engineering programme, not a slogan.
Transformation work here means concrete decisions: which systems to replace, which to wrap, which to leave alone; how data is going to move without breaking; how the organisation absorbs the change without losing its footing.
- —Assessment of current systems, dependencies, and cost drivers.
- —Target architecture proposals with trade-offs made explicit.
- —Phased delivery with milestones tied to measurable outcomes.
- —Operational handover and internal capability building.
05 — Process
From written brief to production system.
STEP / 01
Discovery
Working sessions to understand systems, constraints, and outcomes. Written summary of what is in scope, what is not, and where the risks sit.
STEP / 02
Architecture
Concrete architecture proposal with the alternatives that were considered and rejected. Reviewed with the stakeholders who will operate the system.
STEP / 03
Delivery
Iterative implementation in short cycles. Continuous integration, automated tests, code review, and demonstrable progress at each step.
STEP / 04
Hardening
Load testing, threat review, observability, backup and recovery, and the operational runbooks needed to keep the system healthy.
STEP / 05
Launch
Cutover planning, staged rollout, and support cover for the initial production window.
STEP / 06
Stewardship
Continued evolution under a retainer, or handover with documentation and training that lets the client's team take the wheel.
06 — Cloud & infrastructure
Cloud environments engineered for the workload, not the brochure.
We design cloud environments that reflect the way a specific application actually behaves under load, and that a specific team can operate confidently over time. That means clear network boundaries, sane identity models, versioned infrastructure as code, and observable systems.
Providers
AWS · GCP · Azure
Orchestration
Kubernetes · ECS
IaC
Terraform · Pulumi
Delivery
GitHub Actions · GitLab CI
07 — Cybersecurity
Security is what remains after threats meet a well-built system.
Our security work is engineering work. We model the actual threats a system faces, write down what the controls are supposed to prevent, and verify that the controls behave that way in production — not only in a document.
- Threat modelling
- Structured analysis of assets, adversaries, and attack paths tied to the actual architecture.
- Identity & access
- Least privilege enforced through infrastructure, reviewed and rotated on a schedule.
- Secure SDLC
- Static analysis, dependency review, and code review as normal parts of delivery.
- Incident readiness
- Runbooks, tabletop exercises, and detection tuned to the systems that exist.
08 — Automation & AI
Machine intelligence, integrated into work that actually gets done.
We treat AI as one component in a larger system. That means considered data handling, evaluation harnesses that catch regressions, and product surfaces where a model's uncertainty is visible to the people relying on it.
Retrieval and knowledge
Grounding language models in an organisation's own documents, records, and structured data.
Workflow automation
Replacing brittle manual steps with orchestrated flows across the tools already in use.
Model integration
Serving, monitoring, and versioning models alongside the applications that depend on them.
Evaluation
Test sets, human review, and quality metrics that make model changes safe to ship.
09 — Industries
Sectors we work across.
We are generalist engineers with deeper familiarity in a handful of regulated and data-heavy sectors. The list below reflects where our recent work has clustered.
- Financial services and fintech—
- Healthcare and life sciences software—
- Logistics and supply chain—
- Industrial and manufacturing systems—
- Public sector and civic technology—
- Professional services and legal tech—
- Media, publishing, and content platforms—
- Education and research infrastructure—
10 — Technology stack
Current, non-exhaustive
The tools we reach for, and the reasons they earned a place.
Languages
- TypeScript
- Python
- Go
- Rust
- Kotlin
- SQL
Runtimes
- Node.js
- Deno / Bun
- JVM
- Postgres
- Redis
- Kafka
Platform
- Kubernetes
- Terraform
- Docker
- Nix
- ArgoCD
- Vault
Data / AI
- dbt
- Airflow
- DuckDB
- ClickHouse
- Snowflake
- OpenAI / Anthropic
The stack is not the point. We pick the boring, well-supported option unless the problem clearly rewards something else. Novelty is a cost that has to be justified.
11 — Delivery methodology
How we work versus how we do not.
We do
- Write down scope, assumptions, and trade-offs in plain English.
- Ship in short iterations that each produce something running.
- Automate tests and infrastructure before they become urgent.
- Review each other's code and treat it as a normal part of work.
- Keep the number of moving parts and vendors as small as possible.
We do not
- Estimate work without understanding the problem first.
- Introduce technologies for their own sake or for a portfolio.
- Ship code that no one on the client team can read or maintain.
- Treat security or observability as later-stage add-ons.
- Present slides in place of running systems.
12 — Quality & security principles
Non-negotiables that shape every engagement.
Confidentiality, integrity, and availability are not statements we make on a marketing page — they are properties we design for from the first architecture sketch. Systems that lose data quietly, corrupt state under load, or leak information are considered defective regardless of how quickly they were shipped.
Code that lands in production is reviewed, tested, and observable. Infrastructure is versioned and reproducible. Access is granted narrowly, logged, and revoked when it is no longer required. These practices are boring on purpose.
Where regulatory or contractual obligations apply, we translate them into concrete architectural and operational constraints, rather than treating them as documents to reference in a proposal.
13 — Frequent questions
Answers to questions that come up early.
If a question you have is not covered here, it is likely worth writing directly. See the correspondence section below.
- How does an engagement with Brook Real eGbR typically begin?
- Most engagements begin with a written brief followed by a technical discovery conversation, during which we review the existing systems, business context, constraints, and expected outcomes before proposing a scope of work.
- Do you work with organisations that already have an in-house engineering team?
- Yes. A large share of our work is embedded alongside existing engineering teams, where we contribute specific capabilities such as platform architecture, security review, data pipelines, or dedicated feature delivery.
- Which technology stacks do you support?
- We work across the mainstream cloud providers, container and orchestration tooling, relational and event-driven data systems, and modern application frameworks in TypeScript, Python, Go, and the JVM ecosystem.
- How is intellectual property handled?
- Ownership of source code, data models, and deliverables produced during an engagement belongs to the client, with clear terms established in the master services agreement before any implementation work begins.
- How do you approach compliance-sensitive environments?
- We treat regulatory constraints as design inputs. Requirements from data protection, financial, or industry-specific regimes are documented, mapped to concrete architectural decisions, and reviewed throughout the engagement.
- What does long-term support look like after a project ships?
- We can continue as a maintenance and evolution partner under a retainer, or hand the system over with runbooks, architecture documentation, and a knowledge-transfer period agreed upfront.
14 — Correspondence
Write to us.
A short written brief is the fastest way to start a conversation. Tell us what you are building, what is already in place, what is causing pain, and what would count as a good outcome.
Company
Brook Real eGbR
sophieweber182@gmail.com
Web
brookreal.com
