We are a small engineering team in Giza, Egypt. We build and operate Clasify — a multi-tenant SaaS with live video classrooms, payments and white-label domains, running in production on the same infrastructure and the same practices we would hand to you — and we take client builds on the same way. Everything we recommend to you, we have already had to live with ourselves.
The usual arrangement ends at handover. The agency ships, invoices, and moves on; whoever inherits the code discovers the migrations were run by hand, the secrets are in the repository, and nobody wrote down how to roll back a bad deploy.
We run our own product on the same practices we would hand you, which changes what gets built. Backups are restored and verified, not merely configured. Deploys are pinned to an image digest so a rollback is one command. Payments are idempotent because a double charge is our problem at 2am, not a theoretical one.
That is the whole pitch, and it is why this page has one case study instead of a wall of logos: we would rather show you a system you can open in a browser and inspect than a list of names.
Every item here is something we built and still run ourselves — not a service line we have only read about.
React and TypeScript front ends on a Node and Postgres back end — real applications with accounts, permissions and state, not brochure pages.
Flutter for iOS and Android from one codebase, with push on both platforms, secure credential storage, and Arabic localisation and right-to-left layout from the first screen.
The system that replaces the spreadsheet everyone is afraid of: roles and permissions, audit trails, and reports the finance team actually trusts.
Multi-tenant products with subscriptions, plan limits, per-customer branding and custom domains. This is the thing we have built end to end for ourselves.
Gateway integration done properly: idempotent charges, webhook verification and reconciliation, promo codes, subscription renewals, and refund/void reconciliation that survives a dropped connection.
Full right-to-left layout, Arabic plural rules in all six forms, locale-correct date, number and currency formatting, and bilingual SEO with reciprocal hreflang. Retrofitting this into a finished product costs far more than starting with it.
Monitoring, health checks, alerting, encrypted offsite backups and one-command rollback. The parts nobody demos and everybody needs at 3am.
Source, infrastructure, runbooks and credentials are yours. No hostage arrangement, no per-change fee to read your own database.
The same sequence on every engagement, whatever the stack.
A call, then a written breakdown of what we understood, what we would build first, and what we would deliberately leave out of version one. Free, and yours to keep whether or not you hire us.
Work lands in your repository from week one, on an environment you can open. You see progress in the product, not in a status document.
Deployment, backups, monitoring and the runbook to operate it — set up in your accounts, under your ownership, with a walkthrough before we step back.
The questions that actually come up on a first call.
Because that one is unusually deep and completely open to inspection: Clasify is a live multi-tenant SaaS with WebRTC classrooms, session recording, a payment gateway, per-tenant custom domains and a full monitoring stack. Ask and we will take you through a real academy account — the actual dashboard, an actual lesson room — rather than a slide deck. We would rather show you one system you can interrogate than five logos you cannot.
Giza, Egypt. We work with clients in Saudi Arabia, the UAE and across the region remotely — there is no Gulf office and we do not pretend otherwise. Cairo keeps Riyadh's clock through the summer and runs an hour behind it in winter, one to two hours behind Dubai either way, so the working day overlaps almost entirely.
Both, natively. Calls, documentation and code review in either. Products we build ship bilingual by default because we have already solved right-to-left layout, Arabic plural rules and bilingual SEO on our own product rather than reading about them.
It depends entirely on scope, so we do not publish a rate card that would be wrong for your project. What we do commit to is a written estimate before any code is written, and telling you when a smaller version would get you the same result.
Describe the problem in a paragraph or two. You get a written scope and an honest estimate back — including whether we think it is the wrong thing to build.
Every project starts with a scoping conversation and a written estimate before any code is written. No retainer required to talk.