For engineering leaders

Your team, building with AI agents, the right way. In four weeks.

Halfcycle is the method your engineers follow when AI agents write the code: one way of deciding what gets built, a check on every change by an agent that did not write it, and a page that shows you every project with what it cost. We install it on your repositories, run the first real work with your team, and leave when your team is running it without us.

Where to start

Tell us which of these you are looking at

The engagements

Four ways we come in. Every one ends with your team running it.

Published prices where the scope is fixed. A quote where it is not. No hourly billing anywhere.

US$12,000 to 20,000

Two weeks · fixed fee

The AI-Build Audit

For the leader who knows something is wrong and cannot yet say what.

We point the method at your repositories and read what it finds beside your incidents, your review process and your agent spend. Two weeks later you know what to change first, what to change next, and what each is worth.

You get

  • Your repositories read by the method, every finding pointing at a line
  • Your incidents, your review process and your spend read beside it
  • A written finding: what is costing you, in what order to fix it
  • A sequence your team can run with us or without us

Yours whether you go on with us or not. A fair number of teams take the audit and run the sequence themselves.

Book the audit

US$25,000 to 45,000

Four weeks · fixed fee · plus the Team plan

The adoption pilot

For the organisation where "install it" will not happen on its own.

Four weeks on your repositories, with your team, shipping real work. We drive the first week. Your engineers drive the last. It ends with a baseline you can take upstairs and the whole team on the Team plan.

You get

  • Real production work shipped on your own repositories
  • Every engineer on the Team plan, with the same checks on every edit
  • Your existing code read and reconstructed, layer by layer
  • Your rules written in and running on every project
  • A page per project with cost and cycle time, and one for all of them
  • A written baseline and a recommendation for what comes next

The price sits beside the Team plan, not instead of it.

Book the pilot

Quoted at spec sign-off

One phase · fixed price

A fixed-price build

For the company that wants the software more than the capability.

One phase of your product, built on the method, with your engineers in the room so the capability arrives anyway. The price is set when the spec is signed off, so it is about the work and not a guess at it.

You get

  • A phase of working software, walked on the deployed product before it closes
  • Part of the price held until you accept it
  • A fixed period after delivery in which we stand behind the work
  • Your engineers able to run the next phase
Scope a build

Scoped per organisation

Usually with Enterprise

Implementation

For many teams at once, and for services firms.

Organisation rules, single sign-on, your tracker, training, governance, across more teams than a pilot covers. There is no package, because no two of these look alike.

Also for

  • A services firm that wants to deliver its own client work on the method. We run your first client engagement with you, then get out of the way.
Talk to us

How the pilot runs

We drive. We guide. You run.

Real work, not a workshop. By the fourth week your engineers are running a phase without us, and that is the test the pilot has to pass.

The adoption pilot · four weeks

Responsibility moves to your team, a week at a time

  1. Week 1 We drive Your repositories read and reconstructed. Your organisation set up. The production work chosen.
  2. Week 2 We guide Real work ships. Every change checked. Your engineers at the keyboard.
  3. Week 3 We guide Your rules written in. A second team joins. We step back a pace each day.
  4. Week 4 You run Your team runs a phase without us. We write the baseline and the recommendation.

Ends with your team on the Team plan, running the method without us.

What every engagement ends on

The Team plan: one way of working, every change checked, every project on one page

A lead with one or two repositories and a willing team does not need us. Start the trial, invite the team, and be on it this afternoon.

01

One way of working on every seat

Invite by email or by link. A colleague's next npx halfcycle in a clone of the repository puts them on the project with the role you gave them. Nothing to install beyond the one command, nothing to configure, nothing to keep up to date.

02

Every change checked by an agent that did not write it

On every edit, in the session, before review. What was stopped says why. Your reviewers read code that has already been read.

03

Every project on one page, with its cost

Phase, what is happening now, what is waiting on whom, what the phase has cost in money and how long it has taken. One page per project and one for all of them. Share it with your own lead as a read-only link.

04

Your rules, on every project

An Admin writes a rule once: a convention, a check, a step your organisation needs. It runs on every project from the next edit, and says where it came from when it fires. Your rules add to Halfcycle's. They cannot switch one off.

05

Approval is a person's act

Owner, Admin, Write and Read, the way GitHub does it. Who may approve a phase's scope or close one is named per project, with a second approver when you want one. Every approval is recorded by name.

06

It starts with the code you have

It reads an existing repository before it writes anything, shows you what it sees, and reconstructs the plan from the code with every claim pointing at a line. A product spread over several repositories is one project with one page.

Why review is not enough

The defects that reach customers are not bad lines. They are two halves that never agreed.

Each agent writes its part well. Each part passes its own tests. The failure is in the join: a field named two ways, a rule enforced on one side and not the other, a page nothing links to. Nothing in a standard setup looks at the join. Halfcycle's checks run on it, on every edit.

Two halves of a feature each pass their own tests. The defect is in the join between them. The check runs on the join. WHERE THE DEFECTS LIVE Each half is fine. The join is not. The form written by one agent OWN TESTS · PASS The service written by another OWN TESTS · PASS sends customer_id expects customerId CHECK RUNS HERE The check reads both halves together, on every edit, before review.

What leadership sees

One page per project, written for a person who does not open terminals

What is waiting on you, where each phase is, what passed and what was stopped and why, who approved what and when, and what it has cost. The same page your engineers use.

The Halfcycle console for one project: a notice that phase 3 is waiting on the reader's approval, phase 2 open six days with four of five gates cleared, the six stages from set-up to build with their states, and each approval recorded with a date.
What it never shows: file contents. Halfcycle holds no access to your repositories. Where the page points at code, it links to your own remote, under your own permissions.

What you inherit on day one

You are not buying our experience. You are buying everybody's.

Behind the method is a list of the ways this kind of project actually goes wrong, and each entry runs as a check on the plan and on every change after it. Every entry got past a person on a real project, and somebody wrote down what would have stopped it. The list does not only grow from the projects we are paid to be on. The method runs inside developers' own setups, on far more projects than any consultancy could staff, and each of them can put something new on it.

An implementation goes wrong on one project. The cause and the fix are both kept as a check. The check reaches every other project automatically, before the problem arrives there. WHAT YOU INHERIT ON DAY ONE A problem on one project becomes a check on all of them A project somewhere an implementation goes wrong, once CAUSE + FIX The list every way a project has gone wrong, as a check GROWS WITH EVERY PROJECT Your project Their project The next one Most such problems never reach you. The ones that do arrive with the answer attached.

Proof

We build Halfcycle on Halfcycle

In phases of several hundred tasks, each change checked as it is written, each phase closed only on a walk of the deployed product by somebody who did not build it. Four other products have been built on it from their first phase, from a two-person company's first product to a platform with paying customers, each delivered well inside the time a standard team had estimated for it. We will show you the records on the call.

Series B platform

Velocity that stopped tracking headcount

Each new engineer added coordination cost faster than throughput. The finding was not tooling. Four teams were writing specs that quietly assumed contradictory things.

Mid-market modernisation

A modernisation that had stalled twice

Two previous attempts had produced architecture documents and no shipped change. The third shipped because the work was cut into phases that could close.

Governance and data

Your code never leaves your machines

The agents run in your own Claude Code or OpenAI Codex, on your own accounts, on your own machines. We never hold or proxy the credential. Nothing in your repository is copied to us. Every phase closes with a written record an auditor can read, and every approval is a named person's act.

Your code, documents, credential and agents stay on your machines. The shape of a problem, with counts and timings, travels to Halfcycle. Code, documents and anything about a person never do. WHAT LEAVES YOUR MACHINES One thing travels. Everything else stays. YOUR MACHINES Your code Your documents Your credential The agents, in your own Claude Code or OpenAI Codex Everything that gets built Nothing here is copied to us. HALFCYCLE The method, one step at a time The checks The console The list that grows We do not train on your work. TRAVELS the shape of a problem, counts and timings NEVER code, documents, anything about a person

The full statement, written for the person who signs off on a tool, is on the governance and data page. It includes what the method does not do, because that list is what makes the rest believable.

How we work

Four things to know before the call

The person who scopes it runs it

No senior pitch followed by a junior team. That caps how many engagements we run at once, on purpose.

Your engineers in the room

On every engagement, including a fixed-price build. The point is that your team runs the next phase without us.

No hourly billing

Fixed fee for the audit and the pilot, a quoted price for a build, a scoped price for implementation. Hours reward the wrong thing.

We say no when that is the answer

If your team should install it and go, we say so on the first call. If you should wait, or hire, we say that.

Bring us the stalled rollout

Thirty minutes with the person who would run the engagement. Tell us what is stuck, what deadline matters and what you have already tried. We will tell you on the call whether to install it and go, book the audit, or wait.