Arca Tierra · a custom e-commerce platform

In one line: storefront, admin panel and API for an organic-food business in Mexico City, with me as the sole architect. It is in production and the operations team uses it every day.

The problem it solves

Arca Tierra sells agroecological food from small Mexican producers, runs farm experiences in the Xochimilco wetlands and delivers to homes in Mexico City. Before the platform, that business ran on separate tools: spreadsheets for deliveries and cut-offs, and a third-party SaaS tool for private reservations. The platform puts products, subscriptions, experiences, payments, deliveries and reporting in one system that the team controls.

Who uses it

• Customers buy food one-off or by subscription, book experiences and check whether their postal code is inside the delivery zone before they pay.
• The operations team works from an admin panel: orders, reservations, refunds, delivery cut-offs, reports and catalog.
• Each team member sees only what their role allows. A user with no role is denied.

What it does

• A storefront with search, categories and filters, with one-off purchases and subscription baskets. The public catalog listed 120 products on October 13, 2026.
• Experiences: a public calendar and private reservations. The private-reservations module replaced the SaaS tool the team used before. It was built phase by phase, and the client approved each phase before the next one started.
• Delivery zones: the checkout validates the postal code before the customer signs in.
• Payments through Mercado Pago. Refunds are restricted to one role, because they move real money.
• Reports and cut-offs. The team's weekly cut-off sheets are imported and generated by the system, and they come out identical to the client's own spreadsheet: 41 of 41 cells checked.
• Access control that fails closed:
  • 178 endpoints check a role permission before running.
  • In 25 admin modules the check sits on the router, so a new endpoint there is born protected.
  • There are 6 roles and 29 permissions.

How it's built

• Backend: Python and FastAPI, with asyncpg on PostgreSQL and Redis for caching.
• Frontend: Next.js 15 with React 18, TypeScript and Tailwind. Sign-in with Google or email through NextAuth.
• Containers:
  • The API, the web app, the database and the cache each run in their own Docker container.
  • They talk to each other over a private internal network, behind one reverse proxy (Traefik). Only the proxy faces the internet.
  • The customer database lives on that server.
• How a change ships:
  1. The new code is first run next to the live service and tested against the real database.
  2. Only then is the image rebuilt, from scratch.
  3. Before the switch, the image is checked against the tested source.
  4. Every change to the database is preceded by a backup of the tables it touches.
• Tests run against the live site. What the screen says must match what the database says.

In numbers

Photos

The photos are of the public storefront only. The admin panel is not shown, because it holds real customer data.

Two things worth pointing out

• A fix, end to end. A payment webhook read a field the provider never sends, so net amounts were empty. The fix moved three call sites to one reader, and a backfill reconciled every payment to the cent.
• A search fix, measured before it ships.
  • Today's keyword search returns nothing for 41 of 48 typical customer searches.
  • A local multilingual embedding model, on the same server so customer data stays home, finds the right product in the top 5 for 85 % of them. An English-only model gets 69 %.
  • Measured October 3, 2026. It is not in production yet.