Three months · extendable once to six
Five parts, then a product.
This is what we install, what it produces, and what you keep when the engagement ends.
Built for CTOs already blocked.
Scale-ups and mid-market: large enough to feel the pressure, small enough to act on 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.
So this page answers what happens after you sign, and our services answers what we would be building. Read that one first if the question is still what to build.
Letting us in makes consensus harder.
Granted, with no qualifier attached. 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 larger, 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. The agent 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, written to be forwarded.
The term is 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 not a separate phase; they are how each change gets decided.
- What the term includes
- The factory standing in your repositories and accounts, one product carried through it end to end, and the handover. All five parts below are installed in the opening phase and used from there on.
- What extending to six means
- 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 it needs from you
- 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 for the term. Both sit in infrastructure you already own, so the end of the engagement moves nothing. The procurement set states the access model, where your source code goes, and the exit.
- If it ends early
- Whatever has merged and shipped is already yours, because it was installed in your accounts in the opening phase. It was never held back for a closing event.
- If we are unavailable
- The work sits in your repositories from the first commit, and the way of working is documented as it is installed. So what carries the knowledge is the running system and its documentation, rather than somebody you have to reach. We have published container images in the open since August 2015, and the oldest of those repositories still rebuilds daily.
It opens by installing the factory.
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.
The middle ships one product, 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.
The end is a handover.
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.
Once installed, you can open, run or read every part of it.
Each part below is a file or a run rather than a claim about the way we work. All five are installed once, in your infrastructure, in the order they are listed.
- Repository layout
- Where 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.
- CI gates
- The 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.
- Agent pipeline
- How work is specified, handed to a model, and reviewed before it merges. The agent pipeline debrief names the five stages and the person at the end of them.
- Test suites
- What has to be green before anything ships, and what each suite covers. The second product publishes its own suite counts, green on every commit.
- Deployment path
- Every step between a merged change and the running system. The first product's own path to two app stores is public in its debrief.
Shown in the debriefs.
The stack and the method are shown where something was built rather than described in the abstract.
The agent pipeline debrief matters most here, because it is how every other debrief got built. The Docker images debrief 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. Every debrief here is our own product or our own artefact, which is why you can open each one and check it for yourself.
Tell us what is in the way.
Say what you're building and where it stopped.
hello@beevelop.comCopy 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.