FeatureFragment builds production-grade platforms — multi-tenant, event-driven, and battle-tested under real operations. Two flagship products, one engineering philosophy.
Every request enters through one front door — authentication, rate limiting, and routing to the right service, so no client ever talks to a microservice directly.
Services register themselves with Consul and find each other by name — no hardcoded hostnames, and no redeploy just to move a service to a new box.
State changes flow through Kafka with the outbox pattern — writes and events commit atomically, and consumers are idempotent, so retries never duplicate an order.
Every service owns its schema outright. Integration happens through APIs and events — never a cross-service join reaching into another team's tables.
Health probes, structured metrics, and distributed tracing are wired in from day one, so a slow request can be traced across every service it touches.
Different industries, same non-negotiables: strict multi-tenancy, event-driven consistency, and a database-per-service that never leaks across a boundary.
Stock, stores, and sales — online and in person — sharing one live picture of inventory across storefront, POS, and back office.
A command-driven Property Management System for hotels — one command pipeline, asynchronous domain services, architected for 20,000 ops/second.
Both products are pre-launch, so these are illustrative scenarios built from the real architecture above — not case studies from existing customers.
Stock counts update in real time across storefront and POS as orders land on both channels — no nightly batch reconciling two different pictures of inventory. When a store's safety stock trips a threshold, reorder planning already has an EOQ suggestion queued before anyone opens a dashboard. Every price change and promotion is time-bound and audited, so a comped item never quietly becomes margin someone has to explain later.
Reservations, folios, and the room-lock service share one command pipeline, so two front-desk agents can't double-assign the same room during a rush. Night audit runs against an append-only ledger instead of editable rows, so finance can trust the numbers without a manual reconciliation pass. Revenue management adjusts rates against real occupancy and forecast, not a spreadsheet someone updates once a week.
Different stacks, same discipline. These are the non-negotiables baked into StoreQL and EzeePMS alike.
Every service owns its schema outright. No cross-service SQL joins — foreign data comes over the wire, via API or event, never a shared table.
State changes other services care about are published as domain events through a transactional outbox — the write and the event commit atomically.
Every event consumer and retryable write is safe to process twice. At-least-once delivery is assumed; duplicate effects are not.
Tenant identity is derived from the authenticated principal, never trusted from a request body. Isolation is structural, not a permission check.
Health, metrics, and distributed tracing ship with every service from day one — not bolted on once something breaks in production.
Services start in any order and gate on readiness. Retries, circuit breakers, and fallbacks replace hand-tuned startup sequencing.
There's no public price list yet — StoreQL and EzeePMS are early access. We price directly with the businesses we onboard, based on scale and requirements, and founding customers keep that rate as we grow.
Lock in early-access pricing now — it doesn't rise for you as the product matures and standard pricing goes public.
Early customers work directly with the team building the platform — what you need next genuinely shapes what gets built next.
No forced feature gates. We scope pricing to your actual footprint — stores, properties, transaction volume — and talk it through with you.
Both are working, evolving codebases already running the core business logic described on this page — not a design deck. We're taking on a small number of early customers directly and working alongside you through onboarding.
Yes at the data layer — tenant identity is derived from your authenticated principal, never trusted from a request, and every service owns its own schema. Deployment topology (shared cluster vs. dedicated) is something we scope per customer.
We don't have a public price list yet. We price directly with our first customers based on scale and requirements, and founding customers keep that rate as standard pricing goes public later.
Yes — this site's source is public on GitHub, and we're building both products in the open. Link's in the footer.
The architectural spine — multi-tenant, event-driven, database-per-service — is the same across products. If your use case is close to either one, tell us where it diverges; that's exactly the kind of thing early customers help shape.
Email hello@featurefragment.com or book a call below — we'll figure out together whether StoreQL or EzeePMS is a fit before anything else.
FeatureFragment is a software studio building operationally serious platforms for industries that can't afford flaky software — retail commerce and hospitality today, more to follow.
Every product ships as strict microservices, with a real API gateway, service discovery, centralized config, and an event bus underneath — the same architectural spine, adapted per domain and stack.
The site — and the domain — are brand new. The engineering behind it isn't: both products below are working, evolving codebases, not slide decks.
Whether it's about StoreQL, EzeePMS, or working together — reach out.
FeatureFragment