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, we reuse the application patterns and operating knowledge we already have. The brands share operational standards, but hosting is selected for each workload. Our edge applications and managed cPanel hosting use different platforms. Reusing what works is what lets one small operating team manage six 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 reuse that shape where it fits. Our managed cPanel hosting platform dates to 2015 and has been refined since; our edge applications run on platforms suited to their workloads.

We push to production directly. There is no review board and no QA team. Anything that needs a second look goes out on a preview branch first, but there is no permanent staging copy of the site waiting for a release train. 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, and 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 six brands (QRLynx, Zawjni, Menujo, Lebseh, CVPoet, Bloomvite) are each their own product with its own marketing site, its own customers, its own pricing, its own roadmap. They share an operating team, reusable application patterns, 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 built our hosting platform in 2015 and have refined our infrastructure and operating practices since.

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.