How Jag Journey, LLC designs, builds, tests and ships its own software, and the principles behind each decision.
100 posts
When a website moves to our platform, every image, font and file comes with it. Here is why we never leave a page depending on the old host, and how w...
Our websites load their fonts from our own servers, not from a public font service. Here is how that choice helps privacy, reliability and page speed.
Hiding an action in the interface does not stop someone from performing it. Here is how we check permissions on every page, action, download and backg...
In a platform where many customers share one system, every line of code must know whose data it is touching. Here is the checklist we use to keep it t...
A setting can live in the database, in server environment values or in a default configuration file. Here is the order we check them in and why it mat...
When records come from another system, keeping their original identifiers makes imports safe to repeat and relationships possible to rebuild. Here is...
Many products with many payment integrations multiply risk. Here is why Jag Journey routes its own charges through one shared payment hub, and what st...
Passing tests and a successful release are not the same as a feature working for a person. Here is how signed-in browser checks give us that final evi...
When a check cannot be completed, software has to choose between allowing and refusing. Here is why we design money, access and AI features to refuse...
Imports change a lot of data at once, so we never start one without a verified recovery point. Here is how the automatic backup step works and why it...
Some of our code runs on public pages with no customer account at all. Here is how we write shared code that works safely in both places without crash...
Testing everything equally means testing nothing especially well. Here is how we focus our testing on money, permissions, customer data and the paths...