--- title: "Elite Smart Build: a custom operating system · Polargate" description: "Elite Smart Build, a Spanish hotel refurbishment contractor working in more than twenty countries, ran every site on spreadsheets and email." url: https://polargate.ai/work/hotel-refurbishment-operating-system locale: en publisher: POLARGATE S.L. --- Construction and hotel refurbishment # A custom operating system for Elite Smart Build Elite Smart Build, a Spanish hotel refurbishment contractor working in more than twenty countries, ran every site on spreadsheets and email. Polargate replaced that with eleven modules on Supabase and React: daily Gantt, role-masked margins, per-department alerts and material reception with automatic incidents. 40.4168° N · 3.7038° W In short Polargate built a custom operating system for Elite Smart Build, a Spanish hotel refurbishment contractor that was running its site works on spreadsheets and email. In about a month we delivered eleven modules on Vite, React and Supabase: a daily Gantt, role-masked budgets, a per-department agenda with weekday email alerts, photo incidents, checklists and material reception, on 23 Postgres tables with row-level security forced on every one. 11 modules delivered in Phase 1 23 Postgres tables with row-level security forced ~1 month from development start to first testable version in production 10 role-based accounts live on the client's own domain 59 audit findings confirmed and fixed before client testing ## The problem Elite Smart Build refurbishes hotels in more than twenty countries, and it ran every job on spreadsheets. Each site had its own workbook, the daily plan was a Gantt someone redrew by hand, and everything else moved by email between seven departments. Nobody was looking at the same version of the truth at the same time. One coordination failure between purchasing, logistics and site had already cost a six-figure loss on a single job: wrong material ordered, not caught at reception, installed, then torn out and done again. ## What we built Polargate started from the workbooks and the five-phase process map Elite already used, turned them into a normalised data model, and closed twelve open modelling questions with the client in writing before building anything. Scope was fixed in a signed specification: eleven modules for Phase 1, with the financial module and client invoicing explicitly out. We then built a mobile-first web application on Vite, React, TypeScript and Tailwind, with Supabase Postgres, Storage, Auth and Edge Functions behind it, deployed on Vercel and running on the client's own domain. ## The outcome The first testable version went live in production about a month after development started, with ten role-based accounts and the alert engine running every business day. Row-level security is forced on all 23 tables, and a database trigger writes every change to an immutable audit log. Before anyone logged in, an adversarial multi-agent audit produced 59 confirmed findings, one of them a blocker, and all of them were fixed. The application is in client testing on a weekly review cadence, and no adoption or return figures exist yet. Stack - Vite - React - TypeScript - Tailwind CSS - shadcn/ui - React Router - Supabase - PostgreSQL - Deno - Resend - Vercel - GitHub - Claude ## The context Elite Smart Build refurbishes hotels without structural works. Thirteen years in the market and more than 200 projects across twenty countries, ran every job from spreadsheets. Each site had its own workbook, the daily plan lived in a Gantt someone redrew by hand, and the rest travelled by email. Seven departments worked from copies of copies. A single coordination failure between purchasing, logistics and site had already cost a six-figure loss on one job: the wrong material was ordered, nobody caught it at reception, it was installed, and it had to be redone. ## What we found in discovery We started from what Elite already used, not from a blank page. We read five live workbooks (three site procedure files, the 2026 works calendar and the 2026 quotation list), the five-phase J-500 process map, and one email chain about a shipment that went wrong. From those we derived the entities that mattered: works, phases, departments, people, suppliers, quotations, shipments, receptions and incidents. Twelve open modelling questions went back to the client and were closed in writing before a line of application code existed. Scope was fixed in a signed specification: eleven modules for Phase 1, with the financial module and client invoicing explicitly out. ## What we built A mobile-first web application on Vite, React 19, TypeScript, Tailwind and shadcn/ui, with Supabase Postgres behind it and hosting on Vercel. - Calendario: a daily Gantt of the active sites with the operatives assigned to each day. - Presupuestos: cost and margin masked by role through a database view, so a site manager and a director see different columns of the same record. - Agenda: tasks per department with a business-day traffic light and a written justification when something is missed. - Incidencias and Recepción de material: reception is checked line by line, and a mismatch raises an incident with a photo automatically. - Checklists per J-500 phase and department, plus suppliers, people, availability and notifications. ## How it runs now Access control lives in the database, not in the interface: row-level security is enabled and forced on all 23 tables, roles come from a ten value enum, and a trigger writes every change to an immutable audit log that only management can read. A Supabase Edge Function on Deno runs Monday to Friday and emails each department its open items from the client's own domain, verified for DKIM and SPF through Resend. The application was scaffolded in Lovable and then fully detached: its own GitHub repository, its own Supabase project and its own Vercel deployment, with no dependency on a third-party runtime. Before the first user logged in we ran an adversarial multi-agent audit that produced 59 confirmed findings, one of them a blocker, and fixed all of them. The first testable version reached production about a month after development started, with ten role-based accounts and a weekly review cadence with the client team. [Build →](https://polargate.ai/services/build) · [Care →](https://polargate.ai/services/care) · [Industrial and B2B →](https://polargate.ai/for/industrial) FAQ ## Questions about this project How long does it take to replace our spreadsheets with a custom system? The first testable version of this system reached production about a month after development started, covering eleven modules. Polargate works in phases: a fixed-scope discovery that turns your existing workbooks and process maps into a data model, then a first phase you can use in production while the rest is built. The calendar depends mostly on how quickly your team answers the modelling questions. Can we keep working on site while the system is being built? Yes. Phase 1 was designed to sit next to the spreadsheets rather than replace everything at once, and seeded demo data was kept separate from real data with a visible badge, so the team could test without polluting live records. Each module goes live when it is ready. Nothing forces a single cutover date, and the works calendar is usable from a phone on site from day one. Who can see costs and margins inside the system? Only the roles that should. Cost and margin are not merely hidden in the interface, they are removed by a database view before the data reaches the browser, and access is decided by a role enum checked inside Postgres. Row-level security is enabled and forced on all 23 tables, so a user querying the API directly still sees only what their role allows. Does it work on a phone on the building site? Yes. The application is mobile-first: the works calendar, the department agenda, incident reporting and material reception were all designed for a phone held in one hand, with 44 pixel touch targets and photos taken straight from the camera. It runs in the browser, so there is nothing to install, and the same accounts work on desktop back at the office. Do we own the code and the database? Yes. The project was scaffolded quickly in a prototyping tool and then fully detached: its own GitHub repository, its own Supabase project hosted in the EU, its own Vercel deployment, and transactional email sent from the client's own domain. There is no proprietary runtime in the middle, so the codebase and the Postgres database can be handed over or hosted elsewhere. ## Related work KD.tech ### One platform for a semiconductor company: site, ServiceDesk and admin portal on a single codebase Polargate replaced KD.tech's WordPress site and a planned Odoo rollout with one React and Supabase platform holding the bilingual corporate site, a customer ServiceDesk and an admin portal, and now runs it on a monthly senior retainer. 2026 Read the case [One platform for a semiconductor company: site, ServiceDesk and admin portal on a single codebase](https://polargate.ai/work/kd-tech) INITIATE ## Start the engine Tell us what you are building in a few short questions. A senior engineer answers in writing within 48 business hours, with a first take on scope, timeline and price. [Start your project](https://polargate.ai/start) · [Talk to us](https://polargate.ai/start#static-brief-heading)