CASE STUDY

My Dormot Construction Super App: How Sigi Built It

My DormotConstruction7-Minute Read

My Dormot is a construction super app that brings the materials, trades, and services behind a home or commercial build into a single mobile product. Sigi Technologies designed and engineered the platform: a service catalog spanning supply and labor, vendor and contractor onboarding, quote-to-order flows, scheduling, payments, and an admin layer for approvals, oversight, and disputes. This case study walks through the architecture choices that let one app hold that breadth without confusing the person running the build.

Stock photo of yellow tower cranes against a clear blue sky at a construction site

My Dormot: a construction super app for home and commercial builds

In the market My Dormot was built for, much of construction buying still happens over phone calls and chat threads. A homeowner extending a kitchen and a contractor fitting out a retail unit face the same routine: find a supplier for cement and tiles, find a separate one for electrical fittings, ring around for a plumber, chase a delivery, and keep the whole sequence in their head. My Dormot was conceived to collapse that routine into one place—a single app where the needs of a home or commercial project can be found, priced, ordered, and delivered.

Sigi Technologies took on the full product build. The engagement covered product design, mobile engineering, the supplier and contractor side of the marketplace, and the admin tooling that a multi-category platform depends on. It sits alongside our other marketplace work in on-demand platforms and custom software development.

The problem: construction procurement is fragmented by design

The brief was broad, and the difficulty was less about any single feature than about how the categories interact. Three pain points shaped the scope:

  • Materials, services, and labor live in different places. A build needs building materials ordering, trade services, and contractor booking, but each of those markets has its own suppliers, its own pricing habits, and its own definition of “delivered”. The client’s starting point was that its customers were juggling separate suppliers, directories, and chat threads for the three, with nothing tying them together.
  • Home and commercial needs overlap but do not match. A homeowner wants clear prices and a short list of choices. A commercial project wants bulk quantities, quotes instead of list prices, staged deliveries, and a record of who approved what.
  • Breadth erodes usability. Every additional category makes navigation harder, and a super app that feels like a bundle of unrelated tools loses the convenience that justified it in the first place.

The design target became explicit: one product with a consistent way to search, request, pay, and track across every construction category, with enough structure underneath that new categories could be added without redesigning the app.

Construction super app architecture: one shell, many service modules

The core architectural idea is a shared shell with pluggable service modules. The shell owns identity, the home screen, search, cart and order history, payments, notifications, and support. Each construction category—building materials, trade services, contractor hire, equipment, and so on—is a module that declares its catalog shape, its pricing model (list price, quote-based, or day rate), and its fulfillment steps. The shell renders every module through the same components, which is what keeps a materials order and a contractor booking feeling like the same app.

  • Quote-first where prices are not fixed. Commercial materials and most contractor work have no list price, so the request flow supports “ask for a quote” alongside “buy now”. Vendors respond inside the app, the customer accepts, and the accepted quote becomes an order without anything being re-entered.
  • Scheduling as a first-class object. Deliveries, site visits, and work days all attach to a schedule, so a customer sees one calendar for the project instead of a separate timeline per supplier.
  • Vendor and contractor onboarding with verification steps, so the marketplace holds a supplier’s catalog, service area, and documents before that supplier becomes visible to customers.

The stack we built it on

My Dormot is a native mobile app for customers and vendors sitting over a single backend, with a web admin panel for the operations team. The technical foundation is the shared shell and the one order model beneath it: identity, home screen, search, cart, order history, payments, notifications and support are built once in the shell, and every construction category plugs in as a module that declares its catalog shape, pricing model and fulfillment steps. Payments, refunds, scheduling and dispute handling all run against that single order model, which is what lets a bag of cement and a three-day electrical job move through the same rails and a new category ship as configuration rather than code. It is the kind of multi-module mobile app development one Sigi team can own end to end.

How the platform is built and run

My Dormot is a multi-module super app built so many construction categories can share one set of rails:

  • A shared app shell that owns identity, the home screen, search, cart, order history, payments, notifications and support, with each construction category plugged in as a module that declares its own catalog shape, pricing model and fulfillment steps.
  • A single order model across every category — an order with line items, a fulfillment type and a status timeline — so a bag of cement and a three-day electrical job move through the same rails and a new category ships as configuration rather than code.
  • Quote-first flows where prices are not fixed: a vendor answers a request in-app, the customer accepts, and the accepted quote becomes an order without anything being re-entered.
  • Vendor and contractor onboarding with verification steps, holding a supplier’s catalog, service area and documents in a pending state until admin approval.
  • Payments, refunds, scheduling and dispute handling built once against the shared order model, so a materials refund and a service-job dispute follow the same workflow across the customer app, the vendor side and the web admin panel.
  • Shell-and-order-model-first delivery: modules shipped in slices — building materials, then services, then contractor booking — each reviewed against the shared component library before engineering, with cross-module flows (quote to order to scheduled delivery to dispute) tested end to end.

What we implemented: the construction marketplace app

Sigi designed, built and shipped every surface of the platform — the customer app, the vendor and contractor side, and the admin panel. Here is what we implemented across the three.

Customer app: building materials ordering, services, and contractor booking

The customer app is where a homeowner or site manager spends most of their time, so it carries the full breadth of the marketplace behind a small set of consistent screens.

  • Category-led home screen with search across materials, services, and contractors, filtered by location and project type (home or commercial).
  • Product and service pages that carry the fields construction buyers check first: unit of sale, minimum order quantity, delivery lead time, and service area.
  • Buy-now for catalog items and request-a-quote for bulk or bespoke needs, with both landing in the same cart and order history.
  • Project workspace that groups orders, quotes, and appointments under a named project—useful when a commercial client runs several sites at once.
  • Delivery and job tracking with a status timeline per order, plus cancellation and change-request handling before a vendor has confirmed.
  • Ratings and issue reporting after delivery or job completion, feeding the admin dispute queue.

Vendor and contractor side: onboarding, quotes, and fulfillment

The vendor side turns a supplier’s catalog or a contractor’s availability into something a customer can buy, and every screen here exists to keep the customer’s order timeline accurate.

  • Guided onboarding that captures business details, categories served, service area, and supporting documents, then holds the account in a pending state until admin approval.
  • Catalog management for suppliers (products, units, pricing, stock flags) and service listings for contractors (skills, day rates or quote-only, availability).
  • Quote inbox where incoming requests are answered with itemized pricing and validity dates; accepted quotes convert straight to orders.
  • Order and job management with per-step status updates, so the customer’s tracking view is driven by what the vendor actually does on site.
  • Earnings view showing completed orders, pending settlements, and payout history.

Admin panel: catalog control, approvals, and disputes

The admin panel is the operations team’s view of the whole marketplace: which categories exist, who is allowed to sell in them, and what happens when an order goes wrong.

  • Category and module configuration, where each construction category is defined with its pricing model and fulfillment steps.
  • Vendor and contractor approval queue with document review and the ability to suspend or restrict accounts.
  • Order oversight across every category, with filters by status, region, and vendor, and manual intervention for stuck orders.
  • Dispute and refund handling tied to the shared order model, so a materials refund and a service-job dispute follow the same workflow.
  • Content and promotion management for the customer home screen.

Delivery approach for a multi-module construction app

A platform this wide cannot be built category by category in isolation; when it is, the shell fragments into inconsistent carts, duplicate payment flows, and status screens that disagree with each other. Sigi built the shell and the shared order model first, then delivered modules in slices: building materials as the first fully working category, followed by services and contractor booking on the same rails. Each slice went through design review against the shared component library before engineering, and cross-module flows—a quote that becomes an order, an order that becomes a scheduled delivery, a delivery that becomes a dispute—were tested end to end instead of screen by screen.

The team and expertise behind the build

My Dormot was delivered end to end by one cross-functional Sigi team — product strategists, UI/UX designers, mobile and full-stack engineers, and QA — rather than handed between vendors. Sigi hires only specialists: every engineer is an expert in their own field, and we invest in the team as they deliver, supporting certifications and continuous learning so expert, motivated engineers stay on every build. It is the model we have run since 2016: deep, cross-industry expertise owning the whole product — the native mobile apps, the shared backend and order model, and the admin panel — which is what lets a multi-module marketplace like this ship as one coherent build.

What shipped

My Dormot was delivered as a single product spanning building materials, trade services, and contractor booking for both home and commercial customers: a customer app, a vendor and contractor side with onboarding, catalog, quote, and fulfillment tools, and an admin panel from which the operations team approves vendors, oversees orders, handles disputes, and opens new categories by configuration rather than by an app release.

What we can share is limited to the product itself. My Dormot is a private launch with no public listing or website to link to, and the client has not released usage figures, revenue, timeline, or team size, so this case study does not quote numbers it cannot cite.

The engagement drew on our mobile app development practice, our UI/UX design work for a product that has to stay simple across many categories, and the marketplace patterns from our on-demand industry projects.

Related marketplace case studies

If the shared-order-model approach is relevant to your product, our ServiPR services marketplace case study shows the same idea in a different vertical — and also covers Mahir Company, a home-services app built on the same model. For a catalog-and-delivery angle, the Kwik eMart grocery platform covers product catalog, cart, and delivery scheduling at scale.

Planning a construction marketplace or a multi-category super app? Contact Sigi to talk through the module structure, the vendor side, and the admin tooling your version will need.

Need a construction platform for your business?

Tell us what you want to build. We’ll show you how a Sigi team would scope, design, and ship it — and the stack it would take.