Full-Stack · Property Tech2026 · In Progress

Homie Platform

A unified property management system — handling properties, tenants, leases, invoices, and everything in between.

HOMIE

Property Management Platform

Modules Designed: 12
Auth Flow: Live
DB Tables Live: 4

Client: Homie
Industry: Property Management
Engagement: Full-stack product build
Status: In Progress
Timeline: 2026 · Active Development
Scope: Web application, REST API, database

01 Overview

Who is the client?

Homie Platform is a property management system structured as a full-stack monorepo. It covers twelve operational areas: tenant applications, properties, tenants, owners, contracts, invoices, payments, showings, internal messaging, and administrative controls.

02 Problem Statement

What problem were they facing?

The client needed a single, integrated platform to manage the full scope of their property operations — twelve distinct functional areas with no shared data layer, no unified interface, and no access controls between roles.

Fragmented operations
Twelve operational areas — applications, properties, tenants, owners, contracts, invoices, payments, showings, messages, and admin — each running in isolation with no shared data layer connecting them.
No audit accountability
No system of record for mutations. The requirement for a security-compliant, immutable audit log capturing every create, update, and delete with actor and timestamp was identified as a core need from day one.
No access control
The team operates across multiple roles with different permission levels. Without role-based access control, any staff member had unrestricted reach across the entire system.
No tenant application pipeline
Tenant application management had no dedicated system. It is identified as a core operational area requiring its own module in the platform.
No relational data foundation
Properties, tenants, owners, invoices, and contracts are interdependent entities with no shared database schema. The corresponding tables do not yet exist in PostgreSQL and no Go structs are generated for them.

03 Solution

How did we solve it?

We designed and built a full-stack property management system structured as a monorepo. The architecture is split into a Go REST API backend and a Next.js 16 frontend, sharing a PostgreSQL database via sqlc for compile-time safe SQL generation.

The frontend covers 12 operational modules — all fully designed and scaffolded under the App Router structure. Authentication is live end-to-end. Operational database schemas and API handlers are in active development.

FE Next.js 16 React Frontend React 19TypeScriptTailwind v4
API Go REST API Backend sqlcCookie auth
DB PostgreSQL Database Migrationssqlc types

One monorepo · one deployment · shared PostgreSQL instance

Next.js 16
React 19
TypeScript
Go (Golang)
PostgreSQL
sqlc
Tailwind CSS v4
Radix UI
TanStack Query v5
FullCalendar
Tiptap
dnd-kit

Designed screens — fully scaffolded, data layer in progress

04 Project Timeline

Key milestones and duration

Phase 1 2025 Q4
Discovery & Architecture
Tech stack selected: Next.js 16, React 19, TypeScript, Go, PostgreSQL, sqlc. Monorepo structure defined. 12 module scope established from the frontend sitemap.
Phase 2 2025 Q4
Frontend Scaffold & Design System
Full Next.js App Router structure scaffolded under src/app — auth group, protected dashboard group, and all 12 module route segments. All view components fully designed.
Phase 3 2026 Q1
Auth System & Core DB Schema
Cookie-based session management (HttpOnly, SameSite=Lax) via Go API. Three live endpoints: POST /api/auth/login, POST /api/auth/logout, GET /api/auth/me. First migration ships four core schemas: staff, audit_log, feed_items, and settings.
Phase 4 2026 Q2 — In Progress
Operational DB Schemas
Write and migrate PostgreSQL schemas for Properties, Tenants, Owners, Invoices, and Contracts. Generate Go structs via sqlc.
Phase 5 2026 Q2–Q3
API CRUD Handlers & RBAC
Go router handlers for all business entities. Activate the RequireRole middleware (currently commented out) to enforce role-based access across all routes.
Phase 6 2026 Q3
Frontend Data Integration
Replace static mock data in all 12 module UIs with live API calls via TanStack Query.

05 Challenges & Resolutions

What obstacles did we face, and how did we overcome them?

Flexible configuration across multiple scopes
problemThe system needs to support configuration at three levels simultaneously: global platform settings, per-property overrides, and per-tenant overrides — without separate tables for each scope.
resolutionThe settings schema uses a JSONB-backed design, allowing a single table to store global, property-scoped, and tenant-scoped configuration. No schema changes are required when new configuration keys are introduced.
React 19 + TanStack Query v5 integration
problemThe frontend is built on React 19 and TanStack Query v5 — both production-grade dependencies that require deliberate integration with the Go API for server-state caching and synchronisation.
resolutionTanStack Query v5 handles all asynchronous server-state management between the Next.js frontend and the Go API, with caching and synchronisation managed at the query layer.
Go + Next.js session sharing
problemCoordinating cookie-based sessions across a Go backend and a Next.js frontend requires careful SameSite and domain configuration to ensure auth state is consistent across both sides.
resolutionHttpOnly, SameSite=Lax cookies are set by the Go API. The Next.js app never handles tokens directly — auth state is validated server-side on each API call via GET /api/auth/me.
Frontend built ahead of the data layer
problemAll 12 module UIs are fully designed and scaffolded, but the operational database tables and API handlers do not yet exist. The frontend must remain functional and reviewable without live data.
resolutionAll module views use static mock data during development. TanStack Query is already wired up as the data-fetching layer — replacing mock data with live API calls in Phase 6 requires no UI restructuring.

06 Before & After

Comparison of the situation before and after the project

Before	After
No authentication system — no controlled access to any part of the platform	End-to-end auth live: POST /api/auth/login, POST /api/auth/logout, GET /api/auth/me — cookie-based sessions shared between Go API and Next.js
No audit trail — no record of who changed what and when	Immutable audit_log schema live — append-only ledger capturing every system mutation with actor, timestamp, and entity data
No database schema for operational entities — Properties, Tenants, Owners, Invoices, Contracts had no tables	PostgreSQL schemas designed for all entities; staff, audit_log, feed_items, and settings already migrated (Phase 3 complete)
No role-based access control — no permission boundary between staff roles	RequireRole middleware built and integrated into the Go router — pending activation across all protected routes
No frontend for any operational workflow	All 12 module UIs fully designed and scaffolded: Applications, Properties, Tenants, Owners, Contracts, Invoices, Payments, Showings, Messages, Admin

The Contracts module — lease generation and electronic signing. Fully designed and scaffolded; data layer lands in Phase 4.

07 Client Benefits & Outcomes

What value did the client gain?

Modules Designed: 12; of 12 complete
Auth Flow: Live; Go ↔ Next.js
DB Tables Live: 4; staff · audit_log · feed_items · settings
Active Endpoints: 3; login · logout · profile

End-to-end authentication from day one
The complete auth flow is operational — login, logout, and profile endpoints are live, with HttpOnly cookie sessions shared between the Go API and the Next.js frontend.
Security-compliant audit trail built in
The audit_log schema is live and append-only — every system mutation is recorded with actor, timestamp, and entity data, meeting security compliance requirements from the first migration.
Flexible system-wide configuration
The JSONB-backed settings table supports global, property-scoped, and tenant-scoped configuration from a single schema — no additional tables needed as configuration requirements grow.
Frontend ready, data layer in progress
All 12 module UIs are fully designed and scaffolded with TanStack Query already wired as the data layer. Phase 6 connects live API data with no frontend restructuring required.

The Invoices module — billing and financial overviews, fully designed and scaffolded. Data layer arrives in Phase 4.

08 Key Learnings & Takeaways

What did we learn from this project?

sqlc generates type-safe Go code from SQL
sqlc takes SQL queries and generates compile-time safe Go structs and query functions. Schema changes surface as compiler errors rather than runtime failures.
Monorepo keeps the Go API and Next.js frontend in one repository
The full-stack monorepo structure means both the backend and frontend share one codebase, one development environment, and one deployment pipeline.
Auth was built and completed before any operational feature
Authentication — login, logout, and profile endpoints — was completed in Phase 3. All subsequent development is built against a live, working session model.
All 12 module UIs were designed before the database existed
The complete frontend was scaffolded with static mock data before any operational database schema existed. Phase 6 replaces mock data with live TanStack Query calls — no UI restructuring needed.
JSONB in the settings table supports global, property, and tenant-scoped configuration
The settings schema uses a JSONB-backed design to store configuration at three scopes from a single table — global platform settings, per-property overrides, and per-tenant overrides.