We build it, and we run it.

Four capabilities, and what is public about each one.

We are a software engineering firm in Germany, and these are the four things we build. Two of them you can open on somebody else's server before you write to us. The other two run inside products, so you get the description and the counts, and nothing to open.

Mobile ships as one codebase.

Localised from the start, released through automated lanes.

One Flutter codebase, live in the App Storeapps.apple.com

The same build on Android and on the web

Strings live in a catalogue, never in a view

A single Flutter codebase runs the same product on iOS, Android and web, so one change moves everywhere at once. No string is written directly into a view; the catalogue exists before the first screen does. The shipped app carries 29 languages across 35 locale files.

Certificates, provisioning and phased rollout are automated lanes rather than manual steps: 15 for iOS and 17 for Android. The app behind that link is our own product rather than a client's.

What shipped.

29languages35 locale files, all shipped
distinct languages across the shipped locale files
32lanesFastlane: 15 iOS, 17 Android
lanes declared in the release configuration

The database is the boundary.

Postgres enforces the rules; there is no separate service standing in front of it.

Row-level security as the authorisation boundary, not an API tier

Deno and TypeScript behind one audited request handler

The mobile app talks to Postgres directly, and row-level security is the authorisation boundary rather than a layer of code in front of it. Scoring, referrals and challenge settlement run as database functions and policies, so a tampered client gets nowhere. One schema carries 25 tables, 51 functions and 48 policies.

It held under load. 863,000 predictions came from 32,252 registered players, through a tournament that ran from 11 June to 19 July 2026.

Edge functions on the second product run on Deno, in TypeScript, behind one audited handler shared across every route. That handler carries an allowlist, a method gate, token verification and rate limiting.

What it enforced.

48policiesbeside 25 tables and 51 functions
row-level-security policies in the schemacounted 5 August 2026
863,000predictionsevery one written through them
prediction rows counted in the live databasethrough the 2026 tournament

The container estate is public.

Every image is public, rebuilt daily, and open to inspection by anyone.

Multi-platform builds from one base image

CalVer tags that are never deleted, so an old pin still resolves

Cosign signing, an SBOM and a provenance attestationdocker.yml

31 public images ship across five repositories on GitHub. Every one is rebuilt daily by cron. Tags are CalVer dates and are never deleted, so an old pin still resolves to the image it named.

docker-base publishes five platforms from one build. The other four publish linux/amd64, which is what most of what runs on them needs.

The base image carries the full gate set on every build. That set is Hadolint, container structure tests, an image scan, Cosign signing, an SBOM and a provenance attestation. What runs traces back to the exact build that produced it.

The estate, measured.

31imagesfive repositories, public on GitHub
published images across the public repositoriesgithub.com
14,970,732pullsacross those five repositories
pull counts summed across the estateDocker Hub, 2026-08-06hub.docker.com

Agents get real access.

An agent gets the same door a person walks through, not a separate one.

A Model Context Protocol server, seven tools behind OAuth 2.1

Agent calls under the same row-level policies as a person

A gate set that fails a build rather than filing a warningdocker.yml

An agent client connects to a Model Context Protocol server and calls the tools it exposes. Seven tools sit behind OAuth 2.1. The product owns its data and its rules; the client does the reasoning.

Agent calls mint a per-user token and run under the same row-level policies as a human session. A model gets no looser path, so an agent that misbehaves is stopped by the same policy that stops a tampered client.

That server is behind OAuth, so you cannot open it and check it yourself. What you can open is the gate set. Agent-written change runs the checks a human change runs, and it runs them before the merge, so a failing check stops the change. The container build publishes that whole set in one workflow file.

What an agent pipeline sends to a model provider, and where the terms for it are settled, is on Trust.

Probably not a fit.

Better to find that out now than in the second month.

This is the shape it fits.

The product decision is made and you can defend it upward. Somebody on your side can review a pull request and approve a merge. The infrastructure is yours, and access can be scoped and granted. If you recognise all three, the rest of this page applies to you.

And the shapes we turn down.

Three shapes come up often, and we decline all three. The first is discovery, where what to build is still open. That decision is yours, and a vendor making it for you is how the wrong product gets built well. The second is a brief that arrives as a fixed specification with a fixed date. What we fix is the period, and the scope is decided inside it. The third is work where nobody on your side can approve a merge, because every change would then wait on us. You would have bought a dependency rather than a capability.

The term itself is three months, extendable once to six. How we work sets out what that includes, what it needs from you, and what you keep at the end.

Tell us what is in the way.

Say what you're building and where it stopped.

hello@beevelop.com

Copy it into your mail client if that is easier.

The draft opens with

  1. What you are building
  2. What is in the way
  3. The stack
  4. When you want to start

The contact page says who answers, and what the reply contains.