EnglishLaravel in United States
Laravel development services for US businesses
The US has no single privacy law and no single sales tax, and both facts land in the schema. What a Laravel build has to handle that a European one does not.
Teams building for the United States from outside it usually expect the market to be simpler than Europe. One language, one currency, no GDPR. The first two are true and the third is misleading, because what replaces the GDPR is fifty jurisdictions that do not agree with each other - and the same is true of tax.
Sales tax is not VAT wearing a different name
VAT is a rate per country, occasionally per category. US sales tax is a rate per jurisdiction, and jurisdictions nest: a state rate, plus a county rate, plus a city rate, plus whatever special districts overlap that address. Two customers on the same street can owe different amounts.
There are thousands of these. The boundaries do not follow ZIP codes, which is why address-to-jurisdiction resolution is a real problem rather than a lookup table, and why every serious US application buys the calculation from a service that maintains it.
What stays your responsibility is the modelling around it, and it is not small:
Nexus is a state you track, not a setting. An economic nexus threshold - a volume of sales into a state - creates an obligation to collect there. Crossing it is an event your system should notice, because the alternative is discovering it during an audit.
Taxability varies by product. Software, services, digital goods and physical goods are treated differently, and differently again per state. That is a field on the product, decided by somebody who knows, not a default.
Exemption certificates exist and expire. Resellers and non-profits present a certificate; you store it, apply it, and are liable if it has lapsed. It is a document with a validity period attached to a customer, which is a schema decision.
The rate is a fact about the transaction. Stored on the line item at the time of sale, never recomputed later. A refund six months on uses the rate that was charged.
Privacy is a patchwork you design around, not for
There is no federal equivalent of the GDPR. There is California, which is strict and specific, and a growing set of other state statutes with overlapping but non-identical rules. Sector laws sit on top: health data and children's data each have their own regime with real penalties.
Branching behaviour per state is a trap - it means fifty code paths and a bug in the one nobody tested. The approach that survives is to build to the strictest standard and apply it to everyone:
- A real deletion operation, with a documented list of what is retained anyway for tax and legal reasons.
- An export that produces the data without a developer writing a query.
- A consent record with history rather than a boolean.
- A "do not sell or share" preference that actually reaches the systems data flows into.
The engineering is the same work a European build does. The difference is that in the US it is a commercial decision rather than a legal requirement - and it is much cheaper made once, early, than state by state as each statute arrives.
Payments, and the part that surprises people
Cards behave as they do everywhere. ACH is the one that changes the order model: it is slow, it settles in days rather than seconds, and it can be returned well after it appeared to succeed - including for reasons like "unauthorised", which can arrive months later.
An application that treats an ACH payment as final on receipt will report revenue it does not have. The state machine needs a settled state that is distinct from a received state, and a process for what happens when a return arrives after the goods shipped.
Working with us
We work remotely from Ankara. The overlap with US hours is the morning on the East Coast and the very early morning on the West, so the arrangement that works is asynchronous by design - written updates, reviewable pull requests, and a scheduled call rather than an expectation of availability all day.
The engineering is our usual application development and integration work. What a US engagement adds is that tax is an integration rather than a calculation, and privacy is a design decision taken before the first state statute applies to you.
US teams comparing us with a Rails shop are asking a fair question, and the comparison is closer than either side usually admits. What decides it is hiring and the payments ecosystem, not the two frameworks.
Invoicing and payment. In US dollars, by bank transfer to an IBAN. Codefacture Yazılım A.Ş. is registered in Türkiye and the invoice carries no Turkish VAT, because exported services are exempt. There is no sales tax line on it either. We are not registered in any state.