How we work.

We do not have a roadmap committee. We do not have OKRs. We do not have a "growth team" picking experiments off a quarterly plan. The decision-making process is closer to a long-running conversation with the founder making the final call.

The rough filter for new work is three questions: Does this serve a real audience we already understand? Are we willing to maintain it for ten years? Does it fit on the stack and operating capacity we already have? If any of the three is "no," we pass. Most ideas fail one or more.

When something passes the filter, it gets shipped on the same infrastructure the existing brands run on. We do not start new products with green-field tooling choices. Every brand in the portfolio uses the same hosting platform, the same email infrastructure, the same CDN, the same CMS pattern. That uniformity is what lets one small operating team manage five products.

The marketing site you are reading runs on a modern edge-first stack — server-side rendered framework, global edge delivery, an internal content management layer we built in-house. The brand sites use the same shape with brand-specific tweaks. The hosting stack underneath every Jorbox property is the same managed-control-panel + global-CDN pattern we built in 2015 and have refined since.

We push to production directly. There is no staging environment, no review board, no QA team. We use prerendering aggressively (most marketing pages are static HTML at the edge), server-side rendering for content that needs to be dynamic, and a CMS that the founder edits directly. The deploys take under two minutes from git push to live edge.

That cadence works because the surface area is small enough for one person to hold in their head, and because we trust the people writing the code to also be the people supporting the product. There is no handoff. The cost is that we cannot scale headcount the way a 100-engineer org would; the benefit is that we never need to.

Every customer email is read by the operating team. Not a tier-one outsourced agent. Not an AI triage layer. The same people who write the code answer the questions about it.

This is a deliberate choice — we have a blog post (/blog/why-we-still-answer-our-own-tickets) explaining the reasoning in detail. The short version: tickets are a leading indicator. Five customers asking the same question this month is a product bug we should fix in the docs, the error message, or the default. Outsourced support filters those signals into dashboards nobody reads.

We aim for first reply within 24 hours on weekdays, often much sooner. Edge cases get a real answer from someone who can change the code. We do not have SLAs in the legal-document sense — we have a habit of replying promptly because the alternative is worse for everyone.

Jorbox LLC is the operating company. The five brands — QRLynx, Zawjni, Menujo, Lebseh, CVPoet — are each their own product with its own marketing site, its own customers, its own pricing, its own roadmap. They share an operating team, an infrastructure stack, and an operating philosophy. They do not share customer data, marketing channels, or brand voice.

Each brand has a separate domain (qrlynx.com, zawjni.com, etc.) and is run as if it were its own company. From a customer's perspective, you might use QRLynx for years without ever knowing that Jorbox LLC operates it. From inside, the brands feed each other learnings — a performance optimization that ships on Menujo gets picked up by QRLynx within the week.

jorbox.com (this site) is the parent-company surface. It exists to explain the structure honestly, to host the handbook and blog, and to surface the small client-services arm. It is intentionally not a sales page for any individual brand — those have their own domains.

Jorbox has stayed small on purpose. We bring in additional capacity through contractors when a specific engagement justifies it — a design pass for a brand refresh, a translation effort, occasional client-services overflow. We have never hired aggressively to chase growth, because growth chase is not what the operating principles support.

When we do bring in someone new (employee or contractor), the rough filter is: do they care about the work for its own sake, or are they here for the optionality? The principles page covers the former. The latter is fine and common in this industry; it is just not how Jorbox is shaped.

If you are reading this because you want to work with us, the path is to engage as a contractor on a real piece of work, do it well, and see if there is a longer arc. We do not post job listings. We do not run hiring rounds. We do not have a recruiter pipeline. Everyone currently working with Jorbox came in through a piece of work that mattered.

We do not raise venture capital. We do not entertain acquisition offers. We do not do general agency work; client services are limited to four categories where our own stack already runs (/services). We do not promise SLAs we cannot keep. We do not deploy AI features for the sake of having AI features. We do not chase platform trends — we picked a stack in 2015 and have refined the same one for eleven years.

We also do not pretend Jorbox is bigger than it is. The team is small. The infrastructure is built for a small team to operate. The brand portfolio is sized for a small team to maintain. When someone asks "are you the right partner for a 10× scale engagement," the honest answer is sometimes no, and we say so.