Diagnose
- Diagnostic and readout (3 business days).
- Fixed quote and written scope within 48 hours.
- You sign, pay the 50% deposit, and grant the access we list in the scope.
Process
How an engagement runs.
The same arc every time. Here is a Revival Sprint, day by day, then how we work with AI, how we handle your access, what you receive, and a sample report.
The Sprint, day by day
Fifteen business days, in four phases.
Understand and plan
- Day 1. Kickoff call. We confirm scope, access and who approves what. You receive your progress link.
- Day 2. Access check and environment setup. We take a backup and create a working branch and a staging copy.
- Day 3. Full security assessment of the existing app. Findings drafted and ranked.
- Day 4. Design direction: two options for the core flow, with a recommendation.
- Day 5. Review call. You choose a direction. The plan is locked.
Revive
- Day 6 to 8. Redesign built in code. Auth, data access and secrets work happens in parallel.
- Day 9. Performance pass. Dependencies updated, unused packages removed.
- Day 10. Mid-sprint review. You click through staging and tell us what to change.
Secure and ship
- Day 11. Revision round on feedback.
- Day 12. Attack pass. We test the revived app the way Atarus tests client systems. New findings are ranked.
- Day 13. Fixes and retest. Every Critical and High finding is fixed or explained.
- Day 14. Production deploy with a rollback plan. Final checks on the live site.
- Day 15. Handover call. You receive the code, the written security report and the runbook. You pay the balance.
Fix window
- 14 days of fixes included. Report a defect and we fix it.
- We delete our working copy at the end of the fix window.
- You can move to Life Support or take everything in-house.
Other engagements follow the same arc at a different scale. A Facelift compresses to 7 business days and skips the attack pass. A Resurrection runs 6 to 10 weeks with a planning phase and a data migration.
AI-augmented engineering, senior human review on every change
How we use AI, and where we do not.
We use AI coding tools because they make us faster at the first draft. Scaffolding, refactors, test generation and routine edits all move quickly. That is why scopes are fixed and timelines short.
A senior engineer owns every change. Nothing merges until a human has read the diff. Security-sensitive areas get a second, explicit review: authentication, payments, data access and anything that touches secrets.
- C-01 · HUMAN
A human is accountable.
Every engagement has a senior engineer whose job is to understand and defend each change.
- C-02 · JUDGMENT
Judgment stays human.
Scoping, architecture, threat modelling and the security findings are written by people.
- C-03 · SECRETS
Your secrets stay out of prompts.
We do not paste keys, credentials or customer data into AI tools. Tools run on settings that keep your code out of model training wherever the tool allows it.
- C-04 · HONESTY
We say so.
Most of the apps we revive were built with AI and shipped without review. We believe in the tools. We do not believe in skipping the review.
Access and credentials
Minimum access, in writing.
You are trusting us with the inside of your product. This is how we handle that, and it applies to every engagement. The intake form never asks for passwords or keys.
Roles, not owner accounts.
We ask for a limited role on the repo, hosting team or database project. Never your primary account password.
Separate, narrow keys.
Where a key is needed, you create a new one for us with the smallest permissions that work, and delete it afterward.
Nothing sensitive by email or chat.
If a secret has to move, we use an end-to-end encrypted, expiring share.
Staging first.
Changes go to a branch or staging environment before production.
Backups before changes.
We confirm your data can be restored before we touch anything that holds it.
Revoke and rotate.
At handover you revoke our access. If we saw an exposed secret, we help you rotate it.
NDA on request.
Mutual, signed before you share anything sensitive.
What you receive
At handover, you hold all of this.
The code and design files.
All of it, yours on payment.
A written security report.
What we checked, what we found, what we fixed, what remains and why. See the sample below.
A runbook.
How to deploy, roll back, rotate keys and recover.
A handover call.
We walk your team through the work.
Fix window.
14 days after a Sprint, 30 days after a Resurrection, 7 days after a Facelift or Pre-Sale Revival.
A clean exit.
We revoke our access, delete our working copy and confirm in writing.
Sample report
This is what the report looks like.
Every Revival Sprint and Resurrection ends with a report like this one. It uses the same severity language Atarus uses for client work: Critical, High, Medium, Low. Status is either Fixed or Open.
SAMPLE. Example App Inc. is fictional. Findings are illustrative and written to show format and depth.
31Score before
88Score after
6Findings
5Fixed
F-01
Row-level security disabled on the invoices table
Impact. Any signed-in user could read every customer's invoices, including names, addresses and amounts, by calling the public API directly. Fix. Enabled row-level security. Added policies that limit rows to the owning account. Verified with a non-admin test user.
CriticalCritical
F-02
Service-role key exposed in the client bundle
Impact. The key bypasses all access rules. Anyone who opened the browser developer tools could read or change any record. Fix. Removed the key from client code. Moved privileged calls to a server function. Rotated the key and invalidated the old one.
CriticalCritical
F-03
Missing authorization check on /api/export
Impact. A user could change the account ID in the request and export another team's schedule data. Fix. Added a server-side ownership check on every export request. Added an automated test that fails if the check is removed.
HighHigh
F-04
No rate limiting on sign-in and password reset
Impact. Attackers could attempt unlimited password guesses and flood users with reset emails. Fix. Added per-account and per-IP limits, with progressive delays and generic error messages.
MediumMedium
F-05
Content Security Policy and HSTS missing
Impact. Injected scripts would run unchecked, and first visits could be downgraded to plain HTTP. Fix. Shipped a strict Content Security Policy, HSTS with preload, and the standard hardening headers. Verified with automated checks.
MediumMedium
F-06
Verbose error messages in an internal admin route
Impact. Stack traces reveal framework and library versions to anyone with admin access. Fix. Replace with generic messages and move detail to logs. Scheduled for the next maintenance window, with no exposure to non-admin users.
LowOpen
What we checked: authentication and sessions, authorization, data access rules, secrets, input handling, dependencies, headers and transport, payments webhooks. What to monitor next: dependency advisories, key rotation every 90 days, quarterly re-scan. This report describes the app at a point in time. It is not a guarantee that no vulnerabilities exist.
Next step
Find out what is wrong before it finds you.
A Diagnostic is a one-page diagnosis and a 30-minute readout, in three business days. $490, credited in full toward any engagement booked within 30 days.