FacadeLab

FacadeLab is a set of calculation instruments for facade and structural engineers. I co-built it, and my half was the platform underneath the calculators: authentication, the subscription and billing tier, the data layer, deployment, and the offline behaviour that makes the tools usable on a site where there is no signal.

That division is worth stating plainly. The calculators themselves — panel weights, aluminium mullion strength checks, inertia requirements for multi-span mullions — were written by my collaborator. What I built is the part that has to hold up while someone uses them badly: a session that survives a dead connection, a subscription state that stays coherent across an install, and a deployment that does not become my problem at 2am.

Why an engineering tool has to work without a network

Engineers do not sit at a desk with wired ethernet. They stand on a floor, in a plant room, or halfway up a facade with a laptop and a phone hotspot that is having a bad day. A calculation tool that assumes connectivity is a tool that fails at exactly the moment it is most needed — on site, where the number matters.

So the offline path is the primary path, not a fallback. State is cached locally, reconciled when the connection returns, and the UI never blocks on a request that could wait.

What authentication actually has to survive

Auth on an installed PWA is harder than auth on a tab. The app can be launched cold from the home screen with no network, days after the last successful request, and it still has to know who it is showing data to.

The failure mode is specific and bad: showing a signed-in user’s cached calculations to whoever next opens the app on the device. The mitigation is to treat a stale session as a session that has to prove itself before it is allowed to render anything private — and to be willing to make the user sign in again rather than guess.

Why subscriptions are harder offline than online

Online, a subscription is a lookup. Offline, it is a promise you cannot yet check, and the client has to decide whether to honour it.

The honest answers are boring and worth stating:

• Treat an unverified entitlement as unverified. Show the tool, gate the export, and say why.
• Never cache a “yes” you cannot invalidate. A revoked subscription that works until the next sync is a bug someone notices at the worst time.
• Say which state you are in. A user who is offline and still has Pro features should be told that, not left to infer it from the absence of an error.

What I would do differently

The honest limitation of the current approach is conflict resolution. Right now the offline queue is last-write-wins, which is fine when a device has one user and one role. It is wrong the moment two people edit the same record from different devices, and that is the case I would handle next.

FacadeLab is live at facadelabcorp.com. If you are an engineer and something in it is wrong, I would rather know.