Walk through your use case

What we show

Whether a demo is useful comes down to one thing: can someone, at the end, place what the system does and what it does not do. Four things belong on the table for that.

A job from start to finish

A requirements text becomes a graph of atomic work steps, the work steps become commits, and at the end there is a repository. That is the part you have to have seen once to place everything else.

Where a human steps in

Which point waits for someone and which runs straight through can be configured per project. Without a set level, the job runs through — that is the default, and it belongs in a demo because it is often expected to be otherwise.

What a run costs

Where the costs of a run become visible and which caps can be set. Without a set amount, none applies — the default is unlimited, and that is exactly what the conversation is worth having about.

Hosted or self-operated

The difference decides who owns operations and data and who holds the switches. Much of what is switched on in the hosted service is off in the shipped default; we go through which features those are.

There is no script for this. What we show depends on what you bring — hence the next section.

What you should bring

A demo becomes useful the moment it hangs on your case rather than ours. None of this is a prerequisite; all of it makes the conversation shorter and the answers more concrete.

A requirement you actually have

A ticket, a paragraph from a concept, a piece of backlog. A real text shows what the decomposition delivers and where it asks back — an invented one only shows that it was invented.

Where you work

Do you plan and review in tickets, in pull requests, or in both? That determines where the system fits into your process instead of demanding a new one.

The question that blocks you

A security review, an operational requirement, a question about data sovereignty. If it is on the table beforehand, we can show the answer together with the place it hangs on — or say that we do not have it.

Who is reading along

Whether someone from operations or security is present changes what we talk about. Both are welcome; it just helps to know beforehand.

The same details help if you are writing for another reason — thecontact page sums them up in one paragraph.

Access and tariff selection

To request access, join the waitlist. Before starting a task, review the subscription and usage costs, including any external model-provider charges.

A paid tariff no longer needs this conversation either: the organisation's owner books subscription and credit in the cockpit, payment runs through a payment provider — thepricing page describes the state of things. The conversation remains for what a checkout cannot answer: security questions, operating model, Enterprise.

How to reach us

Write to hello@halvic.ch. One line about what you are building and one about what you want to know is enough to start — the rest follows from what is written above.

There is deliberately no booking tool here and no third-party calendar. This website executes nothing from foreign servers and runs no script besides its own navigation; an embedded scheduling calendar would be both at once. What you write to us, you write from your own mailbox to an address that is listed in the legal notice.

What is deliberately missing on this page is a promise about how fast we answer or how long an appointment takes. Such sentences are quickly written and bind a company, not a system: there is no on-call duty here and no promised availability, so no number is stated either. We prefer to keep it as on the rest of this site — what is not covered is not claimed.