Which of your three real estate pages do I need?
If you manage rented or leased property, start with property management system development. If you sell property and need to track buyers, viewings, offers, and commission, start with real estate CRM and sales platform. If your problem is getting listing or property data in or out of an MLS or portal, start with MLS and property data integration. If you do more than one of these, the systems should share parties and properties rather than duplicate them, and we design that boundary explicitly.
Is your property management system the same as the hotel one under hospitality?
No, and the shared name causes genuine confusion. A hotel property management system handles stays measured in nights, with rates that change daily, housekeeping, and distribution to booking channels. A rental property management system handles tenancies measured in months or years, with leases, arrears, deposits, statutory notices, and owner accounting. Both pages open by stating the distinction and link to each other so you land in the right place.
Do we need custom software, or would a product do the job?
For a standard residential portfolio or a small agency in a single jurisdiction, a product is frequently the right answer and we will say so rather than sell you a build. Custom development earns its cost when your lease or fee structures are unusual, when you operate across jurisdictions with different rules, when you need integrations a product will not support, or when a product forces a workflow that conflicts with how the business actually runs. We would rather lose the project than deliver an expensive version of something you could have bought.
Do you have a real estate case study?
No, and we will not imply otherwise by describing adjacent work as real estate experience. Our two published case studies are both in hospitality. There is real engineering overlap in areas such as availability, booking coordination, third-party API integration, and transactional reporting, but overlap is not evidence. What we offer instead is a walkthrough of the architecture we would use, the specific adjacent systems we have built, and an explicit list of what would be new for us on your project.
Can you integrate with our existing accounting system?
Yes, and it is usually what we recommend. Property accounting and property operations are different problems, and replacing working books at the same time as introducing a new operational system doubles the risk in a single project. We integrate at the ledger level so charges, receipts, fees, and commission post correctly and reconcile at period end.
What is your position on RETS?
RESO ended support for RETS in June 2018 and replaced it with the RESO Web API; RESO now describes RETS as a deprecated transport standard. We build against the Web API by default. Where a service you depend on still offers only RETS we will integrate with it, but we isolate it behind a transport boundary and we will tell you plainly that it is legacy rather than presenting it as a current capability. We do not recommend new development targeted at RETS.
How do you handle client money, deposits, and anti-money-laundering rules?
We build the mechanics and the audit trail: separated money flows so rent, deposits, and your own fees are never conflated, an immutable transaction record so any balance can be explained, identity and source-of-funds checks recorded against the party, and the reporting your obligations require. What we do not do is tell you what those obligations are. These rules differ by jurisdiction and change, and your regulator, professional body, or legal adviser is the authority. We build precisely to what you confirm, and we will not claim the software makes you compliant on its own.
Do you work with commercial property as well as residential?
Yes, and we design for it explicitly rather than assuming residential logic will stretch. Service charge apportionment, rent review, turnover-based rent, and individually negotiated lease terms are commercial realities that residential-first systems handle badly. If your portfolio is mixed, we identify during discovery where the two need to diverge, because it affects both cost and timeline.
How long does a real estate project take?
A focused first release is typically a few months rather than weeks or years, with further modules delivered incrementally afterwards. What moves the timeline most is migration from an existing system, where the quality of your current data usually matters more than the new build, and third-party entitlement approvals such as MLS access, which sit outside our control. We estimate after discovery rather than before.
Which technologies do you use?
Typically PostgreSQL for the relational and temporal core, a dedicated search index where property search matters, queue-driven integration with retry and replay for external feeds, and object storage with a media pipeline for property imagery. On the front end it depends on who uses the system: agents in the field need mobile-first capture, while back-office staff need data-dense desktop interfaces. Each system page sets out the specific recommendations and the reasoning behind them.
What happens after launch?
We monitor what degrades quietly rather than breaking loudly: scheduled charge generation, arrears figures, feed freshness, and reconciliation differences. We also watch which fields go unfilled and which reports go unused, because both indicate the model is wrong somewhere. Support hours and response targets are set in your agreement. Where a portfolio or a feed genuinely needs out-of-hours cover we scope and price it rather than implying it is included by default.
