← All work
Abe Used Mura Design + Full-Stack Build 2026

Abe Used Mura

A catalog that is not a store.

Role
Designer, Full-Stack Developer
Year
2026
not yet launched
Built
A catalog that is not a store

A Japan-surplus shop sells one-of-a-kind stock through a Facebook page, and a stranger cannot tell from that whether any of it is real.

Problem
A Facebook page cannot show a stranger that an item is real, graded honestly, and still on the shelf.
Built
A catalog and a phone-first admin, so one person can list an item in about three minutes from the shop floor.
Result
Designed from February 2026, in development since June, and the owner turned the calm home page into a storefront along the way.

Abe Used Mura sells genuine pre-owned goods from Japan out of one store in Angeles City, Pampanga, run by the same family behind Platinum Trucks and Daitoku Ramen and built on the same Cloudflare setup as both of those. No sale completes on the site, so a customer browses online and then messages, calls, or walks in, and every page ends with one of those three.

Build law

Three rules went down in writing before the first commit and never moved.

Build law 01

Phone-first admin, or the build failed

3 min per item, from a phone, in-store

One person keeps the catalog, listing items from a phone while standing in the store, so I designed the admin at 375px first with 44px touch targets and 16px inputs. If it only worked well on a desktop I would count the build as failed.

Build law 02

Every photo is the unit on the shelf

0 stock photos anywhere on the site

Secondhand stock is one of a kind, so a catalog photo has to be the actual item rather than a press shot of the same model. Grading follows the same rule, and when the person listing is torn between two grades they take the lower one.

Build law 03

Stale is worse than empty

0 surfaces allowed to visibly rot

If listing stops for a month, the site drops back to a brochure and stays presentable for as long as it needs to. Every surface has a defined state for neglect, so nothing on the public site can rot in a way a visitor notices.

  • 6 Reference sites I tore down before designing
  • Feb 2026 Design started, with development from June
  • 3 min To list one item, from a phone, in-store
  • 4 Condition grades on the public scale
  • 0 Sales the site completes on its own
  • 3 Rules I wrote down before the first commit
The research problems

Six references, torn down for one working mechanic each.

Southeast Asian marketplaces, Japanese secondhand chains, and premium resale, and I stripped each one of everything tied to checkout or accounts before translating it to a single shop where every item is the only one of itself.

5.1

Marketplace noise buries the product

Shopee and its peers lead with discount badges, countdowns, and urgency, and the item itself sits underneath all of it. I flipped that order, so an item page opens with what the thing is, then its condition, then its price, then whether it is still there, then how to reach the store.

5.2

Messenger links cannot carry a message for you

Carousell's card to page to chat loop was the model I wanted, pointed at Messenger instead. But m.me links do not reliably prefill text, so every item carries a short code with a copy button and the line "mention this code when you message us."

5.3

"Is this a scam?" gets louder as the price goes up

The bigger the amount, the more proof a stranger needs before they travel to a store. The answer is a real domain instead of a Facebook page, one condition scale of S, A, B, and C used on every item, and a condition-guide page anyone can read before they ask.

5.4

Deleting sold items throws away the proof

Mercari keeps sold listings up under a SOLD overlay, and that archive shows a stranger the shop actually sells things. Abemura items carry a status of available, reserved, or sold, and a sold item keeps its page instead of disappearing.

5.5

Cheap multiples eat the maintainer's day

Blind boxes are the one category that is not stock-of-one. Listing every unit would burn three minutes each on the items worth the least, so that category exists as one editorial page and nothing more.

5.6

Claiming more than the shop can back

Brand names appear as plain text and never as a wall of logos. The site never calls an item authenticated or appraised, since the shop cannot stand behind either word. No sale completes on the site either, so the store keeps selling the way it already does.

The UI/UX problems

Everything here gets edited on a phone, in a shop, one item at a time.

6.1

Unsaved work has to be visible on a phone

The editor runs five states, clean, dirty, saving, saved, and failed, so the screen always says whether the last edit made it. I also fixed which fields save together and never mixed those groups, because a phone browser can drop a tab mid-edit and the person listing needs to know what survived.

6.2

Destructive actions go last and say what they do

Delete sits at the bottom of the editor in a named danger zone, away from the fields someone touches every day, and it spells out what goes with the item. Nobody should hit it while thumbing down the page to change a price.

6.3

An empty category still has to answer someone

A category with nothing in it shows "Ask us, stock changes weekly" with the contact actions instead of a bare grid. Stock in this shop moves constantly, so empty is a normal state and I designed for it rather than treating it as a bug.

The incident log

One defect surfaced during the build, told straight.

Incident 01

One wide photo could shove the whole page sideways

What happened
Item photos come straight off a phone camera roll, so their shapes are all over the place. A wide one in the gallery pushed the item page past the edge of the screen at phone widths, and a shop whose photos arrive that way would hit it weekly.
The fix
I capped the gallery and every block around it so an image can never set the width of the page. The layout decides how wide things get and the photo fits inside that.
What it left behind
The person listing cannot break a page by uploading the wrong shape now, so it stays a layout rule instead of something they have to remember at 9pm with 30 items to go.
The build

Brochure to spec, then the owner asked for a storefront.

  1. 01

    Brochure or catalog was the first fork

    My first call was a brochure-only site, since a catalog nobody updates is worse than no catalog at all. The research changed my mind and the default became a maintained catalog, but only on the condition that a named person owns the listing, and I wrote the fallback down at the same time, so if nobody is named the site reverts to a brochure. I took the riskier option after deciding in advance what happens when it fails.

  2. 02

    The owner overruled the calm home page

    I built the first version to the original spec, so it opened on an oversized hero and ran down through a category grid, a "Just In" rail, a Facebook band, and a sold band. It was a quiet brochure that happened to have a catalog behind it. On 2026-07-19 the owner asked for a storefront instead, and the turn went through most of the front end. I deleted three components I had already built. Search had been parked under "do not build" and became the first thing on the home page. I did not defend the brochure, since it was built to spec, the owner saw it, the owner wanted a shop, so I amended the spec.

  3. 03

    Read a long playbook, then built none of it

    An articles-section playbook came in as reference material and I built no articles section from it. What I kept was one rule. An item that is not published cannot show up anywhere a customer can reach, whether that is a listing page, an item page, a related row, or a search result. Most of what kept the scope from running away was deciding what not to build.

The work

A public catalog and the admin that keeps it honest.

Outcome

Built and gated, not yet launched to customers.

No traffic or revenue numbers exist yet and I am not going to invent any. The site is built and gated, not launched to customers. What exists is a public catalog with a search-first home, category and item pages, and a condition guide, plus an admin behind a login where one person adds items, photos, categories, and the promotion banner from a phone. It is the third business in the family to run on this setup, after Platinum Trucks and Daitoku Ramen. The next thing worth measuring is the same as Daitoku's, whether the store actually runs it.

  • Built shipped and gated, not yet launched to customers
  • 3 min to list one item, from a phone, in-store
  • 3 family businesses now running this setup
Live problems

What's on the bench right now.

The site is built and gated, not launched to customers yet. Three items are open on the bench and one is solved and written up. Open a card to read where each stands.

Live 01 Open
Business, opening hours

The flyer and the Facebook page disagree on opening hours

  • The store's flyer and a Facebook post give different opening hours.
  • The site publishes no hours at all until someone at the store settles which one is right.
Open question

Publishing nothing costs the store a phone call. Publishing the wrong hours sends someone out to a locked door, so the site stays quiet until the store confirms.

Live 02 Open, pre-launch
Launch, admin access

The admin login list is still empty, so nobody can get in yet

  • The login gate in front of the admin ships with nobody on the list, so every attempt bounces.
  • It stays that way until the owner's and the maintainer's real email addresses are confirmed.

Live 03 Open
Business, launch info

Five launch facts are still blank, and one of them decides the rest

  • The domain, the store's Facebook page, the message link, the item-code line, and the person who will list items are all unconfirmed.
  • If nobody is named as the person listing, the catalog reverts to a brochure at launch, which is the fallback written into the spec.

Solved 04 Solved
Build, mobile layout

A wide item photo could break the page at phone width

  • Photos come off a phone camera roll, so one wide shot pushed the item page past the edge of the screen.
  • The layout now sets the width and the photo fits inside it, whatever shape it arrives in.

Live 01
Business, opening hours

The flyer and the Facebook page disagree on opening hours

Where this stands

Two sources at the store disagree about when it opens, so the site carries neither until one is confirmed.

Why the site says nothing

A visitor who finds no hours listed messages or calls, and that costs the store a minute. Confident wrong hours send someone out to a closed shop, and that costs the store the customer.

Live 02
Launch, admin access

The admin login list is still empty, so nobody can get in yet

Where this stands

The admin sits behind a login gate that ships with an empty list of people it will let through. Until I have those two real email addresses, the admin is unreachable for everyone, the owner included.

The owner has seen the public site and signed off on the storefront turn. That review happened on the front end, which needs no login. Getting into the admin to list an item is the part still waiting on two addresses.

Why it ships locked

An admin nobody can open is a known state that one phone call fixes. An admin the wrong person can open is not, so I shipped the version whose worst day is annoying.

Live 03
Business, launch info

Five launch facts are still blank, and one of them decides the rest

Where this stands

Five things are still blank in the spec: the domain, the store's Facebook page, the message link, the wording of the item-code line, and the name of whoever will actually list items.

The one that decides the others

Everything hangs on the maintainer. Build law 03 says a catalog nobody updates is worse than no catalog, so the spec carries a revert clause: if no name comes back, the storefront falls back to the brochure it was built from. The owner picked the storefront, and keeping it depends on somebody at the store owning the listings.

Solved 04
Build, mobile layout

A wide item photo could break the page at phone width

Closed during the build

This one surfaced while I was reading the item page at 375px, and it is fixed in the layout rather than in how carefully the maintainer uploads.

  • The incident log above has the full account.