vertical-real-estate

Featured

Residential-proptech domain knowledge so architect / pm aren't naive when speccing real-estate products (listings, lead-crm, transaction-coordination, property-mgmt). Codifies MLS/IDX reality, listing status lifecycle + syndication canonical-source, long-cycle lead nurture, transaction-coordination as the high-pain wedge, and the must-model entities. Applied during spec authoring so the architecture reflects how real estate actually works — not a generic CRUD assumption.

Code & Development 92 stars 13 forks Updated today MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
66
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Vertical: residential real estate — don't spec it naively Real estate looks like generic CRUD (a listing is a record, a lead is a contact, a deal is a checklist). It isn't. The domain has hard-won structure — MLS quirks, status lifecycles, months-long sales cycles, agent-vs-brokerage data boundaries — that a naive build ignores and then rebuilds. This skill front-loads that structure so the spec is right the first time. Incumbents to know (and what they own): **Lone Wolf / Propertybase** (brokerage CRM + back office), **Follow Up Boss** (lead-to-close CRM, the nurture gold standard), **CINC** (lead-gen + CRM), **Top Producer** (legacy CRM), **kvCORE / BoldTrail** (all-in-one platform). They are expensive, broad, and switching-cost-heavy — which is why the wedge matters (see per-product). ## 1. Domain vocabulary (use these terms in the spec) - **MLS** (Multiple Listing Service) — regional database of listings; there are ~500+ MLSs in the US, each its own system, login, and field set. There is no single national MLS. - **IDX** (Internet Data Exchange) �� the rules + feed that let a brokerage display *other* brokers' MLS listings on its own site. Governed by per-MLS display/redistribution rules. - **RESO** — the standards body. **RESO Web API** (modern REST/OData feed) and **RESO Data Dictionary** (canonical field names) are the standard — but adoption and cleanliness vary per MLS. "RESO-compliant" still means per-MLS quirks. - **Listing status** — lifecycle, not a...

Details

Author
avelikiy
Repository
avelikiy/great_cto
Created
5 months ago
Last Updated
today
Language
JavaScript
License
MIT

Integrates with

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Featured

vertical-construction

Domain knowledge for the construction vertical (contractors, field crews) so architect and pm don't spec construction products naively. Covers the vocabulary (bid vs estimate, takeoff, retainage, change order, AIA G702/G703, lien waiver, draw schedule), the non-obvious money rules that incumbents like Procore price out of reach for small contractors, what a naive build gets wrong (no assemblies, ignored retainage, ungated sub payments), and the entities that must be modelled. Applied by architect when writing ARCH-{slug}.md and by pm when writing PLAN-{slug}.md for any of the four construction products (bid-builder, project-mgmt, subcontractor-portal, field-docs).

92 Updated today
avelikiy
Code & Development Featured

vertical-restaurants

Domain-knowledge primer for the restaurants & hospitality vertical (dine-in, pickup, delivery). Gives architect and pm the vocabulary, non-obvious operating rules, must-model entities, and incumbent landscape so a restaurant-product spec isn't naive about modifiers, 86'd items, aggregator commissions, tip law, and razor-thin margins. Covers the 4 products: online-ordering, reservations, loyalty, shift-scheduling.

92 Updated today
avelikiy
Code & Development Featured

vertical-home-services

Domain-knowledge pack for home & field services (HVAC, plumbing, cleaning, landscaping) — the trades vocabulary, non-obvious pricing/dispatch rules, and field-crew realities a builder must know so home-services products aren't speced naive. Covers the four products this niche ships (dispatch, quoting, field-booking, reviews), how they wedge against ServiceTitan / Jobber / Housecall Pro, and the must-model entities (price book, membership, job window, multi-option quote). Applied by architect/pm during spec authoring so the schema and flows reflect how a trades shop actually runs, not a generic CRUD app.

92 Updated today
avelikiy