Three months · extendable once to six

Three months.
One product.
Then yours.

What we install in your accounts, what it produces, and what you keep when we leave. Written so you can forward it to procurement.

Built for CTOs already blocked.

You have the plan and the budget. What you do not have is anyone free to build it.

A role you open in spring starts three to six months after somebody accepts it. That arithmetic is why the date on the board slide has not moved. We start the week the access is granted, because there is nobody to hire first.

This page answers what happens after you sign. What we build answers what we would be building. Read that one first if the question is still what.

Letting us in makes consensus harder.

Granted. Here is what it changes and what it leaves alone.

Hiring is the first hurdle, and a factory brought in from outside removes it. Consensus is the second, and it binds leadership too. An outside party inside your repositories and cloud accounts makes that second hurdle bigger, because you are the person who signed for it. We are not going to pretend otherwise.

What moves is the thing consensus has to approve, not the people who approve it. Every change still merges through your own review process, on your own release schedule. The factory adds a worker to that process, not a way around it. Access is granted in your accounts, which is also where it is withdrawn.

The second objection is the work itself: code handed to a model is code your engineers did not write. Theagent pipeline debrief sets out the five stages a change moves through and who rules at each one. A check can refuse a change; no check can approve one.

What three months buys.

The whole shape in one block, so you can forward it to procurement.

The period: Three months, extendable once to six. Scope is decided inside it, because the scope of a first product is not knowable before the work starts. Architecture, technical diligence and advice are how each change gets decided, not a separate phase.
What it covers: The factory standing in your repositories and accounts, one product carried through it end to end, and the handover. All five parts are installed in the opening phase and used from there on.
The extension: More product through the same factory, on the same terms. It is a decision you take at the end of the third month. The period lapses unless you take it.
What you provide: Two things. You grant access scoped to the work, in your own accounts, and you name a reviewer who can approve a merge. Everything else is ours to arrange.
What you keep: The running system and the documented way of working, outright and not on licence. Both sit in infrastructure you already own, so the end of the engagement moves nothing.
If it ends early: Whatever has merged and shipped is already yours, because it was installed in your accounts in the opening phase. Nothing was held back for a closing event.

First, the factory goes in.
The five parts go into your repositories, under your accounts, before any product work starts. Everything runs on your infrastructure, and the cloud bill is yours from the first day.
Then one product goes through it, end to end.
That can be a whole product, a subproduct, or an extension to something already live. All five parts carry it, and it is done when it is in production under real load.
Then we hand over and leave.
You receive the running system and the way of working that produced it, documented. The period stops there rather than rolling on.

The factory is five parts.

Repository layout, CI gates, agent pipeline, test suites, deployment path. You can open, run or read every one.

Repository layoutWhere the code, the configuration and the documentation sit, and what may import what. The same discipline runs today, in a public repository you can read.github.com CI gatesThe checks a change has to pass before it can merge, and what each one refuses. The gates on that repository are public, in its own workflow file.docker.yml Agent pipelineHow work is specified, handed to a model, and reviewed before it merges. The debrief names the five stages and the person at the end of them.The debrief Test suitesWhat has to be green before anything ships, and what each suite covers. The second product publishes its own suite counts, green on every commit.The planning matrix Deployment pathEvery step between a merged change and the running system. The first product's own path to two app stores is public in its debrief.Kickgeist

What we decline, and what replaces it.

Not staff augmentation: You are installing a setup that keeps producing after we stop, rather than renting capacity for the term. It goes into your repositories and it stays there.
Not a fixed scope: What we fix is the period. The scope is decided inside it, change by change, with your reviewer approving each one before it merges.
Not discovery: What to build is your decision, and a vendor making it for you is how the wrong product gets built well. We start once it is made.

Shown in the debriefs.

The stack and the method are shown where something was built, so you can judge them on a real product rather than on this page.

Start with the agent pipeline debrief, because it is how every other debrief got built. Then read the Docker images debrief, which is the one you can check without asking us.

An NDA covers every engagement, and that work is not ours to publish. Yours would be covered the same way. So every debrief here is our own product or our own artefact, and you can open each one and check it for yourself.

The technical debriefs

One mail. No form.

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

What you are building
What is in the way
The stack
When you want to start

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

What procurement will ask.

Three months.One product.Then yours.