MVP development in Chicago
If you spent years inside freight, insurance or trading and now want to sell software back into it, you already know the workflow better than any engineer you could hire. What you need is a first version that proves the product in front of buyers who are sceptical of new vendors, and who will ask on the first call how it connects to what they already run.
We build Chicago MVPs around one real workflow and one real integration, because in these industries the integration is often the product. Scope is fixed, the two-week starter is the usual beginning, and we tell you early what is being left out. The code is yours from the first commit, so when you raise or hire, the repository belongs to you and the handover notes are already written.
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.
Every feature is marked essential. We work with you to find the one journey a user must complete for the idea to be proven or disproven, build that properly, and write the rest down as a list for after launch.
It was built with a no-code tool or over a weekend, and real users are now finding its limits. We keep what works, move the data somewhere you own, and rebuild the parts that break without taking the product offline.
A demo that works in the meeting and then has to become the product. We build it on a real database with real sign-in from the start, so the version you demo is the version you keep, not a mock-up you throw away.
You need someone to make the technical decisions and explain them in plain language. We write down every choice that is expensive to reverse, why we made it and what changing it would cost, so whoever you hire next can pick it up.
Began in 2024 as a script that turned monthly exports into charts, and grew step by step into a web app, a mobile app, a technician phone page and the one backend under all three.
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.
What does the fixed-price two-week starter cover?+
A defined slice of the product, agreed in writing before we start. For an MVP it is usually the core flow, working end to end against a real database. It costs $2,800. You get something running at the end and you keep the code either way, so you can judge us on output before committing to the rest of the build.
How long does an MVP take?+
It depends on what the smallest honest version is, which is why we scope before we quote. The two-week starter usually answers the question: by the end of it one flow works, and you have a written estimate for the rest with its assumptions listed. We would rather cut scope with you than promise a date we would miss.
Why Next.js and PostgreSQL?+
Because they are boring in the right way. Both are widely known, so you can hire for them later. Postgres will carry you a long way past your first paying customers, and Next.js gives you a web app and an API in one codebase. If the product is mobile-first, we build the app in React Native on the same backend.
Will we have to rewrite it later?+
Not if we do our job. The shortcuts we take are in scope, not in structure: fewer features, plainer screens, manual steps behind the scenes. The data model, sign-in, permissions and deploys are built properly from the first week, because those are the parts that force a rewrite when they are wrong.
Who owns the code and the accounts?+
You do, from the first commit. Repositories, hosting, domains and payment accounts are created in your name, not ours. If we set something up ourselves to save time, we transfer it to you before the first invoice. An MVP you cannot take to another team is a liability, not an asset.