What problem does it solve?
Local commerce and service-provider discovery are often split across unrelated storefront, booking and fulfillment systems.
Part of HalNora One · Independent product
In developmentMulti-vendor commerce
A marketplace for products, service providers and contractors.
HalNora Marketplace is being built as a standalone commercial system for product vendors and service businesses. A customer could discover a restaurant or retailer, or find an electrician, plumber, HVAC company, roofer, cleaner, landscaper, maintenance provider or other contractor—while Booking and Dispatch remain authoritative for scheduling and field execution.
Designed around
- Product vendors & local storefronts
- Service providers & contractors
- Service listings, profiles & coverage areas
- Marketplace-owned pricing zones
- Booking & appointment handoff
- Dispatch/field-service execution handoff
Current status
One configured storefront is customer-live with 43 active listings, four delivery zones/rates, seven-day hours, PayPal webhook, Google Maps and V22 Dispatch connection. Supplier ingestion remains fail-closed with zero supplier sources/feeds; broader vendor and service-provider rollout remains under validation.
Live development statusActive development
Current focusCustomer-live storefront operations, vendor/service-provider rollout, Marketplace-owned zones/pricing, supplier API/import review controls and Booking/Dispatch/POS/Inventory contracts.
Last updatedOctober 12, 2026
The live status feed is temporarily unavailable. Showing the last published snapshot.
Investor view
Problem, capability, connection and current stage.
HalNora separates demonstrated development progress from future product direction so scope can be understood without treating roadmap items as commitments.
What is it being built to do?
A marketplace for product vendors plus service providers and contractors, with Marketplace-owned pricing and explicit fulfillment/scheduling handoffs.
How does it connect?
Can hand appointments to Booking, field execution to Dispatch, production to POS/KDS, stock authority to Inventory and payments to HalNora Payments through defined contracts.
Where is it today?
Pilot / active development. A configured storefront is customer-live; supplier API/import controls and broader vendor/service-provider rollout remain deliberately gated.
Current direction
What this product is being built to do.
Public descriptions reflect current development direction and do not imply general availability or production certification.
Multi-vendor storefronts
Give independent vendors a controlled commerce presence while preserving tenant and vendor isolation.
Products & catalogs
Support seller catalogs, product details, variants, pricing and commercial merchandising.
Checkout & commercial orders
Marketplace owns checkout, payment state and the commercial order lifecycle.
Service providers & contractors
Support electricians, plumbers, HVAC, roofing, cleaning, landscaping, maintenance and other service businesses alongside product sellers, with bookable offerings handed to Booking.
Independent pricing zones
Marketplace owns drawable polygon delivery zones and customer-facing Marketplace delivery pricing.
Price snapshots
Marketplace-originated fulfillment carries the agreed commercial pricing result so Dispatch does not recalculate it from direct-client rate tables.
Booking handoff
Send service requirements into HalNora Booking while appointment availability and scheduling remain authoritative there.
Fulfillment handoff
Send immutable pickup/delivery snapshots and opaque references to Dispatch using authenticated, idempotent contracts.
Payment/preparation/delivery separation
Keep commercial payment state, preparation state and delivery execution state distinct so retries do not duplicate work.
Vendor & tenant controls
Preserve vendor isolation, permissions and explicit release controls as the marketplace scales.
Service marketplace
Discovery, booking and field execution stay under clear ownership.
HalNora Marketplace can become the discovery and commercial layer for local service providers without turning Marketplace into a scheduler or dispatch system.
MarketplaceProvider profile · services · pricing context · customer discovery
→BookingAvailability · appointment · recurring schedule · provider/resource capacity
→Dispatch / Field ServiceTechnician assignment · route · execution · forms/evidence · customer tracking
Provider profiles
Business identity, service categories, coverage/service areas, hours and bookable offerings can be presented in a customer-friendly storefront.
Quote or book
Some services can be directly bookable while others can begin as a request or lead, allowing different trades and contractors to keep the sales process that fits their work.
Recurring service
Cleaning, maintenance, lawn care and similar businesses can hand repeat scheduling to Booking rather than duplicating recurring appointment logic in Marketplace.
Execution handoff
When work must happen in the field, Dispatch can receive the scheduled job with immutable customer/location/service context and execute it with the right technician, vehicle, skills and evidence.
Supplier/API capability
Supplier ingestion is being hardened as a Marketplace capability—not a separate API product.
HalNora API Market work belongs inside Marketplace: supplier API/import, review, staging, provenance, audit, concurrency and integrity safeguards.
Fail closed before source data can affect the catalogue.
The supplier worker exists in code but remains disabled with zero supplier sources or feeds. Development acceptance scenarios and regression suites have advanced, while live supplier traffic, synchronization and sellable-catalog activation remain gated.
Product boundary
Marketplace owns commerce.
Marketplace owns vendors, storefronts, catalogs, checkout, payments, commercial orders and Marketplace customer pricing. Dispatch owns field execution and direct-client pricing; Booking owns appointments; POS owns POS sales; Inventory owns product movement.
HALNORA ONE ARCHITECTURE
Connected, not coupled.
Cross-product workflows use explicit contracts, authenticated events and clear authority so one product does not silently take over another product’s records.
How the HalNora platform works →Controlled production handoff
Marketplace orders can feed preparation without becoming fake POS sales.
Current integration work preserves the commercial order in Marketplace while allowing POS/KDS and Inventory to receive only the production and availability events they own.
POS/KDS production tickets
Marketplace-originated production can create source-specific kitchen/production tickets without reclassifying the order as a POS sale.
Inventory availability
Marketplace and POS can query Inventory availability through explicit contracts rather than copying stock state.
Consume & reverse events
Inventory movement is driven by owned events with compensating/reversal paths instead of duplicate deductions.
Attention gates
Fulfillment handoffs surface failed or delayed states for operator attention instead of silently losing the commercial order.
What comes next
Development priorities.
HalNora prioritizes reliability, security, recoverability and real-world validation over feature count alone.
Search themes: multi-vendor marketplace software, local marketplace platform, service provider marketplace, contractor marketplace software, trades marketplace, electrician booking marketplace, plumber marketplace, service marketplace software, vendor storefront software and marketplace fulfillment integration.
Product inquiry
Interested in Marketplace?
Talk with HalNora about product direction, commercial use cases, partnerships or investment.