Selected work by our team during its LuckyTruck engineering tenure, 2021–2024. The case describes that contribution; LuckyTruck’s current product has continued to evolve.
Several workloads, one product
The product combined interactive customer and operations screens with carrier integrations, document processing and scheduled or asynchronous work. Those tasks have different execution needs. The archive reflects both long-running container services and focused Lambda functions rather than a single deployment shape for everything.
This overview names the technologies and responsibility boundaries from that work. It is not a reproduction of the client’s private network topology or a description of its current production estate.
AWS services and their roles
| Layer | Technologies | Role in the work |
|---|---|---|
| Container delivery | Docker, Amazon ECR, Amazon ECS | Package services, publish images and run container workloads. |
| Focused functions | AWS Lambda, API Gateway, Serverless Framework | Expose and deploy discrete integration and document-processing functions. |
| Relational data | PostgreSQL on Amazon RDS, Prisma | Represent related product records through a relational database and application data layer. |
| Key-value data | Amazon DynamoDB | Support service-specific data and integration state. |
| Documents and objects | Amazon S3 | Store and exchange files used by document and product workflows. |
| Communication | Amazon SES | Support application email workflows. |
| Delivery automation | GitHub Actions, Docker build/push workflows | Connect code changes with repeatable container publishing and release steps. |
Application engineering around the cloud
React and Next.js powered customer and operations interfaces. Node.js and Express services used GraphQL, Apollo and Prisma in different generations of the backend. PostgreSQL modeled related application records; specialist integrations also used DynamoDB and AWS SDKs.
The stack evolved over the engagement. Salesforce integrations used jsforce and Apex; Zoho integrations used its SDK and embedded-app APIs. Browser automation supported selected carrier journeys, while Java handled the GlobalSign signing service. This variety reflected the systems the product had to connect, rather than a requirement to use every technology in a new build.
Delivery responsibilities beyond application code
Our contribution included deployment configuration, container workflows and serverless packaging alongside product code. The retained repositories include separate environment configurations, Docker definitions, GitHub Actions workflows and Serverless Framework definitions.
For a new engagement, we agree on environment ownership, secrets handling, database changes, monitoring, rollback and support before launch. Those are acceptance questions for a production handover, not optional details after the interface is finished.
What this experience brings to a new product
A product studio should be able to explain how an interface reaches its data and integrations, how a failed background job is handled, and who can deploy or recover the application. Our LuckyTruck work demonstrates experience spanning those layers.
The appropriate first release may be much smaller. We scope the workflow and its operational requirements first, then choose the minimum infrastructure needed to support it. AWS experience is useful judgment; reproducing a large historical stack is not a goal in itself.
Continue exploring
- Carrier and CRM integration work
- Custom software and MVP engagements
- What an MVP proposal should include
