Every operator who has ever asked me for a custom PMS starts from the same place: off-the-shelf software forces them to bend their operation to fit the product, and a full custom build from scratch is a six-to-eighteen-month capital risk they cannot justify. Both are real problems. The 26-Module Scoping Method is the third option we use at JumboTiger to get past both, and it is the reason we can quote a custom deployment in 30 days rather than 30 weeks.
This is not a sales page. It is the actual method, written down so you can run it yourself, whether you end up building with us or not. I have used a version of it on every deployment I have shipped for coliving, BTR, PBSA, student housing, and flex-living operators since 2018. The core idea is simple: you do not build a PMS by writing net-new code for every feature. You build it by scoping which of a fixed library of proven modules your operation actually needs, then configuring those modules to how you work.
We maintain 26 such modules. The method is how you get from a messy real operation to a defensible scope across those 26 in a matter of days.
1. Why scoping beats shopping (and beats building from scratch)
There are two ways most operators try to buy software, and both fail in a predictable way.
The first is shopping: you demo four or five SaaS products, pick the one that feels closest, and then spend the next year discovering the 20 percent of your operation it cannot handle. That 20 percent is never the same 20 percent for two operators, which is exactly why no generic product covers it. You end up running spreadsheets alongside the expensive software you just bought.
The second is building from scratch: you hire developers or an agency and describe your whole operation. This fails the other way. Every workflow is treated as a net-new problem, timelines balloon, and you become the maintainer of bespoke code you do not fully understand. The 80 percent of your operation that is genuinely standard, rent collection, maintenance tickets, document signing, gets rebuilt at custom-build cost for no reason.
Scoping is the middle path. You accept that most of your operation is standard and should be configured from proven modules, and you spend your customisation budget only on the parts that are genuinely specific to you. The method below is how you draw that line precisely, before anyone writes a line of code.
2. The 26 modules, grouped into four layers
Before you can rank anything you need the full menu in front of you. We organise the 26 modules into four layers. The layers matter because they map to how an operation is actually run, and because a gap in a lower layer usually blocks value in a higher one.
Layer 1, Core operations (the spine). These run the building day to day, and almost every operator needs all of them: Booking and Onboarding, Payments and Rent Collection, Inventory and Occupancy Management, Maintenance and Work Orders, Document Management and Digital Contracts, and Communications and Operations. If any of these is weak, nothing above it works.
Layer 2, Revenue and distribution (how you fill and price). Listing Website and Booking Engine, Channel Manager and OTA Distribution, Revenue Management and Dynamic Pricing, Lead and CRM Management, Screening and Verification, and B2B Partners and Owner Management. How much of this layer you need is dictated almost entirely by your channel mix, which is why the method makes you write that down first.
Layer 3, Resident and community experience (what the resident touches). Tenant Portal and Mobile App, Community and Events, Facility and Amenity Booking, Visitor Management, Access Control and Smart Building, and Utility and Energy Management. A coliving brand lives or dies on this layer; a single-family rental portfolio may need almost none of it.
Layer 4, Governance and intelligence (how you stay compliant and see the numbers). Compliance and Regulatory Management, Global Configuration and Compliance, Reporting and Analytics, Owner and Investor Portal, Housekeeping and Facilities Management, Staff and Workforce Management, the Integrations Hub, and the AI Layer and Advanced Analytics. This is the layer institutional capital and multi-country operators cannot skip, and the one early-stage operators most often defer.
That is all 26. The point of the layering is not taxonomy for its own sake. It is that you scope top-down within each layer, and you never let a shiny Layer 3 or Layer 4 feature jump the queue ahead of a broken Layer 1 spine.
3. Step one: map your operating model on one page
You cannot rank modules until you have described how you actually operate, and most operators have never written this down in one place. The map has five inputs, and it fits on a single page.
Inventory model. Do you sell per unit, per room, or per bed? This one answer changes how half the modules behave. A per-bed operator needs inventory, pricing, billing, and contracts that all understand a bed inside a room inside a unit. If you are per-bed and a module cannot model that, it is disqualified regardless of how good the rest of it is.
Channel mix, today and in 18 months. Write down where residents actually come from: direct website, OTAs, corporate and B2B partners, university nominations, agents. Then write down where you want them to come from in 18 months. Almost every operator finds a meaningful gap between the two, and you scope Layer 2 for the target, not for today.
Stay-length profile. All long-term, all short-stay, or a hybrid? Hybrids are where generic tools break, because a single unit has to flip between rate models, tax treatments, and contract types.
Regulatory footprint. One country or several? Which certificates, licences, and checks are non-negotiable in your markets? This sizes Layer 4, and it is the input operators most often underestimate.
Team and scale. How many people touch the system, in what roles, and how many units or beds today versus your 24-month target? This decides how much of Staff and Workforce Management, Owner Portal, and Reporting you need on day one versus later.
When these five are on one page, the ranking in the next step almost writes itself.
4. Step two: rank all 26 as Must, Should, or Later
Go through the 26 modules once and put each into exactly three buckets. Force yourself to be honest, because the whole economic advantage of the method comes from a small, ruthless Must list.
Must means go-live is not possible without it. For nearly every operator this is the Layer 1 spine plus whichever Layer 2 modules match their primary channel and whichever Layer 4 compliance modules are legally required in their markets. If your Must list has more than about ten modules, you are almost certainly mislabelling Shoulds as Musts.
Should means it clearly adds value and you want it, but the operation can run for a few weeks without it while you watch real usage. Community and Events, Facility Booking, Revenue Management, and the Owner Portal often land here for operators who are not yet at institutional scale.
Later means it is real but not now. The AI Layer, advanced analytics, and deeper workforce tooling are common Laters. Putting something in Later is not rejecting it; it is sequencing it so it does not delay your go-live.
The output of this step is a scope, not a wishlist. A tight Must list is what makes a 30-day deployment arithmetic rather than optimism.
5. Step three: the config-versus-custom gap analysis
This is the step that separates the method from a feature checklist, and it is the one most vendors will not do honestly with you. For each module on your Must and Should lists, you answer one question: does the standard module cover this workflow as configured, or does your operation do something genuinely different that needs custom work?
Most of the answer is config. A proven Payments and Rent Collection module already handles multi-gateway payments, reminders, deposits, and reconciliation; you configure the schedule and rails, you do not rebuild it. The same is true for maintenance ticketing, document signing, and onboarding for the large majority of operators.
The custom work is where you are actually different, and it is usually a short, specific list: a bespoke guarantor flow, a meal-plan billing model, a university nomination intake, a corporate-client invoicing rule, a bed-level pricing hierarchy your market demands. Naming that list precisely is the single most valuable output of the whole method, because it is the only part you are paying custom-build cost for, and it is the part a generic SaaS would have forced you to work around forever.
Run this honestly and you get a number most operators have never seen: the true percentage of your operation that is standard versus specific. In my experience that number is far higher on the standard side than operators expect, which is exactly why configuring proven modules is faster and cheaper than either shopping or building from scratch.
6. Step four: sequence the 30-day build
With a ranked scope and a gap analysis, sequencing is mechanical. You build in dependency order, not in order of excitement.
The Layer 1 spine and your Must-list compliance modules go first, because everything else depends on them and because they are almost entirely configuration. Data migration runs in parallel here, using a parallel-running approach so your live operation never goes dark while the new system is populated and validated.
The genuinely custom items from your gap analysis are scheduled next, as discrete, well-specified pieces rather than a vague pile of requirements. Because the list is short and named, it fits inside the window instead of consuming it.
Should-list modules are configured and switched on as the core stabilises. Later-list modules are documented and deferred by design, with the data model built so that turning them on afterwards is configuration, not a re-platforming.
That sequence is why 30 days is a real number and not a slogan. It is not that the work is small; it is that the method removes the two things that usually blow up timelines, undifferentiated rebuild of standard workflows and an unbounded custom scope.
7. How the scope shifts by operator type
The method is the same across verticals; the scope it produces is not. A few patterns recur.
Coliving and shared living load heavily on per-bed inventory, Community and Events, and bed-level pricing, with housemate and matching workflows as the common custom item. If you run coliving, the [coliving software](/use-cases/coliving-software) scope almost always makes Layer 3 experience modules Musts rather than Shoulds.
Build-to-rent shifts weight to Reporting, the Owner and Investor Portal, and Compliance, because institutional capital is watching the numbers. The [BTR software](/use-cases/btr-software) scope treats Layer 4 governance as non-negotiable from day one.
Student housing and PBSA are dominated by term-cycle bulk intake, guarantor and nomination flows, and September onboarding at volume, which is where their custom list concentrates. See the [student housing software](/use-cases/student-housing-software) scope for how the intake modules dominate.
Flex living needs the full Revenue and distribution layer plus the ability to flip a unit between stay-length models, which is the hybrid problem that breaks generic tools. PG and hostel operators load onto bed-level inventory, meal-plan billing, and walk-in onboarding. Residential rental portfolios often need the least of Layer 3 and the most of the payments, owner-reporting, and compliance spine.
In every case the map-rank-gap-sequence method is identical. The value is that it produces a scope shaped to your operation instead of a product you reshape your operation around.
8. Run it yourself before you talk to any vendor
You do not need us to start. Write your operating model on one page. Take the 26 modules and sort them into Must, Should, and Later. For each Must and Should, mark config or custom. When you are done you will have something almost no operator walks into a sales call holding: a precise scope and a named list of the handful of things that are genuinely specific to you.
That document changes every vendor conversation. Instead of watching demos and hoping, you hand over your scope and ask each vendor to show you, module by module, what they configure and what they cannot do. The honest ones will map to it. The ones selling you a future of compromises will insist everything works out of the box.
That is the whole method. It is how we ship in 30 days, and it is a better way to buy software even if you never build with us.
Related reading
- /blogs/migrating-from-spreadsheets-to-a-pms
- /blogs/pms-migration-without-downtime
- /blogs/how-to-choose-coliving-pms
- /blogs/per-bed-vs-per-unit-pms-pricing
