How we build

Tech Stack

Assume nothing exists yet. Every choice below is argued on its own merits for this specific product — a real-estate transaction platform, document- and forms-heavy, with a mobile app, 5 portal types, and real legal/financial exposure — not on what happens to already be running.

Backend language

Option	Pros	Cons
Python (FastAPI)	Pydantic gives strong data validation for exactly the kind of deeply nested, rules-heavy data this product has — a transaction, a Transitional Document, jurisdiction rules API-first by design, so mobile and every web portal consume the same surface — one source of truth for business logic, not a views-and-a-separate-API split Best-in-class libraries for PDF/document generation and data processing, relevant to the Transitional Document and jurisdiction rules engine Excellent AI-coding-assistant support and a strong, available Nepal talent pool	Weaker raw throughput than compiled languages at high scale — irrelevant at pilot volume Type safety requires discipline (mypy/pyright), doesn't come for free
Django (Python)	Batteries-included — admin panel, ORM, auth out of the box could genuinely accelerate the Broker/Admin back-office screens Same Python talent pool and AI-assistant strength as FastAPI	Built around server-rendered views first; using it purely as an API (via DRF) for a mobile-first product gives up most of the "batteries included" advantage anyway More opinionated/monolithic structure than a lean team building 5 distinct portal types plus a mobile API needs
Node.js / TypeScript	Strong typing by default Very strong async I/O — a real advantage for webhook-heavy integration work (e-signature callbacks, payment webhooks) Very strong AI-assistant support	Weaker document/PDF and data-processing ecosystem than Python for the Transitional Document and jurisdiction-rules work specifically Real async footguns are a common source of subtle bugs
Ruby / Rails	Mature, convention-over-configuration — historically strong for fast, CRUD-heavy startups, which this product genuinely is	Smaller Nepal talent pool than Python/Node Ecosystem and AI-assistant momentum has slowed relative to Python/TypeScript in recent years
Go	Excellent performance and concurrency story Simple, hard to write deeply "clever" bad code	Verbose for CRUD-heavy, forms-and-documents product work — the performance advantage isn't the bottleneck this product has Smaller Nepal talent pool than Python/Node
Rust	Best-in-class performance and memory safety Growing ecosystem momentum	Steepest learning curve of any option here — slowest to prototype in Smallest Nepal talent pool of all options listed AI-assistant code generation is improving but still lags Python/JS, and the borrow checker punishes half-correct generated code — a bad match for a lean, fast-moving pilot team
Java / Kotlin	Mature ecosystem, strong typing, good for large teams over years	Heaviest ceremony of the options here — wrong trade for a lean team validating a pilot

Database

Option	Pros	Cons
PostgreSQL (via RDS)	Relational model fits the product's actual shape: transactions, parties, documents, jurisdiction rules, and the commission ledger are all deeply related, and Broker/Admin reporting needs ad hoc joins across them JSONB columns give schema flexibility exactly where it's needed (jurisdiction-specific form fields, the Transitional Document's variable structure) without abandoning relational integrity everywhere else Mature row-level security pairs directly with the tenant-isolation model, see Multi-Tenancy RDS handles backups, patching, and Multi-AZ failover — no dedicated DBA needed on a lean team	Vertical scaling has a ceiling eventually — not a near-term concern at pilot volume
DynamoDB	Scales horizontally with very little operational effort Serverless-friendly, pay-per-request pricing A genuine fit for narrow, high-volume, simple-access-pattern data — e.g. an activity/audit-event log, later, as a secondary store	Forces awkward data modeling for deeply relational data with many access patterns — exactly what a transaction record with parties, documents, and a commission ledger is Ad hoc reporting/analytics queries (explicitly in Phase 1 scope for Admin/Broker) are painful without a relational engine Wrong primary store for this product; worth revisiting only for a specific high-volume sub-system later, not as the system of record
MySQL (via RDS)	A legitimate relational alternative — mature, managed the same way as Postgres on RDS	Weaker JSON/extensibility story than Postgres for the semi-structured parts of the schema No structural advantage over Postgres for this product to justify picking it instead
Self-hosted Postgres on EC2	Marginally cheaper at small scale, more low-level control	Backups, patching, and failover become the tech lead's manual responsibility instead of AWS's — real time taken from foundations/feature work for a cost saving that doesn't matter yet

Mobile

Option	Pros	Cons
Flutter	One codebase for iOS + Android, rendered consistently (Skia/Impeller) rather than through each platform's native components — genuinely valuable with one designer producing one set of screens for both platforms Strong, predictable performance Nepal talent pool has grown substantially and is no longer a real gap	Dart is a narrower skill than JavaScript — a smaller total hiring pool than React Native, even if currently sufficient Occasional platform-specific quirks need native escape hatches
React Native	Largest ecosystem and hiring pool of the cross-platform options Shares JavaScript/TypeScript with a Node backend, if that had been the pick above (it isn't)	Renders through native platform components, which can look and behave subtly differently per platform — more design/QA burden for consistency with a single designer and no dedicated cross-platform QA With a Python backend, the "shared language" argument doesn't apply here anyway
Native (Swift + Kotlin, separately)	Best possible platform fit and performance	Two codebases to build and review — not viable for a mobile team sized at one to two engineers Not justified at pilot scale regardless of team size

Web frontend

Option	Pros	Cons
Server-rendered (Jinja2 + HTMX + a CSS framework)	No build step, no client-state framework to reason about — matches the actual shape of 5 portals that are mostly forms, tables, and documents, not real-time collaboration Simpler for AI to generate safely — a template rendering a value is much harder to get subtly wrong than client-side state management Lower total surface area for a lean team to own across 5 distinct portal types	Less suited to a highly interactive experience if Merchant Integration's marketplace browsing later needs rich client-side filtering/search
SPA framework (React / Vue)	Better fit for rich, highly interactive UI Large talent pool	Adds a build pipeline, client-state management, and API-versioning discipline between backend and frontend — real ongoing complexity for a lean team, for interactivity this product's actual UI shape (forms, tables, documents) mostly doesn't need yet

Infrastructure: AWS reference architecture

AWS. Not a default — the founder's own hands-on expertise is AWS specifically, a genuine first-principles reason to pick it (faster, better-informed infrastructure decisions from day one) rather than a generic "any cloud would do" choice. Concretely, for Phase 1:

Compute	ECS Fargate (containers, no server fleet to patch) for the API — App Runner is a lighter-weight alternative worth a look, but Fargate gives more control over networking/VPC placement for the DB access this product needs
Database	RDS PostgreSQL, Multi-AZ in production, single-AZ in staging — see the comparison above
Object storage	S3 — signed e-signature documents, Transitional Document attachments/photos, marketplace vendor assets
CDN	CloudFront in front of S3 and static assets
Networking	VPC with private subnets for the database and application, a public-facing ALB for API ingress — the database is never directly internet-reachable
Secrets	Secrets Manager / Parameter Store — never in code or committed env files
Observability	CloudWatch for logs and metrics; a dedicated error tracker (see Cost) rather than relying on CloudWatch alone for application-level errors
IaC	Terraform or AWS CDK from week 1, owned jointly by the founder and the tech lead — environments reproducible from a repo, not hand-configured in the console

Deliberately excluded from Phase 1: Kubernetes/EKS (real operational overhead a lean team doesn't need at this scale), multi-region deployment (one region is enough for a single-state or 2–3-state US pilot). See Cost for the actual AWS spend estimate.

How we build: AI-native with human-in-the-loop, everywhere

Every developer has Claude coding access, in every scenario on this site. That's a real velocity multiplier on well-specified, well-scoped work, and part of why the team can stay lean (see Team) — but it's a real risk on anything that touches money or law if it's not paired with deliberate review discipline. The practice, not just the principle:

Safe to AI-generate with light review	Always senior-authored or line-by-line human-verified
Test scaffolding and test cases following an established pattern CRUD boilerplate, UI screens matching the existing design system Documentation, code comments, migration scripts following a known shape Refactors with full test coverage as a safety net	Jurisdiction rules logic (disclosure timing, forms) Commission/payment math and the Merchant Integration ledger E-signature vendor integration, especially webhook/callback handling Auth and permissions logic The Transitional Document's gap-detection logic (it drives real recommendations)

The mechanism that makes this real, not aspirational: mandatory PR review — 1 senior approval standard, 2 for anything in the always-human-verified column — enforced before merge, for every change regardless of who or what authored the first draft. "AI wrote it and it looked fine" is not a merge criterion.

Every recommendation above is argued from the product's actual shape and this team's actual composition — not from what's already running. Where that happens to land on the same stack the POC already uses, that's the first-principles case holding up, not a reason on its own.