Own SaaS product · anonymized case study

Anonymized PropTech SaaS Platform

A technically complex SaaS product platform in the real-estate domain, technically owned from architecture to operations.

Role: Co-founder & CTO · technical ownership
Timeframe: 2025-2026

Context

Starting point & problem

Property management combines legal rules, workflows, documents, deadlines, payments and communication. The product had to model that complexity clearly while staying maintainable.

The platform was intentionally built as a product family: a central web application, supporting portals and reusable domain and UI building blocks share one foundation.

Role

My role & scope

As co-founder and CTO, I owned architecture, backend, data model, frontends and operations while shaping central product decisions.

The focus was clear domain boundaries, consistent data handling, reusable components and an operating setup that stays reliable with a small team.

Architecture

Decisions & trade-offs

Domain logic split into clearly bounded modules instead of one large product core.

Why: Clear boundaries keep complexity local and allow individual product areas to evolve independently.
Trade-off: More initial structure and discipline around interfaces instead of quick cross-wiring.

One shared platform layer for domain model, data access and UI foundations.

Why: Shared building blocks keep behavior and UI consistent and avoid duplicate work per product area.
Trade-off: Stronger coupling to shared contracts and more careful maintenance of shared packages.

Domain-sensitive calculations implemented as isolated, testable domain engines.

Why: Stateless engines can be used by multiple surfaces and tested independently from the rest of the server.
Trade-off: A strict module boundary and injected data instead of convenient direct access to the domain.

Critical domain logic backed by traceable test cases.

Why: Sensitive workflows need visible and reviewable assumptions, not just technically passing tests.
Trade-off: More effort in validation and documentation in exchange for less risk in core workflows.

Backend with manual dependency injection instead of a decorator or magic framework.

Why: An explicit lifecycle (route -> service -> repository) is easier to read, test and maintain over years.
Trade-off: A little more boilerplate in exchange for much less hidden behavior.

PostgreSQL as the reliable core, keeping atomicity close to the data.

Why: Consistent domain workflows need traceable transactions instead of purely optimistic client logic.
Trade-off: More logic near the database, but hard consistency guarantees.

Implementation

Technical highlights

Multiple web surfaces and portals on one shared platform layer
Domain-driven backend with explicit service and repository boundaries
Reusable UI and domain building blocks for consistent product areas
Testable calculation and consistency logic for sensitive workflows
Self-hosted operations with Docker, monitoring and traceable deployments

Stack

Technologies used

TypeScriptNext.jsReactNode.jsPostgreSQLDockerPWA

Outcome

Impact

The project shows my ability to turn a complex domain into a durable SaaS platform: from domain boundaries and frontend to backend and operations.

This case study is intentionally anonymized and reduced. Details about product scope, internal modules and integrations stay private; the relevant engineering work remains visible.

Reflection

What I would decide differently today

Today I would cut individual domains vertically even earlier and prioritize proof material in parallel with development. The fundamental choices around clear domain boundaries, explicit layers and PostgreSQL as a reliable core have nevertheless proven durable.

Sounds like a profile that fits your project?

Check availability More projects