Testing as documentation
Automated test suites express intent as much as they verify behaviour. New engineers read the tests to understand the system; failing tests describe what was expected and what changed.
01Studio · Software · Systems
Software,
built to last.
Fibre & Foam GmbH is an engineering studio designing custom software, cloud infrastructure, and secure systems. We work with teams that treat technology as long-lived material — not as a short campaign.
§ 02The studio
A studio, not a factory.
We are a small team of engineers, designers, and infrastructure specialists. Every engagement is worked directly by senior practitioners — the people who write the code are the people who sit with the problem.
Our work spans backend services, distributed systems, developer tooling, cloud platforms, and the interfaces that surround them. We prefer fewer, deeper engagements over volume.
§ 03Core expertise
i.
Applied software engineering
Custom applications from prototype to production, written with an eye on the years after the launch.
ii.
Cloud & platform architecture
Reproducible infrastructure, cost-aware topology, and platforms that developers actually enjoy using.
iii.
Security-oriented delivery
Threat modelling, secure defaults, and identity boundaries treated as part of the design, not an afterthought.
iv.
Data & integration
Reliable pipelines, well-shaped APIs, and integrations that survive contact with third parties.
v.
Modernisation
Careful, incremental rework of systems that grew faster than their foundations.
vi.
Interface implementation
Interfaces implemented against real design systems, with accessibility and performance treated as requirements.
§ 04Technology capabilities
Working close to the metal, working close to the user.
We are comfortable across the stack: from the operating system boundary and container runtimes, through service meshes and message buses, up to the browser and the mobile client. The technology chosen for a project should serve the problem — not the other way around.
- · Type-safe backend services
- · Event-driven architectures
- · Reproducible infrastructure
- · Observability by default
- · Accessibility-first UI
- · Progressive delivery
§ 05Development process
Predictable steps, honest conversation.
Phase 01
Discovery
Working sessions with your team to understand the problem, the constraints, and the invisible history of the system.
Phase 02
Architecture
A written proposal covering system shape, data model, deployment topology, and the trade-offs behind each decision.
Phase 03
Build
Short delivery cycles with reviewable increments. Working software, not slide decks, becomes the shared reference.
Phase 04
Hardening
Load, security, and failure-mode testing. Runbooks, monitoring, and on-call material treated as project deliverables.
Phase 05
Handover
Documentation, knowledge transfer, and — where useful — a defined support relationship that scales down over time.
§ 06Industries
Sectors we understand.
We work best where the software has weight — where downtime, privacy, or correctness matter. The following are areas where our engineering approach fits particularly well.
- 01
Fintech & payments
- 02
Healthcare technology
- 03
Industrial & IoT
- 04
Logistics & mobility
- 05
SaaS platforms
- 06
Public sector
- 07
Media & publishing
- 08
Developer tooling
§ 07Infrastructure & cloud
Infrastructure you can rebuild from a text file.
We build cloud environments as declarative code: repeatable, reviewable, and version-controlled. Networks, identity, storage, observability, and cost controls arrive together — not as a patchwork of manual clicks.
We are cloud-native without being cloud-locked. Multi-region, hybrid, and on-premise topologies remain first-class options depending on the constraints of the work.
§ 08 · Cybersecurity approach
Security is a property of the system, not a feature bolted on.
Threat modelling begins in the architecture phase. Identity, secrets management, encryption in transit and at rest, and principle-of-least-privilege access are default constraints — not later tickets.
§ 09Quality assurance
Observability from day one
Structured logs, distributed tracing, and meaningful metrics are wired in as the system is built. Debugging a live incident should not require redeploying code to add a log line.
Reviewable increments
Change lands in small, coherent units. Reviews are used as an engineering practice, not a bureaucratic gate, and are the mechanism through which shared understanding is built.
Failure rehearsals
We test what happens when things break: dependency outages, partial network failures, data corruption. Recovery paths are exercised before they are needed, not during an incident.
§ 10Collaboration
We work inside your team, not against it.
Cadence
Short cycles with a written weekly note. No status theatre — one page you can actually read.
Communication
Async by default, synchronous when it matters. Decisions are captured in writing so context outlives the meeting.
Tooling
We adapt to your issue tracker, chat, and repositories. We do not require you to migrate to work with us.
Boundaries
Clear scope, clear owners, clear next step. Ambiguity is resolved before it turns into rework.
§ 11Technology stack
Chosen for the problem, not for the résumé.
We do not have a single stack we push on every project. The following are the tools we reach for most often — always weighed against fit, team knowledge, and long-term maintenance.
Languages
- · TypeScript
- · Go
- · Python
- · Rust
- · SQL
Runtime & data
- · Node.js
- · PostgreSQL
- · Redis
- · Kafka
- · ClickHouse
Platform
- · Kubernetes
- · Terraform
- · AWS · GCP · Azure
- · OpenTelemetry
- · GitHub Actions
§ 12Why teams work with us
Because the work is done by the people you speak with. Because we take the boring parts — testing, infrastructure, documentation — seriously. Because the system we hand back is one you can operate without us.
§ 13Project lifecycle
Weeks 01–02
Framing
Requirements, constraints, and success measures written down and agreed.
Weeks 02–06
Foundations
Architecture proposal, environment scaffolding, delivery pipeline in place.
Ongoing
Delivery
Feature-by-feature increments, weekly review, and open metrics dashboards.
Closing
Continuity
Documented handover, optional support window, and a runbook you can act on.
§ 14Frequently asked questions
What size of engagement do you take on?＋
From a focused four-week piece of work to multi-quarter platform builds. We prefer engagements where our involvement can be measured against a concrete outcome.
Do you work as a subcontractor or independently?＋
Both. We work directly with in-house engineering teams and independently under our own delivery. In either case, senior practitioners lead the work.
Can you operate the system after handover?＋
Yes, where useful. We define a scoped support relationship with clear response expectations, and we design the system so you can operate it without us.
What is your position on new technology?＋
Curious, but conservative in production. We evaluate new tools against the cost of maintaining them for years, not the excitement of using them for weeks.
Where are you based?＋
We are established in the European Union and work with clients internationally in English and German.
§ 15Contact
A short note is enough to start.
Describe the problem, the constraint, or the milestone you are planning against. We will respond with a written first-read and the shape of a next conversation.
- Company
- Fibre & Foam GmbH
- Correspondence
- annamullll33@gmail.com
- Domain
- fibreandfoam.com
§ Colophon
Fibre & Foam GmbH is an independent engineering studio. We build the parts of your system that need to keep working when you are not looking at them.