Taking a personalized publishing platform to production
Stabilizing an inherited multi-service commerce platform, improving its delivery path, and removing severe performance and infrastructure waste.
Outcome: 22× faster image-heavy page loads and 86% lower AWS infrastructure cost.
Context
The inherited platform sells personalized children’s books and coordinates payment, page rendering, high-resolution PDF generation, storage, and print fulfillment across several services. It had substantial product value, but the existing delivery and infrastructure needed to become dependable before the team could confidently operate and grow it.
Responsibility
As fractional technical lead and application architect, I took hands-on responsibility for stabilizing the product, guiding architecture and delivery decisions, reviewing security, improving its infrastructure, and completing the path to production. The work covered the frontend, API, document-generation pipeline, asynchronous tasks, payments, storage, and deployment workflow.
Constraints
- Preserve a working multi-service architecture rather than rewrite it for preference.
- Handle image-heavy and print-ready assets without weakening output quality.
- Improve reliability while feature and internationalization work continued.
- Reduce operational cost without removing services the product depended on.
- Coordinate third-party payment, shipping, and print integrations.
Approach
I started with production risks: security gaps, deployment repeatability, service ownership, failure paths, and missing documentation. The platform moved to a documented containerized setup with automated delivery and clearer environments. I then traced the largest storage and loading costs through the image and generated-artifact pipelines, fixing the highest-leverage bottlenecks instead of applying broad infrastructure upgrades.
The product work also included stronger payment handling, international delivery support, third-party integration fixes, and maintainable technical documentation so the team could operate the system after each change.
Outcomes
- Took the inherited platform from a non-production-ready state through stabilization and go-live.
- Reduced image-heavy page loading from roughly four minutes to 11 seconds—a 22× improvement—while reducing image sizes by 92%.
- Reduced generated artifact size by 83%, cutting a representative download from 1 minute 40 seconds to 17 seconds.
- Reduced database growth by 88% through workflow and lifecycle improvements.
- Reduced AWS infrastructure cost by 86% while keeping the required services intact.
- Produced maintainable technical documentation covering architecture, delivery, debugging, and integrations.
Reflection
The most useful architecture decision was not a rewrite. It was to make system boundaries visible, remove measurable waste, and improve the operating path in an order the product could absorb. Reliability created the room for later product and growth work.
Public boundary
The client is intentionally unnamed, and client-specific growth details, private architecture, and screenshots are omitted. This account covers only the responsibilities and outcomes appropriate for a public portfolio.