After launch

Who fixes a bug found after launch if I am not on a Live Mode plan?

We do, for the first 30 days. Every official launch comes with a 30-day warranty: if something we shipped does not work the way we demoed it, we fix it at no charge. A change is different from a defect; new or altered behavior is scoped as new work. On day 31, your app moves to the entry level of Live Mode, unless you tell us before then that you would rather not. That way there is never a week where nobody is looking.

A pilot or beta is different. It is a work in progress, and testing and support are part of the work, so there is no warranty clock. Your pilot agreement says what support looks like during that stretch; the warranty starts when the real launch does.

What does maintenance actually cover, and what does it not?

Maintenance is the work that keeps a working app working. It is not a budget for new things.

Covered: framework and language updates, security patches, dependency upgrades, keeping up with operating system and app store requirements, error monitoring, and backups.

Not covered: new features, redesigns, and refactors you have asked for rather than ones the platform forced. Those are scoped as work, on whatever mode you are in. Which of the covered items applies to you depends on your level, and your agreement says which.

What is the difference between monitoring, maintenance, and fixes?

They are the three Live Mode levels, in order, and each one adds to the one before it.

Monitoring means we know when something is wrong and we tell you. Maintenance adds keeping the app current as the platforms underneath it change. Fixes means we do the work when something breaks, rather than reporting it and quoting it.

The current names and what each includes are on the Services page, which renders them from the same source we do, so it is never out of date.

How do I know if something breaks before my users tell me?

Error monitoring and uptime checks run against the apps we operate, and they alert us within about a minute. In most cases you hear from us before you hear from a user.

This is true of the apps wired to our monitoring, which is not automatically every app we have ever built. If you want to know whether yours is, ask.

How do app store and OS updates get handled?

Apple and Google change requirements on their schedule, not yours. We track those deadlines and do the work before the deadline rather than after a rejection.

When an update needs your users to move, you choose how hard to push: a forced update that blocks the old version, or a soft nudge that lets people finish what they are doing. We will tell you which one the situation calls for, but it is your call.

What about my AI API bill?

We watch usage alongside everything else and flag anything unusual.

Spending caps and a fallback to a cheaper model are things we set up when we build an AI feature for you, so which of them your app has depends on what we built. Ask and we will tell you.