# The ThorOps story: build, run and keep improving | ThorOps

ThorOps grew out of a familiar engineering problem: software gets delivered, but the work of keeping it useful is left behind. In our founder’s experience, the person called after a failed release was often someone who had never been involved in building it. We wanted a clearer way to work.

## One team across the product lifecycle

We are a small product and engineering studio serving teams across the Arab world. We develop web and mobile software, help run it in the cloud, and build security into the delivery process. You speak to the people doing the work, with scope, ownership and responsibilities agreed before it starts.

Arabic and English belong in that process from the beginning. That means thinking about reading direction, forms, navigation and the words people actually use, rather than translating the interface just before launch.

## The products we are building

Our own products keep us close to everyday users and the operational decisions behind a release. The portfolio includes four products at different stages:

- Saleem, live: an Arabic-first app for older adults and caregivers to record health information and share a summary with a clinician.
- Sijil Cloud, in development: workforce attendance, approvals and payroll costs for contractors, with offline workflows planned.
- Hisabli, in development: a simple approach to recording everyday expenses and understanding monthly spending.
- Small Business Digital, in development: a workflow for moving a small business from an initial review through a proposal, delivery and handover.

Explore [Saleem](https://saleem.thorops.com) or see the current [product portfolio](https://thorops.com/#products). A product being in development does not mean it is ready for public use. We will make its status clear as it changes.

## What we will share next

We will publish new projects, product updates and lessons as the work develops. Some posts will explain a technical decision. Others will cover what we changed after listening to users, or what a team should prepare before asking someone to build a product.

Client stories stay anonymous unless we have written permission. We will not turn private systems or sensitive business details into marketing material. The useful part is the lesson, shared with enough context to help another team.

## Start with a real problem

You do not need a long specification to start a conversation. Tell us who has the problem, how they handle it today, and what a better outcome would look like. We can then decide together whether the next step is discovery, a [proof of concept](https://thorops.com/blog/two-week-proof-of-concept/), a first release or support for an existing system.