Making genuinely different alarm offers comparable on one screen.

The problem

Buying home security is a bad consumer experience everywhere, and worse in a market where every provider quotes differently. One company bundles hardware into the monthly fee. Another charges install separately. A third sells the panel outright and monitors it cheap. Contract lengths differ, response guarantees differ, what counts as "included" differs.

Faced with that, a consumer can't compare. So they either don't buy, or they buy from whoever called them back.

The obvious build is a directory: list the companies, link out, take a referral fee. That solves nothing for the consumer and gives the platform no control over what happens next. The brief was the harder version: a transactional marketplace, where the comparison is real, the purchase happens on the platform, and installation is coordinated rather than handed off and hoped for.

Three different audiences need three different surfaces: consumers comparing and buying, companies managing their own listings and orders, and staff verifying companies and overseeing the whole thing.

What I did

Sole developer on the build. Next.js 15 App Router, Supabase with row-level security, Leaflet for coverage maps, zod for validation, Vitest, pnpm, deployed on Vercel.

• Three route groups in one codebase. Public consumer flow, company portal, admin console. Same schema, same types, three genuinely different permission models, enforced in Postgres with RLS rather than in the UI, so a company can only ever read and write its own rows regardless of which client is asking.
• The quiz as the comparison input. Property type, coverage needs, existing equipment, location. The answers narrow the field and parameterize what each provider's offer actually costs this consumer, instead of showing everyone the same table.
• Standardization into three tiers: Esencial, Recomendado, Plus. The real work of the project. Each provider's packaging is mapped into a common shape so the three columns are honestly comparable, with the differences that genuinely matter surfaced and the noise suppressed.
• Company portal. Providers manage their own offer definitions, coverage areas, and incoming orders. Verification state is admin-controlled, so a company can't self-promote into the comparison.
• Admin console. Company verification pipeline, offer review, order oversight.

The detail that mattered: resisting the fourth tier. Every provider has something that doesn't fit neatly into three, and every one of them wants their exception surfaced. Allowing that would have quietly turned the comparison back into a directory. Three tiers is a product constraint that the data model enforces, not a layout choice.

Outcome

• A working transactional marketplace rather than a lead-referral directory: quiz, honest three-tier comparison, on-platform purchase, coordinated installation.
• Company and admin surfaces both landed, so the platform runs without a developer in the loop for day-to-day operations.
• Permission boundaries live in the database, which means a bug in one of the three front ends can't leak another party's data.
• Active build, and the most current thing in this portfolio.