PRNTD is a project where you can order T-shirts and other merch with designs that you generate iteratively with an AI assistant. Over time we intend to allow you to upload images and work with those, as well as text overlays and so forth. We're happy to have your suggestions on what we should allow you to do.
Today you can only buy one T-shirt or one cell phone case at a time, but we hope to enable groups such as bands or sports teams who want to get a bunch of shirts to benefit from not having to pay individual shipping on each unit and hopefully get some sort of group discount, while allowing them to custom design their shirts and order them as a package — or maybe other merch as well, like mugs.
We have ideas of creating a marketplace where you can sell your designs and raise money for your team or your cause. The intention of this project is to be a not-for-profit platform in service to the community, not trying to make a lot of money.
Get yourself a shirt!
evolution
Active since March 2026 · 46 sessions · 20 commits
↳ from claude · auto-generated at each session handoff
week of Aug 17, 2026· 2 sessions
Selected a composition-first data model. Shipped two changes to production in parallel: a reworked product picker and swap flow that also quietly resolved three latent caching bugs, and the first slice of the composition migration — an additive schema, dual-write publishing, and backfilled existing listings on production.
week of Aug 3, 2026· 1 session
Data model development: how designs, physical products, and print placements (front, back, and so on) relate to one another across shop and product contexts. No code — the point was to settle the foundations before building on top of them.
week of Jul 27, 2026
The week opened badly. A database migration had silently done nothing on production, leaving checkout broken for roughly twenty hours before anyone noticed. It was re-applied and verified across both production and preview — and the failure mode deserves naming, because a migration that fails loudly is a nuisance, while one that succeeds at nothing is a twenty-hour outage.
Despite that start, a large merge session closed out, including the first live contract check against the fulfillment partner, which passed end to end with a real order. An accidental design deletion turned out to be fully recoverable. A masked server error on production exposed a genuine gap in error visibility and produced a concrete proposal to close it. The week ended on mobile polish: deletion failures on phones, slow pages, a missing account address in the menu, and shirt colours rendering inconsistently behind transparent images.
PRNTD is a project where you can order T-shirts and other merch with designs that you generate iteratively with an AI assistant. Over time we intend to allow you to upload images and work with those, as well as text overlays and so forth. We're happy to have your suggestions on what we should allow you to do.
Today you can only buy one T-shirt or one cell phone case at a time, but we hope to enable groups such as bands or sports teams who want to get a bunch of shirts to benefit from not having to pay individual shipping on each unit and hopefully get some sort of group discount, while allowing them to custom design their shirts and order them as a package — or maybe other merch as well, like mugs.
We have ideas of creating a marketplace where you can sell your designs and raise money for your team or your cause. The intention of this project is to be a not-for-profit platform in service to the community, not trying to make a lot of money.
Get yourself a shirt!
evolution
Active since March 2026 · 46 sessions · 20 commits
↳ from claude · auto-generated at each session handoff
week of Aug 17, 2026· 2 sessions
Selected a composition-first data model. Shipped two changes to production in parallel: a reworked product picker and swap flow that also quietly resolved three latent caching bugs, and the first slice of the composition migration — an additive schema, dual-write publishing, and backfilled existing listings on production.
week of Aug 3, 2026· 1 session
Data model development: how designs, physical products, and print placements (front, back, and so on) relate to one another across shop and product contexts. No code — the point was to settle the foundations before building on top of them.
week of Jul 27, 2026
The week opened badly. A database migration had silently done nothing on production, leaving checkout broken for roughly twenty hours before anyone noticed. It was re-applied and verified across both production and preview — and the failure mode deserves naming, because a migration that fails loudly is a nuisance, while one that succeeds at nothing is a twenty-hour outage.
Despite that start, a large merge session closed out, including the first live contract check against the fulfillment partner, which passed end to end with a real order. An accidental design deletion turned out to be fully recoverable. A masked server error on production exposed a genuine gap in error visibility and produced a concrete proposal to close it. The week ended on mobile polish: deletion failures on phones, slow pages, a missing account address in the menu, and shirt colours rendering inconsistently behind transparent images.
The post-incident batch landed — back-design discoverability, cancellable generation, an end-to-end purchase test running in the payment provider's test mode, and route coverage — alongside a migration plan for the new data model. That end-to-end test then ran live for the first time and passed, once adapted to a checkout page the provider had quietly redesigned.
A reported bug where back-side previews always showed the wrong design was reproduced locally and traced to storage keys that omitted the very distinction the cache key relied on — fixed with one shared key builder and a versioned cache. Separately, a warm cache for design threads and per-change disposable test databases landed, both aimed at test flakiness caused by everything sharing a single database.
week of Jul 13, 2026· 1 session
Synchronized repository state across development machines, verified an earlier fix had landed everywhere, pruned stale branches, and took stock of open work before the next push of feature development.
week of Jul 6, 2026· 1 session
A week entirely about hardening order fulfillment against someone else's outage. The centrepiece is a daily job that automatically retries orders that were paid for but never submitted — precisely the scenario where the fulfillment partner is unreachable at the moment payment completes and an order strands with nobody noticing.
The flow was also restructured so that generating a readable order name no longer sits in the critical path, with a timeout guard ensuring a hung language-model call can't push processing past the payment provider's deadline. The job merged and ran, though the absence of any logs raised a fair question: how would we know if it stopped working?
· 1 session
The post-incident batch landed — back-design discoverability, cancellable generation, an end-to-end purchase test running in the payment provider's test mode, and route coverage — alongside a migration plan for the new data model. That end-to-end test then ran live for the first time and passed, once adapted to a checkout page the provider had quietly redesigned.
A reported bug where back-side previews always showed the wrong design was reproduced locally and traced to storage keys that omitted the very distinction the cache key relied on — fixed with one shared key builder and a versioned cache. Separately, a warm cache for design threads and per-change disposable test databases landed, both aimed at test flakiness caused by everything sharing a single database.
week of Jul 13, 2026· 1 session
Synchronized repository state across development machines, verified an earlier fix had landed everywhere, pruned stale branches, and took stock of open work before the next push of feature development.
week of Jul 6, 2026· 1 session
A week entirely about hardening order fulfillment against someone else's outage. The centrepiece is a daily job that automatically retries orders that were paid for but never submitted — precisely the scenario where the fulfillment partner is unreachable at the moment payment completes and an order strands with nobody noticing.
The flow was also restructured so that generating a readable order name no longer sits in the critical path, with a timeout guard ensuring a hung language-model call can't push processing past the payment provider's deadline. The job merged and ran, though the absence of any logs raised a fair question: how would we know if it stopped working?