Six areas of work, built from what has actually shipped across twenty published apps. Each one lists the specific deliverables underneath, so you know exactly what you are buying before the first call.
Android and iOS from one codebase, architected to survive its second year rather than just its launch week. Clean Architecture, a state layer chosen for the problem instead of by habit, and a folder structure the next developer can read without a handover call.
Founders building a first product, and companies replacing two separate native apps with one team.
An app that already exists but crashes, lags, or nobody on the team can safely extend. Starts with a written audit so you get a real diagnosis before committing to a rebuild, and often the answer is that a full rewrite is not needed.
Teams who inherited a codebase, apps that stalled after a contractor left, and AI-generated builds that will not ship.
The last mile that stops more apps than any bug does. Signing, provisioning, review rejections, privacy declarations and the specific reasons Apple sends a build back with a message nobody can decode. Thirty-four live store listings shipped across two platforms.
Anyone whose app is finished but stuck in review, or who has never published to the App Store before.
The part where money actually moves, and the part most likely to fail silently in production. Includes regional gateways that generic developers have never touched, which matters if you are selling in the Gulf, Lebanon or West Africa.
Marketplaces taking commission, subscription apps, and anyone whose payment provider is not Stripe.
Not a chatbot bolted onto a home screen. AI wired into the product where it changes what the app can do, with cost control and graceful failure built in from the start. Already live in two published apps, in Arabic and in six European languages.
Products where classification, transcription or advice is the feature, not a demo.
For teams shipping mobile without a senior mobile voice in the room. Architecture decisions, a code review culture that people actually follow, and mentoring that raises the floor rather than creating another dependency. Currently leading a Flutter team, previously a Flutter trainer.
Agencies scaling a mobile practice, and startups whose developers are strong but junior.
The same sequence whether it is a new build or a rescue. You see working software early and often, not a big reveal at the end.
A call, then a written scope covering features, platforms, integrations and timeline. Anything unclear gets flagged now rather than in month two.
Folder structure, state layer, data models and API contracts agreed before feature work starts. This is the decision that determines whether year two is cheap or expensive.
Weekly builds you can install and use. Progress is measured in working screens, not percentages on a chart.
Signing, store listings, review submission and rollout. Then a handover with documentation so your team is not stranded.
Pick the one that matches how much certainty you have right now. Most clients start with an audit and move up from there.
A fixed-scope review of an existing app, delivered as a written report with prioritised findings and a recommended path.
A defined scope with a fixed deliverable, from first commit through to a live listing on both stores.
Monthly capacity for architecture decisions, code review and mentoring, alongside your existing team.
Both. Roughly half the published work was built while leading a team of five to twelve developers, and the rest was delivered directly. If you have developers already, the usual arrangement is architecture and review rather than writing every line.
Yes, and that is a common starting point. It begins with an audit so you get an honest diagnosis before committing money to a rebuild. Often the answer is that the app is salvageable and a rewrite would be waste.
Firebase is handled end to end, including Auth, Firestore, Storage, Cloud Messaging, Remote Config and security rules. For custom backends the work is on the integration side, consuming REST or GraphQL and coordinating contracts with your backend team.
Implementation of an existing design, yes, including Figma handoff and building a reusable component library. If there is no design at all, that is worth raising early so it can be planned rather than improvised mid-build.
Every role since 2023 has been remote with international teams across Lebanon, the UAE, the Netherlands and the United States. Overlap hours get agreed in the scope rather than assumed.
Project builds include a post-launch support window for issues that surface in production. Beyond that, ongoing maintenance runs as a retainer. Either way you receive the full source, the signing keys and documentation, so you are never locked in.
React is part of the toolkit and is relevant for web-based AI-generated projects, but the published portfolio is Flutter. For anything where a track record matters, mobile is the honest recommendation.
Describe the problem instead of the solution. The first reply will tell you which of these actually applies, including if the answer is none of them.