A store that sells — with checkout and inventory in one flow.

Problems we hear

Typing every order into Excel by hand creates two failures at once: missed rows and the wrong “latest” file. It holds when volume is low. It breaks the week orders jump.

When checkout and inventory are not connected, a sold item still looks available on the sheet. Shortages surface at packing time. One person ends up both apologizing to the customer and reconciling stock.

Marketplace fees add up like a fixed cost. Teams want their own site, but cannot picture checkout, payments, and the work after the sale. The move stalls.

Many companies already have a homepage with no way to buy. Company facts are in place; a purchase still drops to phone or email. Closing that gap on the site is where this work starts.

What we cover

We build new corporate sites with commerce, and we add buying to a site that is already live. Pages come after the relationships among products, stock, orders, and payments are decided.

Stripe card payments include more than a form: success, failure, refunds, receipts, and a notice to the operator. A paid order that nobody inside the company hears about is a gap we do not leave.

Orders flow into admin sheets and stock records. The goal is not zero human work; it is that people only handle exceptions — shortages, split shipments, returns. When you need an internal stock screen, we pair this with the inventory and order system.

Subscriptions and member pricing are in scope. A different price after the first order, or products only members can see, is not a checkout setting alone. Member records have to join the order.

Checkout is not the finish line

The usual failure after “we added payments” looks like this. The customer has already paid. Inside the company, someone prints the order mail, eyes the stock sheet, and writes the ship date on another sheet. Only the payment is automated. The steps around it are unchanged. Volume makes the step larger.

If confirmation, allocation, and shipping stay manual, the same order is processed twice, or another order spends the last unit first. The breakage is on the internal sheet, not in the payment dashboard, so it is hard to see from outside.

We decide first what happens to which data, in which order, when one order arrives. A successful payment starts the stock decrement. If stock is short, we stop before confirm. After shipping, the order status moves. People step in for exceptions and customer contact. That order is fixed as a data flow, not as a paragraph in a manual.

We judge the work by whether the next morning has less typing, not by how the storefront looks. Buying and the work after buying feel like two projects; for the customer they are one purchase. Holding both sides is the point of this page.

Technical setup

New builds use Next.js and TypeScript, Stripe for payments, and MySQL for records. We do not drop in a larger platform than the shop needs. Product master, stock, orders, and payment events sit in one design.

We can add payments and product pages to a WordPress site already in production. A full rebuild is not assumed. We look at the theme and plugins first, and keep the current editing habit where it still works. A working picture is on the EC demo.

Timeline and cost

Four to eight weeks, from ¥500,000. Catalog size, membership features, new versus add-on, and the reach of inventory updates change the number. All listed prices exclude tax. In the first call we ask where you sell now, who does what after an order, and which sheet holds stock.

Questions we hear

Talk through commerce and payments, at no charge.

It is fine to come in at “we want our own site, but today’s order handling would still be there.” First consult and quote are free.