Vol. 01 — Practice
Engineering software
that outlasts the
quarter it was built in.
dreams Beckum GmbH is an independent information technology and software services practice. We design, build and operate systems for organisations that intend to keep those systems in service for many years — not for a launch.
The work covers custom software, web and enterprise applications, cloud architecture, data engineering, DevOps, security consulting and quality assurance. It is delivered by a small group of engineers who prefer legible code, honest documentation and boring infrastructure to novelty for its own sake.
A small studio for
serious software.
We work with product companies, established enterprises and public‑sector organisations. Our engagements tend to run for months or years rather than weeks, because the software we are asked to build is usually load‑bearing for the organisation that commissions it.
The practice is deliberately compact. Every engagement is staffed with senior engineers who take responsibility for the architecture, the code and the handover. There are no unnamed juniors delivering the work behind a slide deck.
We do not describe ourselves as an agency. We are a workshop: small, technical, and answerable for what leaves the door.
Depth over
breadth, chosen
on purpose.
We do not claim to work with every framework in existence. We maintain deep, current knowledge in a deliberately narrow set of technologies, and refuse work that would push us outside it.
- 01
Distributed backends
Long‑running services in TypeScript, Python and Go, designed around explicit failure modes and observable behaviour.
- 02
Web applications
React, Next.js and TanStack for interfaces that need to remain understandable as they grow past their first version.
- 03
Data platforms
PostgreSQL, event streams and analytical stores, modelled from the domain outwards instead of the dashboard backwards.
- 04
Cloud and infrastructure
AWS, GCP and Azure, provisioned as code, with the same standards for reproducibility we apply to application code.
- 05
Security engineering
Threat modelling, access design and cryptography reviews as part of the build, not as a checklist afterwards.
- 06
Developer platforms
Internal tooling, CI/CD, and paved paths that let client teams keep shipping after we leave.
Twelve disciplines,
one practice.
Legible code, written by the people who will maintain it.
We start every project by writing down what the system is supposed to do in plain English, and what it is explicitly not supposed to do. That document is the contract between engineering and the rest of the business.
We favour small, well‑named modules over frameworks that hide behaviour behind convention. We write tests for the parts of the system where a mistake would be expensive, and we accept that other parts are best served by careful review instead.
Every commit is written to be readable by someone who will open the repository in two years — including us.
Fig. 05 — Workstation, morning light
Digital transformation is not a project. It is a sequence of small, unglamorous decisions made by people who understand the existing system well enough to change it without breaking it.
a. Diagnose
Read the code, the tickets and the incident history before proposing anything.
b. Sequence
Identify the smallest change that unlocks the next. Ship it. Repeat.
c. Hand over
Leave the client team with the knowledge, the tests and the runbooks to continue.
Sectors where software has to keep working.
Our clients tend to operate in domains where a broken deployment is expensive, not just inconvenient. That constraint shapes how we design, test and deploy.
How an engagement moves from a first conversation to a system in production.
- 01
Discovery
We read what exists — code, tickets, contracts, incident reports — and interview the people who will use and maintain the system.
- 02
Shape
A short written architecture describes the system, its boundaries, its data, and the decisions we are choosing not to make yet.
- 03
Build
Small, deployable slices land behind feature flags. Every slice is reviewed, tested and observable before it is enabled.
- 04
Harden
Load, failure and security scenarios are exercised deliberately before the system carries production traffic.
- 05
Operate
We run the system with the client team, gathering the operational knowledge that turns into runbooks and dashboards.
- 06
Hand over
Documentation, on‑call procedures and access are transferred to the client team. We remain reachable for follow‑up work.
Selected tools we use every week.
Reliability is a design decision, not a rescue mission.
Systems that stay up are systems that were designed with explicit failure modes. We model what can go wrong before we model what should go right, and we treat degradation, retries and back‑pressure as first‑class concerns.
Security is treated the same way. Access is scoped narrowly, secrets are stored in dedicated systems, transport and storage are encrypted by default, and privacy‑relevant data is documented alongside the schemas that hold it.
Infrastructure as
a written system.
Every environment we operate is described in code, versioned in a repository, and reproducible from a clean slate. Nothing important is configured by hand in a console, and there is a written trail for every change to production.
Provisioning
Terraform and Pulumi modules with reviewed change plans, drift detection and audited state.
Runtime
Kubernetes or managed services, chosen by workload profile rather than by fashion.
Networking
Segmented VPCs, private connectivity between environments, explicit egress controls.
Cost
Continuous cost reporting per workload so that decisions are made with the invoice visible.
A pipeline of small, honest checks.
Quality work is done continuously, not scheduled at the end. Every change moves through the same pipeline before it reaches a real user.
Static
Types, lint, format
Unit
Isolated logic
Contract
Boundaries between services
End‑to‑end
User journeys in a browser
Load
Realistic traffic shapes
We ship the smallest useful thing first, then improve it in public.
A system that is deployed, observed and criticised is more informative than a system that is still being planned.
We prefer plain interfaces to clever abstractions.
The abstraction that saves five lines this quarter often costs five weeks in two years. We choose accordingly.
We are answerable for what we deploy.
The person who wrote the change is on the review, on the deploy and on the incident that follows. That loop is the shortest one available.
Four commitments we do not negotiate.
- Honesty in estimates.
- If we do not know, we say so, and we describe what would let us answer.
- Care for the people who inherit the code.
- Every repository is written with the next maintainer in mind.
- Restraint with data.
- We collect what is necessary, keep it for as long as it is necessary, and no longer.
- Independence.
- We take no referral fees and recommend no tool we would not run ourselves.
Questions we hear in a first conversation.
What kind of engagements does dreams Beckum GmbH typically take on?
Long‑running custom software builds, cloud and infrastructure work, data engineering, and modernisation of existing systems that need to keep operating while they are changed.
Which technology stacks do you work with?
Primarily TypeScript, Python and Go on the server; React, Next.js and TanStack on the web; PostgreSQL and event‑driven data stores; and Kubernetes, Terraform and the major cloud providers for infrastructure.
How do you approach security and privacy?
Security is treated as a design constraint from the first architecture discussion, not as a review step at the end. That means least‑privilege access, encrypted transport and storage by default, and privacy considerations documented alongside the data model.
Do you work with existing internal teams or take full ownership?
Both. Some engagements are embedded with a client's engineering team; others are delivered end‑to‑end and later handed over with documentation, runbooks and a clean operational baseline.
Write to us. We read every message ourselves.
Company
dreams Beckum GmbH
michaelhal33@gmail.com
Website
dreamsbeckum.com
