Your App Works. But What Happens When Something Goes Wrong?
AI development tools can produce working features quickly. That does not establish whether the application behaves correctly when configuration is missing, a database operation fails, a migration encounters existing data, or two requests run at the same time.
These problems are especially important when an application handles customer records, payments, identity information, business transactions or other sensitive data.
Examples of risks worth investigating include:
Encryption and secrets — does the application fail safely when required keys are missing or incorrectly configured? Can encrypted records still be read after an expected deployment or key-management change?
Database transactions — can a failed operation leave an invoice, customer record or related data only partly updated?
Schema migrations — does a migration preserve existing records and behave predictably when an operation fails?
Concurrent operations — can simultaneous requests create duplicate, missing or inconsistent data?
Development versus production — do the security and data-handling behaviours depend on assumptions that change when the application is deployed?
These are testing targets, not a promise that every risk can be covered in a single assessment. The first step is to choose the data workflow where a failure would matter most.
New to this risk area? Start with the article: You built an app with AI — can you trust it with real customer data?
What the Data Integrity Assessment Includes
The fixed-scope package investigates one agreed critical data workflow in one qualifying application. A workflow might be customer-record creation, an encrypted-data operation, an important database migration, or a multi-step transaction.
Included:
- An initial discussion to identify the critical workflow and expected behaviour.
- Review of the relevant application code, data access path, database interactions and configuration.
- Identification of important assumptions and failure conditions.
- Up to three targeted, executable test scenarios agreed for the selected workflow.
- Controlled execution of those tests in an approved non-production environment.
- Recording of observed results, errors, unexpected behaviour and limitations.
- Reproduction steps and relevant test evidence, including agreed scripts or fixtures where appropriate.
- A written findings report with prioritised recommendations.
- One technical walkthrough of the findings.
Examples of tests may include intentionally omitting a required encryption configuration, injecting a failure partway through a multi-step database operation, or testing how a migration behaves against existing records. The precise scenarios are selected during qualification. Not all examples are included in every assessment.
Not included:
- An audit of the entire application or every repository.
- Comprehensive penetration testing, vulnerability scanning or certification.
- A guarantee that the application is secure or free of data loss.
- Remediation, feature development or rewriting the application.
- Changes to live customer records or uncontrolled production testing.
- Ongoing monitoring, incident response or application hosting.
- An assurance opinion about legal or regulatory compliance.
The deliverable is evidence about an agreed data workflow — not a blanket approval of the application.
From Plausible Code to Observed Behaviour
A conventional code review can identify suspicious patterns and potential defects. An executable assessment adds another layer: what actually happens when the selected workflow is exercised under controlled conditions?
For each agreed test, the report aims to document:
- The expected behaviour — what should the application do when the workflow succeeds or fails?
- The test condition — what input, configuration change, controlled failure or operational condition was introduced?
- The observed result — what happened to the application, database state and relevant error handling?
- The supporting evidence — what logs, test output, database observations or reproduction steps support the finding?
- The recommended action — what should be corrected, investigated further or subjected to additional testing?
A passing test establishes behaviour under the tested conditions. It does not prove that all other paths, deployments or attack scenarios are safe. An inconclusive test is reported as inconclusive, with the reason and any additional verification required.
The objective is to replace assumptions with findings an engineer can inspect and act upon.
Your Source Code and Customer Data Remain Under Your Control
The standard assessment is designed around customer-controlled repositories and test environments.
Source code is reviewed through agreed, access-controlled methods. Tests are performed against an approved non-production environment, using synthetic or appropriately de-identified data wherever possible.
Production customer records, credentials and secrets are not required in the initial enquiry and must not be submitted through the contact form.
The standard service does not involve copying customer repositories into Al's personal AI tools or submitting confidential source code, customer records or credentials to external AI model providers. Any proposed exception would require explicit written authorisation and a separately agreed data-handling arrangement.
Before technical work begins, SummitWright and the customer agree on confidentiality, permitted access, testing boundaries and handling of relevant evidence. Reports minimise or redact sensitive information.
If the application cannot be tested safely without exposing live customer information or creating unacceptable operational risk, the proposed assessment will be declined or rescoped.
Fixed Price, Defined Scope
AI Application Data Integrity Assessment — A$1,650
Fixed price for one qualifying application and one critical data workflow. The standard package includes up to two scheduled engineering days, three agreed targeted tests, a written evidence report and a technical findings walkthrough.
To qualify, the customer must provide:
- Access to one relevant source repository and its technical documentation, where available.
- A clearly identifiable data workflow or failure concern.
- A suitable non-production environment or reproducible test setup.
- Necessary test credentials and sample data through approved access methods.
- An authorised technical contact who can explain expected behaviour and approve the proposed tests.
Applications with multiple interacting services, complex infrastructure or substantial environment-reconstruction requirements may need a different scope.
The initial suitability call determines whether the standard assessment is appropriate. If the relevant workflow cannot be tested within the agreed boundaries, a separate proposal may be appropriate.
No GST charged — SummitWright is not registered for GST.
Start With a Free 20-Minute Suitability Call
Describe the application, its main technology stack, the critical workflow and the concern that prompted the enquiry. No repository upload or sensitive information is required for this conversation.
Assessments are scheduled in advance. A written scope, start date, access prerequisites and delivery date are agreed before payment.
Where defects are identified, remediation is a separate engagement. The assessment report remains useful whether the customer asks SummitWright or another engineer to perform the fixes.
Check Whether Your Application QualifiesYour Engineer: Software Development With a Database-Reliability Perspective
Al Elmi — Founder, SummitWright Pty Ltd
Al is a Brisbane-based software engineer and career SQL Server database professional, with practical experience in database architecture, performance, high availability, recovery and software development.
His engineering work includes AI-assisted application development and investigating failures involving encryption configuration, deployment environments and database-backed workflows.
This combination informs the assessment approach: the code matters, but the behaviour of the data layer matters just as much.
Al personally scopes and delivers the work. SummitWright is a founder-led business, not a large agency or a managed incident-response provider.
SummitWright Pty Ltd, ACN 702 814 980, is based in Brisbane and provides remote engineering services across Australia.
Is This Assessment Right for You?
Suitable for:
- Founders and development teams preparing an AI-built application for real customers.
- Organisations using AI-generated or AI-assisted code in systems containing important records.
- Technical leads who want an independent examination of a risky data workflow.
- Applications with repeatable production-like failures involving configuration, persistence or transaction behaviour.
- Teams willing to provide an approved test environment and act on documented findings.
This is not the right service if:
- The application is only a visual prototype and does not yet handle meaningful persistent data.
- The requirement is to build an entire application from scratch.
- There is no source-code access or permission to assess the application.
- No safe test environment can be made available.
- The customer needs emergency incident response or immediate production repairs.
- A complete penetration test or formal security certification is required.
- The expectation is that a fixed-price assessment will automatically include every necessary fix.
The assessment is technology-fit dependent. Not every framework, database platform or application architecture will be accepted.
Need Help With Private AI Infrastructure Instead?
SummitWright can also discuss separately scoped engineering work involving local AI models, self-hosted inference and controlled AI-assisted development workflows.
These engagements are not included in the A$1,650 assessment and require an individual technical discussion.
Frequently Asked Questions
My application was built with Claude Code, Cursor, Lovable or another AI tool. Can it be assessed?
Potentially. The development tool is less important than the application's architecture, available source code, test environment and data-handling risk. The suitability call establishes whether the relevant workflow can be meaningfully tested.
Does the assessment prove the application is secure?
No. The assessment investigates a defined set of data-handling behaviours and records the results. It is not a comprehensive security audit, penetration test or certification. Other vulnerabilities and data-integrity defects may remain.
Will my source code or customer records be sent to external AI models?
Not as part of the standard assessment. External AI processing of confidential customer material requires separate, explicit written authorisation. Testing is designed around approved environments and synthetic or de-identified data where feasible.
What if the application has no tests or staging environment?
That is an important qualification issue. If a safe, reproducible test environment can be established within the agreed scope, the assessment may proceed. If significant infrastructure or test-environment construction is required, that work must be separately scoped before executable assessment work is accepted.
Will SummitWright fix the problems identified?
Remediation can be considered after the assessment, subject to technical fit, scope and availability. The report identifies the findings and recommended next steps. Fixes are not included in the assessment fee and there is no guarantee that every defect is economically or technically repairable.
Before You Trust the Application With More Customer Data, Test the Critical Path
Find out what the selected workflow actually does under realistic failure conditions — and what still needs attention.
Request a free suitability call for an AI Application Data Integrity Assessment.
Request a Data Integrity AssessmentDo not submit source code, passwords, API keys, personal records or other confidential material through the initial enquiry form.