MotoFuji · Side project

August 2026 – present

Making Japanese motorcycle auctions clear to Polish buyers

A side project for a friend’s workshop in Warsaw that imports motorcycles from Japan. With a back-end developer, I build the whole digital side of the business. I own the product and everything the buyer sees.

Visit aukcje.motofuji.pl (opens in a new tab)

Role
Product and design lead · front end built with AI coding agents
Team
A back-end developer, the business owner and me
Stack
Claude Code (the app runs on .NET and Blazor)
The MotoFuji import landing page in English: “The best examples are in Japan”, a search by manufacturer and model, and lots currently at auction under it.
The import landing page starts with a search by make and model and shows the lots now at auction.

7%

median price error, down from 18%

3,000+

lots from Japanese auctions in one catalogue

80

pull requests, August – October 2026

Context

MotoFuji is a friend’s motorcycle workshop in Warsaw that also imports motorcycles from Japanese auctions. A back-end developer had already written the auction parser, the API and a basic catalogue. I started as an adviser. Since August 2026, I have designed everything the buyer sees and built the front end with AI coding agents.

The problem

The catalogue was built around the database. It did not answer the questions a buyer has. What does the auction sheet say about this bike? What do similar bikes sell for? And what will this one cost in Poland?

What I did

A price card that buyers can use

The first price card had a purchase price field that buyers did not know they could change. I replaced it with a slider, but on real lots it was awkward to use. So I tested the estimate on 338 past sales. An estimate from the start price had a median error of 18.1%. An estimate that also used comparable sales had 7.4%. I shipped the new card the same day. Its first and largest number is the price in Poland.

A lot page for a Kawasaki Z900RS SE: the photograph and thumbnails on the left; on the right, the card “Estimated price in Poland” with “PLN 56,500” and minus and plus buttons, a scale marked “usually 53,900–60,300” and “11 sold”, the starting price and the forecast in yen, and a red button “Bid for me · up to PLN 56,500”.
The new card shows the price in Poland first, with plus and minus buttons and the usual range below.

One catalogue for lots on sale and sold lots

Lots on sale and sold lots were on two pages, because the database had two tables. When no lots on sale matched a search, the page said “Nothing found” and gave no link to sold lots. I combined the two pages into one catalogue with a switch. For the filters, I compared seven reference sites and took ideas from four. I did not add a “not damaged” default, because on real data it would hide nothing.

The catalogue with the switch between available and sold lots, its filter panel fully open — manufacturer, model, year, engine size, mileage, rating, frame number type, damage, the auction houses BDS, Aucnet, JBA and ARAI, “Only with photos” and “Exclude unknown mileage” — and to the right the three active filters as chips, “3,096 lots found” and the first lots.
One catalogue shows lots on sale and sold lots, with the filters on the left and active filters on top.

Teaching buyers to read an auction sheet

Each bike at a Japanese auction comes with an auction sheet: grades, mileage and the inspector’s notes. The import landing page explains it in seven steps, on a real lot page from BDS, a Japanese auction house. It took four versions. A drawing of our own lot page explained less than the real one, so the final version uses the real page.

“How to read an auction sheet”: numbered steps on the left with step 01 of 07 active, and on the right a lot page from the BDS portal for a Ducati 1199 Panigale S, its header outlined in red.
Seven steps walk through a real BDS lot page, and the current part is outlined in red.

Rules for building with AI agents

Two people work on this product with AI agents, so the working rules live in the repository. Each rule comes from a real incident. Once I opened the site on a phone and found a page that scrolled sideways. Since then, every pull request is first checked at six to eight screen widths. My pull requests merge only after the tests pass and I approve them. Before my first pull request, I suggested the back-end developer try Claude Code, and he did.

Three phone screens: the import landing page with its search, the catalogue with filter chips and a lot card, and a Kawasaki Z900RS SE lot page down to the start of its price card.
Every pull request is checked on phone screens like these before it opens.

Results

  • 80 pull requests shipped from August to October 2026, all built with AI coding agents.
  • Test files in the repository grew from 3 to 93.
  • The site is live with real auction data, and the workshop is preparing its official launch.

Who did what

  • Me: product and design decisions, everything the buyer sees, the admin portal’s screens and the rules for working with agents.
  • Back-end developer: the auction parser, the API, hosting and deployment, and the sign-in service.
  • Business owner: all real content (photos, prices, history) and business decisions.

What I learned

  • A default filter is a promise to the buyer about what they will see. I add one only when real data supports it.
  • Test a design on real data early. The slider looked fine in the mockup but was hard to use on real lots.