Portfolio

Last updated: May 2026

ARKA: a configurator and a real checkout on one page

ARKA is a carved walnut object that holds solid 50 mm spheres, made to order in a first run of twelve. Urbano DX designed the product, built the page, and runs the orders. Every decision a buyer makes changes the specification and the price in front of them, and a small API re-checks the whole configuration, including the shipping country, before Stripe is ever asked for a payment page.

The product page opens on one form and one claim, with the render labelled as a render
The product page opens on one form and one claim, with the render labelled as a render
Three decisions (sphere count, form, material) with mass and price recomputed on every change
Three decisions (sphere count, form, material) with mass and price recomputed on every change
The range: nine forms, each with its own dimensions, mass, and bench time behind the price
The range: nine forms, each with its own dimensions, mass, and bench time behind the price
The specification table and the reserve form, both generated from the same source of truth
The specification table and the reserve form, both generated from the same source of truth

Buyer Guide

How to review ARKA: a configurator and a real checkout on one page

ARKA: a configurator and a real checkout on one page is a proof asset: it shows how Urbano DX expects software and AI sprints to be scoped, reviewed, delivered, and handed over. The point is to replace vague promises with concrete artifacts a buyer can inspect.

When reviewing a proof asset, look past the surface. The important questions are whether acceptance criteria, data assumptions, risks, ownership, and the next decision are clear. A good sprint output supports procurement and business review, not just a nice demo.

Use this page before a first call to align expectations. It helps buyers know which materials to prepare, how to judge a demo, and what should remain useful after the sprint ends.

Evidence to inspect

Working surface, demo path, risks, assumptions, and acceptance criteria.

Internal use

Procurement, budget approval, security review, and next-scope planning.

Good output

Something reusable, handover-ready, and clear enough to explain.

What it is

A single page that sells a physical object. Nine forms, three sphere counts, four sphere-material choices, and an optional engraving, all of it made to order in a first run of twelve and shipped within six weeks. The imagery is rendered rather than photographed, and the page says so next to every picture instead of hoping nobody asks.

  • Nine forms, from a long flat piece to a standing sculpture
  • Copper, steel, ceramic, or a mixed set of spheres
  • Live specification: dimensions, mass per sphere, total mass
  • Every plate opens full screen and turns on rendered frames

What was built

A prerendered static page in front of a small FastAPI service. The catalogue is one source of truth: masses are computed from material density rather than typed in, the server mirrors only what it must validate, and a test fails the build if the two ever disagree. Reserving posts the configuration to the API, which re-checks the form, the material, the engraving, and the shipping country, creates the Stripe Checkout Session with that configuration attached, and emails the studio the intent. The webhook that confirms payment is idempotent, so a retry from Stripe cannot produce a second order.

  • Configurator with live mass and price, no page reloads
  • Server-side validation of every combination before payment
  • Stripe Checkout Sessions carrying the configuration as metadata
  • Idempotent payment webhook plus studio notification email
  • Stack: Vite, React, TypeScript, FastAPI, Stripe, nginx

What it demonstrates

This is the difference between a payment link and commerce. A payment link cannot refuse an unshippable country, cannot keep the page and the payment agreeing on what was ordered, and cannot capture the buyer before the money. Moving those rules to the server is a day of work that removes a class of support tickets, and the same pattern carries straight over to client quote flows, booking flows, and configurable products.

  • Product rules live on the server, not in the button
  • Catalogue drift is a failed build, not a customer complaint
  • The page still reads and sells with JavaScript blocked
  • One pattern for any configure-then-pay flow

Scope the first sprint

Bring the app, API, LLM feature, or AI workflow you want to test. We will turn it into a clear first-sprint scope.

Start a conversation