Property Intelligence Platform
A property data and field-operations platform — one API serving several purpose-built frontends, running on managed containers against a Postgres cluster, shipped by an automated build pipeline.
Client
Fintech (India)
Service
Cloud Architecture
Date
November 1, 2025
Challenge
Four different audiences needed four different interfaces over the same data, and the whole thing had to deploy repeatably without a platform team standing behind it. Schema changes and reference data are the two ways a container deploy quietly fails.
Solution
One container service per application on a managed orchestrator, a Postgres cluster with migrations held in version control, per-service build pipelines, configuration in a managed secret store, and a deploy procedure that treats migrations and seed data as separate shippable things.
The shape of it
The data is property and field-visit data. The consumers are not one product: an internal dashboard, a field capture app for walk-ins, public-facing forms, and an API that other services call. Building one interface flexible enough for all four would have produced something bad at each. Building four frontends against one well-specified API produced something maintainable.
Infrastructure
Each application runs as its own container service on a managed orchestrator, which means each can be scaled and rolled independently and none of them can take the others down by misbehaving. The data layer is a managed Postgres cluster. Every service reads its configuration from a managed secret store rather than baked-in environment files, so rotating a credential does not mean rebuilding an image.
Builds are per-service pipelines: a change to one frontend rebuilds and redeploys that frontend only.
The lesson worth writing down
A container deploy is not a release. Three things can need shipping and only one of them is automatic:
- Application code — the pipeline handles this.
- Schema migrations — held in version control, but applied deliberately.
- Reference and seed data — the rows a feature needs in order to function at all.
Skipping the third is the reason a feature can deploy successfully, report healthy, and still not work. Most “the deploy went fine but the feature is broken” incidents on this platform traced back to missing reference rows rather than to code. Codifying a verification pass — what is deployed versus what is on the main branch, which migrations have run, whether the seed rows exist — turned that from a recurring surprise into a checklist item.
Stack
TypeScript, NestJS, Prisma, PostgreSQL, ECS Fargate, CodeBuild, AWS.