Three ways.
One front door.
Every engagement starts with the same free assessment. It ends with a recommendation in your customer's IT team's own words, and one of three ways. You can move up a way later, through the same gate; the rules we wrote down carry forward unchanged.
- Free assessment
- Non-critical · Important · Critical
- Report · Both SLAs
The Report.
The document your customer's IT team needs to decide about an AI-built app that stays where it is and stays with you. Sold as a product with a fixed fee, not as an open-ended audit.
It doesn't repeat what your builder's own security scan already finds. It reads the scan's output and goes past it: double-submits, retried payments, who can reach whose data, and what happens when it breaks. Where the honest answer is “not yet”, the summary says so.
What you get
- Every rule your app follows, written down and signed by you, including the ones nobody wrote
- The seven answers for their IT team, for this app, with the “not yet”s
- A fix list you run yourself, as prompts in your own tool, in order of impact
- A confirmation pass: we re-read the app after your fixes and update the summary
Credited against either SLA if you move up within six months.
Add Standby and there's someone to call in business hours.
Standby.
Your app stays where it is, with you. The Report says what it does and where it stands. Standby means that when something goes wrong, there's someone to call who already knows the app.
A small monthly fee with a block of hours included; hours beyond it at an agreed rate. Cancel at a month's notice.
What you get
- We watch the app from outside: is it up, is it answering
- A named person at Vibe Assured, for you and for your customer
- A response in business hours, with a target in writing
- Fixes you ask for, made in your own tool, from the hours block
- A re-read of the app each quarter and a refreshed summary for your customer
What it isn't
- Not an SLA: we don't run the app, so we don't guarantee its uptime or behaviour
- Not out-of-hours cover; a non-critical app can wait until morning
- Not custody: your builder's platform still hosts it and publishes it
- Paused while a critical finding from your builder's own scan stays open
Need more than this? The Standard SLA is the step up: we take custody, every change passes our gate, and it runs under a service agreement your customer signs.
The Standard SLA.
We take custody of production, and you keep building in the tool you built it in. Your code repository, hosting, production database and domain move into our hands. Your builder's publish becomes your preview. Every change you make reaches production by pull request, through our checks and one engineer's review, usually within hours.
We can't stand behind what we don't control, so the Standard SLA only exists where we hold all four. If you'd rather keep the keys, the Report with Standby is the honest alternative.
We're taking first clients for the Standard SLA by arrangement. Talk to us.
What we run
- The gate: build, migration checks, access-rule tests, server-code review, a secrets scan, and your recorded journeys replayed against every change
- Hardening at setup: access rules on every table, keys rotated, public storage closed, server code reviewed against our rules
- Monitoring with alerts to our team, daily backups, a restore test each quarter with the result reported
- Incident response within the SLA, a written note after each one, a monthly posture note
- Exit on request: a full export and verified deletion within the notice period
What the SLA excludes, in writing: changes that never passed the gate, your builder's platform outages, and features you haven't built yet. If your app's backend lives inside your builder's cloud, moving it is part of setup; we'll tell you what that involves before you sign.
The Enterprise SLA.
Your app rebuilt properly, piece by piece, outside the tool you built it in, to the rules you signed. Each piece is checked against a recording of your original before it goes live. It runs on its own instance, in a region your customer chooses, and we run it for you. It's your IP, independently built.
We propose it only when the assessment finds something the other two ways can't carry: restricted data such as money or health records, a residency requirement, heavy background work, a tenancy model the data design can't be bent to, or a customer who needs an SLA with behaviour guarantees. Most apps don't need it, and we'll say so.
What you get
- The foundation: hosting, sign-in, security, monitoring, backups
- Each area of your app, rebuilt and proven against the recordings
- Everything the assessment found, fixed
- Your own instance, run under an SLA; a governance pack for their auditors
- Changes in plain words, each one proven before it ships
Paid in milestones. Where your customer pays, the quote goes to them with the assessment's constraint finding attached, so they see why the other ways weren't enough.
We're taking first clients for the Enterprise SLA by arrangement. Talk to us.
What each way carries.
| Their question | Report | Standard SLA | Enterprise SLA |
|---|---|---|---|
| Where does our data live? | Where it is today; the summary says where | A database we hold, in a region we choose with you (not yet in South Africa) | Its own instance, in a region of your choice |
| Who can reach it? | The rules written down and signed; gaps named | Access rules tested on every change | Checked by the server on every request, and by the database again |
| What happens when it breaks? | Your builder fixes it. With Standby, someone to call in business hours | Monitored, incident response under the SLA in business hours; out-of-hours cover as an option | The same, on an instance built to our standard |
| Who supports it? | Your builder; or Standby | Vibe Assured, under an SLA you sign | Vibe Assured, under an SLA you sign |
| Can we audit it? | The signed rules and the summary, dated | Every release gated; a monthly posture note | A governance pack per release |
| Can we leave with our data? | As your builder's platform allows | Full export and verified deletion, in the contract | Full export and verified deletion, in the contract |
| Is it secure? | Your builder's scan, plus what we found beyond it | The scan, plus our review and tests on every change | Built to our written standard, reviewed every release |
Which way fits?
Who decides the tier?
Your customer's IT team, in their own language. The assessment recommends one, with the reason; they confirm it. If they call the app non-critical, that's a Report, and a perfectly good outcome.
Can we start small and move up?
Yes. The rules we write down at the Report are the first thing both other ways need, so the Report's fee is credited if you move up within six months. The move goes through the same gate.
Why wouldn't you recommend the Enterprise SLA?
Because most apps don't need it. A working app your customer calls non-critical or important is better served, and better priced, by the Report or the Standard SLA. We propose the Enterprise SLA only with a constraint we can name.
My app was built a while ago. Does the Standard SLA work for it?
The Standard SLA needs the newer kind of app your builder makes now, where the server code lives in your repository. Older apps get the Report and Standby; your builder can upgrade the app in place, and then the Standard SLA is open to it.
Find out which way your app needs.
The assessment is free, and it ends with a recommendation, not a sales call.