Sign in

Maintenance Package

Keep what you already built running correctly every month, with defined upkeep tasks and a named response time.

Pro simple Service Offers

What it adds

The builder inspects your support tickets, upkeep checklists, and incident history to define an ongoing offer covering routine care of an existing asset: scheduled tasks, monitoring, and a stated response commitment. It converts by pricing peace of mind against the cost of neglect, using a concrete in-scope task list so buyers know exactly what their monthly fee prevents.

What your builder is told to do

8

The actual instructions, in order.
  1. 1

    Read the maintenance checklists and ticket history in the source files and split every task into two groups: scheduled recurring upkeep and reactive incident response. These two groups become the two halves of the offer.

  2. 2

    Publish the scheduled upkeep calendar showing which tasks run weekly, monthly, and quarterly, naming each task in operational terms rather than as a category.

  3. 3

    State the reactive commitment: how issues are reported, the acknowledgement window, and the response window by severity level, using only response times the source files show are actually met.

  4. 4

    Draw the scope boundary hard: list what maintenance covers versus what counts as new work, and describe how new work is quoted, since scope creep is the failure mode of every maintenance agreement.

  5. 5

    Define the reporting rhythm — what the buyer receives each month showing the work performed — because invisible maintenance feels like paying for nothing.

  6. 6

    Explain the pricing model as a recurring fee tied to the size or complexity of the asset being maintained, and name the specific factors that would move the fee.

  7. 7

    Apply breakpoint rules: on mobile show upkeep tasks grouped in collapsible frequency sections with the response commitment pinned at the top; on tablet display the frequency calendar and severity table side by side; on desktop present a persistent left rail listing severity levels with the upkeep calendar and reporting sample scrolling to its right.

  8. 8

    Close with one action — start coverage — and beside it state the coverage start date and the cancellation notice period.

Edge cases it handles

5

The things an agent skips when you only say "build a maintenance package".
  • The asset is already in poor condition — define the remediation step required before ongoing coverage begins and how it is priced.
  • An incident falls outside supported hours — publish the coverage hours and the after-hours policy plainly.
  • The buyer or a third party makes changes that cause failures — state how externally caused issues are handled.
  • Repeated incidents point to an underlying defect — define when maintenance escalates into a recommended rebuild rather than absorbing infinite fixes.
  • A quiet month passes with no incidents — state what the fee bought so the value is visible without failures.

Definition of done

7

Your builder is required to check every one of these before reporting the work finished.
  • Scheduled upkeep and reactive response are presented as two clearly separated halves.
  • Every upkeep task is named operationally with its frequency stated.
  • Severity levels with acknowledgement and response windows are published, drawn from real performance data.
  • The in-scope versus new-work boundary is explicit, with the quoting path for new work stated.
  • A monthly reporting artifact is described so the buyer sees value in quiet months.
  • Mobile collapsible sections, tablet side-by-side, and desktop pinned-rail layouts all behave as specified.
  • The builder reports which source files shaped the upkeep scope and response times, and lists unresolved assumptions.

Related offer files

How it works

  1. 1

    Copy the link

    Grab the Markdown blueprint URL for this offer type.

  2. 2

    Give it to your builder

    Paste it into Claude Code, Cursor, Codex, or whatever AI builder is already working in your app.

  3. 3

    It maps, then builds

    Your agent reads the blueprint first, then builds the offer into your app around the product, audience, and stack.

Works with your stack

These blueprints are written to adapt. They tell the agent to detect your framework, match your existing design system, and use your source files instead of guessing the offer.

Need it tighter than that? Customize the offer file and tell it exactly which source docs and stack to use.