A
Engineering
Application development from first requirement to production release, including data modelling, interface design and test coverage.
01Technology partner for business operations
Software that keeps business systems running
FEW Blankenburg GmbH designs, builds and maintains software for companies that depend on technology to operate. The work is practical: applications that fit an existing process, infrastructure that stays predictable, and integrations that remove manual handovers between systems.
We take a small number of engagements at a time and treat each system as something that has to be operated for years, not demonstrated once.
02Who we are
A software company, plainly described
FEW Blankenburg GmbH is an IT company providing software engineering and technology services to businesses. We do not sell a single product. We work on the specific systems a company already runs and on the new ones it needs.
Most requests we receive fall into a few recognisable categories: a process that still depends on spreadsheets, an application that has become expensive to change, data that lives in three systems and agrees in none of them, or infrastructure that nobody wants to touch. Those are engineering problems with practical solutions.
Our role is to understand the operational reality first, describe the options honestly including the option of doing less, and then build carefully.
03Core capabilities
Four practices that cover most technology needs
B
Infrastructure
Cloud and hybrid environments defined as code, with deployment pipelines, monitoring and recovery procedures that are written down.
C
Integration
Connecting applications, databases and third-party services so information moves once, reliably, instead of being re-entered by people.
D
Operation
Maintenance, dependency updates, performance review and incident handling for systems that have to remain available.
04Services in detail
What we are typically asked to build
- Custom software
- Applications shaped around a specific operational process rather than around a generic product roadmap.
- Web applications
- Browser-based tools for internal teams, partners or customers, built for daily use and long service life.
- Cloud solutions
- Environments, deployment automation and cost-aware architecture on managed cloud platforms.
- Systems integration
- Interfaces and data pipelines between software that was never designed to work together.
- Process automation
- Replacing repetitive manual steps with validated, auditable automated workflows.
The full list is described on the Services page
05Business challenges
Problems that usually bring a company to us
Manual work that does not scale
Order handling, reporting or reconciliation still depends on people copying values between tools. Volume grows, errors grow with it, and nobody has time to fix the underlying cause.
Software that resists change
An application still works, but every modification is slow and risky. Undocumented behaviour and missing tests make even small requests expensive.
Fragmented information
The same customer, product or invoice exists in several systems with different values. Decisions are delayed because nobody trusts a single source.
Unpredictable infrastructure
Deployments are manual, environments differ from each other, and recovery depends on one person's memory rather than a documented procedure.
Unclear technical direction
A decision has to be made between rebuilding, buying or extending, and there is no independent technical assessment to base it on.
Growing compliance expectations
Access control, data retention and auditability were never designed into the system and now have to be added responsibly.
06Delivery approach
How the work is organised
The sequence below is a general working method, not a fixed contract. Engagements differ in size, and steps are adjusted to the situation.
01
Understand
Discussion of the business process, the systems in use and the constraints that cannot be changed.
02
Assess
Review of existing code, data and infrastructure, followed by a written summary of findings and options.
03
Define
Agreement on scope, priorities and the smallest useful first delivery, including what is explicitly out of scope.
04
Build
Development in short cycles with version control, code review, automated tests and reproducible environments.
05
Verify
Functional review against the agreed scope, performance checks and a security-oriented look at access and data handling.
06
Operate
Release, documentation handover, monitoring, and a defined way of handling changes and incidents afterwards.
07Technology expertise
Tools are chosen for the problem, not for fashion
Application layer
Typed languages and mainstream server frameworks, modern JavaScript and TypeScript front-ends, component-based interfaces, and API designs that stay understandable as they grow.
Data layer
Relational databases as the default for business data, schema migrations under version control, caching where it is measurably needed, and analytical stores when reporting demands them.
Platform layer
Containerised workloads, infrastructure described as code, continuous integration and delivery pipelines, structured logging, metrics and alerting.
08Reasons to work with us
What clients can expect from the collaboration
Direct communication
You speak with the people doing the engineering work. Questions are answered in plain language, without layers of account management.
Honest scoping
If a request is larger than it appears, or if an existing tool would solve it, we say so before work begins.
Documented systems
Architecture decisions, environment setup and operational procedures are written down so the system is not dependent on us.
Incremental delivery
Work is released in reviewable steps, which keeps direction changes cheap and progress visible.
Maintainability as a requirement
Readability, tests and dependency hygiene are treated as part of the deliverable, not as optional extras.
Respect for existing investment
Rewriting is a last resort. Where a system can be improved in place, that is usually the better business decision.
09Security and reliability
Principles applied to every system we build
Least privilege
Accounts, services and integrations receive only the access they need to perform their function.
Data minimisation
Personal and sensitive data is collected only where there is a defined purpose, and retention is bounded.
Encryption in transit and at rest
Standard, well-supported cryptographic mechanisms rather than custom implementations.
Traceability
Meaningful logging and audit trails, so that changes to important records can be reconstructed.
Recoverability
Backups that are tested by restoring them, and recovery procedures that are documented and rehearsed.
Dependency discipline
Third-party components are reviewed, pinned and updated deliberately rather than automatically or never.
These are working principles rather than guarantees. Security is a continuous engineering practice shared between a software provider and the organisation operating the system.
10Business scenarios
Where this kind of work usually applies
The scenarios below describe common contexts for business software. They are illustrations of the type of problem we address, not claims about specific clients.
Manufacturing and logistics
Production planning, stock movement, shipment tracking and interfaces to machine or scanner data.
Professional services
Project accounting, resource planning, time capture and client-facing document workflows.
Retail and e-commerce
Catalogue and order synchronisation between shop systems, warehouses and finance software.
Finance and administration
Reconciliation, structured approval flows, controlled reporting and long-term record keeping.
Healthcare and regulated sectors
Access-controlled record handling, audit trails and careful treatment of sensitive information.
Technology teams
Additional engineering capacity, platform work and modernisation support alongside an in-house team.
11Frequently asked questions
Questions we hear often
What kind of work does FEW Blankenburg GmbH take on?
We work on business software: custom applications, web platforms, cloud environments, integrations between existing systems, automation of manual processes, and the ongoing maintenance that keeps those systems dependable.
How does a project usually start?
It starts with a written description of the situation: what exists today, what is not working, and what outcome matters. From there we discuss scope, constraints and a realistic sequence of delivery steps before any code is written.
Do you work with systems that were built by someone else?
Yes. A large share of technology work involves inherited systems. We review the existing codebase, data model and deployment setup, document what we find, and propose changes that can be applied without interrupting daily operations.
Which technologies do you use?
We select technology per project rather than applying a fixed stack. The decision depends on the problem, the existing environment, the skills available on the client side, and the expected lifetime of the system.
How is progress communicated during a project?
Through regular written updates and working software. We prefer short delivery cycles so that decisions can be reviewed against something functional instead of a document.
How can a company get in touch?
By email. The address is robertorichar45@gmail.com. A short summary of the business context, the systems involved and the expected timeframe makes the first reply more useful.
12Company information
FEW Blankenburg GmbH
Enquiries are handled by email. A message that describes the business context, the systems already in use and the timeframe under consideration allows us to give a substantive answer instead of a generic one.
- Company
- FEW Blankenburg GmbH
- robertorichar45@gmail.com
- Website
- fewblankenburg.com
- Correspondence language
- English