Before scaling: A technical audit of a web and Android platform

As a product grows, it needs to handle concurrent operations, sensitive data, increasing workloads, and unexpected failures. These requirements introduce engineering challenges that may remain invisible during development or early testing. A working application doesn't necessarily have the architecture, security controls, or operational processes required for broader use.

This was the context for a technical audit Mad Devs conducted for a B2B platform combining a web application, backend services, and an Android client. The product already supported project management, media processing, offline operations, and synchronization between mobile devices and the server.

The client needed an independent engineering assessment before relying more extensively on the platform. Was the system secure enough to handle real user data? Could its synchronization mechanisms recover from failures? Would the infrastructure support growth? And which technical problems required attention before further development?

Mad Devs evaluated the system beyond its visible functionality, reviewing architecture, security, infrastructure, code quality, deployment, and scalability. We also assessed the Android application separately and examined documented manual testing results.

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.

Teams can begin with Enji Guard to identify potential security vulnerabilities, dependency risks, testing gaps, and maintainability issues in their repositories.

When a product requires deeper evaluation, Mad Devs' technical audit services assess not only the codebase but also architecture, infrastructure, deployment, data handling, and operational readiness.

Building a working product is easier than ever. Knowing whether it is ready for production still requires engineering expertise.