Our Stack: Honest Technical Disclosure

Nexorev is split into a web application and a Python model service. The web application is built with Next.js 15 and React 19. It serves the public website, marketing pages, authentication routes, dashboards, pricing pages and SEO content. The Python service is built with FastAPI and exposes health, cancellation prediction, demand forecasting, dynamic pricing and batch prediction endpoints. In a production pilot, the web app would call the model service through an internal API URL rather than asking a hotel browser to run pricing logic.

The split is intentional. Hotel pricing logic benefits from Python libraries, numerical routines and clear model tests. The SaaS application benefits from Next.js routing, server rendering, metadata control and a modern React interface. Keeping the model service separate also makes it easier to benchmark, replace and monitor model behavior without rewriting the public site.

The current repository is still an early-stage product, not a hardened multi-tenant enterprise deployment. It contains authentication, database, PMS connector scaffolding, billing-related code and AI model modules, but real production use requires a pilot-specific hardening pass: environment secrets, tenant isolation review, PMS sandbox validation, logging policy, backup policy, incident process and owner approval workflow for rate changes.

The executable Python pricing path is an EMSR-style and demand-elasticity recommendation function. It reads base rate, occupancy percentage, competitor-reference rate, segment, month, day of week, cancellation risk, total rooms and available rooms. It returns a recommended rate, direction, adjustment percentage, reasons, confidence, elasticity and segment. The model applies occupancy pressure, competitor positioning, month seasonality, day-of-week effects, cancellation-risk adjustments and segment elasticity, then dampens extreme swings.

This is a pragmatic first model, not a magic optimizer. It is useful because it is explainable. A hotel owner can see whether the recommendation came from high occupancy, low occupancy, being above or below market, high season, weekend premium, cancellation risk or segment inelasticity. The model also supports floors and ceilings at the product layer, which are necessary before any pilot should trust automated suggestions.

The limitation is that the current pricing model does not yet learn property-specific elasticity from PMS outcomes. It uses segment-level assumptions and market-context inputs. In a pilot, Nexorev should compare recommendation outcomes against actual accepted bookings, rejected recommendations and pickup after rate changes. That is how the system can move from rule-weighted intelligence toward measured property-level learning.

The executable Python forecasting path uses an ensemble of linear trend, Holt-style exponential smoothing, Fourier-style seasonality, moving average, month factors and day-of-week factors. If statsmodels is available, the service can use ExponentialSmoothing; otherwise it falls back to numpy. The output includes predicted occupancy, predicted ADR, predicted revenue, confidence intervals and demand drivers for the forecast horizon.

This is appropriate for pilot-stage use because it is transparent and debuggable. The forecast can show weekend premiums, high-season effects, low-season effects, high-demand pricing power and low-demand promotion prompts. For independent hotel pilots, a transparent forecast often beats a black-box model that gives no operational reason for its output. The owner needs to know not only what the forecast says but why the system believes it.

The limitation is that public or synthetic history cannot validate a hotel-specific forecast. A 365-day synthetic series can test latency and code paths. It cannot prove performance for a 28-room hotel in Verona or a 40-room hotel near Como. Production forecast claims should begin only after PMS data is imported, withheld periods are backtested, and error is reported by booking window and season.

XGBoost and Prophet are treated as relevant benchmark methods, not as current production claims. XGBoost is a strong candidate for tabular booking and cancellation features because gradient-boosted trees often work well on structured hotel data: lead time, segment, channel, ADR, stay length, cancellation history, special requests, country and booking changes. Prophet-style additive forecasting is relevant because hotel demand has trend, seasonality and holiday effects that analysts need to inspect.

Nexorev should use these methods in a disciplined way. A future pilot can evaluate Prophet, ARIMA/ETS, gradient boosting and the current ensemble against the same holdout windows. The model that wins should be the one with better business accuracy, explainability and operational stability, not the one with the more fashionable name. If XGBoost or Prophet is not used in a production endpoint, the website should not imply that it is.

This distinction is part of the company s positioning. Hotel owners and investors are tired of vague AI claims. A credible technical page says: here is what runs, here is what is researched, here is what is not proven, and here is how we will decide whether to promote a method into production.

The first local benchmarks were run on the current server on April 30, 2026. They measure algorithm execution only, not network latency, database reads, authentication, PMS calls or browser rendering. The pricing function was called 1,000 times with randomized inputs. Median execution time was 0.0085 milliseconds, p95 was 0.0103 milliseconds and max was 0.0462 milliseconds. The 90-day forecast function was run 50 times against 365 synthetic historical points. Median execution time was 2.0957 milliseconds, p95 was 2.3905 milliseconds and max was 11.4495 milliseconds.

These numbers are useful but narrow. They show that the current algorithmic path is not computationally heavy. They do not prove production SLA. A real pilot has other costs: PMS data retrieval, rate-shopper calls, database queries, queueing, audit logging, UI rendering and human approval. For a hotel revenue-management workflow, sub-second recommendation generation is usually sufficient because rate decisions are not high-frequency trading. Reliability, explanation and data freshness matter more than shaving another millisecond from the algorithm.

A pilot benchmark should therefore report three layers: algorithm latency, API latency and workflow latency. Algorithm latency measures model compute. API latency measures the model service behind authentication and logging. Workflow latency measures the time from new PMS data to visible recommendation. The last layer is the one hotel owners actually feel.

The recommended pilot cadence is daily pricing refresh, weekly owner review, monthly model-health report and source refresh whenever public data updates. PMS reservations and room availability should refresh at least daily for early pilots, with more frequent refresh during high-demand windows if the PMS connector and owner workflow support it. Rate recommendations should be recalculated after material changes: new pickup, large cancellation, event calendar change, competitor-rate movement or manual owner override.

Public market data has a different cadence. ISTAT accommodation flows are published as official periodic releases and should be used for market priors and research updates, not intraday pricing. Banca d Italia tourism data is useful for inbound spend and source-market context, but it is not a daily hotel-rate signal. ENIT monitoring helps with demand themes and forward-looking market notes. Nexorev should never let a quarterly public statistic override fresh PMS booking data for a specific property.

The clean data hierarchy is: PMS and channel data for property decisions, local event and competitor-reference data for tactical context, public tourism data for market priors, and research literature for model design. Mixing those layers without labels is how early-stage software creates false confidence.

A production pilot should minimize data exposure. Nexorev does not need guest passport numbers, payment card data or sensitive free-text notes to make room-rate recommendations. The useful fields are booking date, stay date, room type, status, channel, rate, currency, cancellation flag, lead time, stay length, occupancy, rooms available, revenue and basic segment labels. If a hotel exports more than that, the pilot should filter it before modelling.

Rate recommendations should remain human-approved at the start. The system can generate a recommended rate and explanation, but the owner or manager should accept, edit or reject it. Every recommendation should be logged with timestamp, inputs, model version, decision and outcome. That audit trail is essential for both investor diligence and hotel trust. It also creates the training set for improving recommendations later.

Security posture still needs pilot hardening. Before handling real hotel data, Nexorev should review authentication, tenant boundaries, API secrets, PMS token storage, backup retention and deletion workflows. This is not a mature compliance claim. It is an honest list of the work required before a pre-revenue founder should handle sensitive customer data at scale.

Nexorev is pre-revenue and pilot-stage. The current stack can support demos, backtests, methodology pages and controlled pilot preparation. It should not be sold as a fully audited enterprise RMS. There is no evidence yet of live customer RevPAR lift, no long-term production monitoring across hotels, and no signed customer benchmark portfolio. That is not a failure; it is the current stage.

The product becomes materially stronger after three milestones: first, a clean PMS import and baseline recreation for one hotel; second, a live recommendation log with owner accept/reject behavior; third, a post-pilot report comparing accepted recommendations against the hotel s original rules. Those milestones are more valuable than adding another model acronym.

The engineering roadmap should therefore prioritize reliability, explainability, data contracts, monitoring and pilot workflow before broad automation. If the model cannot explain why it changed a rate, the hotel will not trust it. If the data pipeline is stale, the model will be wrong. If the founder cannot reproduce a recommendation in a diligence call, the investor should discount the claim.

For a narrow North Italy independent-hotel wedge, the current stack is enough to start honest pilots because the core problem is not massive scale. It is decision quality, data freshness and trust. A 30 to 60 room hotel does not need a distributed optimization cluster to decide whether tomorrow s rate should be EUR 128 or EUR 142. It needs clean data, a sensible recommendation, a reason, and a way for the owner to override the system.

That does not mean the stack should stay simple forever. As pilots produce PMS data, Nexorev can add stronger property-specific models, rate-shopper feeds, channel-cost optimization, cancellation-adjusted RevPAR, direct booking value and owner-specific policy learning. The stack page will need to change when the code changes. Until then, this page is the technical boundary: Next.js application, FastAPI model service, transparent forecasting and pricing logic, benchmarked locally, not yet production-proven across paying hotels.

The next technical layer is observability. A pricing recommendation should be reproducible after the fact. That means storing model version, input snapshot, source freshness, guardrails, recommendation, owner decision and eventual outcome. Without that log, the founder cannot explain a wrong rate to a hotel and cannot prove a right rate to an investor. Observability is therefore not enterprise polish; it is the foundation for credible pilot learning.

Model governance should start lightweight but explicit. Every pilot should define who can approve automated rate changes, what maximum movement is allowed per day, what floors and ceilings apply, what dates are locked by the hotel, and what happens when input data is stale. If the PMS feed fails, the system should stop producing confident recommendations rather than continue as if the market had not changed. A stale-data warning is more valuable than an elegant but misleading forecast.

The roadmap should also distinguish model upgrades from product upgrades. Adding XGBoost or Prophet does not automatically improve the product if the owner still cannot understand the recommendation. A useful upgrade might be a better reason panel, a cleaner alert threshold, or a comparison view showing what the hotel s current rule would do. The benchmark winner should be chosen by pilot outcome, not by reputation.

Finally, Nexorev should publish a changelog for model behavior once pilots begin. If seasonality weights change, if cancellation-risk logic changes, or if a new segment model is introduced, the hotel should know. That transparency is especially important for a solo-founder company because trust has to substitute for institutional brand weight. Clear model governance makes the small-company status feel deliberate rather than risky.

The pilot integration strategy should stay intentionally modest. A hotel does not need a deep two-way automation project on day one. The first useful integration can be a controlled PMS export or sandbox connector that provides reservation status, stay dates, booking dates, room type, channel, booked rate, cancellation flag and rooms available. Once Nexorev can recreate historical occupancy, ADR and RevPAR from that data, it can earn the right to make recommendations.

Two-way rate pushing should come later. Updating live rates directly in a PMS or channel manager introduces operational risk: parity issues, accidental overrides, stale inventory and staff confusion. The safer sequence is export, backtest, recommendation, human approval, manual or assisted update, and only then controlled automation. This sequence may look slower than an enterprise sales demo, but it is the correct approach for a pre-revenue company working with independent hotels.

Data contracts are part of the product. Each connector should define required fields, optional fields, freshness expectations, failure behavior and deletion rules. If a field is missing, the system should say which recommendation quality is affected. For example, missing cancellation status weakens cancellation-adjusted pricing; missing channel data weakens channel-cost analysis; missing room type weakens rate differentiation. Clear data contracts turn integration friction into an honest implementation checklist.