Ecommerce platform · 2024 — present
Colombiatodo CI SAS
Shipped an ecommerce platform end to end: storefront, CMS, payments, shipping and auth.
Context
Colombiatodo needed to sell online without an existing storefront or a backend team. The catalog, pricing and content had to be editable by non-technical staff, and checkout had to integrate Colombian payment and shipping providers.
I led the build as developer and designer: information architecture, storefront, headless CMS, checkout services and the integrations behind them.
My role
Web Developer & Designer — end-to-end ownership of the platform.
- Designed the storefront and its information architecture.
- Built the frontend in Next.js and React on top of a Strapi content model.
- Integrated payments, shipping, authentication and realtime data.
Decisions
Headless CMS over a custom admin
- Constraint
- The product team needed to edit catalog, pricing and content without waiting on a deploy.
- Options
- Build an admin panel from scratch
- Use a hosted commerce platform
- Model content in Strapi and expose it through an API
- Choice
- Model the catalog in Strapi and consume it from Next.js.
- Why
- Content modeling is a solved problem. Building an admin panel would have consumed the schedule and still been worse for the people who use it daily.
One API service instead of scattered functions
- Constraint
- Checkout needed payment webhooks, shipping quotes and auth without a backend engineer on the team.
- Options
- Serverless functions per integration
- A single Fastify service
- A no-code integration layer
- Choice
- A single Fastify service with typed contracts, backed by Supabase and Firebase.
- Why
- One deployable service kept the integration logic in one place, which matters when one person owns the whole path from cart to confirmation.
A performance budget, not a rewrite
- Constraint
- Catalog pages loaded slowly on mobile networks, and the stack was already shipped.
- Options
- Move everything to a CDN and hope
- Rewrite the storefront
- Set a budget and audit images, fonts and JavaScript
- Choice
- Set a load budget and fix the largest contributors: image sizes, font loading and JavaScript on catalog pages.
- Why
- Load time dropped roughly 25% without changing the framework or the team's release rhythm.
Outcome
The platform launched with catalog, checkout, payments, shipping and authentication working together. Sales stopped depending on manual channels, and the catalog is maintained by the business team.
- −25%
- page load time in production
- 1
- platform delivered end to end
- 5
- integrations shipped: payments, shipping, auth, CMS, realtime
Lessons
- Owning design and implementation at the same time removes handoff cost, but it also removes the person who catches your assumptions. I started writing decisions down before building them.
- A performance budget survives future features; a one-time optimization does not.