ETL

Extract, transform, load: moving data from sources through a transformation step into a destination where it becomes useful.

ETL is the plumbing behind every dashboard and integration: extract data from source systems (APIs, databases, exports), transform it (clean, join, reshape, aggregate), and load it into a destination where analysis happens. The modern variant is ELT, load raw data first and run the transformations as SQL inside the warehouse, because storage and compute are cheap enough to re-run history on demand.

Why it matters to an indie builder: nearly every data question you will have, real MRR by plan, activation by signup source, churn overlap with support tickets, requires joining data that lives in different systems. Nobody ships a join across Stripe, your app database and a spreadsheet by hand for long. At indie scale the correct tool is usually a scheduled script and SQL; heavyweight orchestrators earn their keep only after several pipelines already exist and hurt.

A concrete example: revenue reconciliation. A nightly job extracts yesterday's invoices and subscription events from Stripe, loads them into a billing schema in Postgres or DuckDB, and a SQL view joins them with the users table to compute MRR by plan and cohort. Forty lines of Python, twenty seconds of runtime, and it replaces a manual spreadsheet ritual that used to eat an afternoon a month and was wrong by Wednesday. When sources multiply, connector tools like n8n or Airbyte standardize the plumbing.

Common mistakes: transforming inside the pipeline, where a logic error means history is gone (load raw, transform in views, so fixes replay), non-idempotent loads (re-running a day must not double revenue: upsert on natural keys), silent failures (a pipeline that dies quietly produces confident wrong dashboards; alert on row-count anomalies), and adopting an orchestrator before two boring cron jobs have proven the questions. The automation and analytics blocks on IndieBoot cover the sensible middle of that tooling range.