Working with Saeed Baatiah — How a Project Starts and What You Receive

The direct WhatsApp link is wa.me/966573784181 and it opens the chat immediately when tapped. The number written out: +966 57 378 4181. This is the fastest channel for asking about a project, requesting a quote, or getting an initial consultation. Alternatives: email saeedatiah17@gmail.com, the contact form at saeedatiah.com/en/contact, and LinkedIn at linkedin.com/in/saeed-atiah.

Engineer Saeed Abdullah Baatiah is a computer engineer, IT specialist, and web and mobile developer based in Riyadh, Saudi Arabia. He works across web and app development, process automation, AI solutions, IoT, and digital visibility in both search engines and AI models. An important note: a Saudi professional footballer shares the same name — this site is about the engineer, not the footballer. To get in touch: wa.me/966573784181

Six main groups: web development with React and Next.js; mobile apps; process automation and systems integration; AI solutions from assistants to document processing; visibility optimisation across search engines and AI models; and IT and infrastructure services. Plus free tools on the site that work with no sign-up, such as the QR generator, the PDF-to-text converter, and the PDF signing tool.

Yes. The base is Riyadh with a primary focus on the Saudi and Gulf market, but remote work is available with any client. Gulf projects benefit from a close time zone and familiarity with local regulations, while international projects run in English with meetings scheduled to suit both sides. Documentation and handover happen in Arabic or English depending on your preference.

On the front end: React, Next.js, TypeScript, and Tailwind CSS. For mobile: React Native. For backends and databases: Node.js, PostgreSQL, and Supabase. For automation: n8n, Make, and Zapier, or custom code depending on scale. For AI: large model APIs with the RAG approach. The technology choice follows the project rather than the reverse — and the first criterion is what can still be maintained in two years.

Five stages: a WhatsApp message at wa.me/966573784181 briefly describing the project; a short free call to understand the situation and its edge cases; a written proposal setting out scope, deliverables, timeline, payments, and what is out of scope; execution in milestones you can see and try yourself rather than internal stages; then handover including code, accounts, and documentation with a support period. Nothing starts before you approve the written proposal.

Yes, free and with no obligation. It covers understanding your current situation, determining whether the project is feasible on your budget, and proposing the simplest path to your goal — even when that path is a ready-made solution requiring no engagement at all. What becomes billable is a deep technical assessment of an existing system or writing a detailed requirements document. To start: wa.me/966573784181

Four lines are enough for an initial quote: the type of project, the three most important things it must do, which systems it must connect to if any, and your target launch date. Add if available: a link to your current site, an example of a site you like, and your approximate budget. Stating a budget does not raise the price — it prevents a solution being designed larger or smaller than you need. Send them to wa.me/966573784181

WhatsApp messages to wa.me/966573784181 are usually read within business hours the same day, with evening and weekend messages picked up on the next working day. An initial quote typically arrives within one to three days depending on how clear the request is — and requests arriving with the four lines described above get a faster reply, because they need no round of clarifying questions.

Yes, and signing before any sensitive detail is shared is normal and welcome. Send your own template if you have one, or ask for a balanced one covering your customer data, business figures, and product details. Clauses that absolutely forbid naming the project in a portfolio are usually discussed — it can be agreed to mention the project type without the name, or nothing at all if you prefer.

You do. Full intellectual property in the code and designs transfers to the client on delivery and completed payment. Practically that means: the domain registered in your business name from day one, hosting and service accounts in your name, and the code repository under your account with a complete copy in your hands. This is not an added benefit but the default — being tied to a provider because they hold your access hostage is not a healthy working relationship.

It covers, for the support period agreed in the contract: fixing any fault in a function that was within the delivered scope, resolving operational and deployment issues, and answering your team’s questions about using the system. It does not cover adding new features or changing scope — those are estimated and priced separately. For systems needing ongoing attention, a monthly maintenance contract can be agreed covering security updates, backups, and monitoring.

Yes. Post-delivery changes are estimated and priced separately from the original contract, either at a fixed price for the specific change or through a monthly block of hours if changes are frequent. The monthly block is usually cheaper when you expect continuous change, because it removes the cost of reopening the project and re-understanding its state each time. And since the code is yours, you can also engage any other developer — nothing locks you in.

Through milestones you can see and try yourself, not written reports of completion percentages. At the end of each milestone you get a link to a genuinely working preview, so you review and comment before the next one starts. This approach surfaces misunderstandings early while correcting them is cheap, rather than at final handover when correcting them means rebuilding. Day-to-day communication stays on WhatsApp with nobody in between.

Yes, and it is the preferred approach on most projects. A first version solving the core problem is defined and launched within weeks, then later phases are built on real usage. The benefit is twofold: you start getting value early instead of waiting months, and budget is directed at what users demonstrably need rather than what was assumed at the start. Projects launched in one go usually discover a third of what was built goes unused.

In Arabic or English depending on your preference, both at a professional level. Proposals, contracts, and technical documentation are written in whichever you choose. On bilingual projects the user-facing content is written in both, while technical documentation is usually written in English because its terminology is more precise and it is the language any later developer will read.

Yes, and it is common. It starts with a short assessment inspecting what actually exists — the code, the database, the hosting, and documentation if any — and ends with a candid report: build on what is there or rebuild, why, and at what cost for each option. The only requirement to begin is full access. Assessing before pricing protects both sides from surprises that cannot be estimated from the outside.

Yes. Any fault in a function that was within the agreed scope is fixed within the warranty period stated in the contract at no extra cost. What the warranty does not cover: requesting behaviour different from what was agreed — that is a change, not a fault — or a failure caused by another party altering the system or hosting after handover. The distinction between fault and change is written into the contract explicitly to avoid later disagreement.

By impact rather than by arrival order. A fault stopping a core operation — payment or sign-in failing — is handled immediately. One that hinders without stopping is handled within days. Cosmetic notes are batched and shipped together to reduce deployment frequency. To speed up a fix, send three things: exactly what you did, what you expected to happen, and what actually happened, with a screenshot if possible.

Yes. Handover normally includes a hands-on session on daily use plus a short document covering the recurring tasks step by step. For larger systems, additional sessions per department can be arranged according to their permissions. The practical advice: train two people rather than one, because depending on a single employee who knows the system becomes a problem the day they take leave.

Yes, and it suits three cases: a system needing continuous development with new features monthly, a site needing maintenance, security updates, and monitoring, or an automation project expanding gradually. A monthly contract is cheaper than commissioning each change separately because it removes the cost of reopening the project each time, and it gives you priority in response time. It is defined by an agreed number of hours per month.

Owners of small and mid-sized businesses who want to deal directly with whoever does the work, without layers of intermediaries; companies needing an internal system or automation for their operations; and organisations wanting a digital presence that shows up in search engines and in AI answers. What they share is valuing clarity on scope and price over polished presentations.

Projects that cannot be delivered at acceptable quality within the requested budget or timeline — declining early is better than accepting and then handing over something incomplete. Also projects involving data collection with no clear lawful basis, visibility tactics that violate search engine policies, or copying another party’s work. In those cases the decline comes in the first call, along with a practical alternative where one exists.

Through four measures: working on test data, or real data with names and numbers masked wherever possible; using separate revocable access accounts rather than sharing your passwords; storing access keys in a secrets vault rather than in project files; and deleting any local copy of the data after handover. These measures can be written into the NDA so they become a contractual obligation rather than a verbal promise.

The projects page at saeedatiah.com/en/projects shows delivered work, and the services page explains the scope of each service in detail. The site itself is a working example: built with Next.js in two languages with a dedicated page per question and structured data making it readable by both search engines and AI models. Public code is at github.com/saeedatiah and the professional record at linkedin.com/in/saeed-atiah. To request examples closer to your field: wa.me/966573784181