Client background
The client is a Coimbatore-based IT firm that builds business applications for enterprises across sectors, with a focus on logistics and supply chain management. Led by a co-founder with deep domain expertise in the logistics sector, the firm had been providing IT solutions to logistics companies for several years and had accumulated a clear view of the operational problems that enterprise logistics providers faced but that existing software solutions addressed poorly.
The core opportunity was building a purpose-designed cloud platform for enterprise logistics operations: a system that could handle the complexity of multi-tier supply chains (manufacturers, distributors, carriers, and end clients, all with different visibility and access requirements), support over 1,000 concurrent business users across different roles, and deliver the performance that logistics operations demand — where a slow system during a peak shipment period has direct cost consequences.
The firm had the domain expertise and the client relationships to take this product to market. What they needed was an engineering partner with the architectural capability to build an enterprise-grade cloud platform and the capacity to execute the build alongside their existing business commitments.
The challenge
Enterprise logistics platforms have a specific set of engineering challenges that differ from typical SaaS products. User counts in the hundreds to thousands mean that database design, API performance, and caching strategy all matter from day one — the luxury of "we'll optimise later when we have more users" doesn't exist when the first enterprise client deployment requires reliable 1,000-user concurrent load from launch.
The access control model for a logistics platform is unusually complex. Different stakeholder types — operations managers, warehouse staff, carrier partners, finance teams, and read-only clients — need different views of the same underlying data, with different edit permissions and different notification rules. A poorly designed access control model either over-restricts (making the system unusable for legitimate users) or under-restricts (creating data leakage between clients or roles that is unacceptable for a system handling commercial logistics data).
The requirement to build "an application with good architecture" (as the co-founder specified) was not a vague aspiration but a specific technical requirement: the platform needed to be structured with clean domain separation, documented architectural decisions, and maintainable code patterns that would allow the engineering team to evolve the system over years without accumulating the debt that makes software expensive to maintain.
Moving enterprise logistics clients from paper-based processes to a digital platform also requires careful change management. The system needed to be intuitive enough that warehouse staff and operations teams with varying digital literacy could use it without extensive training, while being sophisticated enough to handle the complexity that experienced logistics managers needed.
How we engaged
The engagement began in August 2018 and has continued as an ongoing partnership across multiple development phases. The initial team composition — two full-stack Angular engineers, one database administrator, one QA engineer, one architect, and one business analyst — reflected the scope of the build and the need for dedicated specialisation in architecture and data design.
Prijith R., the co-founder, was specific about what differentiated the engagement from his previous experiences with development vendors: "Every time they came with interesting recommendations that would add value to our project." This advisory engagement — where the Squash Apps team actively contributed to product and architectural decisions rather than simply executing requirements — was central to the quality of the outcome.
The working methodology used an agile approach with clear documentation ownership: business requirements were provided by the client, while user stories, change request processes, training materials, and deployment management were owned by Squash Apps. This division of responsibility gave the client control over what the system should do while freeing them from the operational overhead of managing the development process.
Stakeholder communication used weekly Friday meetings as the primary forum for status review and forward planning, supported by shared project management tooling for task tracking and a documented sharing methodology for requirements and design artefacts.
What we built
The platform was delivered in phases, starting with the core operational modules and expanding to additional capabilities based on user feedback and client requirements. The first phase delivered the foundational capabilities: shipment lifecycle management (creation, assignment, tracking, delivery confirmation), carrier management (carrier profiles, capacity, routing rules), warehouse operations (inbound, outbound, inventory), and the client portal (read-only access for the logistics company's end clients to track their shipments).
The role-based access control system was one of the most carefully designed aspects of the platform. Rather than implementing a fixed permission model, the team built a configurable RBAC system where the logistics company's administrators could define roles, assign permissions, and manage user role assignments through an admin interface. This flexibility was essential for accommodating the different organisational structures of different enterprise clients without requiring code changes.
Performance engineering was a first-class concern from the architecture phase. Database schema design prioritised query performance for the access patterns identified during the business requirements phase — specifically, the high-frequency read operations (shipment status checks, warehouse inventory views) that would be executed hundreds of times per minute under production load. Index design and query plans were reviewed by the database administrator at the end of every feature sprint to catch performance regressions early.
Training materials and documentation were delivered alongside the software: role-specific user guides for the different stakeholder types, system administration documentation for the client's IT team, and API documentation for the integration interfaces used by the client's enterprise logistics customers.
Technical approach
The platform was built on Angular for the frontend, with a Node.js/Express backend and PostgreSQL as the primary data store. The entire stack was deployed on AWS, using EC2 with auto-scaling for application servers, RDS for PostgreSQL with read replicas to support the high concurrent read load, and CloudFront for static asset distribution.
The database design prioritised both correctness and performance. Shipment and inventory data was modelled with event sourcing principles in the audit trail: every state change was recorded as an immutable event, providing a complete, tamper-evident history of every shipment's progression through the system. This was important for the regulatory and dispute resolution requirements that enterprise logistics contracts typically include.
The API layer implemented response caching for frequently accessed, slowly changing data (carrier information, product catalogues, client profiles) using an in-process cache backed by Redis. Cache invalidation was event-driven: updates to cached entities published invalidation messages to a Redis pub/sub channel, which the application servers subscribed to. This pattern kept the cache consistent across multiple application server instances without requiring synchronous cache invalidation calls.
The Angular frontend used a modular lazy-loading architecture, splitting the application into role-specific modules that were loaded on demand. This reduced initial load time and meant that a warehouse operator's browser never downloaded the financial reporting module code — improving both performance and the conceptual simplicity of each user's experience.
Results
The impact on the client's business was substantial and directly measurable. The client went completely digital: paper-based processes that had been a daily operational burden were eliminated across all logistics workflows. Communication between field teams, warehouse staff, and operations managers moved entirely online, reducing the information latency that had been a source of errors and delays.
The financial outcome was remarkable: 39% revenue growth in the year following the first phase go-live. This growth reflected both the operational efficiency improvements that allowed the firm to handle more volume with existing resources, and the competitive advantage of a proprietary platform that differentiated their offering from logistics providers still using generic software or manual processes. Enterprise logistics clients increasingly required digital visibility into their supply chains — and the platform provided exactly this, giving the firm a commercial argument that commodity logistics providers without proprietary software could not match.
Performance — one of the qualities Prijith specifically highlighted — remained strong at the 1,000+ concurrent user scale the platform was designed for. The upfront investment in index design, query optimisation, and read replica architecture meant that the platform handled production load without the performance degradation that commonly afflicts enterprise applications that were optimised for a smaller user base.
Prijith R.'s assessment captures the technical qualities that drove this outcome: "Technically they are very strong and technical challenges were quickly addressed. Very good UX and UI recommendations. The application was fast — they focused on it a lot. The server management support post-deployment was an added value." The ongoing engagement — from 2018 to the present — reflects what a logistics platform software development partnership looks like when the architecture is built correctly from the start and the team that built it continues to evolve it.