How big should a ticket be?

A ticket is a brief. How big that brief is, you decide, and that decision affects the result more than any other.

The rule of thumb

A ticket is cut right when you can check its result in one sentence.

"The contact page has a form with three fields, and after sending there is a thank-you." Checkable.

"The site is finished." Not checkable.

If you can say in one sentence how you will recognise that it worked, AdenAI can build it too. If you need three sentences with "and" in them, it is probably three tickets.

Why too big does not work

Everything hangs on one thread. AdenAI breaks your ticket into steps and works through them in order. If it misreads the matter in step three of eight, steps four to eight carry the misunderstanding along. You do not get a partial result, you get a crooked whole, and you have to describe everything again.

Doing it again costs again. You are billed for what a run consumed, and the second run consumes again. A big ticket that goes wrong and has to be repeated therefore costs big twice. Three small ones, of which one goes wrong, cost one small one extra.

Time grows with the steps. How long a run takes depends almost entirely on how many steps are needed. A ticket with twice as many steps runs roughly twice as long. You see it in the ticket: "step 5 of 8".

There is a hard limit. The description may be at most 4,000 characters. The reason is not storage space but that your text goes along again at every single step. With eight steps, a long description becomes eight times the work for everything you wrote. Hitting the limit is not a technical annoyance, it is a hint: take the first point out, make it this ticket, and let the rest be the next one.

Why too small is not good either

The opposite mistake is rarer, but it exists.

Every run has a fixed base: AdenAI looks at the project, plans, builds, serves the preview again. That base applies to "change the heading" exactly as it does to "build the contact page". And credits are billed per ticket, not by effort: five small wishes in five tickets cost five times, the same five in a single ticket cost once.

On top of that, only one ticket runs per account at a time. So ten tiny briefs queue up one after another.

The cut that is usually right

What belongs in one ticket is what shares the same place and the same intention:

On the home page: change the heading, swap the image below it, make the "Enquire now" button green.

That is three moves, but one result, in one place, checkable at a glance.

What belongs apart is what can be right or wrong independently:

Add a contact form and update the prices and start a blog.

Three tickets. They have nothing to do with each other, and if the blog goes astray you do not want to describe the form all over again.

Four signs that you should split

1. Your title contains an "and", and the two halves concern different pages.
2. You are describing something that is only needed later ("and then at some point also...").
3. You notice while writing that you are describing an order: first, then, afterwards.
4. You hit the 4,000 characters.

An example: an online shop

The most common case of "too big at once". Not like this:

Build me an online shop for my ceramics with products, basket, payment, shipping costs, customer accounts, newsletter, blog and Instagram feed.

But in this order, one ticket per line:

1. The frame. Shop for handmade ceramics, home page, about us, contact. Mood, colours, audience. No products yet.
2. The catalogue. These eight products with name, price, description, image. Overview and detail view.
3. Basket and payment. With the shipping options you really offer.
4. Customer accounts, if you need them.
5. The rest. Newsletter, blog, everything else, one each.

The advantage is not only precision. After ticket 1 you can already look and say "not like that", and you can say it before eight products are sitting inside a look you do not like.

Correcting is not a new ticket

When a result is nearly right, write your correction as a comment on the same ticket. AdenAI reads the thread, so it knows both the original brief and your note. A new ticket would have to tell the whole story again.

The ticket jumps back to Offen (Open) by itself and gets worked on once more. See Changing a ticket status.