Designing payment around an episodic job search

My contribution: Evaluate the credit model against the episodic-use hypothesis. Revise the paid boundary from capture to selected preparation actions. Connect price explanation, checkout, balance, history and saved-result reuse.

Jobio began with a donation-supported tracking proposition. Later iterations introduced credits for imports and extension saves. As the product moved toward preparation, I revisited both the reason to charge and the tasks that should remain free.

Matching the model to the task

The post-MVP strategy explored a practical hypothesis: job search is episodic. Someone may work intensively on applications for a short period and then stop. A successful search can also remove the need for the product. That made non-expiring credits worth exploring alongside a subscription model.

I treated this as commercial reasoning, rather than proof that users preferred or would pay for it. The important product decision was where the paid boundary belonged. Charging for basic capture discouraged the step that supplies context for everything else. The revised model made saving and organisation free, with credits attached to selected AI preparation actions.

Alternative considered

Require a monthly subscription or keep charging for basic capture. The strategy questioned ongoing commitment for a bursty task, while the revised proposition placed paid value in preparation.

Deliberate choice

Keep capture and tracking free, and use non-expiring top-ups for selected AI preparation actions.

Accepted trade-off

Per-action pricing needs visible costs, balance handling and a clear distinction between reusing a saved result and paying for a new run.

Inspect image and full context

Designing the complete exchange

The credit model required more than a checkout button. Users needed to understand what an action would produce, its prerequisites and its cost before running it. Insufficient balance needed a route to top up. Checkout, balance refresh and transaction history needed to agree about what had happened.

Saved results also mattered. Returning to an existing analysis or application document should be distinguishable from choosing to generate a new one. Otherwise the payment boundary becomes difficult to predict even when the arithmetic is clear.

Inspect image and full context

Keeping the explanation current

The project record contains different proposed and delivered prices, package structures and minimum top-ups. I use those as stages of the decision, rather than copying an old number into a current promise. The application, pricing page and supporting copy needed to follow the same revised boundary, including removal of obsolete extension charges.

I owned the product/commercial reasoning and payment experience with AI-assisted implementation. This establishes practical monetisation work, while revenue, profitability and willingness-to-pay results remain outside the evidence available here.