Mortar

Problem

Commercial buildings juggle three workflows in three different tools: tenant management here, work orders there, short-term space rental cobbled together with calendar invites and email threads. Enterprise products solve this for the Sears Towers of the world. Small landlords with one or two properties get by with spreadsheets and email. The owner with 5–15 mid-sized commercial buildings — the gap between those two — gets neither: the enterprise tools price them out, and the small-business tools don't model commercial complexity. We built Mortar for that underserved middle.

Role

Co-founder and CTO. I own the product, the technical architecture, the deployment, and the roadmap day-to-day. My two co-founders run business, sales, and marketing, and we make product decisions together. I write the code I'm best positioned to write and contract out the lower-level pieces that don't need my time.

Approach

The architectural problem at the center of Mortar is multi-tenancy with messy edges. Three distinct user types (building admins, tenants, and vendors), each moving through the system differently, and any one of them might cross building boundaries. A property manager might own five buildings. A tenant company might rent space in three of them. A vendor might service ten unrelated buildings under different ownership.

The architecture I landed on uses MongoDB with a normalized join-table pattern. A BuildingMembership collection links users to buildings with a role and a granular permissions object. Domain documents like Spaces, Bookings, and WorkOrders carry a buildingId foreign key with compound indexes for efficient querying. Vendors get a separate three-layer model (User → VendorMember → Vendor → BuildingVendor) because a vendor company isn't a tenant and shouldn't be modeled as one.

That last piece came from a refactor. The original vendor model tied each vendor account to a single building, which meant a vendor working five buildings under one property manager needed five separate logins. I caught it while testing the user journeys end-to-end before our first beta. I made fake accounts for every persona and walked through the flows. The model didn't survive five minutes of actual use. I rebuilt it as a true many-to-many through the BuildingVendor junction, which also let vendors have building-specific configuration (preferred status, scope of services per building) without forcing it onto every account.

A second refactor happened in the role system early on. The initial design encoded business hierarchy directly: six roles distinguishing owners from property managers from tenant employees. Combined with the granular permissions object already in place, this was redundant: permissions answered "what can you do," roles only needed to answer "what kind of user are you." I collapsed six roles into three (building_admin, building_tenant, vendor) and let permissions carry the rest. The lesson held: roles should be coarse categories, permissions should be granular.

For real-time updates I picked polling over WebSockets. Sixty-second interval, fast enough for the in-app messaging to feel conversational, slow enough not to engineer for scale we don't have yet. For notifications, in-app and email only at beta. SMS and WhatsApp are wired into the architecture but not paid for; we'll switch them on once users tell us they want them.

Outcome

Three workflows live: tenants, bookings, work orders. Payments integrated. First pilot customer running on the platform. One company managing five buildings, primarily using bookings and tenant management. Active feedback loop, no major rebuilds since the vendor refactor.

Stack

MongoDB, Node.js, Express, GraphQL, React, TypeScript, Tailwind, Stripe, deployed on Render with Cloudflare for DNS and CDN.