Web platform development in Seattle
If your customers are Microsoft shops, and many enterprise buyers are, they expect your platform to fit into their tenant. Sign-in through Microsoft Entra ID, access decided by the groups their IT team already manages, and notifications that arrive in Teams rather than another inbox. A platform with its own passwords and its own user list feels like extra work to the people who approve purchases.
We build web platforms that fit that estate. Single sign-on through Entra ID and other identity providers, roles mapped from customer groups, provisioning that removes a leaver's access automatically, and integrations with Teams and SharePoint where they earn their place. We built Teams alerts into FM360's pipeline, so we know how that integration behaves in practice, including when it does not.
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.
We replace the role column with a permission model that can express teams, access to individual resources and roles the customer defines, add SAML or OIDC sign-in, and write the audit log their security questionnaire will ask about.
Or very nearly did. We find every query that can cross a tenant boundary, enforce the tenant in one layer rather than in every handler, and add tests that try to read across that boundary on purpose.
We build the admin side properly: search across organisations, an audited view-as-user mode, and screens for access and usage. Support stops asking an engineer to run a query against production every time a customer says something looks wrong.
An early Next.js app with auth stitched into middleware, a custom server, and a release process that lives in someone's head. We move it forward in small steps, with preview environments and a pipeline anyone on the team can ship from.
A Next.js platform scoped per organisation, where an administrator can view the app as any other user and each Tableau report opens only for people granted it.
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.
What is wrong with a role column?+
Nothing, until you have more than one kind of customer. A role says who a user is; most real questions are about what they can do to one specific thing, inside one specific organisation. Encoded as role checks, every new requirement becomes a code change in many places. We model permissions as data, check them in one place, and test them like any other logic.
Should we use an auth provider or build our own?+
Use a provider for identity: passwords, magic links, SSO and multi-factor. It is a solved problem and getting it wrong is expensive. Authorisation, meaning what a signed-in user may do, is specific to your product and usually belongs in your own code and database. We wire the first to the second and keep the line between them clear.
How do you handle multi-tenancy?+
Usually one database with a tenant ID on every row, enforced in one place: Postgres row-level security, or a data-access layer every query has to pass through, rather than each handler remembering. A separate database per tenant is sometimes right, for one very large customer or strict isolation, and we will say if that applies to you.
Where does it get hosted?+
Wherever suits your team. Vercel is the least effort for Next.js and fine for most platforms. If cost or long-running background work make that awkward, we run it in containers on Railway, AWS or your own Kubernetes. The repository, the cloud accounts and the bill are in your name either way.
What do enterprise customers ask for, and can you build it?+
Single sign-on through SAML or OIDC, audit logs, role management, session controls, encryption and data export. We build each of them into the platform and help you answer the technical questions on a customer's checklist accurately, so the security conversation speeds the deal up instead of stalling it.