Data engineering in Seattle
A Seattle company on AWS can tell you its monthly cloud bill to the cent and still not know what serving one customer costs. The detailed billing data exists, in the Cost and Usage Report, but it arrives as enormous files that nobody has joined to accounts, teams or features.
We build pipelines that turn that billing data into answers. Usage and cost files land in a warehouse every day, resources are mapped to teams and customers through tags and, where tags are missing, through rules you can read. The output is cost per customer, per feature and per team, next to revenue, so pricing and architecture decisions rest on numbers rather than guesses. It is the same append-only, verified approach we run on FM360.
Seattle's software market was shaped by Amazon and Microsoft, and by the cloud platforms they run. Many of the region's startups were founded by people who left one or the other, and they cluster in cloud infrastructure, developer tools, enterprise software and, increasingly, AI. Around them sit life sciences and global health organisations, retail and outdoor brands, and a long tail of companies whose entire estate lives in AWS or Azure. Buyers here have usually run services at scale themselves, and it shows in what they ask for.
The practical effect is more rigour and less explaining. A Seattle buyer expects a written design before code, with the alternatives considered and the reasons one was chosen. They count metrics, alarms and a runbook as part of done, not a later phase, and they want trade-offs stated plainly. Most already have a cloud agreement and committed spend on AWS or Azure, so the job is usually to make that estate tidier, cheaper and better understood. The other common pattern is the founder who left a large company and misses its internal platforms, because at a startup nobody has built them yet.
Built In puts the average base salary for a software engineer in Seattle at around $149,000, and the large employers add stock on top, which is what a startup is really competing against. A senior search can run for months, and the work that waits is often the most concrete on the roadmap: a service split out of a monolith, a migration, a cloud clean-up, a model moved from a notebook into production. Each has a clear finish line, which makes it a good fit for a small team that writes the design first and the runbook as it goes.
We work from Bengaluru with four hours of live overlap every working day, placed across your morning in Seattle. Stand-ups and design reviews happen in that window, with the engineer who writes the code. Everything decided outside it goes into your repository, your tracker and the architecture notes we write as we go, so each day starts with a written record of what changed.
We fit best on work with a clear finish line: a new service, a migration, a cloud clean-up or a model moved into production. We add senior capacity within days while a req stays open, starting with a fixed-price two-week piece. Agencies can bring us in white-label, under their own name.
Four ways this arrives.
Two definitions of the same metric, computed in two places. We pick one, write it as a tested model in version control, and point every report at it, so the argument moves from whose number is right to what the definition should be.
A job reports success while the report still shows yesterday. We give every table a written freshness guarantee, monitor what the reader actually sees rather than the job that feeds it, and alert a person when the guarantee is missed.
A CRM, an ERP or a work-order tool reachable only through its API. We build the sync with retries, rate limits and normalisation at the boundary, and keep append-only snapshots so last Tuesday is a query rather than a restore.
Analytical queries running against the application database at the worst possible moment. We move them to a columnar store, keep Postgres for transactions, and feed one from the other by change data capture or scheduled extracts, whichever the freshness requirement calls for.
A nightly work-order extract into append-only ClickHouse snapshots, with a verifier that reads the live Tableau dashboard to prove it shows the newest data.
Read the write-up →Asked by Seattle teams.
How do you work with teams in Seattle?+
From Bengaluru, with four hours of live overlap every working day placed across your Seattle morning. Stand-ups and design reviews happen in that window, and you talk to the engineer who writes the code. We work in your Slack, your GitHub and your Linear. Designs are reviewed before code, and runbooks and architecture notes are written as we go, so the record lives where your team already works.
Do you work with teams already running on AWS or Azure?+
Yes, and in Seattle that is most teams. We work inside the estate you have: hand-built resources imported into Terraform, serverless functions made idempotent and traced end to end, cloud costs broken down per customer and feature, and AI features built on Bedrock or Azure OpenAI through the access your agreement already covers. The aim is an account that is tidier, cheaper and easier to explain, on the cloud you already pay for.
How does your rate compare to hiring in Seattle?+
Built In puts the average base salary for a software engineer in Seattle at about $149,000, before stock, benefits and recruiting fees. Our published rate is $35 an hour, with a $5,000 minimum. There is no recruiting search and no employment overhead, and we can start within days. The usual first step is a fixed-price two-week piece at $2,800, so you judge us on shipped work before committing to more.
What do the first two weeks look like?+
You share the context, and within two days you have a 30-minute call with the engineer who would do the work. Within a week you get a written plan: the options, the one we recommend and why, and how it rolls out. Then comes a fixed-price two-week piece, built in your repository from the first commit, with the design reviewed before code and the runbook written as it goes.
Do we need a data warehouse yet?+
Maybe not. If your reporting runs comfortably against a Postgres read replica, a warehouse adds a second system to pay for and keep in step. The signs you need one: analytical queries slowing the product, data from several sources that has to be joined, or history you must keep that the application overwrites. We will tell you which side of that line you are on.
Why ClickHouse rather than Snowflake or BigQuery?+
Not always. For steady, high-volume analytical work, ClickHouse is fast and cheap to run, self-hosted or on its managed cloud, and we run it in production. Snowflake and BigQuery ask less of you operationally and suit ad hoc querying across a large team. If nobody on your side wants to operate a database, we will recommend the managed option even when the invoice is larger.
What does a freshness guarantee actually mean?+
A written statement per table or report, such as "never more than an hour behind" or "reflects yesterday's close by 07:00". Each one has a check that measures it and an alert that fires when it is missed. Without it, stale data looks exactly like correct data until somebody makes a decision on it.
Can you work with the tools we already have?+
Usually, yes. If you already run dbt, Airflow, Fivetran or a BI tool your team knows, we build inside it. We suggest replacing a tool only when it is the cause of the problem you hired us for, and we show you the evidence before asking you to fund a migration.
How do you handle personal data in the warehouse?+
We decide what should reach the warehouse at all before building the pipeline. Identifiers can be hashed or tokenised at ingestion, sensitive columns restricted by role, and retention enforced by the pipeline itself. Every field is documented from source to dashboard, so anyone can see where a number came from and who can read it.