
design
dev
A Product Lifecycle Studio
Launchpad is where Tecovas takes a product from a date on a launch calendar to a live page on the storefront. Merchandising, copywriting, photography, and e-commerce all work the same pipeline, with every product carrying its own assignments, approvals, and readiness state, so anyone can see at a glance what's ready to go and what's still waiting on someone.
Death by Spreadsheet
Launching a product at Tecovas used to mean reconciling half a dozen spreadsheets against each other. Merchandising kept the launch calendar in one sheet, copywriters worked out of documents, photography tracked approvals somewhere else entirely, and none of it talked to the CMS where the product actually lived, which meant the true status of any given launch was whatever the last person to update a row happened to say it was. With dozens of products going live in a single week, the gap between what the spreadsheet claimed and what was genuinely ready cost us hours on every launch, and occasionally cost us a product going live half finished.
Letting the Tool Do the Remembering
I architected Launchpad around one idea, which is that a product shouldn't be able to go live until everything it needs is actually done, and the tool should be what enforces that rather than a person remembering to check. Every product carries a readiness state assembled from its own data, so a boot that's still waiting on approved gallery images says exactly that, in plain language, to whoever opens it. Our team built the surface area out from that core: a launch calendar that rolls up everything shipping on a given date, a writer's workspace where copy tasks move from ready to in progress to awaiting approval, and per channel visibility so eCommerce, retail, and wholesale each see only the products that concern them.
Building Inside the CMS, Not Beside It
The decision I'd defend hardest is that all of this lives inside our Sanity CMS as a plugin rather than as a separate application sitting next to it. A standalone tool would have been quicker to build and would have drifted out of sync within a month, because anything that mirrors product data eventually starts disagreeing with the source of truth. Living inside the CMS means the pipeline reads and writes the same documents that feed the storefront, so a status in Launchpad can't go stale, and nobody using it has to reconcile two systems or learn a second place to look.
© 2026 Alton Chaney
Built with React Router and Tailwind