[ Not vibe coding ]

Your product lead and one engineer ship production software at 10× the output per person.

For product companies with their own engineering team. Your product lead directs CraftHQ's AI agents on Claude Code. A separate agent writes the tests, and your engineers approve every merge.

Scope a 3-month pilot Get a baseline report

[ Scroll to watch one feature go live in two days ]The company and its people are made up, to tell the story.

  1. 01 / 07Mon 8:40

    Dana decides

    A deal is blocked on one feature.

    A big customer is waiting on one feature. Dana, the CEO, makes it this week’s top job.

  2. 02 / 07Mon 9:12

    Emily asks for the feature

    She’s the product lead. She writes no code.

    Emily, the product lead, asks for the feature in a normal chat message. CraftHQ asks her two quick questions.

  3. 03 / 07Mon 9:15

    CraftHQ makes a plan

    CraftHQ takes it from here.

    CraftHQ turns her message into a plan, and adds the lessons from earlier mistakes.

  4. 04 / 07Mon

    The AI builds it, and tests it

    One AI builds it. Another tests it without seeing the code.

    Builders on one side of the glass wall write the code. Testers on the other side write the checks from the request without seeing the code, so a test can’t just repeat what the code does. It catches what the code got wrong.

  5. 05 / 07Mon 17:40

    It all comes together

    One simple report, for a person to check.

    All the work comes back as one simple report: what changed, how it was checked, and the risks.

  6. 06 / 07Tue 9:30

    Sam, an engineer, checks the work

    Nothing goes live until a person says yes.

    Sam, an engineer, reads the report and asks for one more check. Then he says yes, and it goes live.

  7. 07 / 07Tue

    Nothing learned is lost

    Everything this request taught is saved.

    Everything this request taught is saved, so the next one starts smarter.

That was one made-up request.

Here’s what a real team using CraftHQ measured.

10×+output per person vs the industry median (one team)
734pull requests merged in two months, across our client work
3Claude Code subscriptions for all of it
0.19%of changes undone

Output and reverts: one two-person BetaCraft team, over 30 days. Pull requests: all BetaCraft client repos, mid-July to mid-September 2026. The company in the story is made up.

Scope a 3-month pilot Get a baseline report
MADE-UP COMPANY WORK CHECKED PERSON DECIDES MEMORY

[ Not vibe coding ]

Your product lead and one engineer ship production software at 10× the output per person.

Your product lead directs CraftHQ's AI agents on Claude Code. A separate agent writes the tests, and your engineers approve every merge.

Scope a 3-month pilot Get a baseline report
LEDGERLY · ILLUSTRATIVE · 1:08

That was one made-up request.

Here’s what a real team using CraftHQ measured.

10×+output per person vs the industry median (one team)
734pull requests merged in two months, across our client work
3Claude Code subscriptions for all of it
0.19%of changes undone

Output and reverts: one two-person BetaCraft team, over 30 days.
Pull requests: all BetaCraft client repos, mid-July to mid-September 2026.
The company in the story is made up.

Scope a 3-month pilot Get a baseline report
Built with CraftHQ for
NexdigmZiplines EducationiSoftpull
How it works

Three steps. Your engineers keep the final say.

A product lead asks, CraftHQ’s agents do the work, an engineer decides.

  1. 01

    Point it at a repo

    Give it pull-request access to one repo. It reads your architecture, conventions and test setup once. That's a one-time setup per codebase, not ongoing consulting. Then it works through your backlog, asking questions about every ticket before it builds.

    Questions before code, on every ticket
  2. 02

    It builds and tests from the spec

    Builders write the change. Separate testers write checks from the requirement, never from the code, so a test catches what the code got wrong instead of repeating it.

    0.19% of changes undone in 30 days
  3. 03

    Your engineers review and merge

    A normal pull request in your CI, tagged by risk (UI-only, logic or core), with the requirement, tests and results attached.

    A person approves every merge
Not another coding assistant

Keep Claude Code and Cursor. CraftHQ adds the proof around them.

Out of the box, an assistant doesn't know your business rules or what broke last quarter, and it grades its own work.

What CraftHQ adds compared with a coding assistant used out of the box
CapabilityCoding assistant, out of the boxWith CraftHQ
Your codebaseKnows what's in front of it right nowFitted per repo: architecture, conventions, test setup
TestsOften written in the same session as the codeWritten from the spec by a separate agent that never sees the implementation
MemoryRules files you maintain by handA ledger of every defect class, enforced on every later change
ReviewDiffs, reviewed like any other codeRisk-tiered PRs with requirement → tests → results attached
ProofNot measured by defaultFunction points, reverts and test share from your own git history

Already building your own setup? Run it side by side with CraftHQ on the same tickets during the three-month pilot and let the numbers decide.

Feature library

Real features, shown the way we build them.

Twenty features from SaaS products built with CraftHQ: the spec, the questions we asked, the diagrams and the tests.

Browse all 20 features

FP = function points, the ISO size unit we quote in.

Single sign-on · ticket10 FP
Integrations

Works with the tools your team already uses.

Tickets come from your tracker or a chat message. Pull requests go to your Git host. Your engineers review and merge.

Where work comes from
  • Email
  • Slack
  • Microsoft Teams
  • Jira
  • Asana
  • Trello
  • Linear
  • ClickUp
  • Shortcut
Where code goes
  • GitHub
  • GitLab
  • Bitbucket
What runs it
  • Claude Code

Don’t see yours? We connect a new tool in about a day.

Proof

Measured from git history, the same way you'd measure your own team.

We count output in function points, the ISO-standard unit of working software. They don't depend on the language, and AI can't inflate them the way it inflates lines of code.

Output per person10×+
function points per person-month: 140+ vs. an ISBSG median of ≈ 14
two-person BetaCraft team · 30 days · IFPUG-counted
Revert rate
0.19%
of shipped changes in the measured 30-day window rolled back: fewer than 2 in 1,000
same team · repo's last 30 days
Time to production
12.5 weeks
~780 FP platform · ~9 months for six people at the ISBSG median
one client platform (Nexdigm) · 18 Jun to 14 Sep 2026 · size estimated, ±15%
  • 734 PRs merged in two months
  • 3 Claude Code subscriptions
  • Every PR approved by a human
How we measuredThe ISBSG sample, a solo product-owner project, delivery cadence and every source
Output per person, measured
Function points per person-month · higher means more working, tested software per person
ISBSG sample median (a published ISBSG sample; shaded band)≈ 14
One product owner, not an engineer, on CraftHQ (a separate solo project, May–Sep 2026)30–35
Two-person team on CraftHQ (product owner + engineer), per personat least 140
shaded band = ISBSG sample, middle half (≈12–16) hatched = upper end of a reported range · rounded end = lower bound

ISBSG 2023, 512 Java/Agile projects (800–1,200 FP): median 7.9 hours per function point (P25 6.8, P75 9.4), converted at 110 productive hours per month. The 140+ figure counts both people, including the product owner's requirements time.

See the delivery cadence 1,431 commits by our founder, Apr–Sep 2026 · 734 pull requests merged across client repos, mid-Jul to mid-Sep
Delivery cadence across client repos, Apr–Sep 2026 The founder's git log · every cell is a day · scroll for earlier weeks
Apr 21May 0Jun 9Jul 79Aug 567Sep 755 to datebusiest day: Sep 8, 302= 1,431 commits by one person across client work

Commits show cadence, not output. Output is measured in function points above. Between mid-July and mid-September 2026, 734 pull requests were merged, each approved by our tech lead rather than the person who raised it. All of it ran on 3 Claude Code subscriptions, not a metered API bill.

Sources: one two-person BetaCraft team, its repo's last 30 days, IFPUG-counted (the product-owner row is a separate solo project, May–Sep 2026); the 12.5-week figure is one client platform, kickoff (18 Jun) to production (14 Sep 2026), about 780 function points (derived, ±15%), set against the same ISBSG median (hatched = the ±15% range); much of that calendar went on client decisions and testing, not code; the comparison is a published ISBSG sample (ISBSG 2023, 512 Java/Agile projects of 800–1,200 FP: median 7.9 hours per function point, converted at 110 productive hours per month). Figures reported without project detail at clients' request. Ask for the full benchmark.

Get your own baseline report, free. Read-only, one repo, NDA first. Access revoked when the report is delivered, and you get the report whether or not you run a pilot.Get my baseline report
In practice

A three-month bug backlog, cleared in one week.

An ad-tech SaaS team cleared a three-month bug backlog in one week with CraftHQ. It was driven by one person from their QA and product team, not an engineer, and every fix was raised as a pull request for their engineers to review.

Every fix raised as a pull request
“When we talked about this yesterday evening, we came up with exactly this solution, and it was done by morning. That’s the speed we want.”
Tech lead, ad-tech SaaS company
Read the Nexdigm case study →

Customer story

Featured story
Two people. 12.5 weeks. A regulated tax platform in production.

How two people built TaxMind | UAE for Nexdigm’s tax team: a UAE Corporate Tax platform, in production since 14 September 2026.

Questions before codeTests written separatelyEvery change signed off by an engineer
Read the storyTechnical details →
~10×
output per person. About 136 function points per person-month, against an industry median of about 14 (ISBSG 2023).
12.5 wk
kickoff to production
~780
function points
14,600+
automated tests
It gets better with use

Every lesson stays in your repo.

Every mistake it catches becomes a written rule with its own check, kept in your repo and run on every build.

Starts as
the same harness every team gets
Grows with
every defect caught, rule clarified, domain quirk
Lives in
plain, readable files in your repo
Enforced
a check per rule, run on every build

And the ledger is yours. Passing checks are review evidence, not a guarantee that every business rule is met.

Ledger · defect classes on fileyour repo
  • L-41webhook retried → customer charged twicecaught in review
  • L-41.1rule: every payment handler is idempotentchecked every build
  • L-42tenant ID missing from export querychecked every build
  • L-43usage rollup at timezone month-endchecked every build
  • L-44your next onepending
Security

Everything your security team will ask about, answered up front.

Your repo, a dedicated machine, your model subscription. Only your engineers merge.

Repo-scoped token

Contents + pull requests only, verified by you, with branch protection on.

Security brief first

Token permissions, hosting region, retention and who can reach the machine, before any access.

Your own cloud, if you prefer

We'll assess your cloud account before the pilot is agreed.

Independently assured

ISO/IEC 27001:2022 certified

Independently certified information-security management. Certificate available under NDA.

Independent penetration test

An outside security firm tests the platform. The latest summary is available under NDA.

SonarCloud quality gate

Security A · Reliability A · Maintainability A on the client build we delivered.

Three checks on every pull request

On our client builds: one check on the product owner's machine, one on the engineer's, then a SonarCloud scan in CI, before anything can merge. On yours, we fit the checks to your CI.

  • NDA before read access
  • Every change traceable
  • DPIA for personal data
The certificate, the penetration-test summary and a security brief are available under NDA. The brief covers access, network design and data flow, written for your security team to sign off.Request the security brief
For engineering teams

The questions your engineers will ask.

Do you need write access to our repo?

We need a repo-scoped token with contents and pull-request permissions: it can push feature branches and open pull requests. You turn on branch protection for main and your release branches, so the token can't merge or push to main. That rule is enforced by GitHub, not by trusting us.

Nothing reaches main unless one of your engineers approves it.

Why not just give our developers Claude Code or Cursor?

You should, and many teams already have. A coding assistant helps developers write code faster. On its own it doesn't carry your business rules or check its work independently.

CraftHQ is the layer around the model that fixes that:

  • A per-repo understanding of your architecture and conventions.
  • Tests written independently from the spec, never from the code.
  • A ledger of every defect class and business rule, enforced on every later change.

That combination is what we measure, and the pilot tests it against the workflow you run today.

Is a single task faster with CraftHQ than with Claude Code?

No. On one small task it's often slower. Every change gets a plan, tests written by a separate agent, and checks before a pull request is raised.

The speed comes from elsewhere: many tasks run in parallel, the work arrives tested and reviewable, and less of it comes back as rework. That is why we measure output per person per month on your own git history, not seconds per prompt.

Won't this replace our engineers?

It changes what they spend time on. The harness handles building and first-pass testing. What it can't supply is judgment: architecture, what a requirement really means, and whether a change is safe to ship.

The measured team was one product owner and one engineer, with the engineer as reviewer, architect and quality gate. That's the most senior part of the job. The pilot runs on your existing team and measures what changes for them.

We'll be buried in PRs. Who reviews all of this?

Your engineers do. CraftHQ takes the repetitive part off them.

  • Tell us what your reviewers check for. CraftHQ checks those things on every pull request before a person looks at it.
  • When a reviewer leaves a comment, it becomes a rule CraftHQ follows on later pull requests, so you don't have to keep making the same comment.
  • Each pull request is tagged by risk (UI-only, logic or core) and arrives with its requirement, tests and results, so review means checking evidence, not reading code cold.

Nothing merges without a human.

What is a function point, and why measure with it?

A function point is the ISO-standard unit of delivered functionality, counted with the IFPUG method. It measures what the software does (inputs, outputs, queries, stored data) regardless of language, framework or how many lines it took.

We use it because lines of code, commits and story points can all be inflated, and AI makes that easy. Function points are hard to pad, and anyone trained in IFPUG can recount them.

We report the everyday metrics too: PRs merged, revert rate and test share.

Isn't the comparison unfair? Most of our time goes into working out requirements.

Two parts to the answer. First, the 140+ figure counts both people on the team, including the product owner's time spent working out requirements. Second, the speed-up isn't uniform:

  • Change requests, fixes and enhancements still need clear requirements, but the existing product answers most of the questions, so they move fastest.
  • Brand-new features move at the speed of your team's decisions. The harness doesn't guess. It sends back its open questions before anything is built.

That second part often saves the most time, because the questions come before the build, not after it.

What does the pilot need from us?
  • Pull-request access to one repo, with branch protection on main.
  • A CI/CD pipeline that runs your tests on every pull request. The target is 95%+ test coverage; if you're below it, we close the gap in weeks 1–2 of the pilot, before your team takes the wheel.
  • Claude Code subscriptions on your organisation's account. For scale, our 734 pull requests ran on 3.
  • A real backlog of tickets, so there are no toy tasks.
  • One or two engineers reviewing PRs, with a reviewer-time budget and a PR submission limit agreed up front. We measure actual review hours and slow the submission rate if the budget is exceeded.
  • A success measure agreed before day one, including reviewer hours.

More questions

Where does our code go? Can it leak?
  • Your repo is cloned to a dedicated machine in an isolated VPC that we operate, reachable only over VPN.
  • The model runs through your own Claude Code subscription, so model usage and data handling fall under your organisation's agreement with Anthropic. Outbound traffic is allow-listed: Anthropic, your GitHub, and the package registries your build needs.
  • Retention terms, hosting region and exactly who on our side can access the machine are written into the security brief you get before any access.
  • An NDA is signed before we get any read access.

Need it to run inside your own cloud account? Raise it when we scope the pilot, and we'll assess it before anything is agreed.

Do you keep or reuse our code?

No. Your code, and the rules CraftHQ writes about it, stay in your repository.

What carries over from one client to the next is general engineering practice, like writing tests from the requirement or questioning a ticket before building it. Nothing specific to your code goes into it.

How can we check for ourselves that nothing leaks?

You don't have to take our word for the main controls:

  • Your GitHub audit log shows every action CraftHQ takes in your repo. You can see its permissions in your GitHub settings and remove its access at any time.
  • The model runs on your own Claude Code subscription, so the usage shows up in your account, not ours.
  • Branch protection is a GitHub setting you control. Nothing reaches main without your engineers, whatever we do.

If your security team wants more, like outbound traffic records or running it inside your own cloud account, raise it when we scope the pilot.

What compliance do you have?

We have ISO/IEC 27001 certified information-security management, an independent penetration test, SonarCloud quality gates on every build, and a DPIA wherever personal data is in scope.

The certificate and the latest penetration-test summary are available under NDA. So is a one-page security brief covering the access model, network design and data flow, written for your security team to sign off.

Can our developers drive it themselves, or is this a service?

It's built for your developers to drive. So far, the measured results come from teams where our people drove it, and the pilot is where yours do. There are three phases:

  • Readiness (weeks 1–2): we bring the code in pilot scope to 95%+ test coverage, with CI and documentation.
  • Enablement (week 3): a harness engineer works with your team. The first PRs are reviewed together, with no merges, while we fit the harness to your repo.
  • Self-serve (weeks 4–12): your developers submit tickets, inspect results and request revisions themselves. Our harness engineer is on call, and we record every point where our help was needed.

Fitting the harness to a repo is a one-time step per codebase, not an ongoing consultancy.

Who stays in control of what gets built?

Your team does, at every step.

  • Before building, CraftHQ writes a plain-language plan and asks its questions. Nothing is built until someone on your team approves it.
  • Business users get plain-language questions. Technical decisions are made and logged, so an engineer can see and override each one.
  • Where your setup supports it, each change gets a preview link you can try before review.
  • Your engineers review and merge. CraftHQ never merges.
How do we know it's apples to apples?

Don't rely on our benchmark. Measure your own. Before the pilot starts, your recent git history sets the baseline: how much working functionality your team ships each month, and what each unit costs you. Weeks 1–3 (readiness and enablement) are reported separately. Weeks 4–12 run on the same repo, comparable tickets and the same team, measured from your git history with the same rules as the baseline. Both periods count everyone's time, ours included: requirements, setup, build, review and rework. We count function points (the ISO-standard unit of working functionality) to the IFPUG standard for both periods and show every count, and any item can be recounted by a certified counter of your choice.

Which Claude Code plan do we need?

You run CraftHQ on your own Claude Code subscription. One shared higher-tier account usually works better than several small ones, because the work runs in parallel and draws on the same allowance. Usage limits reset on a rolling window, so we plan the pilot's workload around it. We'll size it with you on the scoping call.

Where do the tickets come from?

From your tracker. CraftHQ imports the tickets assigned to you from Jira, and from other trackers such as Shortcut through its intake. A plain chat message works too. Each ticket becomes a story with its questions, plan, tests and pull request.

Is there an ideal size for a request?

No. You can ask for a one-line bug fix or a large feature. A larger feature usually takes more back and forth in the questions step before the spec is final.

Is the output maintainable, or AI-generated sprawl?

It lands as normal PRs, following your conventions, through your CI and quality gates. Your engineers review it like any other code.

On the measured project, in the measured 30-day window, 47% of the shipped code is test code (14,600+ automated cases) and 0.19% of changes were reverted. Low reverts alone don't prove maintainability, so the pilot puts it to your engineers directly: can they read, review and change what was delivered?

Does it work with our stack?

Tell us your stack when we scope the pilot. The harness adapts per codebase, so fitting it to your stack is part of the one-time setup. If yours isn't a good fit, we'll tell you before the pilot starts, not after.

Will it fit our branch rules, CI and release process?

Yes. It works inside your flow instead of replacing it.

  • Pull requests go to the branch you choose, such as develop, never straight to main or production.
  • We recommend a rule that requires a pull request and at least one human approval, so nothing is ever pushed directly.
  • Each pull request shows your CI result, so reviewers know the suite passed before they look.
  • Hotfixes, UAT and deploys stay your process.
What happens if we stop?

You keep everything. The code, tests, documentation and ledger of rules are plain files in your repository. There's no runtime dependency on CraftHQ, so your software keeps running. Tests and ledger checks already written keep running in your CI. What stops is CraftHQ building new work and adding new checks.

What does it cost?

Early-adopter pricing for the first 3 months is $3,000 a month for one repo and up to 20 people.

Our target is at least $12,000 of working software a month, 4× what you pay; if we miss it, you can stop at the end of that month. The pilot section below has the details.

We're already building our own setup. Why switch?

Then you know how much of the work is around the model: independent spec-derived tests, defect ledgers, risk triage and review evidence. Run them side by side on the same tickets during the three-month pilot and let the results decide. We'd rather win on measured output than on a pitch.

What about bugs that need real data, and database changes?

Some bugs only show up with real data. For those, we agree a minimal data sample with you first, under the NDA and as set out in the security brief, or your team reproduces the issue for us.

Database migrations are never run automatically. Any change to your tables is flagged in the pull request, for your team to approve and run.

Does it matter which cloud we're on?

No. CraftHQ works whichever cloud your product runs on: AWS, GCP or Azure. If you need it to run inside your own cloud account, raise it when we scope the pilot and we'll assess it before anything is agreed.

Still have questions? Book a 30-minute technical session with the engineer who'd run your pilot.Book a session
The 3-month pilot

Three months. Your repo. Your numbers.

The pilot measures your team operating CraftHQ, and logs every time we step in. Our time counts too.

$3,000per month
Early-adopter pricing · 3-month pilot · one repo · up to 20 people

Our target: at least $12,000 of working functionality a month, 4× what you pay, valued at what the same work costs your team today and measured from your own git history. We report it every month; if we miss it, you can stop at the end of that month.

After the pilot, pricing is per function point (units of working functionality), not per seat or per token. Early-adopter pricing will change.

  1. 01BeforeBaselineA baseline measured from your own git history sets the starting point.
  2. 02Weeks 1–2ReadinessWe bring the code in pilot scope to 95%+ test coverage, with CI and documentation.
  3. 03Week 3EnablementA harness engineer works with your team on how to drive CraftHQ.
  4. 04Weeks 4–12You driveYour team drives CraftHQ with our harness engineer on call, and the same measurement runs again at the end.
For the CEO

What you get

  • A measured before-and-after on your own delivery data, not our benchmark.
  • A go/no-go decision at the end of the pilot, backed by numbers your CTO signed off on.
  • Everything we build stays yours, including readiness work and unmerged PRs.
For the CTO

What you control

  • Pull-request access to one repo, branch protection on main.
  • Your backlog, your CI and your review: nothing merges without your engineers.
  • Your own Claude Code subscriptions. Ours ran 734 pull requests on 3.
  • The success measure, agreed before day one, reviewer hours included.
Before you start

What the pilot needs

Tests are the feedback loop: they let CraftHQ catch its own breakage instead of waiting for someone to test by hand. The closer you are to this list, the sooner your engineers can step back to reviewing.

  1. Target
    95%+ test coverageBelow that, we close the gap in weeks 1–2, before your team takes the wheel: CraftHQ writes the missing tests from your specs, to agreed rules (one behaviour per test, asserted values), and your engineers review them. After that, every new feature arrives with its tests.
  2. Required
    A CI/CD pipelinethat runs the full test suite on every pull request, with branch protection on main. That's where CraftHQ's changes prove themselves.
  3. A plus
    Code documentationUp-to-date docs shorten the one-time fitting step. No docs yet? Tell us at scoping; we’re building a tool that writes verified documentation from your code.
  • Everything is yours. All code, tests, docs and ledger files from the pilot, including tuning work and unmerged PRs. Walk away any time: everything already written keeps running in your CI.
  • Nothing hidden. Every pull request carries its requirement, tests and results, and every trade-off is logged with an owner and a date to revisit it.
Scope your pilot

A 30-minute call agrees the scope and success measure.

Start here

Don't take our numbers. Measure yours.

One repo, three months: delivery speed, review effort and rework, measured from your own git history against your own baseline.

Scope a 3-month pilot