Custom software development in Chicago
Chicago's manufacturers, warehouses and distributors run on internal systems that were built for a smaller business. Shift scheduling lives in a spreadsheet, timekeeping in a vendor tool that exports to another spreadsheet, and the order that matters most goes through an Access database or a green-screen system that one long-serving employee knows how to drive. Every new site, shift pattern or product line adds another workaround.
We build internal systems for Midwest operations around how the floor actually works. We sit with the supervisors and the office staff, collect the exceptions they handle from memory, and write the process down before building anything. Then we replace one system at a time with a small, documented web application, with badges or PINs where staff clock in, old data brought across with counts checked against the source, and screens that work on the shared terminal by the loading dock as well as in the office.
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.
Approvals, schedules or stock, tracked in a shared file with colour codes only one person understands. We turn it into an application with proper records, permissions and history, so you can see who changed what and when, and nobody works from an old copy.
Staff copy data from one system into another by hand, and the two slowly drift apart. We connect them through their APIs, clean up the data where it crosses over, and alert someone when a sync fails instead of letting it fail quietly.
The numbers exist, spread across exports and inboxes, and someone assembles a report by hand every Monday. We pull them into one place, build the dashboard the people making decisions will actually open, and check it is current rather than trusting the job that feeds it.
A legacy application still runs the business and every change to it is a risk. We map what it really does, move it piece by piece onto something maintainable, and keep both running until the last piece has landed. No weekend cut-over.
A facilities operations platform for a healthcare estate, built so supervisors can see what is overdue and what keeps coming back without exporting spreadsheets by hand.
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.
Why not buy an off-the-shelf tool?+
Often you should, and we will tell you when. If a product already does most of what you need, configuring it is cheaper than building. Custom software earns its cost when the process is how you compete, when you pay for several tools to do one job badly, or when the workarounds cost more staff time than the software would.
Can you work with the systems we already have?+
That is usually the job. Most internal tools are valuable because of what they connect to: an ERP, a work-order system, a CRM, a finance package. If it has an API, we integrate with it. If all it offers is a nightly export, we can work with that too, and we will tell you how fresh the data can honestly be.
How do you find out what we actually need?+
By talking to the people who do the work, not only the people who asked for the tool. We watch the spreadsheet being used, collect the edge cases everyone handles from memory, and write the process down before we build anything. The first release covers the core of it; the exceptions follow once people are using it.
What happens to our old data?+
It comes with you. We migrate it, check the counts and totals against the source, and keep the old system or spreadsheet readable until your team is confident nothing was lost. Where the old data is inconsistent, we show you the records that do not fit rather than quietly guessing what they meant.
Who looks after it once it is live?+
You choose. We can stay on at our hourly rate for changes and fixes, or hand it to your own team with runbooks, architecture notes and a recorded walkthrough. Internal tools change as the business changes, so we build them to be changed by someone other than us.