Ali Farrokhtala
Menu
EmailGitHubLinkedIn

Selected work

Projects shaped by real constraints.

Applications, experiments, and research tools built to make complex domains easier to use and understand.

Build notes use shortened examples to show the real architecture and workflow without pretending to be a full source listing.

Full-stack investment platform

Home In Block

A property-investment and tokenization application with server rendering, type-safe routing, authentication, relational data, and production observability.

TypeScript · React 19 · TanStack Start · PostgreSQL · Drizzle ORM · Better Auth

Open build notes

What I built

  • Modelled properties, users, transactions, investments, and token holdings in PostgreSQL.
  • Kept types aligned across React components, routes, server functions, and database operations.
  • Added authentication, seed data, controlled migrations, logging, tracing, and application monitoring.
System sketch
React routesServer functionsAuth boundaryDrizzle + PostgreSQLLogs + traces

Build sequence

  1. Define the ownership, investment, transaction, and token-holding relationships before building screens.
  2. Generate and review migrations so schema changes remain reproducible between environments.
  3. Put authenticated reads and writes behind server functions instead of trusting client state.
  4. Seed representative property and investment data to exercise the complete workflow.
  5. Instrument requests and database work with Sentry, OpenTelemetry, Grafana, and Loki.

Typical schema workflow

npx drizzle-kit generate
npx drizzle-kit migrate
npm run dev

Failure modes & troubleshooting

A server-only import reaches the browser bundle.

Separate database helpers from callable server-function wrappers and keep secrets behind the server boundary.

The TypeScript schema and deployed database drift apart.

Generate versioned SQL, inspect the diff, then apply the same migration sequence in every environment.

A protected action is hidden in the UI but still callable.

Repeat authorization at the server-function or middleware boundary; the interface is not a security control.

Full-stack commerce platform

Online Store

An e-commerce system covering authentication, catalogue search, cart and checkout workflows, persistent state, automated tests, containers, and AWS deployment.

React · Redux · Redux-Saga · Node.js · Express · MongoDB · PostgreSQL · Docker · AWS

Open build notes

What I built

  • Built product search, filtering, cart persistence, authentication, and checkout workflows.
  • Used MongoDB for catalogue data and PostgreSQL for relational transaction workflows.
  • Protected critical journeys with Jest and React Testing Library before containerizing the services for AWS EC2.
System sketch
React storefrontRedux + sagasExpress APICatalog + ordersDocker on EC2

Build sequence

  1. Map the customer journey from catalogue search to a confirmed order and make each state transition explicit.
  2. Keep product discovery in the catalogue store while treating PostgreSQL as the transactional order system.
  3. Coordinate asynchronous cart, account, and checkout work through Redux-Saga.
  4. Test behaviour through the controls and labels a customer uses, rather than component internals.
  5. Build the services into containers and run the production composition on an EC2 host.

Containerized release check

docker compose up --build
npm test
docker compose -f compose.yaml   -f compose.production.yaml up -d

Failure modes & troubleshooting

The cart renders before persisted state finishes loading.

Represent hydration as an explicit state and block checkout until the stored cart has been reconciled.

A catalogue update changes an item after checkout begins.

Snapshot the price and product identity on the order, then commit the relational checkout work together.

The container works locally but is unreachable on EC2.

Check the bound host port, production environment values, process logs, and the EC2 security-group rule in that order.

Research data-modelling toolkit

Network Analysis

Reproducible workflows for processing large spatio-temporal datasets and studying network behaviour with clustering, centrality, spectral analysis, and graph visualizations.

Python · Pandas · NumPy · NetworkX · Matplotlib · Jupyter

Open build notes

What I built

  • Processed more than 500,000 noisy, partially labelled mobile-sensor records.
  • Converted time-based observations into dynamic graph models for human-mobility research.
  • Ran clustering, centrality, spectral, breadth-first search, and HITS analyses in reproducible notebooks.
System sketch
Raw sensor dataClean + validateTime windowsNetworkX graphMeasures + plots

Build sequence

  1. Profile timestamps, identifiers, missing values, duplicate readings, and label coverage before modelling.
  2. Normalize the observations into stable entities and relationships.
  3. Build graph snapshots for daily, weekly, or monthly windows instead of flattening time away.
  4. Compare clustering, centrality, spectral, breadth-first search, and HITS results.
  5. Record parameters and visual outputs in notebooks so the analysis can be repeated for publication.

Representative graph pass

edges = (
    readings.dropna(subset=["source", "target"])
    .groupby(["source", "target"])
    .size()
    .reset_index(name="weight")
)

graph = nx.from_pandas_edgelist(
    edges, "source", "target", ["weight"]
)
hubs, authorities = nx.hits(graph, max_iter=500)

Failure modes & troubleshooting

A few malformed records create misleading graph structure.

Validate identifiers and time ranges before edge construction, then report how many rows each cleaning rule removes.

HITS fails to converge on a graph snapshot.

Inspect connectivity, increase the iteration ceiling deliberately, and preserve the tolerance with the result.

A full analysis exceeds local memory or runtime.

Reduce columns early, process bounded time windows, and move the intensive run to the university computing cluster.

Real-estate data application

REIT Analytics

A Django application with a normalized relational model for properties, agents, owners, features, investments, and role-specific workflows.

Python · Django · SQLite · Django ORM

Open build notes

What I built

  • Designed a normalized schema with more than eight models, foreign keys, and junction tables.
  • Implemented CRUD workflows for properties, agents, owners, features, and investments.
  • Created reusable fixtures and documented migration and schema-management procedures.
System sketch
Role-based viewsDjango formsCRUD servicesDjango ORMSQLite schema

Build sequence

  1. Name the real-estate entities and cardinalities before choosing model fields.
  2. Use foreign keys for ownership and explicit junction models where a relationship carries its own data.
  3. Build CRUD paths around the user role responsible for each record.
  4. Create fixtures that exercise relationships, not just isolated rows.
  5. Inspect generated migration SQL and keep schema changes reviewable.

Repeatable database setup

python manage.py makemigrations
python manage.py sqlmigrate properties 0001
python manage.py migrate
python manage.py loaddata demo_portfolio

Failure modes & troubleshooting

Fixture loading fails on a related record.

Load dependencies in a stable order and avoid signal handlers that assume related objects exist while fixtures are raw.

A many-to-many change would replace an existing join table.

Inspect the migration first and separate the database operation from Django's model state when preserving data.

Role-specific fields make the core user or property table sparse.

Move distinct role data behind explicit relationships instead of accumulating nullable columns.