ShopaBlock didn’t start as a “startup idea”. It started as friction — the kind you feel when the simplest intention (sell one thing) forces you into decisions that have nothing to do with the thing itself.

Most commerce products are built like operating systems: infinite options, infinite settings, and a dashboard that quietly assumes you’re already a company. The platform becomes the work. The product you’re trying to sell becomes a detail inside someone else’s framework.

ShopaBlock flips that. It treats small-scale selling as a first-class use case, not a watered-down “lite” mode. The system stays strict so the surface can stay calm. The goal was to create something you can share in seconds, trust immediately, and grow later — without ever forcing you to build a shop just to sell a single object.

The goal wasn’t “compete with Shopify”. Shopify is brilliant — for shops. The problem is that the default shape of commerce has become the default shape of selling. If you’re not building a shop, you end up fighting the tool.

I wanted a system where a single product is not a compromise. A product should be able to exist independently: clear media, clear price, clear checkout, clear delivery, and a URL that behaves like a real object you can pass around.

The business goal, in plain terms: make commerce feel lightweight without making it fragile. Keep it credible. Keep it durable. Keep it simple enough that the user feels in control, but structured enough that the product can scale.

Most commerce platforms are built for companies, not individuals. If you want to sell a single product — a digital file, access, a service, a one-off item — you’re usually forced into heavyweight storefront builders, complex dashboards, and configuration that only makes sense once you’re operating at scale.

On the other end, lightweight tools often remove so much structure that they break the moment you need control: predictable URLs, decent branding, reliable payments, ownership of customer data, or even just a flow that feels trustworthy.

The core tension is simple: the tools are either too big to start, or too small to grow. ShopaBlock is an attempt to remove that gap.

Instead of designing around storefronts, I designed around a single primitive: the Block.

A Block is not a page and it’s not a product listing. It’s a self-contained commercial object. It owns its media, pricing, checkout, and delivery. It doesn’t depend on global navigation to explain itself. You can paste the URL anywhere — a message, a bio, a tweet — and it still reads as a complete product.

That shift sounds small, but it changes everything. Once the Block became the unit of value, every feature had to justify itself against that model. If it didn’t make the Block clearer, faster, or more transferable, it didn’t belong in the product.

This is the part most commerce tools miss: the user isn’t trying to build software. They’re trying to sell something. The Block makes the selling the point again.

The name ShopaBlock reflects the product logic directly. “Shop” makes the intent obvious. “Block” signals modularity and composability. The goal wasn’t clever branding — it was clarity.

The name explains how the product works without marketing language. It also leaves room for the system to grow: blocks can become catalogs, catalogs can become collections, collections can become ecosystems — but the primitive stays the same.

Visually, ShopaBlock is deliberately restrained. The UI is calm, neutral, and product-first. Typography, spacing, and hierarchy do more work than decoration — because trust is built through clarity, not noise.

The interface is designed to feel credible and durable. It should look like a tool you’d trust with money, not a template you’ll outgrow in a month.

I approached ShopaBlock as a system, not a collection of screens. Before UI, I mapped the core journeys: create a block, add media, set a price, connect payouts, share the URL, complete checkout, fulfil delivery.

Each step was reduced to the minimum number of decisions required to move forward. Where possible, defaults replaced configuration. Structure replaced instructions. Constraints replaced tutorials.

The biggest challenge wasn’t adding features. It was deciding what not to expose — and where to keep power behind the scenes without making the experience feel limited or vague.

Before polishing UI, I designed the underlying logic. Blocks, orders, users, and payouts are cleanly separated. Public URLs are predictable by design. Blocks can exist independently without requiring a storefront or catalog to “complete” them.

Orders are treated as immutable records rather than UI artifacts. That decision keeps the system honest: a purchase is a fact, not a stateful UI moment.

The goal was to make the product simple because the system is strict — not the other way around.

Because I was both designer and builder, design and implementation happened in a single loop. Every UI decision had a real technical consequence, and every technical constraint fed back into clearer UX.

I built ShopaBlock using Next.js and TypeScript, with Prisma and PostgreSQL for data modelling, and Stripe-based payment flows (with KompiPay integration points where relevant). There was no handoff phase. No translation layer. The system was designed the way it was built, and built the way it was designed.

That loop is what makes the product feel coherent: the interface isn’t a “skin” on top of a backend. It’s a direct expression of the underlying model.

ShopaBlock doesn’t try to replace traditional e-commerce platforms. It solves a different problem.

There’s no storefront setup, no themes, no unnecessary dashboards. One block equals one product, one URL, one clear purpose. It works for selling a single item today, and it can grow into a broader catalog later — without ever forcing the user to rebuild their workflow.

The product stays small on purpose. Not because it’s missing features, but because it refuses to expose complexity that doesn’t serve the core action: selling.

ShopaBlock is a fully working product and a foundation for a larger modular commerce system.

More importantly, it represents how I approach product work: system-first, opinionated, and deeply connected to implementation. Designing the interface is only part of the job — designing the logic underneath it matters just as much.

This project wasn’t about shipping fast or chasing trends. It was about owning ambiguity, making decisions without safety nets, and building something I’d actually want to use.

ShopaBlock is less a one-off project and more a blueprint for how I think about products.