Посібник
Як структурувати PropTech ринок або платформу оголошень нерухомості
Коротка відповідь
Платформа PropTech може залишатися програмним або рекламним бізнесом, або вона може стати брокером, посередником у транзакціях, управлінцем нерухомості або обробником платежів завдяки своїм функціям. Периметр залежить від оголошень, рекомендацій, переговорів, депозитів та того, хто отримує комісію за транзакцію.
Розпочніть з дорожньої карти продукту, а не з меню ліцензій. Запишіть, що платформа робить сьогодні і що додають наступні релізи — оголошення, обмін повідомленнями між сторонами, пропозиції, резервування, платежі — оскільки регуляторна відповідь змінюється функція за функцією. Потім відокремте звичайну реєстрацію компанії від будь-якого брокерського, рекламного чи грошового дозволу, який спровокує дорожня карта.
Чому модель експлуатації попереду юрисдикції
У технології нерухомості регульовані учасники — брокер, управитель, розробник — визначаються за функцією, і платформа успадковує їх зобов'язання в момент, коли її функції виконують ці функції, незалежно від того, як називає себе компанія.
Юридична особа, зареєстрована для розробки програмного забезпечення, може випустити продукт, який тихенько стає брокерством: в момент, коли платформа вводить сторони, проводить пропозиції або отримує доходи від завершення, аналіз змінюється. Корисне питання не в тому, яка ліцензія видається найшвидше; йдеться про те, яка функція, в якому релізі, вперше виконує регульовану функцію — і яка юридична особа триматиме цю функцію, коли це станеться.
Почніть з вибору того, яка з цих моделей найближче описує ваш план:
- Програмне забезпечення, яке постачається брокерам і розробникам
- Портал для оголошення нерухомості та генерації лідів
- Цифрова брокерська або транзакційна платформа
- Застосунок для оренди, обслуговування або управління нерухомістю
Якщо застосовується більше ніж одна модель, стандартним рішенням є розподіл: технологічна структура, яка розробляє та ліцензує продукт, та окрема затверджена структура, яка виконує будь-яке брокерство, управління або обробку грошей, які дозволяє продукт. Цей розподіл захищає оцінку програмного бізнесу від зобов'язань регульованої частини.
Де може закінчитися звичайне створення компанії
Перевірте ці питання на основі поточного продукту та наступних релізів, а не лише на основі презентаційної дошки, перш ніж обрати юрисдикцію або діяльність:
- Брокерська діяльність, переговори та комісійна діяльність
- Авторизація на оголошення та рекламу
- Депозити, орендна плата та обробка платежів
- Дані про нерухомість та клієнтів
- Перевірка розробника, брокера та власника
Виявлена проблема — це запитання, а не вирок — безліч моделей перелічення та програмного забезпечення перебувають поза регульованою територією. Те, що ніколи не працює, — це захист через ярлик: називати продукт ринком або інструментом SaaS, коли його робочий процес веде угоди або переміщує депозити.
Позиція для платформи є документом, що містить характеристики: що продукт робить, що він навмисно не робить, які регульовані функції залишаються для затверджених партнерів і які заплановані функції можуть змінити відповідь. Інвестори, партнери порталу, банки та постачальники платежів усі перевіряють саме цей документ.
Структурні рішення, які змінюють відповідь
Вибір продукту та монетизації визначають рішення щодо компанії, тому виправте ці змінні перед порівнянням материк, вільна зона та фінансових центрів:
- B2B SaaS проти споживчого ринку
- Комісія за залучення, підписка або транзакційна комісія
- Хто комунікує пропозиції та укладає угоди
- Контроль руху грошей та депозитів
- ОАЕ та покриті типи нерухомості
Юридична особа, яка укладає угоди з користувачами, повинна відповідати тому, що продукт насправді робить для них — комісії за програмне забезпечення для компанії програмного забезпечення, регульовані послуги для затвердженої. Власник інтелектуальної власності або зарубіжний материнський підрядник може займати вищу позицію з реальними ролями. Структури, які ігнорують дорожню карту, виступають пізніше як аварійне повторне платформування в середині раунду фінансування.
Витрати та терміни: використовуйте шари, а не одне заголовне число
Для платформи ліцензія є невеликою лінією поряд з інженерією, але регульовані функції мають свій власний бюджет, де б вони не знаходилися. Бюджет у шарах:
- Формування підприємства: реєстрація, учредні документи, вибір діяльності, стартова картка, робоче місце та імміграційна спроможність — легкий рівень.
- Схвалення, що активуються функціями: будь-які дозволи на брокеридж, рекламу або перелік, які модель потребує, незалежно від того, утримуються вони безпосередньо чи через партнерів, плюс юридична робота з проведення меж.
- Операційна інфраструктура: сам продукт, хостинг і дані, інструменти верифікації переліків та інтеграції платежів або ескроу, які тримаються поза технологічною юридичною особою — домінуючий рівень.
- Люди та управління: керівництво у сфері інженерії та продукції, будь-які окремо затверджені особи, яких потребує регульований підрозділ, відповідальність за дотримання вимог щодо даних та реклами, а також візи для команди.
- Постійні зобов'язання: поновлення ліцензій і дозволів, угоди платформи та порталу, підтримка захисту даних, аудити та подання податкових звітів.
Чистий запуск програмного забезпечення обмежується головним чином створенням і банківським укладанням контракту; кожна регульована функція, додана до сфери дії, додає етап схвалення перед випуском. Чесний графік покаже, який випуск поставляється лише за торговою ліцензією, а який чекає на дозвіл — або на партнера.
Готовність до банківської, інвестиційної та комерційної діяльності
Банк читає платформу через її грошові потоки: дохід від підписки простий, але успішні комісії, бронювання та будь-що, що нагадує депозити, кардинально змінює розмову. Підготуйте наступне до початку процесу укладання контракту:
- Карта функцій до дозволів
- Рамка верифікації переліку
- Угоди з брокерами та розробниками
- Архітектура даних та платежів
- Витрати споживачів і процес скарг
Заявка на обліковий запис, умови використання і презентація повинні описувати той самий продукт — особливо щодо того, хто отримує комісію і хто утримує кошти. Відхилення тут — це класична помилка під час укладання контракту на платформу. Вирівнювання прискорює його; ніщо не гарантує обліковий запис, дозвіл або схвалення.
Питання, на які потрібно відповісти перед тим, як сплачувати за налаштування
- Чи відображає платформа лише інформацію?
- Хто веде переговори та отримує комісію?
- Чи можуть користувачі платити або резервувати власність?
- Хто перевіряє оголошення?
- Які ринки охоплюються?
Залиште кожне непідтверджене питання з його власником — продуктом, консультантом або ліцензуючим органом — і датуванням згідно з дорожньою картою. На платформі чесна відповідь вчорашнього дня закінчує свою дію з наступним оновленням функцій.
Поширені помилки
- Визначення угод, що ведуть до генерації клієнтів
- Публікація неперевірених оголошень
- Отримання депозитів через технологічну компанію
- Розширення на емірати без повторної перевірки правил брокерів
Дорога помилка в PropTech - виявити в середньостроковій перспективі, що функція, яка була впроваджена, зробила компанію брокером або особою, що обробляє кошти, без відповідного дозволу. Порівняйте всі маршрути за тим, як кожен з них вписується в дорожню карту — дозволи, варіанти партнерства, витрати на реструктуризацію — а не лише за початковою платою.
Що оцінює Velarozone
Оцінка за підтримки консультантів Velarozone перетворює дорожню карту продукту на рішення щодо створення. В залежності від фактів, письмовий план може охоплювати:
- Категорії маршрутів, які варто порівняти, та як кожен з них розглядає програмну одиницю поряд з регульованим підрозділом.
- Які поточні та заплановані функції є звичайним постачанням програмного забезпечення, а які спонукають до отримання дозволу.
- Залежності партнера, даних та обробки платежів, які дозволяють платформі залишатися на правильній стороні межі.
- Слії витрат, у яких інженерні рішення та регульовані функції, а не ліцензія, формують бюджет.
- Документи, відкриті питання класифікації функцій і припущення, які потребують підтвердження спеціалістів.
- Послідовність подачі, яка починається тільки після того, як клієнт розуміє та затверджує маршрут.
Остаточний список уповноважених осіб, точний вибір діяльності, поточні вимоги та шлях подачі підтверджуються на основі актуальних даних. Це результати рішень, а не заяви сайту.
