THE COMPLETE PRODUCTION HARDENING SCOPE
A complete view of the engineering work included in your Production Hardening Sprint—from access control and billing to deployment, recovery, and the technical due diligence pack.
123 included deliverables · 13 engineering areas
$2,500 fixed price · 10 working days · One codebase
For each deliverable, you can see the work we do, the business problem it addresses, and the evidence we provide at handover.
We inspect the existing implementation, correct what is incomplete or unsafe, and build the missing controls. Work that is already correct is tested and recorded rather than replaced unnecessarily.
The scope follows your application. A control that does not apply to the product is marked with a written reason—for example, subscription reconciliation in an application with no subscriptions. This is never used to move an included item into a paid upgrade. Missing safeguards on an existing feature are part of the work.
Your final report records every item as verified or not applicable with a reason. Any unresolved applicable item remains visible and unfinished until it is corrected and retested.
Browse the areas below or search for a specific deliverable.
No matching deliverables. Try another term or browse the 13 areas below.
Give every user the right access, and keep privileged actions protected.
11 deliverables · All included
What we deliver: Review and fix signup, login, logout, password reset, email verification, and OAuth callbacks.
Why it matters: Broken account flows can lock out customers or allow unauthorized access.
How we verify it: Exercise successful, rejected, expired, and reused-token paths for each supported flow.
What we deliver: Verify expiry, refresh, and session revocation on logout and password change.
Why it matters: An old session can remain usable after an account owner tries to secure it.
How we verify it: Confirm expired and revoked sessions cannot continue accessing protected resources.
What we deliver: Enforce permissions on every protected route, API endpoint, and server action.
Why it matters: A hidden button does not prevent a direct request to the backend.
How we verify it: Call protected actions directly as unauthorized and underprivileged users; confirm rejection.
What we deliver: Implement and test Row-Level Security or equivalent server-side scoping across all tables, with explicit rules for intentionally public data.
Why it matters: Missing data boundaries can expose one customer's records to another.
How we verify it: Run read and write tests as anonymous users, different roles, and separate tenants.
What we deliver: Restrict admin routes and operations to explicit, verified roles.
Why it matters: Unprotected administrative actions can let ordinary accounts change or delete important data.
How we verify it: Test administrative operations using both authorized and ordinary accounts.
What we deliver: Implement rate limits and brute-force protections on authentication and recovery endpoints.
Why it matters: Automated login attempts can compromise accounts or overwhelm account services.
How we verify it: Simulate repeated attempts and verify limits, responses, and normal-user recovery.
What we deliver: Write a one-page matrix defining roles and their permitted actions.
Why it matters: Ambiguous permissions create inconsistent behavior as the product grows.
How we verify it: Compare the role matrix with tested backend permissions.
What we deliver: Build the account deletion flow, covering related records and stored assets under the documented retention rules.
Why it matters: Removing a profile alone can leave personal data scattered through the system.
How we verify it: Delete a seeded account and inspect its related records, files, and recorded retention exceptions.
What we deliver: Provide session listing and a way to sign out across all active sessions.
Why it matters: Users need a way to remove access from lost devices or unfamiliar sessions.
How we verify it: Create multiple sessions, revoke them, and confirm protected access stops.
What we deliver: Log role changes, deletions, and billing changes with the actor, action, and time; protect access to the log.
Why it matters: Important changes are difficult to investigate without a reliable activity record.
How we verify it: Trigger the listed actions and verify accurate, access-controlled audit entries.
What we deliver: Enforce a second factor on every owner and admin account, in the application and on every provider dashboard behind it, with recovery codes stored in the owner's vault.
Why it matters: One leaked password on a dashboard account is a full takeover of the product and its data.
How we verify it: Attempt sign-in to each owner and admin account without the second factor and confirm it is refused.
Keep privileged credentials out of browsers, repositories, and accidental test activity.
9 deliverables · All included
What we deliver: Remove all private secrets from frontend code and downloadable bundles, relocating their use to server-side code.
Why it matters: Exposed private credentials can let others access services using your permissions.
How we verify it: Scan source and built assets and inspect browser traffic for private credentials.
What we deliver: Scan Git history for committed secrets and rotate every exposed credential found.
Why it matters: Deleting a secret from the latest commit leaves earlier copies accessible.
How we verify it: Retain scan results and confirm exposed credentials have been invalidated and replacements work.
What we deliver: Verify service-role and administrative keys are used exclusively in protected server environments.
Why it matters: Administrative keys can bypass the data protections intended for ordinary users.
How we verify it: Check runtime configuration, built assets, and each code path using administrative credentials.
What we deliver: Separate development, staging, and production variables, databases, and keys; document the configuration inventory.
Why it matters: Testing with live credentials can affect real customer data and transactions.
How we verify it: Inspect environment mappings and confirm staging actions stay within staging services.
What we deliver: Move private AI, email, SMS, and other service keys server-side and implement usage caps.
Why it matters: Abused endpoints can consume paid services on your account.
How we verify it: Test unauthorized calls, per-user limits, and configured usage ceilings.
What we deliver: Document how to rotate each key, update its dependents, verify the change, and recover from a failed rotation.
Why it matters: An urgent rotation becomes harder when nobody knows which services depend on a key.
How we verify it: Rehearse rotation with a test credential and record the affected services and checks.
What we deliver: Configure spend or usage alerts for every metered API, using provider alerts or application-side measurement.
Why it matters: Unexpected consumption can continue unnoticed until the next invoice.
How we verify it: Trigger a test threshold and confirm the alert reaches the designated owner.
What we deliver: Move every service the product depends on (database, hosting, payments, email, AI, domain) into an account the founder owns, with the founder as the owner role, billing in the founder's name, and any previous builder removed.
Why it matters: AI-built apps are often wired to accounts the builder created. The business does not control what it does not own.
How we verify it: Produce an inventory listing each provider, the owning account, the owner role holder, and the date the previous builder's access was removed.
What we deliver: Review and harden the settings of every managed service in the stack: auth policies, storage access rules, privileged keys kept server-side, and a plan tier adequate for backups and recovery.
Why it matters: Managed platforms ship permissive defaults so that prototypes work. Those defaults are what leaks data in production.
How we verify it: Record the before-and-after settings for each managed service, naming each risky default and its new value.
Protect the application's public entry points and test them from an attacker's perspective.
12 deliverables · All included
What we deliver: Validate every data-writing endpoint with explicit schemas and safe input/output handling, including injection defenses.
Why it matters: Malformed or hostile inputs can corrupt records or reach other users' screens.
How we verify it: Submit invalid and hostile payloads and confirm safe rejection or handling.
What we deliver: Validate upload types and sizes, enforce bucket permissions, and protect access to stored files.
Why it matters: Weak upload and storage controls can expose documents or accept unsafe files.
How we verify it: Test disallowed formats, oversized files, unauthorized downloads, and storage listings.
What we deliver: Restrict CORS to intended origins and check credentialed request behavior alongside authentication and request-forgery protections.
Why it matters: Overly permissive cross-origin access can expose authenticated responses to untrusted websites.
How we verify it: Test approved and unapproved origins, credential handling, and state-changing request protections.
What we deliver: Configure and test CSP, HSTS, framing restrictions, and other appropriate browser security headers.
Why it matters: Missing browser protections can increase exposure to script injection, framing attacks, or insecure connections.
How we verify it: Inspect response headers and exercise the application to confirm intended protections without broken flows.
What we deliver: Audit dependencies, upgrade or remove known-vulnerable packages, and remove unused packages.
Why it matters: Published package vulnerabilities can remain reachable in an otherwise functional product.
How we verify it: Record the dependency scan, remediation, and regression checks after changes.
What we deliver: Protect public forms, signup flows, and resource-consuming endpoints with appropriate limits.
Why it matters: Abuse can create spam, availability problems, and unexpected service bills.
How we verify it: Simulate bursts and verify enforcement without blocking ordinary use.
What we deliver: Review the application against the OWASP Top 10 and record findings, fixes, and evidence by category.
Why it matters: Unexamined application risks leave preventable weaknesses in the production foundation.
How we verify it: Deliver category-level results and supporting test evidence, with justified non-applicable cases identified.
What we deliver: Add bot protection to public forms using Turnstile, hCaptcha, or an appropriate equivalent.
Why it matters: Automated submissions can pollute accounts, reporting, and outbound communication.
How we verify it: Confirm valid users can submit and rejected or missing bot challenges are handled safely.
What we deliver: Publish security.txt and a monitored disclosure contact for vulnerability reports.
Why it matters: A researcher needs a clear way to report an issue to the right person.
How we verify it: Check the published file, contact details, and delivery of a test message.
What we deliver: Test the five highest-risk externally reachable attack surfaces, remediate findings, and deliver the methods and evidence.
Why it matters: Implementation review alone may miss behavior exposed through real attack paths.
How we verify it: Record the five surfaces, authorized tests, findings, fixes, and retest outcomes. AxonBuild performs this targeted test.
What we deliver: For every model-backed feature: prompt-injection defences, validation of model output before it touches data or users, per-user usage limits, and a timeout with a fallback when the provider is down.
Why it matters: Model calls are a new input surface. Unbounded ones leak data, run up bills, and fail loudly when the provider does.
How we verify it: Run injection test cases against each feature, a spend simulation that hits the limit, and a provider-outage simulation in staging.
What we deliver: Place a CDN or web application firewall in front of the origin, with rate and abuse rules that absorb floods before they reach the application.
Why it matters: Application-layer bot protection never sees a volumetric flood; it takes the app down first.
How we verify it: Send a load burst at the edge and confirm it is absorbed while the origin's health endpoint stays green.
Keep records consistent, queries efficient, and recovery practical.
14 deliverables · All included
What we deliver: Review and correct types, nullability, foreign keys, uniqueness rules, and cascade behavior.
Why it matters: Inconsistent relationships create broken workflows and unreliable reports.
How we verify it: Test rejected invalid records and expected relationship behavior using representative data.
What we deliver: Review every foreign key and hot query path with execution plans and implement appropriate indexes.
Why it matters: Missing useful indexes can make ordinary requests expensive as data grows.
How we verify it: Retain before-and-after query plans and timings; document the index decisions.
What we deliver: Replace repeated per-record lookups with appropriate joins, batching, or prefetching.
Why it matters: Fetching a list can create unnecessary database traffic and slow responses.
How we verify it: Measure database query counts for representative list and detail views.
What we deliver: Wrap related database changes in transactions and protect workflows spanning several writes.
Why it matters: A partial operation can leave users, orders, or workspaces in inconsistent states.
How we verify it: Inject a failure between writes and verify atomic rollback or the documented recovery behavior.
What we deliver: Configure connection pooling or the platform's equivalent connection management and test it under load.
Why it matters: Connection exhaustion can make the database unavailable during busy periods.
How we verify it: Run concurrent requests and record connection usage, errors, and pool configuration.
What we deliver: Move schema changes into ordered migrations committed to the repository.
Why it matters: Untracked dashboard changes make environments difficult to reproduce and maintain.
How we verify it: Apply the migration sequence to a clean test database and compare the resulting schema.
What we deliver: Verify automated backups, set retention, and perform a real restore test.
Why it matters: A backup only helps if it exists and can be restored successfully.
How we verify it: Restore a backup into an isolated environment and check representative data integrity.
What we deliver: Standardize event timestamps in UTC and document local-date and display-time behavior.
Why it matters: Inconsistent time handling can distort billing schedules, reporting, and user expectations.
How we verify it: Test timestamps across time zones and relevant date boundaries.
What we deliver: Implement soft deletion where the product needs recovery, consistently with account-erasure and retention rules.
Why it matters: Accidental deletion should be recoverable where the business workflow requires it.
How we verify it: Delete and restore a test entity and verify normal queries exclude deleted records.
What we deliver: Provide a repeatable seed script with realistic non-sensitive test records.
Why it matters: An empty staging system gives the team little opportunity to test realistic workflows.
How we verify it: Run the seed process on a clean staging database and exercise core flows.
What we deliver: Identify and clean abandoned records and broken relationships with documented safeguards.
Why it matters: Unnecessary data complicates exports, reporting, maintenance, and storage.
How we verify it: Run a dry-run comparison and confirm the cleanup preserves valid linked records.
What we deliver: Restore the application and data into a fresh environment, time the recovery, and document the procedure.
Why it matters: Your team needs evidence of recovery time before a real incident.
How we verify it: Record the timed drill, recovered services, integrity checks, and observed recovery limits.
What we deliver: Deliver a readable diagram of entities, relationships, and ownership boundaries for the data room.
Why it matters: Technical reviewers and future engineers need a quick way to understand the data.
How we verify it: Compare the diagram against the delivered schema and migrations.
What we deliver: Use signed, expiring links for private files, enforce size and type limits, scan user uploads for malware, and set a retention rule for uploads.
Why it matters: File buckets are the most common place an AI-built app is publicly readable without anyone noticing.
How we verify it: Fetch a private file without a signed link and confirm refusal; upload an oversized and a disallowed file and confirm rejection. Upload a safe malware-scanner test file and confirm rejection. Verify that expired uploads are removed according to the configured retention rule.
Keep payment events, subscriptions, and product access in agreement.
10 deliverables · All included
What we deliver: Verify the payment provider's signatures before processing webhook payloads.
Why it matters: Forged events can wrongly grant paid access or change account state.
How we verify it: Confirm valid events succeed and invalid or altered payloads are rejected.
What we deliver: Make every webhook handler safe to repeat, including concurrent delivery and its downstream side effects.
Why it matters: Repeated events can duplicate fulfillment or corrupt subscription state if processed unsafely.
How we verify it: Replay and concurrently deliver events; confirm one intended business effect.
What we deliver: Handle creation, updates, cancellation, payment failure, refunds, and disputes, including delayed or out-of-order events.
Why it matters: Missing lifecycle handling can leave paid access inconsistent with billing.
How we verify it: Test the relevant lifecycle transitions and verify the final account state.
What we deliver: Enforce paid-plan permissions and usage limits in backend actions.
Why it matters: Client-side plan labels alone do not protect paid functionality.
How we verify it: Attempt paid operations with free, expired, and valid paid accounts.
What we deliver: Verify test and live credentials are isolated by environment.
Why it matters: Misconfigured environments can process real charges during testing or accept no real payments in production.
How we verify it: Inspect provider accounts and run isolated test-mode transactions.
What we deliver: Compare the application's billing records with the payment provider and correct mismatches.
Why it matters: Undetected drift creates access and revenue-reporting inconsistencies.
How we verify it: Seed mismatched records and verify they are identified and reconciled correctly.
What we deliver: Implement grace periods and dunning messages consistent with the product's billing rules.
Why it matters: Payment failures need a clear recovery path for customers and predictable access behavior.
How we verify it: Simulate payment failure, notice delivery, recovery, and grace-period expiry.
What we deliver: Connect Stripe Customer Portal or the existing provider's equivalent for invoices, card changes, and supported plan management.
Why it matters: Routine billing changes otherwise require manual support.
How we verify it: Test an authenticated customer's portal access and resulting updates in the application.
What we deliver: Run recurring reconciliation and alert the team to billing discrepancies.
Why it matters: A one-time check will not catch drift introduced after future changes.
How we verify it: Execute the scheduled job against test mismatches and verify its alert and output.
What we deliver: Document refunds, complimentary access, and dispute handling in the application's payment setup.
Why it matters: The team needs clear procedures when a billing question becomes urgent.
How we verify it: Walk through the procedures in test mode and identify the responsible account permissions.
Keep failures visible, recoverable, and contained.
10 deliverables · All included
What we deliver: Remove swallowed failures and empty catch blocks, replacing them with deliberate recovery or useful error reporting.
Why it matters: Silent failures can make an unsuccessful operation look complete.
How we verify it: Inject failures and verify accurate responses and diagnostic records.
What we deliver: Implement global backend error handling and frontend error boundaries with clear recovery states.
Why it matters: A localized failure should not leave the customer with an unexplained blank page.
How we verify it: Trigger server and component errors and confirm safe responses and contained UI failures.
What we deliver: Install error tracking such as Sentry with protected source maps, environment labels, and alerts.
Why it matters: Customer complaints should not be the only way you discover application faults.
How we verify it: Send a test error and verify symbolication, environment attribution, and alert delivery.
What we deliver: Set deliberate timeouts for AI, email, payment, and other external calls.
Why it matters: Slow providers can leave requests and workers waiting indefinitely.
How we verify it: Simulate a slow dependency and confirm bounded waits and a useful failure state.
What we deliver: Add bounded retries with backoff to transient failures where repeating the operation is safe.
Why it matters: Temporary failures need recovery without creating duplicate actions or retry storms.
How we verify it: Simulate transient and persistent failures and verify retry limits and side effects.
What we deliver: Move long-running AI generation, exports, and bulk communication into background jobs.
Why it matters: Lengthy work can exceed request limits or be interrupted when a browser disconnects.
How we verify it: Run a long task beyond the normal request window and verify completion and user-visible status.
What we deliver: Make jobs idempotent and provide a dead-letter or failed-job path with a recovery procedure.
Why it matters: Retries can duplicate actions, while discarded failures leave work unfinished.
How we verify it: Replay jobs, exhaust retries, and verify one intended result plus a recoverable failure record.
What we deliver: Keep unaffected functions usable when an external service is unavailable.
Why it matters: One provider outage should not unnecessarily block the entire application.
How we verify it: Disable an integration and check its fallback plus unaffected customer journeys.
What we deliver: Provide a safe health endpoint reporting the readiness of required services without exposing secrets.
Why it matters: Monitoring needs a reliable signal for whether the application can serve requests.
How we verify it: Check healthy and degraded responses and confirm sensitive details are not public.
What we deliver: Simulate AI or payment-provider failure in staging and verify the expected recovery behavior.
Why it matters: Fallback code needs to be exercised before customers depend on it.
How we verify it: Record outage scenarios, queue behavior, customer messages, and recovery results.
Make releases repeatable and give the team a tested way back.
13 deliverables · All included
What we deliver: Provide development, staging, and production with separate databases, credentials, and configuration.
Why it matters: Routine tests should not change real customer records or trigger live transactions.
How we verify it: Verify service isolation and perform a staging action without a production side effect.
What we deliver: Protect the main branch with required checks and controlled merge permissions.
Why it matters: Unchecked changes can otherwise bypass the release process.
How we verify it: Attempt a failing merge and confirm the protection prevents it.
What we deliver: Run linting, type checks, builds, and tests on every pull request.
Why it matters: Automated checks catch regressions before changes reach customers.
How we verify it: Submit failing and passing changes and retain the CI results.
What we deliver: Automate staging deployment and require an explicit promotion step for production.
Why it matters: A repeatable release path removes reliance on one person's manual routine.
How we verify it: Deploy a change to staging, then demonstrate the production promotion gate.
What we deliver: Integrate database migrations into the deployment process with ordering and compatibility checks.
Why it matters: Application code can fail when its expected schema is missing or incompatible.
How we verify it: Deploy a representative schema change and verify sequencing and failure handling.
What we deliver: Document and rehearse release rollback, including how database changes are handled safely.
Why it matters: A failed release needs a recovery path the team has already practiced.
How we verify it: Roll back a test release and verify application behavior and retained data.
What we deliver: Provide browser-accessible preview deployments for pull requests with isolated test configuration.
Why it matters: Reviewers need to inspect a change before it joins the release branch.
How we verify it: Open a preview from a test pull request and verify its environment isolation.
What we deliver: Provide a short contributing guide and a template covering the change, verification, and release considerations.
Why it matters: Consistent review information makes future development easier to assess.
How we verify it: Create a pull request using the template and follow the guide on a clean checkout.
What we deliver: Configure Renovate, Dependabot, or an equivalent to propose dependency updates with checks.
Why it matters: Routine security and maintenance updates need a repeatable path to review.
How we verify it: Verify an update proposal triggers the appropriate CI checks and review requirements.
What we deliver: Optimize and document the deployment pipeline to complete a representative release in under ten minutes.
Why it matters: A slow release process delays delivery of urgent fixes.
How we verify it: Time the agreed deployment path and record its start, finish, and included steps.
What we deliver: Keep the application in a version-controlled repository and on a hosting account the founder controls, deployable through a documented pipeline, independent of the tool that generated it.
Why it matters: An app that only exists inside the builder tool cannot be reviewed, rolled back, or handed to another engineer.
How we verify it: Deploy a fresh clone to staging through the pipeline with no step that depends on the generating tool.
What we deliver: Add a flag mechanism for risky features and third-party dependencies so any one of them can be turned off without a deployment.
Why it matters: The fastest fix for a broken release is switching the feature off.
How we verify it: Disable a flagged feature in production and confirm the product stays usable with the feature hidden.
What we deliver: Enforce HTTPS everywhere with HSTS and a CAA record, lock the registrar, document the DNS records, and confirm renewal ownership.
Why it matters: An expired domain or a misissued certificate is an outage no code fix repairs.
How we verify it: Pass an external TLS scan at the top grade and file a DNS record export in the runbooks.
Give the team an operational view and alerts they can act on.
8 deliverables · All included
What we deliver: Add structured request logs with correlation IDs and appropriate user references; exclude passwords, tokens, and unnecessary personal data.
Why it matters: Useful traces need to support investigation without creating another data leak.
How we verify it: Trace a test request across services and check log content for sensitive fields.
What we deliver: Monitor the production URL and health endpoint with outage alerts.
Why it matters: A public outage can go unnoticed without independent checks.
How we verify it: Trigger a controlled check failure and verify notification and recovery reporting.
What we deliver: Alert on error spikes, latency, connection pressure, and queue backlog.
Why it matters: Gradual degradation needs attention before it becomes a broad outage.
How we verify it: Trigger each configured condition and record its alert threshold and behavior.
What we deliver: Route alerts to the designated Slack or email destination and tune thresholds to reduce noise.
Why it matters: An alert is only useful if the responsible person sees and understands it.
How we verify it: Send test alerts and verify their destination, context, and response instructions.
What we deliver: Set and document log retention across the application's services.
Why it matters: Retention that is too short impairs investigation; uncontrolled retention increases cost and exposure.
How we verify it: Inspect the configured windows and verify retention behavior in supported systems.
What we deliver: Instrument signup, activation, core actions, and payment-funnel events with consent-aware collection.
Why it matters: The team needs to see where customers progress or encounter friction.
How we verify it: Run core journeys and verify event names, properties, and consent behavior.
What we deliver: Provide a status page for service availability and incident communication.
Why it matters: Customers need a central place to understand an interruption.
How we verify it: Publish a test incident and verify the page remains reachable separately from the app.
What we deliver: Create one view of uptime, error rate, latency, signups, and revenue for the application's relevant services.
Why it matters: Checking the health of the business should not require piecing together several tools.
How we verify it: Compare the displayed metrics with their source systems and verify refresh behavior.
Measure what the application can handle and improve the bottlenecks that matter.
7 deliverables · All included
What we deliver: Cache repeated reads where it is safe, with explicit invalidation and customer-data boundaries.
Why it matters: Repeated expensive work wastes resources; unsafe caches can expose stale or private data.
How we verify it: Compare cache hits and misses, test invalidation, and verify tenant separation.
What we deliver: Simulate concurrent users, identify the first bottlenecks, fix them, and rerun the workload.
Why it matters: Launch capacity should be measured before real traffic becomes the test.
How we verify it: Report the workload, duration, environment, concurrency, latency, and error rate before and after changes.
What we deliver: Reduce unnecessary frontend code and load routes or features when needed.
Why it matters: Large initial downloads slow first use, especially on constrained devices.
How we verify it: Compare built bundle sizes and test route loading with representative network conditions.
What we deliver: Optimize image dimensions, formats, compression, and delivery while preserving useful quality.
Why it matters: Oversized assets waste bandwidth and slow customer-facing pages.
How we verify it: Compare transferred sizes and inspect rendered images at intended display dimensions.
What we deliver: Run Lighthouse on representative pages, implement performance and accessibility improvements, and deliver a passing result against recorded acceptance targets.
Why it matters: Slow or difficult-to-use pages create avoidable friction.
How we verify it: Report the chosen pages, device profile, numerical targets, and final results; manually check key accessibility interactions.
What we deliver: Document measured concurrent capacity on the current infrastructure and the changes needed to plan for five times that workload.
Why it matters: A number without its conditions is a poor basis for growth decisions.
How we verify it: Link capacity claims to load-test evidence and identify untested projections as projections.
What we deliver: Bring the core flows to WCAG AA: keyboard navigation, contrast, labels, and focus order.
Why it matters: Enterprise and public-sector buyers require it, and generated interfaces fail it by default.
How we verify it: Score 100 on an automated accessibility audit of the core pages and complete a keyboard-only walk through signup, checkout, and the main task.
Make the application easier for your team and AI tools to change safely.
11 deliverables · All included
What we deliver: Remove dead code and consolidate duplicated logic while preserving required behavior.
Why it matters: Repeated implementations make it easy to fix one path and leave another broken.
How we verify it: Record removed or consolidated code and run regression checks on affected flows.
What we deliver: Consolidate conflicting state ownership into a documented, consistent pattern.
Why it matters: Competing sources of truth can show different values in different screens.
How we verify it: Exercise refreshes, mutations, and navigation and verify consistent displayed and stored state.
What we deliver: Define types at every API boundary and share contracts between frontend and backend using the stack's appropriate tooling.
Why it matters: Uncoordinated schema changes can break clients silently.
How we verify it: Introduce a deliberate contract mismatch and confirm type or contract checks catch it.
What we deliver: Organize the codebase consistently and explain its layout in the README.
Why it matters: Future developers and AI tools need to know where responsibilities belong.
How we verify it: Follow the README from a clean checkout and trace a core feature through its documented modules.
What we deliver: Automate smoke tests for signup, login, the core product action, and payment flows.
Why it matters: A small change can break a business-critical journey elsewhere.
How we verify it: Run the suite in CI and demonstrate that an intentional regression fails it.
What we deliver: Enable TypeScript strict mode and resolve errors in TypeScript applications, with an equivalent strict-checking approach for other supported stacks.
Why it matters: Stronger checks catch classes of mistakes before execution.
How we verify it: Record the strict configuration and a clean checking run without suppressing the errors being fixed.
What we deliver: Add unit tests around authorization and payment logic, including negative and edge cases.
Why it matters: Sensitive decisions need a reliable safety net when the implementation changes.
How we verify it: Run the tests and show rejection of unauthorized access and incorrect billing transitions.
What we deliver: Provide CLAUDE.md, AGENTS.md, Cursor rules, or equivalents describing conventions and protected patterns; add CI checks for enforceable rules.
Why it matters: Future AI-assisted changes can undo hardening unless the workflow checks them.
How we verify it: Review the guidance and demonstrate CI catching a representative forbidden regression.
What we deliver: Record a 20–30-minute walkthrough of the repository, data model, and key architectural decisions.
Why it matters: A future engineer should not have to rediscover the system from scratch.
How we verify it: Deliver an accessible recording with chapter markers or a short contents list.
What we deliver: Provide one documented command that brings the application up locally, with an environment example and seed data.
Why it matters: The next engineer's first hour decides whether they can work on the product at all. Generated apps rarely have this.
How we verify it: Go from clone to running application on a new machine by following the guide alone.
What we deliver: Inventory the licences of every dependency, flag copyleft or unlicensed packages, and replace or approve each one.
Why it matters: Licence questions are on every technical due diligence list, and generated apps pull packages without checking.
How we verify it: Include the licence report in the due diligence pack with zero unresolved flags.
Make account and transaction messages traceable and maintain the sending setup.
3 deliverables · All included
What we deliver: Verify and configure SPF, DKIM, and DMARC for the transactional sending domain.
Why it matters: Domain-authentication problems can undermine legitimate email delivery.
How we verify it: Inspect DNS and received message headers for the configured authentication results.
What we deliver: Configure a dedicated transactional provider with delivery tracking for account and transaction messages.
Why it matters: Untracked failures make it difficult to know whether a customer received a critical message.
How we verify it: Trigger each critical message type and confirm provider records and expected recipient delivery.
What we deliver: Process bounces and complaints and suppress further sending where appropriate.
Why it matters: Repeated sending to invalid or complaining recipients can damage sending reputation.
How we verify it: Simulate provider events and verify suppression and subsequent send behavior.
Implement the technical controls and documentation needed to handle personal data deliberately.
8 deliverables · All included
What we deliver: Document what personal data is stored, where it lives, why it is collected, and who can access it.
Why it matters: The team needs a reliable record when a customer or reviewer asks about data use.
How we verify it: Trace a sample user through storage, logs, and providers and compare it with the inventory.
What we deliver: Implement authenticated export and deletion workflows covering related systems and documented retention exceptions.
Why it matters: Personal-data requests are difficult to fulfill when the application has no reliable mechanism.
How we verify it: Export and delete a seeded user's data; verify completeness, authorization, and recorded exceptions.
What we deliver: Verify privacy and terms links and review the stated data practices against the application; document and resolve technical discrepancies with the owner.
Why it matters: The public description of data use should match what the product actually does.
How we verify it: Compare the policy statements with the data inventory and provider flows and record the owner-approved alignment.
What we deliver: Implement consent controls for the application's audience and tracking configuration, including EU visitors where relevant.
Why it matters: Optional tracking needs to follow the user's recorded consent choices.
How we verify it: Test consent, refusal, withdrawal, and persistence; verify optional scripts respect those choices.
What we deliver: Document retention periods and handling rules for logs, user history, and abandoned records.
Why it matters: Keeping data without a defined purpose makes storage and data handling harder to govern.
How we verify it: Review the schedule against the data inventory and the configured lifecycle controls.
What we deliver: Deliver a technical controls checklist with supporting evidence organized for enterprise security review.
Why it matters: Enterprise buyers need evidence of how the application is protected and operated.
How we verify it: Link each documented control to its owner, configuration, or test evidence. This deliverable is not a SOC 2 audit report.
What we deliver: Inventory the user data that reaches AI providers, redact what is not needed, and record each provider's data-processing terms.
Why it matters: For an AI app, the model provider is a second place customer data lives.
How we verify it: Trace each model call, list the fields sent, and match them against the inventory.
What we deliver: Publish the list of vendors that process customer data, with the agreement in place for each.
Why it matters: Every business customer's security questionnaire asks for it, and reviewers cross-check it against the privacy policy.
How we verify it: Confirm the list matches the provider inventory and the privacy policy.
Leave with the application, its operating instructions, and support for putting the handover to use.
7 deliverables · All included
What we deliver: Deliver the result for every scope item, the work completed, and its verification evidence.
Why it matters: Engineering work needs a record your team and reviewers can inspect.
How we verify it: Account for all 123 IDs; keep failures visible until resolved and explain genuine non-applicable items.
What we deliver: Show the deployed components, data flows, authentication boundaries, and third-party integrations.
Why it matters: New engineers and reviewers need to understand how the application fits together.
How we verify it: Compare the diagram with the delivered environment and repository.
What we deliver: Document deployment, rollback, key rotation, backup restoration, and the response to each operational alert.
Why it matters: The team needs usable procedures when an incident or release requires action.
How we verify it: Walk through the runbooks against the delivered configuration and reference the rehearsal evidence.
What we deliver: Conduct and record a 60-minute walkthrough with the client team and technical advisors.
Why it matters: Documentation is more useful when the team can ask questions about operating the system.
How we verify it: Deliver the recording, supporting documents, and answers or follow-ups from the session.
What we deliver: Provide fourteen calendar days after handover to fix defects in the sprint deliverables at no additional engineering charge.
Why it matters: Issues discovered just after delivery need a clear route back to the team.
How we verify it: Record the coverage dates, reporting channel, reproduction details, fixes, and retest results.
What we deliver: Bundle the readiness report, architecture diagram, data model, security checklist, and capacity statement into one PDF.
Why it matters: Technical reviewers need an organized evidence pack rather than scattered files.
How we verify it: Check the pack for completeness, consistent version references, and readable linked evidence.
What we deliver: Provide thirty calendar days after handover for questions about the delivered architecture, operation, and safe future changes.
Why it matters: Small questions often arise when the client starts using the handover independently.
How we verify it: Provide the channel, access instructions, and the start and end dates in the handover.
Your handover report records each scope item, its implementation, and the check used to verify it. You can trace the engineering work back to the repository, test results, configuration, or delivered documentation.
For working controls:
We record the implementation and the passing verification result.
For a genuine non-applicable item:
We explain why the relevant system or condition is absent from your application.
For an unresolved applicable issue:
We keep it visible as unfinished work until it is corrected and retested. It does not become a paid upgrade or disappear into a recommendation list.
Load-test results specify the environment, data volume, workload, duration, and observed performance. Security test results specify what was tested and how. This gives your team and reviewers a concrete basis for assessing the application.
We make a functioning application production ready through the published 123-point scope. Building new features or completing unfinished core workflows is separate work.
For example:
Adding webhook verification and duplicate-charge protection to a working checkout is included. Completing a checkout that cannot process an order because its core business logic is unfinished is separate feature-development work.
$2,500
Engineering fee:
$2,500 USD for the complete sprint.
Third-party costs:
Hosting, paid tools and API usage are paid through your accounts. We explain any required costs before enabling them.
Payment:
$1,250 at kickoff and $1,250 at verified handover.
Start date:
Your agreed kickoff date, once repository access and the required environment credentials are available. We provide the access checklist beforehand.
Delivery:
By day ten, we demonstrate the verified application in staging, deliver the report and due diligence pack, and conduct the technical walkthrough. Production release is coordinated with your team through the included deployment process.
Included support:
Fourteen calendar days of defect cover and thirty calendar days of async questions, both beginning at handover.
No. All 123 deliverables are included in the same $2,500 package. There is no advanced tier to unlock them.
We inspect and test it. If it is correct, we record the evidence. If it is incomplete, we fix it. The fixed fee buys the completed production scope, including verification of existing work.
We apply the equivalent controls for your payment provider, database, and framework. The list describes the production capability we deliver; the implementation follows your stack.
The targeted security tests are performed by AxonBuild and cover the five priority attack surfaces documented in your report. The package also includes the OWASP review and a controls checklist with evidence. Formal third-party certifications and independent audit opinions are separate from these engineering deliverables.
We implement and document the technical data-handling controls listed above and check that the application's behavior matches its published data practices. Legal advice and certification are separate services.
It includes the supporting interfaces needed for the listed controls, such as session management, account deletion, and billing self-service. New features that change the product's core capabilities are separate work.
We address the failure and retest it. The report keeps unresolved work visible, and final acceptance requires the applicable scope to be verified.
The delivery date moves by the time work is blocked by missing access, delayed approvals, or changes your team makes to the agreed code during the sprint. We explain the impact and confirm the revised date with you.
After handover, your team operates the application and receives its alerts.
Our included cover is 14 calendar days of fixes for defects in the delivered work and 30 calendar days of questions about the handover and architecture.
YOU HAVE SEEN THE COMPLETE SCOPE
Our engineering team implements, verifies, and hands over all the work above in one focused sprint.
Start Your Sprint →$2,500 fixed price · 10 working days · One codebase