Backend and API development in Chicago
A load tender arrives by EDI, the carrier's tracking API reports the truck delivered, and the proof-of-delivery photo turns up two days later by email. In Chicago freight and logistics, the backend's real job is to reconcile events that arrive late, out of order and in three formats, and to keep a shipment's state honest when its sources disagree.
We build and repair those backends in Node and Python on PostgreSQL. EDI documents such as 204 load tenders, 214 status updates and 210 invoices are parsed into one event model, every inbound message is stored raw before it is interpreted, and processing is idempotent so a resent file changes nothing. Queues are monitored, retries do not duplicate invoices, and when two sources disagree the system flags it for a person instead of picking one silently.
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.
We read the code, write down what it does versus what everyone believes it does, and give you the list of the five things most likely to page someone at night. Then we fix those first.
Usually queries, not architecture. We profile under real traffic, fix the plans and the indexes, and only then discuss whether anything needs splitting apart.
A mobile client, a partner integration, a public API. We design the contract first, version it properly, and write the docs your consumers will read.
Jobs that silently vanish, retries that duplicate charges, a queue nobody monitors. We make it idempotent, observable, and boring.
A moderated messaging backend where sends acknowledge in-band and the review runs behind them.
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.
Can you work in our existing codebase?+
Yes, and it is most of what we do. We do not require a rewrite as a condition of working with you. If we think a rewrite is genuinely the right call we will say so, with the reasoning and the cost, and you can decide.
What if the backend is in a language you do not list?+
Then we will tell you. We are useful in Node, Python and TypeScript. We can read Go and PHP well enough to migrate off them. We would not take a Rust or Elixir project and learn it on your budget.
Do you write tests?+
For anything with money, permissions or data loss in it, yes. We do not chase a coverage number. We will tell you which parts are covered and which are not in the handover notes.
Who owns the code?+
You do, from the first commit. Repositories live in your organisation. If we set them up, we transfer them before the first invoice.
What happens when the engagement ends?+
You get runbooks, architecture notes and a recorded walkthrough. We stay available for questions for a month at no cost, because a handover that needs us on retainer is not a handover.