Case study
Revolico
Frontend engineering for search, listing detail, publishing, contact, admin tools, mobile web, and performance.
Revolico is a classifieds marketplace for Cuba. I have worked on and maintained its frontend since 2017 across search, listing detail, publishing, contact, admin tools, and mobile web.
- Role
- Frontend engineer, Current maintainer
- Period
- 2017-Present (maintainer)
- Scope
- Frontend engineering and product UI across marketplace search, listing detail, publishing flows, contact paths, admin and moderation interfaces, performance work, and testing.

Since 2017
A frontend refactor became ongoing product development
I started working on Revolico in 2017 by refactoring its frontend for a new version of the product. Since then, I have continued developing marketplace functionality across search, category browsing, listing detail, publishing, seller contact, admin tools, and mobile web.
I am now the frontend maintainer. That means new work starts with the product as it actually behaves, including the URLs, cached data, forms, operational tools, and user habits that have accumulated over time.
- 2017 frontend refactor
- Search, listing, publishing, and contact flows
- Admin tools and moderation
- Ongoing frontend development and maintenance
Marketplace paths
Keep the actions people repeat fast and familiar
People return to the same paths: search, scan results, adjust filters, open a listing, publish an ad, or contact a seller. Small delays and unclear state become noticeable because those actions repeat across sessions and categories.
I keep titles, prices, locations, images, filters, and contact actions easy to find, then preserve the user's context as they move between results and detail. Mobile web carries the same jobs without hiding the information needed to make a decision.

Change over time
Modernize without breaking marketplace habits
Revolico spans vehicles, property, technology, employment, services, household items, and many other categories. Content quality, image sizes, device constraints, and connection speed all vary.
The refactor and later changes had to preserve useful habits and contracts. Search URLs, server-rendered pages, cached GraphQL data, authentication, publishing forms, and admin operations could not be replaced as isolated components.

Ongoing development
Refactor one boundary at a time
React and Next.js replaced older frontend boundaries while GraphQL and Apollo kept data behavior explicit. SSR and SSG were chosen where the route and content benefited from them, and cache behavior was handled as part of the user flow rather than as a separate technical concern.
I treat publishing, contact, and admin interfaces as complete workflows with loading, validation, permissions, image handling, and failure states. Tests protect the repeated paths between search, detail, publishing, and operations; qualitative performance work focuses on rendering, images, data loading, and backend coordination.
- Preserve search state across results and listing detail.
- Make publishing progress, validation, and image handling visible.
- Keep admin permissions, edits, and moderation state understandable.
- Protect repeated marketplace paths with regression tests.


Maintainer perspective
The product keeps teaching the frontend what to preserve
The marketplace has continued to change while preserving its core loop: search, inspect a listing, return to results, publish, and contact a seller. My maintenance work protects that loop as rendering, cached data, authentication, and admin behavior evolve.
Years of production work have made the lesson cumulative. Clear search state, predictable publishing, tested data contracts, and understandable admin behavior matter more than novelty because people repeat those decisions every time they use the marketplace.
