Write it down
Decisions that are not documented are lost within months. Architecture notes, environment setup and known limitations belong in the repository, not in memory.
AAbout the company
Engineering work, described without decoration
This page explains how FEW Blankenburg GmbH operates: what we value in software, how we make technical decisions, and what a company can reasonably expect when working with us.
01Company overview
What the company does
FEW Blankenburg GmbH is an IT company that builds and maintains software for business use. The work covers custom applications, web platforms, cloud environments, integrations between systems, and the operational care those systems require after release.
We are deliberately specific about what we do and equally specific about what we do not do. We are not a marketing agency, we do not resell licences, and we do not position technology as a shortcut around organisational problems. Software solves a defined class of problems well; being clear about that boundary saves clients money.
Every engagement begins with the same assumption: the client understands their business better than we ever will, and we are responsible for translating that understanding into systems that behave predictably.
02Mission
To make business technology dependable enough to be uninteresting
Good business software is rarely noticed. It records what happened, moves information where it is needed, and does not interrupt the day. Our purpose is to move client systems toward that state: fewer manual corrections, fewer surprises during deployment, fewer decisions blocked by unreliable data.
That goal shapes ordinary choices. We prefer boring, well-supported technology over novelty. We prefer a smaller system that is fully understood over a larger one that is partially understood. We prefer to remove a feature that nobody uses rather than maintain it indefinitely.
03Working principles
Rules we apply to our own work
Prefer the smaller change
The change that touches least is usually the change that can be reviewed, tested and reversed most easily.
No hidden work
Scope changes, discovered defects and estimation errors are reported when they happen, not at the end of a phase.
Automate what repeats
Manual deployment or manual data correction is a defect in the process, and it is treated as one.
Design for the next engineer
Code is read far more often than it is written, including by people who have never spoken to us.
Measure before optimising
Performance work starts with observation. Assumptions about bottlenecks are frequently wrong.
04Approach to technology
Choosing tools with a long horizon
Technology selection is an economic decision as much as a technical one. A framework chosen today determines hiring options, upgrade effort and operating cost for years. We therefore weigh maturity, documentation quality, community activity and upgrade history alongside raw capability.
We also account for the client's own environment. If a team already operates a particular database or cloud platform competently, introducing a second one needs a stronger justification than personal preference.
New technology is adopted when it removes a concrete problem, and it is introduced in a bounded part of the system first, where the consequences of being wrong are small.
05Quality standards
What "finished" means to us
The behaviour is specified
Expected behaviour, including edge cases and failure states, is agreed before implementation rather than inferred afterwards.
The change is reviewed
Another engineer reads the change before it reaches a shared branch. Review comments are about the code, never about the person.
The tests are meaningful
Automated tests cover the logic that would be expensive to get wrong, instead of chasing a coverage percentage.
The deployment is reproducible
The same commit produces the same result in every environment, and a release can be repeated or rolled back.
The system can be observed
Logs, metrics and error reporting exist before the system is needed in production, not after the first incident.
The documentation exists
Setup, configuration, integration points and operational caveats are written for someone who was not part of the project.
06Collaboration philosophy
Working alongside a client team
Shared understanding first
Before estimating, we want to be able to describe the client's process back to them accurately. If we cannot, the estimate would be fiction.
One point of contact, no filters
Technical questions reach the engineers working on the system. Answers come back in language that a non-technical stakeholder can act on.
Clients keep control
Source code, infrastructure definitions and credentials belong to the client. Nothing about our involvement should make it hard to change direction or provider.
Disagreement is useful
If we think a requested feature will create more work than value, we say so and explain why. The final decision remains with the client.
Knowledge transfer is continuous
Handover is not an event at the end of the project. Documentation and walkthroughs happen while the work is fresh.
Realistic commitments
We would rather decline a deadline than accept one we cannot meet responsibly.
07Security and data
Responsible handling of information
Client systems frequently contain personal data, commercial information or both. We treat access to that data as a responsibility that has to be limited by default. Where development or debugging can be done with synthetic or anonymised records, that is the approach we take.
In the systems we build, data protection is a design input rather than a later addition. That means defining who may see which records, how long information is kept, how deletion requests can actually be executed, and how sensitive actions are recorded for later review.
On the operational side, credentials are managed through secret storage rather than configuration files, access is reviewed when responsibilities change, and third-party components are kept current so that known vulnerabilities are not carried forward.
These are the practices we apply. They reduce risk; they do not eliminate it. We say this plainly because any provider claiming otherwise is describing marketing rather than engineering.
robertorichar45@gmail.com