Web and Android Technical Audit Before Scaling

The challenge is no longer just getting code to work. It's knowing whether the system behind it is engineered to handle real-world use. Security, architecture, data consistency, testing, and recovery require decisions that AI-generated code alone cannot guarantee.

That gap between a functional product and a reliable system was the focus of a technical audit Mad Devs conducted for a B2B platform combining a web application, backend services, and an Android client. The platform already supported project management, media processing, offline operations, and data synchronization.

Before expanding its use, the client needed experienced engineers to look beyond working features and identify what could break, what posed security risks, and what would limit future growth.

Mad Devs reviewed the platform's architecture, security, infrastructure, code quality, deployment processes, and scalability. The assessment also included a separate Android review and documented manual testing results, turning hidden technical weaknesses into a prioritized plan for improvement.

Challenge 1: Working authentication did not guarantee consistent security

The platform already used established authentication mechanisms and included authorization checks for core resource operations. However, these protections were not consistently applied across API endpoints, file operations, and third-party integrations.

The most serious finding involved a media-processing endpoint that could allow unauthorized access to files outside its intended storage directory. Because the affected functionality was also accessible through public resource-sharing workflows, the vulnerability received critical P0 priority.

We also identified incomplete access checks, insufficient protection of stored authentication tokens, and sharing mechanisms that could expose more resources than users intended.

These weaknesses were not immediately obvious from normal application behavior. Users could authenticate and work with resources successfully, while certain backend operations still exposed sensitive data.

We recommended stricter input validation, consistent resource-ownership checks, encrypted token storage, and explicit controls for publishing and revoking shared resources.

The assessment also identified application interfaces exposed outside the intended reverse-proxy protections. We recommended restricting access to internal services and validating security settings in the deployed environment, not only in repository configurations.

The findings demonstrated why a working authentication flow is not sufficient evidence of application security. Engineering reviews need to evaluate how protection is enforced throughout the system, including less visible operations and edge cases.

Pending operations were managed across multiple components, while locally stored queues lacked robust recovery and versioning mechanisms. API error handling also failed to distinguish some temporary connection problems from permanent errors, potentially triggering ineffective retries or leaving operations incomplete.

Manual testing confirmed problems that directly affected users. Initial data capture could remain stuck in a loading state without completing synchronization. Repeating the operation could unblock the process but leave duplicate or outdated files. Local project data also remained accessible after logout.

These failures demonstrated the difference between implementing a feature and ensuring it behaves reliably across interrupted operations, retries, and changes in application state.

We recommended centralizing synchronization state, introducing versioned queue storage and atomic updates, and separating retryable errors from failures requiring user intervention.

The remediation plan also included automated regression tests for interrupted uploads, repeated operations, and data recovery, together with stronger controls over locally stored data.

The tested Android build received a No-Go recommendation for pilot acceptance until the high-priority limitations were resolved or explicitly accepted. This gave the client a concrete understanding of which core workflows still required engineering work before broader use.

Large media files were stored directly in the database, increasing its size and complicating backups. Resource-intensive processing ran synchronously within application requests, creating a risk of excessive memory consumption when multiple heavy operations occurred.

The audit also found that backups were stored on the same host, created irregularly, and lacked a tested restoration procedure. A serious server or storage failure could therefore affect both production data and the available backups.

These limitations illustrated an important engineering trade-off: an architecture sufficient for initial use may become increasingly difficult to operate as data volumes, concurrent requests, and availability requirements grow.

For near-term reliability, we recommended regular off-site backups, tested recovery procedures, operational alerts, and safer deployment practices.

For future growth, the roadmap proposed separating binary media from the database, moving resource-intensive processing into background job queues, improving database indexing, and preparing the platform for multiple application instances.

The goal was not to introduce unnecessary complexity or rebuild the entire system. It was to establish which architectural changes were essential for reliable operation and which could be implemented as the product expanded.

The application compiled successfully, but its automated test tasks completed without executing actual tests. A green build therefore provided no meaningful confirmation that critical business workflows had been verified.

Static analysis revealed numerous code issues, while large application components combined interface logic, networking, local storage, and synchronization responsibilities. This structure made individual changes harder to isolate and test.

The backend delivery process showed similar weaknesses. Automated quality checks were not consistently enforced before deployment, and releases lacked a reliable rollback procedure.

An operational inspection revealed another problem: a native media-processing dependency failed to load in production. The application silently switched to a less suitable processing method, resulting in degraded output without completely stopping.

We recommended introducing automated tests for critical workflows, enforcing meaningful quality gates in CI/CD, and separating responsibilities within large application components.

For deployment, we proposed versioned releases, reliable rollback mechanisms, and runtime checks for required dependencies.

The assessment demonstrated why successful compilation is only a starting point. Production readiness also requires evidence that important workflows behave correctly, errors are handled predictably, and the system can be maintained and recovered when something goes wrong.

The audit helped the client understand which risks required immediate attention, where additional engineering expertise was needed, and what to prioritize before scaling the product.

But there is a difference between generating code that performs a task and engineering a system that can operate reliably as requirements grow.

Security boundaries, concurrent operations, data consistency, recovery procedures, and deployment reliability require deliberate technical decisions and validation. Problems in these areas are not unique to AI-generated code, but they can be overlooked when development focuses primarily on delivering working features.

This case demonstrates why independent engineering reviews matter before scaling. Mad Devs helped the client look beyond visible functionality, identify risks across the entire system, and understand what additional work was necessary for reliable operation.

For teams building products with AI coding tools, the first step can be identifying potential issues directly in the codebase, before they turn into bigger production problems.

Code-level checks are a useful starting point, but production readiness goes further. Architecture, infrastructure, deployment, and real-world workflows also need engineering oversight. A comprehensive technical audit helps connect these findings and establish what needs to be addressed before wider rollout.

Building a working product is easier than ever. Making it secure, reliable, and ready to scale still requires engineering expertise.