[HN Gopher] Launch HN: Propify (YC W23) - Property Management Sy...
___________________________________________________________________
Launch HN: Propify (YC W23) - Property Management System API
Aggregator
Hey HN, we are Remen, Ben, and Nick, the founders of Propify
(https://getpropify.com), an API aggregator for residential
property management. We abstract over archaic APIs and merge them
into a single modern API for the real estate industry, giving
companies access to multiple property management systems (PMSs) via
a REST API. Think merge.dev or Plaid for real estate. Property
managers nowadays use software to operate residential rental
properties. Our customers are not these property managers directly,
but companies who provide services to both property managers and
renters. Our customers are solving problems around resident
screening, security, parking, maintenance, etc., which property
managers typically outsource. Compared to most other industries in
2023, property management still runs on old tech with
bad/wrong/absent API documentation. Creating and maintaining
integrations with these systems is incredibly painful (1999 called
and wants to tell you about its cool new SOAP technology!) As an
example of what we're solving for, one prospective customer told us
they regularly get 503 (service unavailable) errors from one of
these PMSs at the beginning of each month because the system can't
process rent payments and other requests at the same time. We
address challenges like this using an exponential backoff retry
strategy. We abstract over all these APIs to give our customers
software they can reasonably use. Our goal is to eliminate old
tech, poor docs, and unreliable infra for our customers so they can
focus on delivering value instead of fighting with integrations.
We offer a tested RESTful API with accurate documentation and
modern architecture that we can scale. In addition, we want to make
the developer experience as good as possible with things like
webhooks, SDKs, websockets, and even a GraphQL API (coming later
this year). Before Propify, we built a rent payment app to bridge
the technology gap between renters and landlords. Then we
encountered the pain of PMS integrations and decided to pivot and
solve that problem instead. dang suggested that we include a
product demo or video but since our core product is an API, there's
not that much to show--sorry! But our docs are here:
https://docs.getpropify.com/, and if you're working/interested in
this space and have your own credentials for one of our supported
integrations, we'll be happy to get you a sandbox account and a
demo. This industry has been stagnant because of the barrier to
entry for integrating with these vital PM systems. Our goal is to
unlock innovation by pulling real estate tech into the modern
world. Ultimately, developer experience is incredibly important to
us, and we are always looking for areas where we can improve. We
welcome your feedback, questions, and comments!
Author : kole78
Score : 62 points
Date : 2023-03-15 16:40 UTC (6 hours ago)
| obblekk wrote:
| Curious how you implemented this to be more reliable? Headless
| browsers or official APIs?
| kole78 wrote:
| Great point of clarity. We made a business decision to only
| leverage actual APIs from these companies. As a result, our
| customers are still required to have an official relationship
| with each PMS they want to integrate with. We have made it a
| point to not do anything that violates ToS for each of these
| systems.
|
| While we do possess some insight into how to more easily
| navigate the business development process with each PMS (and we
| help our customers do so), we do not help or encourage anyone
| to circumvent the process altogether.
|
| Without naming specifics, it seems you have identified perhaps
| one of the more closed systems.
| rbaudibert wrote:
| 3 questions:
|
| 1. Where are the docs for Webhooks?'
|
| 2. Is there any way to get only partial data, which was updated
| since the last time we hit your API? Is there a way to use a
| date-based cursor?
|
| 3. Is the data being saved (and duplicated) in your server, or
| are you simply parsing the request, converting to the PMS format,
| hitting their API, formatting the data, and sending it back,
| every time?
|
| edit: formatting
| kole78 wrote:
| Thanks for the questions!
|
| 1. Docs for webhooks are located in our app (after login). But
| a basic outline is that you add your URL, add any custom
| headers you wish, get the signing key, subscribe to an event
| and you're off the races. Events that we currently support are
| Job Success, Job Failure, New Data, Diff Data. Probably the
| most popular event (as you have alluded to in your next
| question) is our Diff Data event. The payload for this event
| will return only the data that has changed for a particular
| record since the last time we received data from a PMS.
|
| 2. Currently, not via the API. We will be adding more features
| like this to the API in the coming weeks. For now, our
| customers seem to prefer the Diff Data webhook anyway.
|
| 3. We do cache the data. One of the hallmarks of PMS APIs is
| that they are unreliable. That being the case, all of the data
| served from our API is from our cache so we can pass along our
| uptime SLA benefits to our customers.
| rbaudibert wrote:
| Thank you for responding so promptly! That seems quite
| interesting :).
|
| Diff data + new data definitely seem what 90% of your
| customers will need.
|
| Another quick question: When you say "Job Success/Failure",
| what's a job?
|
| _Full disclosure: I work at LeadSimple
| <https://www.leadsimple.com> and we integrate with most of
| these companies ourselves, and these questions were just me
| being interested in knowing how you solved (or intend to
| solve) some of the same problems we had to solve when
| integrating with them :)_
| kole78 wrote:
| Of course, since we are not a pass-through API, our tech is
| set up as an async ETL. So a job represents a unit of work
| for Propify either fetching data from or pushing data to a
| PMS. You can track jobs to understand the lifecycle of your
| requests and overall status of your integrations.
| rbaudibert wrote:
| Oh, got it, because you'll save any POST/PATCH request
| and try updating it in the PMS in case they've been down.
| That's cool, thank you for clarifying that :)
| A6gYPfxNas wrote:
| Awesome concept! Good luck!
| kole78 wrote:
| Thank you!
| nerdchum wrote:
| Are y'all based out of Lafayette, Colorado by any chance?
| kole78 wrote:
| Haha strange question, but no. We are in SF for the YC batch,
| and then back to Boston where we all normally live.
| letsgetsilly wrote:
| It's my understanding that PropertyWare requires large licensing
| fees to access their API. How are these fees managed for your
| development/testing/production access, and how are they (or not)
| passed on to your customer?
| kole78 wrote:
| Propertyware does charge an access fee, you are correct.
| Additionally, they offer a licensing agreement where their
| customers can provide API keys to consultants to help them
| build out their tool(s). We are one of those consultants.
|
| As far as who assumes the access fees, they are managed
| strictly by our customers and we have no pass-through pricing
| on that side. Our pricing is solely based on our own costs,
| infra, value, etc. All of our customers get access to all of
| our integrations (current and future) as part of our standard
| pricing model.
| stevenaanen wrote:
| Very interesting proposition. Curious, which PMSs are you
| integrating with first?
|
| I'm the CTO of https://obeyo.com and integrations are a huge
| thing for us.
| kole78 wrote:
| Ben said he's talking to you all next week! Looking forward to
| it.
|
| Our current integrations include Yardi, RealPage, Entrata,
| Propertyware, Buildium, Rent Manager and Rentvine. On the
| roadmap are Appfolio, MRI and ResMan.
| idopmstuff wrote:
| Can you give some example use cases for this? For context I own
| some investment properties and have a property manager who
| manages them, so I have some familiarity with tools like Appfolio
| (but probably not as much as you'd expect your target customer to
| have).
|
| I'm just curious what this would be used for. Maybe user story
| style - as <who> I would be able to <what>.
| kole78 wrote:
| Of course! Let me give this a shot with a couple examples in
| your suggested format...
|
| - As an engineer for a tenant background check company, I can
| use Propify to easily integrate with systems like Entrata,
| Buildium and Propertyware so that I only need to create a
| single integration instead of 3.
|
| - As a sales rep for a property maintenance company, I can
| confidently sell into new property managers who use systems
| that we don't integrate with yet because I know a new
| integration for our engineering team is basically like flipping
| a switch.
| idopmstuff wrote:
| Aaah, got it now - thank you!
| jxramos wrote:
| I've seen a lot of appfolio usage in the rental application
| process in the last two years. https://www.appfolio.com/
|
| I'm wondering if that tooling is more customer facing and the
| Propify solution is more I don't know business to business
| oriented for the folks that serve property managers? It's
| interesting to see this space take off into tech, better than
| mailing a check and doing email tag.
| kole78 wrote:
| You are 100% correct. Propify is focused on the relationships
| between companies like the rental application processors and
| the property managers who use systems like Appfolio. We really
| appreciate the kind words and hope to be as helpful as possible
| in pushing this industry forward!
| zdms wrote:
| I work with multiple PMS platforms and centralizing even a simple
| unit price table is hellish given different PMS have different
| paradigms for concepts such as unit pricing. For example, Yardi
| (depending on the version of course) has 3 different tables for
| Market Price of a unit flying around in the backend, each with a
| slightly different definition.
|
| Another issue (for users not API creators) is the lack of
| universal KPI definition - there are at least 6 major ways of
| calculating occupancy, each one needing its own specific dataset
| (economic occupancy, physical occupancy, economic occupancy
| revenue generating units, physical occupancy revenue generating
| units, trending occupancy, trending occupancy revenue generating
| units)
|
| Concepts such as renewal ratio and collection ratio are
| particularly difficult due to their time component. Most of the
| pain comes not from getting the data out of the PMS through an
| API but rather knowing WHAT data is needed and for what KPI.
| kole78 wrote:
| Totally agree! This is part of the conversation with each of
| our customers. We have learned early that this is a part of the
| pain and we are solving it in two ways:
|
| 1. Rapidly developing a deep understanding for naming and
| meaning within each PMS so we can speak intelligently, and
| properly guide our customers to focus on the data they care
| about.
|
| 2. Technically, we have data transformations at a couple
| different layers so we can repoint data coming in to exist in
| customer-specific locations for their business needs.
| [deleted]
| pplante wrote:
| I wish this was a thing back in 2012 when I was the technical co-
| founder of Rentlytics! We built our own integrations and it was
| terrible working with these systems. The docs were non existent
| and APIs limited in their capabilities to further vendor lock in.
|
| What systems do you support? I couldn't find a list anywhere.
| kole78 wrote:
| Thanks for your feedback! Unfortunately your story is a common
| one - not much has changed with these APIs since 2012... or
| since 1999 for that matter.
|
| Our current integrations include Yardi, RealPage, Entrata,
| Propertyware, Buildium, Rent Manager and Rentvine. On the
| roadmap are Appfolio, MRI and ResMan.
|
| Necessary disclaimer: we only support integrations for
| customers who have officially sanctioned relationships with
| each PMS. We do not do anything that violates ToS (e.g.
| scraping, chrome extensions, etc.).
| pplante wrote:
| From my memory some of the big players require api license
| fees in the thousands per api. It was my understanding that
| these are to be paid by every implementor using their docs.
| How are you guys getting API access to build? Is this not
| really as common anymore?
| kole78 wrote:
| Some of the systems remain pay-to-play for sure. We have
| adopted the consultant model where we are implementing our
| solution on behalf of our customers. This is why we require
| our customers to have their own relationship with each PMS.
| Their credentials are used to access each API. I sent a
| connect request to you on LI - happy to chat in more
| detail!
| Cshelton wrote:
| Ah, I went to your "How it Works".. didn't see Yardi,
| RealPage, or MRI and almost dismissed this product entirely!
|
| Recommend updating that screenshot!
|
| Now I'm interested.. will submit work email. I'm head of
| product at RealINSIGHT
| samstave wrote:
| HouseCannary
|
| Look them up
| InitialLastName wrote:
| Hear me out: instead, you could put the slightest bit of effort
| in and tell us what they are and why they are relevant.
| mikaeln wrote:
| Hmmmm, interesting
| ramesh31 wrote:
| Should probably clarify in the title that this is for property
| management, not real estate. MLS data is notoriously impossible
| to get without huge contracts, which is what made want to check
| this out.
| jxramos wrote:
| what's the deal with MLS data? That sounds pretty interesting,
| some kind of protective moat they have in place? What's the
| backstory there?
| ismokedoinks wrote:
| I misread it the same way--I've been praying for a good API to
| do some housing affordability data projects.
| kole78 wrote:
| Updated. Thanks for the feedback!
| TheMiddleMan wrote:
| Very nice!
|
| I wish you had a page listing which vendors you currently
| integrate with. I was able to find it in the docs though,
| eventually.
| echion wrote:
| Would love to know who your clients are so we could patronise
| them :)
___________________________________________________________________
(page generated 2023-03-15 23:00 UTC)