KaRZMa Code is a software brand. We design, build and publish our own products, and we take on custom software work for people and organisations who need something built properly.
It is founded and led by Mohammed Salem Al-Wosabi, and today he is also the person who maintains it. We say that plainly, because writing as though there were floors of people behind this would be the first thing we got wrong.
The distinction is deliberate. A portfolio is a record of work that has already happened. A brand is a commitment about the work that comes next — a name attached to products that are maintained, documented, and still here next year.
Everything we publish carries this name, and that is the entire reason to have one. If a product is released under KaRZMa Code, it is ours to keep working: to fix, to update, and to answer for.
Software is easy to start and hard to keep. Plenty of it is abandoned soon after launch, or grows until it is heavier and slower than the problem it was built to solve. We wanted somewhere to build the other kind: tools that stay small, stay maintained, and keep doing their job without asking much in return.
That is a modest ambition and the harder discipline. It means refusing good features that belong somewhere else, and treating a release as the beginning of a product's life rather than the end of a project.
KaRZMa Code works in two complementary directions, and the first is the one that defines it.
Products are software we own. We choose the problem, design the solution, publish it under our own name and keep it maintained. LinkNest — an offline-first app for saving and organising links, available for Android and Windows — is the first of them, and the product this entire site was built and tested against.
Services are software we build for someone else: mobile, web, desktop and custom development, shaped around a requirement that already exists rather than one we chose.
The two reinforce each other. Products are evidence — anyone can read what we claim about quality and then go and use something we built to that standard. Services are how the same capability reaches problems we would never have found on our own.
We would rather show the choices than describe them. This site is entirely static, with no server to go down. It was bilingual from its first line rather than translated afterwards, so Arabic is a first-class layout and not a mirrored afterthought. Adding a product to it is a content change, not a rewrite — and that was proven by adding one and removing it again, rather than assumed.
None of that is remarkable on its own. Together it is what lets a small operation ship something that keeps working, and it is the same standard we apply to work we build for other people.
Writing software and running a product are different jobs. Code is finished when it works; a product is finished when someone can find it, understand it in seconds, install it without help, and still rely on it after an update. We plan for the second one, which makes a release a starting point rather than a finish line.
Every feature is paid for long after it ships — in support, in bugs, and in the time it takes anyone to understand the thing afterwards. We would rather release something narrow that works completely than something broad that works approximately. When we turn an idea down it is usually a good idea that belongs in a different product.
Most of a product's life is maintenance, so we write for whoever has to change it later — which is usually us. That means clear structure, one place for each decision, and no clever shortcut that saves an hour now and costs a day in a year. This site is built that way too: its visual values live in a single file, its content is validated before it can ship, and its architecture is written down rather than remembered.
Software is used by people who never asked to become experts in it. We design for the ordinary case before the impressive one: readable type, full keyboard access, both languages treated equally, and nothing that needs a fast connection to be useful. Accessibility and performance are requirements we check against, not polish applied at the end.
We would rather state the current size of KaRZMa Code plainly than imply a scale we have not reached. Nothing on this site describes a product, a capability or a client that does not exist, and where something is an intention we say so in those words. That is far easier to keep from the start than to recover later — and it is what makes everything else here worth reading.
Mohammed Salem Al-Wosabi — Founder
KaRZMa Code was founded and is led by Mohammed Salem Al-Wosabi. Today he is also the one maintaining it: the products, the code, the content and the decisions behind this site are his.
That is context rather than ceremony. Knowing one person stands behind the work explains the shape of it — why the catalogue is deliberately short, why the standards are specific rather than generic, and why everything is documented as though it will one day be handed to someone else.
Detailed personal and career information belongs elsewhere. This site is about the brand and what it builds.
KaRZMa Code is small today and built to grow. The way this site is structured, the way its content is separated from its code, and the way products are added were all chosen with that in mind.
What follows is direction, not announcement. None of it exists yet, and each one will be described as a product only when there is something real to use.
The catalogue is one product deep. We expect it to grow across mobile, web and desktop — each one published, versioned and maintained under the same name, and held to the same standard as the first.
Over time we aim to publish technical writing: what we built, which trade-offs we took, and what we would do differently. Useful to other developers, and an honest record of how decisions were actually made rather than how they look in hindsight.
We envision a place for small, free utilities — the kind that solve one problem for a developer, a student, or anyone who happens to need them, with no account and nothing to install.
People have ideas for software they cannot build themselves. As KaRZMa Code grows we would like a proper way for those to reach us, and for the right ones to become real products. For now that route is simply the contact page.
The brand is deliberately not one person's name, and the work is structured so that it can be handed over. If KaRZMa Code becomes a team, nothing here has to be rebuilt to make room for that — which is the point of building it this way while it is still small.
The products are the argument. The contact page is the shortcut.