Bookish Boutique: Validating a Direct Sales Platform Through Technical Prototyping

After five years working with independent authors, I kept hearing the same frustration:

Their options were limiting. Most storefronts buried their brand identity under generic one-pager templates. Custom websites demanded $10K+ investments plus ongoing developer costs. E-commerce platforms required cobbling together confusing plugins and rising fees that ate into already thin margins.

Spotting a Niche Opening

While there's no shortage of SaaS solutions for selling digitally, even with Merchant of Record services, there are almost no online solutions that allow authors to sell both physical and digital goods together. Audiobooks, ebooks, paperback, and hardcover products need extremely niche fulfillment solutions. On top of that, authors need ways for their fans to connect to them and a way to funnel them to their latest releases. Generic ecommerce just isn't set up for this.

My market research validated the many conversations I'd had with authors: 300,000+ indie authors currently juggle 5-6 different services costing $1,000-2,500 annually, and 33% more plan to start selling direct within the year. While this $2-4B market won't excite YC or moonshot VCs seeking unicorn exits, it's perfect for building a healthy, sustainable business serving professional authors desperate for a solution that actually understands their needs.

I set out to validate a solution.

Architecture-First Design

Unlike traditional projects where I'd start with UI mockups, Bookish Boutique forced me to flip my process.

I began by learning Next.js 14's router system, then the headless framework constraints. I dove deep into Swell's commerce API and discovered what it could and couldn't do. I took many wrong turns, refactored, and learned to ask more and more questions before introducing each new feature. This meant mapping information architecture based on those realities rather than wishful thinking. Only then could I design interfaces that worked within the technical boundaries, using Figma as a thinking tool rather than the source of truth. This aligns with industry findings that wireframes often fail to represent final products, with design teams reporting 'no drawbacks from ditching wireframes' after years without them.

This inside-out approach shaped many design decisions. For instance, understanding that Swell's CMS capabilities were limited for media storage led me to architect a hybrid solution—using AWS S3 for author assets while leveraging Swell for product data. This technical insight directly influenced the UI, determining where I'd need to build custom uploaders in the author dashboard versus relying on existing commerce infrastructure.

1. Social Share Cards: Making the Invisible Visible

During my conversations with authors, I discovered they were frustrated when sharing their books on social media. Many marketplace platforms prioritize their own branding in social share cards—when authors share their products, they're often promoting the platform more than their own work.

I made a deliberate choice: each author's subdomain would have its own unique share card. This wasn't about fixing broken previews—it was about brand continuity. When authors share their sites, they're promoting their own brand, not mine. The visual editor shows exactly how posts will appear when shared. Behind the scenes, the system generates Open Graph tags, optimizes images, and ensures cross-platform compatibility.

By giving each author control over their social share appearance, I reinforced the bespoke nature of their sites. This decision came from understanding that authors wanted to feel ownership over their digital presence—not like tenants on someone else's platform.

2. Focused Editing: Reducing Cognitive Load Through Isolation

In my conversations with authors, a pattern emerged: they abandoned website edits because traditional CMSs overwhelmed them. Too many options, too many things that could break, too much visual noise.

My solution: radical focus. Click edit, and a drawer overtakes the screen showing only that section. No global navigation, no unrelated settings—just the content you're editing and its controls. Changes preview instantly in isolation.

This constraint-driven approach emerged from building solo. I couldn't create a complex page builder, so I created something better: an environment where authors never feel lost. They edit one thing at a time, see exactly what changes, then return to the full view.

The drawer showcases my design philosophy: guided defaults with deeper control available. Text colors automatically switch to maintain contrast—a smart default that keeps sites accessible. But authors can override this with custom colors if they choose. This balance emerged from understanding that authors wanted beautiful results with minimal effort, but also the option to customize when inspiration struck.

Design intent: Create an experience where minimal changes produce professional results, while preserving the freedom to go deeper. Remove decision fatigue without removing decisions.

3. Books Aren't T-Shirts: Rethinking Product Architecture

I started with a standard e-commerce pattern: one product, multiple variants. Then I hit Swell's limitation—variants share attributes, but ebooks and paperbacks need completely different fields.

Instead of fighting the system, I redesigned around it. Each format became its own product with tailored experiences. This "limitation" unlocked better UX: audiobook listeners can rate narration quality, ebook readers review formatting, and paperback buyers comment on print quality. Each format gets its own reviews, pricing strategies, and promotional tools.

Why this matters: This design choice creates focused user experiences. Authors can optimize each format independently—different descriptions, format-specific reviews, even release dates. Readers find exactly what they're looking for without landing on an irrelevant primary format option. If an author wants to create a custom landing page for their audiobook release, that's possible while keeping other formats just a click away. Behind the scenes, it opens powerful possibilities: tracking deep links to specific formats, analyzing customer preferences by product type, and building format-specific marketing campaigns. Yet to users, it feels as simple as choosing between buttons.

Rapid Design Iteration Through AI-Assisted Development

In previous projects, this initial design would have been the first of many static mockups—weeks of iterations before any functional testing. But industry practice is shifting. Leading design teams are finding that wireframes rarely survive the iterative nature of modern product development, often becoming outdated artifacts that slow teams down. With AI assistance, I went directly from early-stage concepts to polished, functional UI. Every design decision was immediately testable with real data and interactions.

This approach reflects emerging industry practices. With modern design tools and systems, many teams find that jumping straight to branded, high-fidelity work takes no more time than creating grayscale boxes. Tailwind CSS amplified this efficiency. Instead of writing custom styles, I could explore variations instantly: adjusting spacing, testing color combinations, fine-tuning responsive breakpoints. The utility-first approach meant design decisions translated directly into code, with AI helping me implement complex interactions in minutes.

The evolution from before to after tells a story of discovery through doing. That drag handle on the right side? It seemed logical in the wireframe, but the moment I tested it with real content, I watched text get cut off and action icons cluster awkwardly. Moving it to the left took seconds to implement and immediately felt right.

The sub-navigation transformation was even more revealing. My initial block-based design looked clean in isolation, but once I built the full page hierarchy, everything blurred together. Switching to an icon list with Tailwind's utility classes created instant visual separation. I could see the hierarchy breathe.

Perhaps my favorite discovery came from eliminating friction. That "See Changes" button seemed necessary—until AI helped me implement real-time updates. Watching changes save automatically as users dragged sections into new positions felt like magic. The interface became conversational rather than transactional. This kind of rapid experimentation is becoming more common as design teams embrace AI tools for prototyping. As IDEO discovered when building their GPT Prototyper, teams no longer have to wonder if an interaction is possible—they simply build it and give it a try. This shift from speculation to experimentation compresses what once took weeks into days of work.

When Performance Shapes Design

Working in code exposed truths that mockups hide. That beautiful variable font I'd fallen in love with? It doubled page load time. The hero images that looked stunning in Figma needed art direction at different breakpoints, not just scaling. Every animation I added was immediately tested against performance metrics.

Real API delays revealed something deeper than just where to add skeleton screens. They exposed the nuances of waiting states—when to use a spinner inside a button versus a full skeleton layout, when a subtle progress bar beats a loading overlay. Context matters: uploading a file needs different feedback than submitting a form. These micro-decisions about loading states are what make an interface feel polished versus merely functional.

The Reality of Headless Commerce

Building Bookish Boutique taught me lessons no amount of documentation could have provided. What started as an exploration of headless commerce architectures evolved into a masterclass in the delicate balance between platform capabilities and user needs.

The most surprising discovery came from implementing multi-site architecture. I'd theorized that a single platform could power multiple author storefronts, each with isolated data and unique branding. The theory proved sound, but the implementation revealed nuances I hadn't anticipated. Session management across domains, cart persistence between sites, and maintaining separate analytics streams—each challenge pushed me to think more systematically about data flow and user context.

Working within Swell's constraints transformed from frustration to inspiration. Their variant system, which initially seemed limiting compared to more flexible platforms, actually forced cleaner product architecture. Instead of endless customization options that would overwhelm authors, I designed around curated choices. This constraint-driven approach echoed throughout the project—every platform limitation became an opportunity to simplify the author experience.

Headless commerce promises infinite flexibility, but building on these platforms revealed a different truth: APIs have opinions, and those opinions shape your design. Every API call introduced latency that needed visual acknowledgment. Data that arrived in fragments required progressive disclosure patterns. The gap between clicking "Add to Cart" and seeing the update wasn't just a technical detail—it was a design problem that needed solving.

Integrating Stripe with Swell exposed the complexity hiding beneath simple checkout flows. Payment processing isn't just about moving money; it's about handling failed cards gracefully, managing subscription states, and providing clear feedback at every step. Each edge case I encountered—expired cards, international payments, disputed charges—required both technical implementation and thoughtful UX decisions.

State management emerged as the invisible foundation of the entire experience. Coordinating data between Next.js, Swell's API, and Stripe's webhooks felt like conducting an orchestra where each musician played at a different tempo. The solution wasn't just technical—it required designing interfaces that gracefully handled uncertainty, that communicated system state without overwhelming users with technical details.

Beyond Technical Implementation

This project fundamentally changed how I approach design partnerships. When developers mention API limitations or caching strategies, I understand the implications for user experience. When they suggest alternative implementations, I can visualize not just the technical architecture but how it will feel to users navigating the system.

The ability to speak both languages—design and development—transforms collaboration from translation to conversation. Instead of defending design decisions against technical constraints, I can propose alternatives that achieve the same user goals through different means. This shared vocabulary accelerates decision-making and builds trust across disciplines.

Perhaps most importantly, building this prototype confirmed what I'd long suspected: the best designs emerge from understanding the whole system, not just the surface. Every technical decision cascades through the user experience. Every design choice has infrastructure implications. The magic happens when these perspectives merge into solutions that feel both inevitable and effortless.

The Designer I've Become

Building Bookish Boutique fundamentally reshaped how I approach product design. Where I once saw interfaces, I now see systems. Where I once designed in isolation, I now think in architectural ripple effects. This project taught me that the symbiosis between design and execution isn't just about making things work—it's about balancing aesthetic ambitions, practical constraints, and intuitive user experiences while understanding how each decision cascades through the entire system.

I no longer design just interfaces; I design systems. Every component decision now considers the whole—how data flows through the application, how state is managed, how scalability influences even my earliest concepts. This shift happened gradually as I built. Each feature I implemented taught me to see the connections I'd missed in static mockups.

Working in code gave me pattern recognition that makes me a better design partner. I can diagnose technical issues that affect design because I've lived through them. When a developer says something is complex, I understand why. When they suggest an alternative approach, I can visualize the implications. I've learned that many "design problems" are actually technical constraints in disguise, and recognizing them early saves everyone time.

Perhaps most importantly, I've learned to embrace constraints as creative fuel. Platform limitations that once frustrated me now spark innovation. Technical boundaries that seemed restrictive now focus my solutions. "We can't do that" has become "what if we..." in my vocabulary. Swell's variant limitations led to better product architecture. Next.js routing constraints shaped cleaner information hierarchy. Every restriction became a design opportunity.

This project validated something I'd always believed but couldn't prove: prototypes answer questions mockups can't. Building working code reveals truths that no amount of stakeholder review can surface. It becomes the best specification because it forces honesty about what actually works versus what we hope might work.

This architecture diagram reveals the scope of what emerged from rapid prototyping. What started as a simple storefront concept evolved into a complete ecosystem—author dashboards, customer portals, fulfillment workflows, and analytics. Each component was designed and built with the same principles: author ownership, reduced complexity, and thoughtful constraints.

A Strategic Decision

This project accomplished exactly what I intended: I prototyped an end-to-end commerce experience using a headless stack—Next.js, Swell, and Stripe working in concert. The technical implementation proved the concept's feasibility and deepened my understanding of marketplace complexity through real implementation. Every edge case I hit, every API limitation I worked around, every user flow I optimized—these experiences can't be gained from documentation alone.

While the prototype successfully demonstrated technical feasibility and validated key design patterns, I made a strategic decision not to pursue production deployment. Having previously navigated the challenges of bootstrapping a startup with Zory, I recognized that bringing Bookish Boutique to market would require significant time and resources that didn't align with my current career objectives.

This experience reinforced an important lesson: knowing when to transition from exploration to focus is as valuable as the ability to execute. Rather than pursuing another lengthy startup journey, I'm excited to bring these cross-functional skills to an established team where I can concentrate on what I do best—designing products that balance user needs with technical reality. The insights gained from building this proof-of-concept have proven invaluable for understanding how modern commerce platforms shape user experiences.

What I Bring Forward

What I bring to my next role has evolved beyond traditional design deliverables. I offer deep understanding of the problem space, validated through real implementation. I've developed design patterns that work within headless commerce constraints, not theoretical ones that assume infinite flexibility. My experience building custom frontends that integrate with existing commerce infrastructure means I can architect solutions that leverage platform APIs while creating unique user experiences. I understand the technical cost of design decisions because I've paid it.

Lessons for the Design Community

For product designers considering a similar journey, my advice is simple: learn enough about the technology to design within reality, not despite it. Build something—even if it's imperfect—because the act of building teaches lessons no tutorial can capture. Let constraints guide you toward better solutions rather than fighting them for familiar patterns.

Teams benefit when designers understand implementation. We make better decisions when we grasp the technical implications. Prototypes teach lessons that documentation can't capture—about performance, about edge cases, about user behavior. Cross-functional skills don't replace specialization; they multiply impact by enabling better collaboration.

For projects like this—building on existing platforms with technical constraints—start with the hardest technical challenges first. Design the system before the interface. Validate with real functionality, not just mockups. The constraints that seem most limiting often lead to the most innovative solutions.