SaaS development in Chicago
Selling SaaS to a large Chicago insurer, manufacturer or logistics company means winning over its IT department before you reach its users. They will ask for single sign-on, user provisioning, a change history, data export, and a clear account of who can see what. They will also expect to pay on an annual contract and an invoice, not a card. A product without those answers waits in procurement while its champion loses patience.
We build SaaS with those requirements designed in rather than bolted on after the first deal: tenant isolation enforced in every query, SAML and OIDC sign-in, roles that customers administer themselves, change history they can export, and billing that copes with annual contracts and invoices as well as cards. The architecture notes are written as we go, so your answers to a large buyer's IT team are short and true.
Chicago's software buyers are mostly not startups selling to other startups. The city's economy rests on trading and derivatives, around CME Group and the proprietary trading firms that grew up beside the exchanges; on freight and logistics, because this is where much of the country's rail and trucking traffic meets; on insurance, from carriers to the brokers and agencies around them; and on manufacturing and distribution across the Midwest. These are established, profitable businesses, and a good deal of their software is older than some of the engineers who maintain it.
So the work is integration and modernisation more often than a blank page. Freight systems speak EDI and carrier APIs that disagree about what happened to a load. Insurers run on policy administration systems nobody wants to replace and everybody wants to build around. Trading firms keep their latency-critical code with in-house specialists, and buy the layer around it: risk and reconciliation reports, operations dashboards, internal tools and data pipelines. The strongest pitch in Chicago is rarely a rewrite. It is a clean, documented system built beside the old one, with work moved across one piece at a time.
Built In puts the average base salary for a software engineer in Chicago at around $133,000, and every employer in the city competes with the trading firms for the same engineers. The result is a familiar backlog: the carrier integration that has to be done properly once, the agency portal everyone complains about, the internal tools the engineering team is too busy to reach. Those are defined pieces of work, which suits an engagement. It starts with a fixed-price two-week piece, and the code belongs to you from the first commit.
We move our working day for Illinois. Four hours of every working day overlap with your morning in Central time, stand-up included, so calls, reviews and decisions happen live with the engineer who writes the code. Everything decided or discovered is written down in your repository and tracker, and runbooks and architecture notes are written as we go, so the system built beside the old one is documented from its first day.
We are the right fit for a defined piece of modernisation, an integration that has to be done properly once, or the internal tools your own engineers are too busy to reach. Senior capacity starts within days, the first piece is a fixed-price two-week engagement, and agencies serving Chicago's insurers can put the work under their own name.
Four ways this arrives.
Then SCIM, then role mapping, then a security questionnaire. We add SAML and OIDC through a provider or your own identity stack, provision users from their directory, and keep the permission model working for the self-serve customers who never asked for any of it.
Shared tables with a tenant column and every query trusted to filter on it. We enforce isolation below the application, with Postgres row-level security or separate schemas, and write tests that try to read across tenants and must fail.
Moving from seats to usage, adding a free tier, or selling annual contracts beside monthly plans. We model plans and entitlements separately from the payment provider, meter usage into a ledger you can audit, and make proration and dunning tested code rather than a monthly surprise.
Every larger customer asks who changed what, who can reach production and how access ends when someone leaves. We build exportable audit logs, least-privilege access and change control through pull requests, so your answer is a screen, not a spreadsheet.
A multi-tenant platform scoped per organisation, with admin screens for users, access and login alerts, and a way for an administrator to view the app as any user.
Read the write-up →Asked by Chicago teams.
How do you work with teams in Chicago?+
We are in Bengaluru and move our working day for Illinois, so four hours of every working day overlap with your morning in Central time, stand-up included. Calls, reviews and decisions happen in that window. The rest of the work lives in your tools: messages in Slack, code in GitHub, tickets in Linear. The person on every call is the engineer who writes the code, so a question about the system gets answered by the person who built it.
Do you build for Chicago freight and logistics companies?+
Yes. The work is usually the layer that turns messy events into a shipment you can trust: EDI load tenders, status updates and invoices parsed into one event model, carrier tracking APIs reconciled against it, and proof-of-delivery photos from a field app that works offline. Around that sit the operations screens a brokerage floor uses all day, and the pipelines that turn loads and lanes into pricing and margin reports.
How does your rate compare to hiring in Chicago?+
Built In puts the average base salary for a software engineer in Chicago at about $133,000, before benefits and bonus, and you are competing with trading firms for that person. Our published rate is $35/hour, or $5,400 a month for an embedded engineer, with a $5,000 minimum. There is no recruiting time and no employment overhead, and work starts within days. A fixed-price two-week first piece at $2,800 lets you judge us on output.
Can you build alongside our existing systems rather than replacing them?+
Yes, and in Chicago that is most of the work. We read the old system, write down what it actually does, and build the new piece beside it. Work moves across one workflow at a time, with both running until the last piece lands, so the business keeps running without a cut-over weekend. We did exactly this on FM360, moving a pipeline across module by module rather than in one cut-over.
Shared database, separate schemas, or a database per tenant?+
Shared tables with row-level security for most products, because it is the cheapest to run and the simplest to migrate. Separate schemas or databases when a customer contractually needs isolation, data kept in a particular region, or its own backup schedule. We design so a large tenant can move to its own database later without rewriting the application, because that request usually arrives with the biggest contract.
When should we add SSO and SCIM?+
Before the deal that needs them, not in the first month. Design the user and organisation model so SSO slots in without a data migration, then switch it on when a paying customer asks. A provider such as WorkOS saves you building SAML and SCIM yourself, which rarely pays off until enterprise customers are a large share of your revenue.
Stripe, or a merchant of record like Paddle?+
Stripe gives you the most control over plans, invoices and the checkout. A merchant of record such as Paddle takes a larger fee and becomes the seller, handling tax wherever you sell. For a small team selling internationally from the start, the merchant of record is often the simpler path. We lay out both at your price point before you choose.
Can you make the product ready for enterprise buyers?+
Yes. Enterprise buyers ask for the same things every time: single sign-on, directory provisioning, roles they can define, an audit log they can export, and admin screens their IT team can use. We design those into the data model early, so saying yes to the next large customer is a configuration change rather than a quarter of rework.
What have you built that carries over to SaaS?+
Multi-tenancy, per-organisation access and admin tooling run through most of what we build. FM360 is a multi-tenant platform with all three: organisations, apps and access managed per customer, usage analytics and login alerts. Subscriptions and billing logic we build inside the product, tested like any other code rather than left to a dashboard.