Your coding agents are the engineers. Halfcycle is the rest of the team.
A product owner that pins down what you are actually building and will not
accept a vague answer. An architect that decides how it fits together and
writes the rules down where your agents will read them. A planner that
cuts the work into pieces that can really ship. And a reviewer that reads
all of it back, on its own, and stops you when it is not ready.
It runs inside your own Claude Code. You say what you want to build, and
it takes it from there, telling you what happens next at every step. You
do not need to know the process. That is the whole point of it.
AI gave everybody the engineers. It gave nobody the rest of the team.
Good software gets built by a handful of people doing different jobs.
Somebody decides what is being built. Somebody decides how it fits
together. Somebody cuts it into pieces small enough to finish. Somebody
else checks the work, because the person who did it is the worst judge of
it. Your coding agents do one of those jobs. Halfcycle does the other
four.
01
The product owner
It writes the first version of what you are building, then argues with it. One question at a time, in an order that makes sense, each with a suggested answer and the reason behind it. Anything it can look up in your project it looks up and shows you. Anything only you can decide, it actually asks, and it writes down the options you turned down so nobody reopens them in three months.
How it makes sure it is right: it will not record a decision with no reason attached, and it will not hand the spec on while it still contains a placeholder or an unanswered question.
02
The architect
It works out how the pieces fit, draws the diagram, and pulls out the rules your system must never break so that every later decision points back at them instead of quietly reinventing them. The diagram and the written version have to agree, so somebody looking only at the picture can still see how it works.
How it makes sure it is right: the picture and the words are checked against each other, and each rule gets a short reference so later work points at it rather than restating it slightly differently.
03
The planner
It cuts the work into pieces that can actually be finished and shipped, rather than a plan for the whole product that stops being true in week two. If a piece is too big it says so and splits it. Anything it guessed at rather than checked, it marks as a guess, so nobody further down the line treats it as fact.
How it makes sure it is right: four questions get asked of every piece of work, and two answers in the wrong direction force a split. Guesses are labelled, so nothing travels downstream sounding more certain than it is.
04
The reviewer
Before any detailed design starts, somebody who did not write the plan reads it back and decides whether it is ready. It runs away from your machine, so it cannot quietly agree with itself. If it comes back with too many problems, you do not get to carry on until they are fixed. This is the job almost nobody has, and it is the one that saves the money.
How it makes sure it is right: it is never the same reviewer twice, it runs away from your machine so it cannot mark its own homework, and anything the plan claims about code that already exists has to point at a real line in a real file or be taken out.
Every AI coding tool will write you a PRD. Halfcycle is the one that
tells you it isn't finished. Round one looks the same everywhere, and it
should. What almost nothing else has is round two.
You are never lost
You don't have to know what to do next. It tells you.
This is the part people are most surprised by. There is no process to
memorise, no checklist to keep open in another tab, and no set of commands
to learn before you can start.
01
It works out where you are
It reads your project and figures out how far along you actually are, rather than asking you or trusting a box somebody ticked last month. If you come back after two weeks away, it already knows.
02
It tells you the next step
In plain language, when it is relevant: what you are one step away from finishing, what you just finished, and what you are about to do that you are not ready for yet. The rest of the time it stays quiet.
03
You can just ask
Say what you want in your own words. You do not need to know that the thing you are asking for is called a phase, or which step it belongs to. It works that out and starts you in the right place.
If you have never run a project this way before, you are not expected
to. The experience is meant to feel like having somebody senior sitting
next to you who has shipped this kind of thing many times, telling you
what usually goes wrong here and what to do about it.
What every build teaches us
Every build teaches us a new way software breaks. Then it becomes a check.
None of the list below was imagined. Each one turned up on a real project,
got written down the week it was found, and became something checked on
every build after it. The list started at six, from one project's
post-mortem. It has doubled since, from four more. The ones below are the
ones that come up most, and almost none of them is a coding mistake.
What that is worth to you is the part people miss. You are not buying a
checklist somebody wrote. You are starting your build with every mistake
that has already been made, and already paid for, somewhere else, designed
out of it before you write a line.
What goes wrong
What Halfcycle does about it
Tests that pass without testing anything. The most common one by a distance. Code gets written with stand-ins for the real parts, and then the test checks the stand-in instead of the real path. The suite is green and the feature was never run.
Every piece of work that crosses between the screen and the database has to say what the real path is and prove it was exercised, not stood in for.
Two halves that never agreed what to call things. One side sends a name spelled one way, the other expects it spelled another. Nothing fails to build. It fails later, on real data, quietly.
Before either half is written, the exact shape of every message that passes between them gets pinned down: the names, the types, and who is responsible for converting what.
A permission rule enforced in one place and not the next. Somebody wrote the rule, and it works everywhere they remembered to put it. A new path gets written separately, nobody carries the rule across, and something can now be done that nobody is supposed to be allowed to do.
Rules about who may do what get written down once, given a name, and every later piece of work has to point at that name rather than restate the rule from memory. A path that does not cite it does not pass.
A stand-in for the login that made everything pass. Test setups often substitute a fake identity so tests can run without one. When that substitution also survives into something deployed, the real login was never once exercised, and every test was green the whole time.
Anything that lets a missing real dependency succeed quietly is banned from a deployed build. It has to be absent, or loud, or exercised for real somewhere. Turning “this is broken” into “this looks fine” is the worst trade available.
Something built properly and connected to nothing. The feature works, the tests reach it directly, and no part of the live product ever puts it in front of a user.
Every feature has to state how a person actually gets to it, and that becomes one of the things somebody has to confirm before it counts as done.
A save that works for you and not for a new customer. The code updates a record your test data already had, and nothing in the live product ever creates that record. Every new account saves nothing and is told it worked.
Wherever the product writes to a record belonging to one user, the plan has to name what creates that record in the first place. If nothing does, the design changes before anybody builds it.
Settings that exist at the wrong moment. A value the application needs as it starts gets set up as something read later, or the other way round. The build succeeds with nothing in it, and every page fails once it is deployed.
Each setting has to be declared as needed either when the software is built or when it runs, with every place it must be written listed out. This is the single class most likely to take a whole deployment down.
An integration that rejects every message. Another company sends data wrapped one layer differently from what was expected. Your own tests pass, because they were written from your own assumption rather than from anything they actually sent.
Any point another company sends data to has to pin the real shape, captured from a real message they sent, never the shape you assumed.
A dependency doing something nobody asked for. An outside library behaves a certain way by default, the design quietly assumed otherwise, and the tests agree with the library because it is consistent about it.
Any new dependency comes with a list of the behaviours the design needs changed, each one turned off deliberately and each one confirmed.
A plan that was confidently wrong about the existing code. The most expensive one, because everything after it gets built on top. Somebody remembered how it worked, or pattern-matched from a similar piece of work, and never actually looked.
Anything a plan says about code that already exists has to point at a real line in a real file. Then somebody who did not write it checks the conclusion rather than just the line, because a correct quotation can still support a wrong conclusion.
How the list gets longer
This is the part that compounds, and it is the reason a copy of the
method is worth less than the method. It runs at the end of every build,
and it is a procedure rather than an intention.
01
A piece of work finishes
We list every problem that got as far as a person. Not the ones a check caught, because those are already handled. Only the ones that got through, which are the ones that have something to teach.
02
We ask one question about each
Which check would have caught this before it reached anybody, and at which step? Not who wrote it and not why they missed it. Those questions produce apologies. This one produces a check.
03
The check gets installed
It goes into the list, into the planning step it belongs to, and into what the reviewer looks for. From then on it runs on every build, including yours, and the next project never meets that problem at all.
The aim is not zero problems. A person walking the finished product is
supposed to find things. The aim is zero problems reaching that person
which an earlier step could have caught, and that target gets a little
closer every time somebody runs the loop.
A framework you download knows exactly what its author knew on the day
they wrote it, and it will never know more. This gets longer. Every
build inherits everything the ones before it learned, which means the
work you never have to redo is the only kind of speed we are willing to
claim.
And a bar for calling something finished
Passing its own tests is not the same as being ready for real people.
Four rules, and they exist because things that had been signed off for
months turned out never to have worked once anybody used them properly.
It has to work for somebody who is not you
A real person, really signed in, on the deployed product, doing the whole thing start to finish. A developer's own machine and a test suite are exactly where this class of problem hides, so neither counts.
Nothing is allowed to fail quietly
Any shortcut that lets a missing piece succeed silently is banned from anything deployed. It converts “this is broken” into “this looks fine”, which is the worst possible trade.
On a real phone, not a narrow window
A desktop browser squeezed to phone width is still a desktop browser, and it cannot reproduce what a phone does. A mobile check that was not done on a mobile is not a mobile check.
Signed off against the conditions it ran under
When something underneath changes, like how people log in, everything that was signed off before it is no longer signed off, and gets walked again. Otherwise you quietly inherit a pile of things that were true once.
This bar is part of the method and it is what our consulting engagements
hold today. The version that runs automatically is in the next release,
listed below.
Three things people say about software built this way
All three come up in every conversation, they are all reasonable, and
two of them are partly right. Here is what this actually does about
each, including where it does nothing.
“It will be full of security holes”
The security failures we actually find are not a model writing a bad line of code. They are a rule enforced in one place and not the next one, a login stood in for by a test fixture, a permission check on a neighbouring path that nobody carried across. Those live in the joins, and the joins are what this whole method is built around. Rules about who may do what get named once and cited everywhere after, and the final walk is done as a real person, really logged in, on the deployed thing.
Where it does nothing: this is not a substitute for scanning your dependencies, modelling threats, or paying somebody to try to break in. Keep doing all three. We would rather say so here than let you assume otherwise.
“It will fall over under real load”
Honest answer first: this does not measure performance, and no plan can tell you what a system does under load. What it changes is upstream of that. The shape of the system becomes something somebody decided on purpose and wrote down, with the rules it must not break named before anybody builds against them. Most of the systems that surprise people at load are the ones nobody designed, that arrived one accepted suggestion at a time.
Where it does nothing: no load testing, no query analysis, no latency budgets. If performance is the thing keeping you up, this is not the purchase that fixes it.
“In three months nobody will know what it does”
This one we will answer without hedging, because it is the problem the method was built for. When everyone on a team can change the code in minutes, the code moves away from everybody's understanding of it just as fast. So: one authoritative copy of every document and everything else a mirror. Rules referenced by name rather than restated and quietly diverging. A check between feature designs for the moment two of them start assuming different things. And a gate that refuses to let building start against a copy that has gone stale.
Where it does nothing: it reduces this, it does not end it. Large products drift. The method says so in its own documentation and so do we.
Coming next
The parts we are building now, said plainly because they are not here yet
None of the three below is in what you install today. They are what the
next releases add, and we would rather list them here than let a demo
imply you already have them.
Next
A team of agents that builds it
Right now the plan hands back to you and your agents do the building. Next, Halfcycle runs that too: several agents working in parallel on separate copies of the code, with one coordinating them, so a phase gets built the way a team would build it rather than one task at a time.
Next
A dashboard you can watch
One screen showing where the project actually is: which piece is being worked on, what each agent is doing right now, what passed its checks, what got stopped and why, and what happens next. Today that state lives in your terminal. Next it has a picture.
Next
Checks that run on the real code
Today the checking happens on the plan, before anything is built. Next it also happens on what actually got written, comparing each change against every way we have seen a build go wrong before.
The proof
One small feature. Eight defects, caught before any code existed.
Almost every claim about process is impossible to check, because nobody
writes down the bugs that never happened. Here is one that can be checked.
A real feature on a live product: let somebody restore an older version of
a document they had edited. Small, by any measure. Two screens' worth of
work and a button. It was reviewed five separate times before anybody was
allowed to start building it. Problems found each round: 6, then 2, then
1, then none, then none.
#
What was wrong, and what it would have done
Would a code review or the tests have found it?
1
Restore could overwrite a file that is supposed to be locked. Some documents are marked as never-to-be-changed. That rule was enforced in the normal save path, and nobody copied it into the new restore path. Restoring could quietly overwrite a document the product promises never to touch.
No. Every test of the new code passes. Somebody has to notice a rule that is not there.
2
The undo feature could destroy the backup it exists to protect. The plan was to save a backup, update the search index, then save the change, all as one step. If the index step failed, the backup was thrown away, and the new content had already been written.
Almost certainly not. It only happens when one step fails at one exact moment. This is the one that reaches a customer.
3
The button would never have appeared for anybody. It was set to show up based on a piece of information the system only attaches to the exact documents this feature refuses to work on.
No. The code is correct on its own and the tests pass. It ships, it gets announced, and nobody can see it.
4
Restoring a document would have silently deleted the labels on it. A shared piece of code wipes all of a document's labels and puts back whatever it is handed. The plan handed it an incomplete list.
Unlikely. Nothing fails and nothing errors. The loss turns up weeks later, somewhere else in the product.
5
The plan described a bug that did not exist. It claimed a piece of code never updated the search index, based on a search of the codebase that was accurate but led to the wrong conclusion. Both places that use that code already do it.
Partly. Somebody who knew that part of the code might. Somebody who did not would have approved it.
6
The design could not be built in the place it was going. The part of the screen it was meant to live in is not able to change the content it would have had to replace.
Yes, eventually. By the person building it, halfway through, after the work had already been handed out.
7
Two people were about to build two different versions of the same thing. The work was split between two contributors and nothing anywhere said what the new connection between the two halves should look like.
Yes, eventually. When the two halves were joined and did not fit.
8
The summary everybody reads first still described a plan that had been thrown out. Three rounds of review had already replaced that design, and the one-line summary at the top was never updated.
No. Nobody goes back and re-reads a summary line. The next person builds from it.
Four of these eight would have reached real users. Not one of them is a
coding mistake. Every single one sits in a join: between two pieces of
code, between two people's work, or between the plan and what was
already there. An agent writing the file in front of it cannot see any
of them, and neither can a person reading the change on its own.
Honest about the cost: five rounds on a feature this small is heavy, and
roughly five of the later defects were introduced by the previous round's
own fixes. The method was amended because of it. On the same feature today
it would be about three rounds. We do not defend the five.
Nothing here is bad at its job. None of them checks the work.
We are not arguing that the tools you already use are wrong. Each makes
one stage of building faster. The gap is the same gap in every category.
App builders
The fastest path from idea to a demo, and the worst path to a durable product. They are excellent at the eighty percent that looks finished and fall over on the twenty percent that decides whether software survives real users: integrations, migrations, auth edge cases, deploy correctness, load.
IDE assistants
They make a capable engineer faster. They do not make an inexperienced team correct, and they cannot see the joins. An assistant works in one editor on one task, and the failures that sink builds live between tasks, between separate parts of the system, and between the build and the release.
Autonomous agent platforms
You rent the capacity and you keep the risk. The dashboards measure tokens, tool calls and output volume, not whether the build is correct, because there is no library of how builds fail to measure against.
Spec-driven frameworks
Spec-driven development is table stakes now, and the free frameworks differentiate on step count. They hand you the format and assume you already have the judgment. Nothing in any of them independently checks that the built thing matches the spec.
So what are you actually paying for? Every serious alternative is free
to download, and we think that is correct. Writing the process down is
not the valuable part and we do not sell it. What you pay for is four
things a downloaded folder cannot do. Somebody other than you checks the
work, and it is not the same one that did it. You get a written record
that a piece of work really finished, instead of a claim that it did.
Everybody on your team gets the same checks automatically, with nothing
to set up. And the checks keep getting better: every time we watch a
build break in a new way, that becomes a check on the next one. A
framework you download knows what its author knew on the day they wrote
it, and it will never know anything more.
Three ways in
How much of this do you want to run yourself?
One method. Three answers, and they are not tiers of the same thing.
Available now
Halfcycle
All of it. The method runs inside your own Claude Code, on your own
seats. Your code, your data and your inference never leave your
machine. Free for solo developers.
None of it. You describe the product in a guided conversation, the
platform builds it, you approve at the gates and watch the phases
land. It is not ready, and we would rather say so than run a waitlist.
The part where someone teaches your team. We run the method on your
live product with your engineers until it is the way your team works.
What stays when we leave is the method on your team's own seats.
