Back to the NaorX spine
If you skim this blog in order, you already noticed something: some posts zoom out to AI trends, and some are pure tech explainers without a client name. Both help SEO and learning. What was missing is one piece that ties it to how I actually work week to week.
I am Naor Cohen. Under the NaorX brand I build websites and web systems, bots for any platform, including WhatsApp, Discord, Telegram and more, and automations plus integrations (payments, CRM, sheets, third-party APIs). Not a campaign agency, and not a slide-design studio. I sit on the side of what ships to production and stays there while real customers use it.
This post is for people landing from searches like WhatsApp bot development, small business website Israel, or freelance developer Tel Aviv who want to know how the engagement feels before they send a message. No empty promises, and no generic service-page voice.
What actually sits under "NaorX"
In most projects I work as a single builder who still owns architecture and delivery. That does not always mean solo forever, but it does mean one person understands how the pieces connect: forms, permissions, database, a bot talking to the server, and an admin screen someone opens on a normal Tuesday.
Websites and web systems
From marketing sites with smart forms, through stores and order flows, to admin panels, reports, and payment wiring. Often PHP and MySQL, sometimes Node, depending on what the client already runs.
Bots
WhatsApp (including Business API realities: approvals, template messages, limits), Discord (commands, website tie-ins, sometimes huge member counts in one system), and Telegram when the product model fits.
Automation and integration
This is the "connect two systems" lane. I wrote a dedicated piece on APIs and integration because it is its own world. Short version: expect logs, errors, and staging, not a magic button.
Why this matters to you as a client
When someone writes concretely about what they build, how phases unfold, and where projects actually stall, it is easier to judge fit for your business. The goal here is less "keyword stuffing" and more clarity before the first call.
Israel 2026: what breaks the "global default" template
Businesses here still live heavily on WhatsApp. It is not "another channel" - it is often the first sales and support channel. A good bot therefore respects Meta constraints and the time of a human agent on the floor or in the office.
For sites: RTL, local phone formats, addresses, company numbers, accessibility expectations belong in planning on day one, not as a last-minute patch. If you read my Core Web Vitals and revenue article, remember speed without a clear story does not save anyone.
Payments: Israel mixes local providers, cards, and sometimes digital wallets. In builds I often meet infrastructure like Hyp or Tranzila - not to push a brand, but because each vendor has its own terms, docs, and webhook flow. I am not here to sell a vendor, but I do need to understand failed transactions, how to verify callbacks, and what a real success screen looks like for a user who does not care about backend drama.
A typical delivery path (shortened for clarity, not a contract)
Every project shuffles the order a bit, but five beats repeat almost always.
1) A tight discovery call
Not only "how much." Also who uses the system, what timeline exists, what already runs, and what would count as failure. If we cannot answer the last part, we pause before code.
2) A scope you can test
Capability list, one full flow example, and a clear approver. This intersects with my other writing: WhatsApp bot pricing explains why the same word "bot" can 10x in price - usually different scope, not someone being "cheap" or "evil".
3) Build with mid-flight checks
I prefer showing something working early, even if a bit ugly, over a big-bang reveal. It prevents the classic "but I thought it was automatic" fight.
4) Staging and client sign-off
When payments, forms, or customer-facing bots are involved, someone from the business must click the real buttons before launch.
5) Launch, short monitoring, warranty
Launch day is not the finale. There is a window where edge bugs appear, and external vendors change rules. For ongoing care, see my website maintenance article if you plan to keep the system alive longer than a month.
What you get beyond the code
Some projects include access to my Workspace (a Trello-like task board) so status is visible without pinging WhatsApp twice a day. Not mandatory for everyone, but it cuts noise when multiple people sit on the client side.
Beyond that, I keep short internal docs: where critical knobs live, how to change copy safely, and what counts as a new change versus a bug. Boring now, cheap later.
When someone says mid-project: "wait, we forgot something important"
It happens almost every time, and that is fine. What is not fine is pretending it is a "tiny fix" when it is actually a new flow or a new field that rewires logic. In those moments I pause, translate it into words both sides can mentally sign, and only then continue coding.
Why say this in a public article? Because buyers are tired of copy that hides real project friction. When you talk about the friction honestly, trust is easier to build before day one.
Security and privacy at a level a business owner understands
I will not promise "full zero trust" in one sentence, but I do care about role separation, passwords not stored in plain text, baseline protections against common abuse, and not collecting data you do not need (especially in bots and forms). If regulation or enterprise requirements exist, they enter scope during discovery.
Examples of project types (without breaking client confidentiality)
- Discord service systems with permissions, logs, and a tie-in to an external site that manages reviews or operational data.
- Merch or commerce sites with carts, payments, and basic reports for whoever truly runs inventory.
- WhatsApp bots that book appointments or collect details and update a sheet or system - including the case where users type free text, not only tap buttons.
- Wiring two existing services: forms, CRM, or payments - with a field mapping table instead of "looks the same to me".
If something in that list sounds like your project, good sign. If every line feels foreign, you might need a different specialist - also legitimate.
How this connects to other posts (without repeating them)
- AI: I wrote about where AI is worth it versus waste. NaorX is not an "AI agency" - I use models when they fit the problem.
- Legacy systems: the patch, upgrade, rewrite guide stays relevant when I join an existing stack.
- Picking a vendor: if you are comparing developers, my how to choose a developer article is the checklist.
- Project handover: what a client should receive at the end of a digital project - access, docs, tests, and warranty.
Great fit vs weak fit
Especially strong fit if you need someone who connects customer-facing channels (WhatsApp, site, receipts) to data reality (database, APIs, reports), and you are willing to talk scope instead of demanding a one-line quote.
Weaker fit if you want a template site lifted with zero questions, or a project with no clear owner who can approve flows. Without an owner, every project ends the same way: "that is not what I imagined."
Summary
NaorX is not a buzzword stack. It is sites, bots, and automations that enter the real life of a business, in Hebrew, with local payments and support habits people already know. This article is here so you know upfront how working with me tends to feel - without the "I assumed that was included" surprise.
Project that mixes a site, a bot, or wiring into an existing system?
Use the contact form on the homepage. In two sentences: what hurts and what already exists - we can split it into sane phases.
Need help with your project?
Whether it's a website, bot, automation or something else - I'm here to help you build a solution that works
