Automating the colombian auction market

I owned the full product vision: database schema, design system, and AI pipeline, turning bureaucratic opacity into a marketplace worth paying for.

The spark and the blueprint

Last year, a complicated family situation forced me to look into buying a house in Colombia on a very tight deadline. I had just read a Wall Street Journal piece on fix-and-flip strategies and thought judicial auctions could be the perfect entry point. The reality was a brutal wake-up call. The information was fragmented, opaque, and buried in government portals from the early 2000s.

I envisioned Alafija to bridge this gap between public data opacity and investor clarity. The premise was simple: automate the brute force. I designed a system that programmatically scrapes thousands of chaotic legal records across multiple judicial branches, leverages AI models to classify and extract messy documentation into clean database entities, and serves it all through a searchable marketplace interface.

The competitive audit

Colombia Chile

Competitive analysis: the Colombian market leader vs. the Chilean equivalent operating in a market a third of the size.

I ran a competitive audit and the numbers told a clear story. The biggest player in the Colombian market was running a manual data entry farm: paying people to read legal edicts in local newspapers and manually upload posts to their platform. The leading Chilean equivalent, operating in a market a third of the size, pulls 120K monthly visits. The Colombian leader barely hits 17K. 300K unique monthly users at a conservative 2% sign-up rate was enough to keep going.

The strategy crystallized: automate the brute force with an AI pipeline, undercut the incumbent subscription price, and deliver cleaner data at a fraction of the operational cost. But before touching a single pixel or writing a line of code, I needed to prove this was a viable product and not just a frustrating personal edge case. I used AI to write a rigorous PRFAQ and a detailed PRD, the same frameworks I had used at Amazon for years. Core functionality, business logic, P0 constraints, and success metrics were locked before anything got built. You can take the designer out of Amazon, but you can't take Amazon out of the designer.

The PRD: core functionality, business logic, and P0 constraints locked before building.

The tooling shift

When you are a solo builder, speed and cognitive load are your primary design constraints. I did not need a shared source of truth in Figma to align engineering stakeholders, so I intentionally altered my design pipeline. In Figma, I only built the foundational design system tokens and structural task flows to map content requirements. Everything else happened in code.

To build the actual platform, I split my workflow across two distinct AI environments. Cursor to spin up documentation and design system pages, Claude Code for the heavier backend work. Cursor required constant micro-management. Claude Code excelled at continuous workflows: autonomously reasoning through complex files and executing long refactoring sequences. My time was better spent guiding the product than approving individual lines of code.

By offloading execution to the AI, I designed the entire UX directly in the browser using Next.js 15, Tailwind CSS v4, and Radix UI primitives. If I ever need to scale this into a proper company, modern plugins can instantly ingest the final semantic HTML back into Figma as auto-layout components and variants.

A proper Staff Engineer would have opinions about my codebase. But this prototype was built specifically to test market viability, not to pass a code review. If the product proves itself, I partner with dedicated engineering to refactor for production scale. If it does not, I scrap the repository and move onto the next idea. That is the beauty of building lean.

The universal UX and conscious tradeoffs

Because this was a zero-to-one validation phase, I indexed heavily on established marketplace heuristics drawn from e-commerce and real-estate platforms to lower cognitive load from day one. I mapped the core jobs-to-be-done based on known investor behaviors: compare opportunities, assess risk, act fast. This let me bypass a lengthy discovery phase and accelerate time-to-market without designing in the dark.

I have clear indicators of our core user personas (institutional real-estate investors, litigation lawyers, and retail bargain hunters), and deep qualitative research is on the roadmap once the engine proves itself. For now, data precision and usability at launch trump granular persona targeting.

The visual language was a deliberate choice. The design system is clean, geometric, and restrained: no gratuitous box-shadows, no rounded everything, no decorative flourishes. Borders are subtle and functional, spacing is generous, and the palette is neutral with high contrast where it matters. The aesthetic had to communicate what the product does: take chaos and impose order. Every surface signals precision, structure, and machine intelligence. My product is literally an AI parsing thousands of messy legal documents into clean data, the interface must play its part.

The interaction craft

With the backend nearly in place, I shifted focus to designing the full breadth of user-facing flows: login, onboarding, two-factor authentication, account recovery, subscription checkout, smart alerts setup, and the core marketplace experience.

I settled on a design that partially displays information for non-subscribed users. Enough to get their attention and understand the opportunity, but not enough to actively participate in a foreclosure or look it up on a separate platform. The free tier is a window, AND a door.

To drive monetization, I designed a three-tier pricing structure to anchor expectations and position plans as good, better, best. Free plan captures you with limited data. Second plan converts you with full access to all foreclosures. Third plan keeps institutional investors coming back with advanced notifications, reporting, and early access to foreclosures before they are officially announced.

Transparency by design

Investors need to trust the reliability of the platform before they trust it with their money. I decided to include every reference document the system extracts data from as a virtual library attached to each foreclosure listing, alongside a navigable timeline that lets users trace the full legal history of the process. Transparency is the product.

Learnings

This project compressed a decade of compartmentalized skills into a single pipeline. After years working closely with product managers, I learned that I know enough to be dangerous, and that the gap between designer and builder is smaller than it has ever been. Does not mean it is easy. I had to sharpen my prompting and documentation skills, learned to set up MCP servers, played with databases and data structures, discovered the value of specificity and memory agents, and more.

I learned to think in systems before thinking in screens. Database schemas, API contracts, and service boundaries became my new wireframes. I learned to prioritise modularity and reusability above all else.

The biggest lesson? Knowing when to stop designing and start shipping. A proof of concept does not need pixel perfection. It needs to prove the concept. Everything else is iteration.

Where do we go from here

Alafija still has not launched but I am almost there. Q3 2026 is my target, although a first, non-monetised version will go live in the next few weeks. My early strategy relies on organic SEO, so I want to be online as fast as possible.

The potential is considerable, given the size of the Colombian market and how underdeveloped it remains. It is still too early to say, but as a true product person, I am already scheming different monetisation avenues. Why stop at subscriptions when you can turn your backend into a B2B API, or sell market leads to attorneys and banks. Why not even enter the loan business as an intermediary between banks and investors.

We will find out soon enough. I will keep you posted.