On a running system instead of slides

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.

Also the way to a paid plan

If you just want to try it, you do not need this conversation: the free plan is open without any detour, and the "Start for free" button on the other pages leads exactly there.

For a paid plan it is different. The pricing page says it itself: the owner of an organisation does set the model tier in the settings, but there is no self-service checkout in the cockpit yet. The way there is therefore the same today as the way to a demo — an email, a conversation, then the setup. We write that down instead of hiding it behind a button that triggers nothing.

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 no JavaScript and loads nothing from foreign servers; 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.