Next.js in Chicago
Next.js development for Chicago insurance, logistics and trading
A Next.js development company working with Chicago insurers, logistics operators and trading firms. Documents that have to print correctly, and an accessibility exposure that arrives as a letter.
- Working day overlap
- About two hours. Chicago is nine hours behind Ankara, so our late afternoon is your morning
- Who buys here
- Insurers and brokers, logistics and freight operators, trading and clearing firms, and manufacturers across the Midwest
- What that changes
- A lot of what gets built ends as a document somebody files or sends, so print output is a requirement rather than an afterthought
- Local specifics
- Accessibility exposure in the United States arrives as a demand letter rather than an audit, which changes who needs convincing
Chicago buys software for industries where the output of an application is frequently a document.
Insurance, freight, clearing, manufacturing - the screen is a step, and what comes out the other end is a policy, a bill of lading, a confirmation or a statement that somebody files, sends or is audited against. That makes print a first-class requirement, which modern web development has largely forgotten how to do.
A document is not a web page with a print stylesheet
This is the recurring Chicago problem and it is almost always solved the expensive way first.
A responsive web layout and a paginated document have incompatible requirements. The document needs a known paper size, predictable page breaks, headers repeated on every page, totals that land in the right place and output that is byte-for-byte the same whoever generates it. A web page needs to adapt to a viewport. Printing the second through a stylesheet produces something that differs by browser, by machine and by printer driver, and somebody always finds the version where a table breaks across a page boundary mid-row.
The arrangement that works is a separate route whose job is the document, rendered on the server from the same data, with the PDF generated server-side rather than by the visitor's browser. It is more deliberate and it produces the same file every time, which is the entire point when the output is filed.
Accessibility here arrives as a letter
In the United States the mechanism is not an audit, and that changes the shape of the work.
A demand letter cites specific barriers on specific pages - a form that cannot be completed with a keyboard, a modal that traps focus, an error message that a screen reader never announces. What it does not cite is a score from an automated tool, and what an automated tool does not catch is most of what gets cited.
For an App Router application the failures cluster in the same three places as everywhere, and they are worth naming because they are invisible to a sighted developer with a mouse. Focus is dropped on client-side navigation. A loading state announces nothing. A Server Action's validation error is styled but not programmatically associated with its field.
Fixing those is a fortnight. Being able to show that somebody tested with a keyboard and a screen reader, and wrote down what they found, is what turns a letter into a short conversation.
Internal tools, used all day, on managed laptops
A large share of Chicago work is internal rather than public, and the performance argument for it is different.
Nobody abandons an internal application because it is slow, so the cost is not conversion - it is a hundred people losing four seconds fifty times a day, on a corporate laptop with endpoint security inspecting every request and a proxy adding latency to each one.
That makes round trips and shipped JavaScript the things worth reducing, rather than images. A data-dense screen assembled in the browser from six API calls is six sequential waits; the same screen rendered on the server is one. Where the client boundary sits is the lever, and on an internal tool the saving compounds in a way it never does on a marketing page.
Commercially
Scope fixed in writing before work starts, priced per project. The country-level ground - state privacy laws, sales tax, invoicing in dollars - is on the United States market page.
Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in US dollars by bank transfer, with no Turkish VAT under the export-of-services exemption and no US entity on our side.
