Software engineering for DACH companies
We install a build system in your repositories and put your first product through it. When we leave, it keeps running.
Three months, extendable once to six. Every merge is approved by your reviewer, in your accounts, on your schedule.
Three things we built, dated and public. Each card links to the artefact behind it, so you can check before a call.
the pipeline we use, and the one you get
A model drafts and tests. A check can refuse. A person merges. That is the whole method, and it is what we install in your repositories.
Read the debriefa public container estate, since 2015
Five public repositories, rebuilt every day for eleven years. Open one and count the pulls yourself.
Read the debriefa prediction game on iOS, Android and web
32,252 players and 863,000 predictions on one Postgres schema. The debrief includes the database we got wrong.
Read the debriefFour capabilities, each with a number you can check on its own page.
One Flutter codebase on iOS, Android and web. Fifteen iOS lanes and seventeen Android ones release it by script.
29 languages, 35 locale files
Row-level security instead of an API tier. Scoring, referrals and settlement run as database functions.
25 tables · 51 functions · 48 policies
Signed, scanned, rebuilt daily by cron. Tags are dates and are never deleted, so an old pin still resolves.
31 images · 5 platforms
Seven planning tools behind OAuth 2.1, under the same row-level policies a person runs under.
7 tools · one door
The term is fixed at the start. Extending is a decision you take once. It never drifts into a retainer.
Repository layout, CI gates, the agent pipeline, test suites and the deployment path go into your accounts before any product work starts. The cloud bill is yours from day one.
A whole product, a subproduct, or an extension to something already live. It is done when it runs in production under real load, with your reviewer approving every merge.
You keep the running system and the documented way of working that produced it. The next product goes through the same setup without us in the room.
Two things, and procurement can scope both. Access to the repositories and accounts the work touches, and one reviewer who can approve a merge. We bring the rest.
Staff augmentation, because the capability leaves with the person. A fixed scope before the term, because a first product's scope is discovered inside it. How we work sets out both.
One mail. No form.
Say what you're building and where it stopped.
Copy it into your mail client if that is easier.
The draft opens with
The contact page says who answers, and what the reply contains.
