Warranty & Support

30-day warranty + /hr on-demand after — no retainers

Version 1 · June 29, 2026 pricingdelivery

Content

# Warranty & Post-Warranty Support

_Parent: Pricing & Engagement_

How we handle bugs after go-live — and what the long-tail looks like.

## The 30-day warranty

Starts the day they go live.

**Included at no charge during warranty:**
- New vendor email format we haven't seen
- API hiccup from a source system
- Edge case the test data missed
- Bluebeam template tweak that breaks invoicing
- Any bug attributable to our build

**Not included (would be a separate quote):**
- New scope (a new workflow, a new source system, a new output)
- Major scope changes (e.g. switching from Sage to Foundation)
- Changes to their internal processes that require automation reconfiguration

## After day 30

| Engagement | Rate / cost |
|---|---|
| On-demand bug fix or small enhancement | **$225/hr**, no minimum |
| New workflow | **$25K base** (Foundation already paid, so no $22K re-charge) |
| Major scope change on existing workflow | Custom quote |

**No retainer. No monthly minimum. No SaaS subscription.**

## Why we don't push annual maintenance retainers

Lock-in retainers undermine the "you own everything" pitch. We'd rather have customers come back hungry for the next workflow than feel trapped paying us monthly for a system that runs fine.

In practice: most customers go entire years between calls, and when they do come back it's usually to add a new workflow, not fix the first one.

## How to position warranty + support to the prospect

> "30 days of free bug fixes after go-live — anything that breaks because of us, we fix at no charge. After that, you only pay when you want something — $225 an hour, no retainer, no monthly fee. You own the system. Most of our customers go a year or more without needing us, and when they do come back, it's to add the next workflow."

## What to do if they want a stronger SLA

Some larger prospects will push for things like 99.9% uptime guarantees. We don't offer those because:
- We don't control the underlying infrastructure (their Azure / Microsoft 365)
- The system runs in their tenant, not ours

What we DO offer: **monitoring and alerting baked into the build**. If something breaks at 2am, our monitoring catches it and they get a Teams notification. They know before their team notices.

That's usually enough.

---
_Last updated: 2026-05-24_

Change notes (optional)

Cancel