A practice, not
a platform.

Brook Real eGbR is a partnership organised around a specific idea: that most software problems worth solving are best handled by a small number of senior engineers working closely with the people who understand the underlying business.

The practice takes on engagements where the client needs a system to be designed, built, or improved to a professional standard, and where a template solution is not adequate. We are comfortable working alone or embedded alongside internal teams.

Our mission is to build systems that continue to serve their purpose long after the engagement ends. That means readable code, maintainable infrastructure, honest documentation, and a client team that understands what has been built.

A successful project is one where, two years later, changes are still cheap to make and no one is afraid to open the repository.

We would like the software organisations depend on to be built with the same seriousness as the physical infrastructure they depend on. That means measured decisions, durable materials, and honest reporting of what a system will and will not do.

The industry frequently treats software as disposable. We are trying to work against that grain, one engagement at a time.

• Write things down. Verbal understandings become disagreements.
• Prefer the boring, well-understood tool unless the problem clearly demands otherwise.
• Ship in short cycles that end with something running.
• Review code and architecture on the merits, not the seniority of the author.
• Keep the client informed about problems as soon as they are visible.
• Document the decisions that were rejected as clearly as the ones that were kept.

Technology choices are design decisions. Each new dependency, service, or vendor added to a system has a lifetime cost in maintenance, operational surface, and security review. We treat additions as decisions to be justified, not defaults to be accepted.

Where a new technology genuinely improves the outcome, we adopt it deliberately and document why. Where it does not, we leave it out, no matter how visible it is elsewhere.

We work best when the client team is involved throughout, and when their engineers, product owners, or operators are part of the conversations that shape the system. Knowledge transferred continuously is far more useful than knowledge dumped at the end.

We are comfortable disagreeing in the open, and we expect the client to do the same. Systems built by silent agreement tend to fail the moment they are tested.

We prefer systems that do not require heroics to keep running. That means automated testing, continuous integration, thoughtful error handling, and observable behaviour in production. Weekends spent firefighting are, in our view, a sign that something earlier in the process was skipped.

Speed comes from removing friction, not from cutting corners. The two are frequently confused.

A piece of work is done when the code is reviewed, the tests cover the important cases, the deployment is automated, the operational documentation exists, and someone other than the author can safely take the next change through the same path.

Anything short of this is unfinished, regardless of what a demo shows.

Security is treated as a property of the architecture, not as a layer added after the fact. We consider threat models, identity boundaries, data classification, and operational access at design time. Later reviews confirm those decisions rather than discover them.

When we identify security weaknesses in existing systems during an engagement, we raise them clearly, even when they are outside the immediate scope.

Most of our engagements evolve into longer relationships. Once a system is in production, its most valuable improvements are usually the ones informed by real usage, and those take time to see clearly.

We offer both retainer arrangements for ongoing evolution and clean handovers for teams that want to take full ownership. The choice belongs to the client.