Lettings software knew properties. Hotel software knew rooms and nights. Neither could hold a room inside a property with a tenant inside the room on a ninety-day contract, so the company's shared apartments did not fit anywhere.
A subscription-housing operator, after almost two years testing property-management, hotel and hospitality software that could not model rooms inside apartments, moved its inventory, maintenance, inspections and check-outs onto one system where rooms belong to properties, tenants belong to rooms, and every ticket, form and dashboard hangs off those links.
“The main problem that led us to the platform was the inflexibility of the systems available. We tested them for almost two years before finding it: solutions for lettings agencies, for hotels, for hospitality companies, all very focused on specific pains, and we were building a company a bit different from all of those. In the beginning we had a lot of shared apartments, and the systems on the market wouldn't let me have rooms related to a property. It was always properties, in an agency. None of them had the flexibility we needed.”

What was not replaced. The company's own sales system stayed and was integrated. Email and WhatsApp stayed as channels. The tenants, owners and suppliers are the same; the operation around them is now recorded and triggered.
Divid manages residential assets for income on behalf of investors, in one coastal city, under a subscription-housing model: furnished, ready-to-live units, shared or individual, on contracts of ninety days or more. It was founded in 2018 by two partners who saw a market that was, in the founder's words, amateur at every end, and set out to give both the tenant and the investor a better experience: transparent management, better returns, less friction. By late 2023 it reported about four hundred apartments under management and had tripled revenue in a year.
Subscription housing is neither a lettings agency nor a hotel, and its data does not fit either. An agency manages properties; a hotel manages rooms and nights. Divid manages a property that contains rooms that contain tenants on overlapping contracts of different lengths, with maintenance, inspections and check-outs happening at the room level while ownership, returns and reporting happen at the property level. Software built for one end of that cannot hold the other.
That is why the bottleneck was operational and not commercial. Tenants and investors were there. What the company could not find, in almost two years of trying, was a system whose structure matched its own, and until it had one, every process ran on whatever the nearest-fitting tool allowed plus a person filling the gap.
“The main problem that led us to the platform was the inflexibility of the systems available. We tested them for almost two years before finding it: solutions for lettings agencies, for hotels, for hospitality companies, all very focused on specific pains, and we were building a company a bit different from all of those. In the beginning we had a lot of shared apartments, and the systems on the market wouldn't let me have rooms related to a property. It was always properties, in an agency. None of them had the flexibility we needed.”
Lettings software knew properties. Hotel software knew rooms and nights. Neither could hold a room inside a property with a tenant inside the room on a ninety-day contract, so the company's shared apartments did not fit anywhere.
The company tried several market solutions in sequence. Each solved a neighbouring problem well and this one badly.
Inventory, maintenance, inspections and check-outs were handled with whatever the current tool allowed and the rest by hand, which made the back office slow and made portfolio data hard to relate.
By the founder's account, the tenant satisfaction score for maintenance was around 70 to 75 before the system, a level he now treats as the problem it was.
The pattern: a company with a new operating model and only old data models to run it on. Nothing was broken; the company was growing. But every process that did not fit the tool was carried by a person, and the number of those processes grew with the portfolio.
“For me, in my position, what I like most are the dashboards, because I can see basically my whole operation in a few screens. All our company's data is in the system, so the dashboards we generate from the data we create, and from what the tenant creates by using it, are where the value is.”
| What did this before | What does it today |
|---|---|
| Properties as the only unit, in agency software | Properties, rooms and tenants as linked records |
| Inventory data poorly related across tools | One inventory of properties and rooms, with tenants attached |
| Maintenance requests by hand and message | Ticket forms, with automations on defined triggers |
| Inspections and check-outs handled case by case | Inspection and check-out flows run through forms and automations |
| Portfolio performance assembled when needed | Dashboards for performance, occupancy ticketing and idle time, used to set weekly and monthly priorities |
| Commercial checking property details by asking | Commercial integrated with the operation, checking characteristics and matching offers to inventory from the same records |
| Tenant, owner and supplier messages typed | Email and WhatsApp automations |
What was not replaced. The company's own sales system stayed and was integrated. Email and WhatsApp stayed as channels. The tenants, owners and suppliers are the same; the operation around them is now recorded and triggered.
A person has to match the tenant to the room.
The chain is the record.
The system cannot see the apartment.
The ticket carries its context.
The back office no longer remembers the route.
The score is the company's.
A person has to inspect at check-out.
The dashboards read the same records the operation writes.
The hard links are 1, 3 and 7. A person has to match the tenant to the room, inspect at move-in and inspect at check-out; the system cannot see the apartment. What the design removed is the reconciliation: because the tenant is linked to the room and the room to the property, a ticket, an inspection or a check-out carries its context, and the dashboards read the same records the operation writes. The founder's own account of the maintenance result is that the back office got much faster; that is the mechanism.
"94" and "70 to 75" are given as a maintenance satisfaction index without saying whether it is a percentage, a CSAT or an NPS-style score, over what period or how many responses. The direction and size of the change are clear in the founder's account; the write-up reports the figures as given and does not name the metric.
No team size before or after is given.
The company's structure, rooms inside properties with tenants on long-stay contracts, existed before. What the system did was let that structure be recorded as it is, which is what two years of other systems could not.
Apartments under management and revenue growth describe the company. Nothing in the source attributes them to the system.
| Indicator | Result | Where it comes from |
|---|---|---|
| Maintenance satisfaction | From around 70 to 75 to 94, by the founder's account | Recorded interview; self-reported, scale and method not stated |
| Back-office speed | Described as a very large gain in agility | Recorded interview; no measure |
| Data structure | From properties only to properties, rooms and tenants linked | Recorded interview |
| Portfolio visibility | From assembled on demand to dashboards used for weekly and monthly decisions | Recorded interview |
| Team size relative to model | Operation described as much leaner than a traditional agency of the same size would need | Recorded interview; no headcount given |
All descriptions and both quotes come from one co-founder in a recorded interview. No process was independently observed.
Ticket volumes, resolution times, occupancy, idle days and headcount before and after are not given.
See above. Nothing is claimed about what kind of score it is.
Several passages were reconstructed from context, including the satisfaction index name, which could not be recovered. The founder's mention of a specific lookup function as recent suggests the interview post-dates that feature; no date is inferred from it. A public video of the interview was published in September 2023.
The four-hundred-apartment figure is from late 2023; an undated investor-facing profile gives a smaller portfolio with a larger target. Neither is reconciled with the interview.
He describes starting with related tables and building forms and apps from them. Jestor now builds and maintains the system on the customer's behalf; those passages are not used as evidence.
| Indicator | Number | Source |
|---|---|---|
| Share of gross nights on the largest short-term rental platform from stays of 28 days or more | 18% in the third quarter of 2023, up from 13% in the first quarter of 2019 | Airbnb, company statements |
| Nights and seats booked on that platform, 2025 | 533 million; Latin America the fastest-growing region at 18% | Airbnb, Form 10-K for 2025 |
| How that platform accounts for long-term stays | As month-to-month contracts, each month a separate contract | Same filing |
When almost one night in five is booked for a month or more, the product stops being a trip and becomes housing, and the platform's own accounting treats it that way. An operator built for ninety-day contracts from the start is in the segment the platforms are still learning to serve.
A platform that treats a stay as a month-to-month contract has, in effect, discovered the same thing this company found: the unit is not the property and not the night but the tenant's period in a specific space. Software that cannot represent that cannot run the business, whatever else it does well.
The share of long stays describes demand on one marketplace. An operator's occupancy, idle days and maintenance satisfaction are not in any public series; its own dashboards, as in this case, are the numbers to plan on.
Divid spent two years learning that the software market had a model for agencies and a model for hotels and no model for it. That is the general case for any company whose operation is new: the data model comes before the features, and off-the-shelf tools sell features. The question a bespoke system has to answer is what happens in year two: a data model nobody can extend when the company adds a new kind of unit, or a dashboard nobody can change when the board asks a new question, becomes the next ill-fitting tool in three years, with a login.
One builder owns each request from start to finish, and one is always in execution.
A new flow, a new automation or a new dashboard comes in through the same channel, without becoming a new project.
If what was built is not right, it is rebuilt. Unlimited revisions within the subscription.
Seats are never the billing unit, which matters when commercial, operations, maintenance suppliers and every tenant opening a ticket touch the same records.
People learn to use their app the way they learn any app, by opening it. Building, configuring and maintaining stays on our side.
Full export at any time, by CSV and API. SOC 2 compliant, no exit fee. Pause in one click and the systems keep running.
The before-and-after descriptions and both quotes come from a recorded interview with co-founder Arthur Estrella, used through its machine-generated transcript. Quotes were cleaned of transcription noise without changing their content. The account is the company's own and was not audited. Passages describing the founder building the operation on the platform himself were not used as evidence.
Founding year, partners, business model, city and apartment count from regional business and innovation press, 2021 to 2023, and from the company's own investor-facing profile. The 400-apartment figure is from late 2023 press. The 90-day minimum contract is the company's own description of its long-stay model. The satisfaction figures are the founder's, from the recorded interview.
Airbnb, Inc., company statements on long-term stays (2022 and 2023) and Form 10-K for the year ended December 31, 2025.
No ticket volume, resolution time, occupancy, idle-day or headcount figure is claimed, because none was given. The satisfaction metric's name and scale are not guessed.