No‑Code یا Low‑Code؟ انتخاب پلتفرم، TCO و خروج

ساخت یک فرم در دو روز با ساخت یک محصول قابل اداره فرق دارد. در No‑Code ممکن است Demo سریع باشد، اما اولین تغییر Permission، افزایش تعرفه، محدودیت API یا نیاز به خروج نشان دهد هزینه واقعی فقط زمان Drag-and-drop نبوده است. Low‑Code نیز اگر Development، Test، Rollback و Owner نداشته باشد، «کد کمتر» را به «کنترل کمتر» تبدیل می‌کند.

این راهنما برای انتخاب و اجرای No‑Code/Low‑Code در کسب‌وکار ایرانی نوشته شده است: تعریف Scope، Use case، ارزیابی Platform، امنیت، داده، ALM، TCO، Lock‑in و Exit test. وضعیت منابع در ۶ اوت ۲۰۲۶ (۱۵ مرداد ۱۴۰۵) بررسی شده است؛ رتبه‌بندی ثابت Vendor یا قیمت منقضی ارائه نمی‌کنیم.

No‑Code و Low‑Code دقیقاً چه هستند؟

No‑Code امکان ساخت Interface، Data model و Workflow را عمدتاً با ابزار بصری و Component آماده می‌دهد. Low‑Code نیز توسعه بصری دارد اما Extension با Code، API، Plugin یا Component سفارشی را بیشتر پشتیبانی می‌کند. مرز این دو استاندارد واحدی ندارد و Vendorها بر اساس Positioning خود از برچسب استفاده می‌کنند.

«بدون کد» به معنی بدون منطق، تست، امنیت یا عملیات نیست. Expression، Formula، Permission rule و Workflow همان نرم‌افزارند، حتی اگر Syntax عمومی نداشته باشند.

WordPress فقط «سایت‌ساز محتوا» و ذاتاً ناتوان نیست؛ CMS extensible است و با Plugin/Code می‌تواند Workflowهای زیادی بسازد. سؤال درست این است که پیچیدگی موردنیاز با چه هزینه، کیفیت و Exit path پیاده می‌شود. برای دامنه، امنیت و محدودیت مدل رایگان، راهنمای سایت‌ساز رایگان را ببینید.

ابتدا نوع مسئله را مشخص کنید

پلتفرم را قبل از Use case انتخاب نکنید. یک Brief یک‌صفحه‌ای بنویسید:

• کاربر چه کسی است و چند نفر/سازمان دارد؟
• Workflow اصلی و Exceptionهایش چیست؟
• چه داده‌ای وارد، پردازش و خارج می‌شود؟
• اگر سیستم یک ساعت/یک روز قطع شود چه اثری دارد؟
• کدام Integration، SLA، Latency و Volume لازم است؟
• چه Permission، Audit و قانون نگهداری داده نیاز دارید؟
• مزیت متمایز محصول کجاست و چند بار تغییر می‌کند؟
• در خروج از Vendor چه Artifact و داده‌ای باید باقی بماند؟

چه پروژه‌هایی معمولاً تناسب بیشتری دارند؟

عنوان «MVP» مجوز بدهی بی‌صاحب نیست. اگر MVP داده واقعی مشتری می‌گیرد یا تعهد مالی ایجاد می‌کند، امنیت و بازیابی از روز اول لازم است.

چه زمانی Custom یا Hybrid بهتر است؟

• منطق محصول مزیت اصلی و به‌سرعت در حال تغییر است؛
• Latency، Throughput یا Offline/Realtime سخت دارید؛
• Tenant/Data isolation و کنترل امنیتی ریزدانه حیاتی است؛
• Protocol، Device یا Integration خاص و کم‌پشتیبانی دارید؛
• Data residency، On-prem یا Source access الزام قراردادی است؛
• هزینه License در Scale از ساخت/عملیات کنترل‌شده بیشتر می‌شود؛
• Exit و Portability برای تداوم کسب‌وکار حیاتی است.

Hybrid می‌تواند UI/Workflow داخلی را Low‑Code نگه دارد و Domain service حساس را Custom API بسازد. اما هر مرز API، Auth، Monitoring و Ownership می‌خواهد. برای انتخاب مرز و سرویس مستقل، راهنمای Monolith و Microservices مفید است.

Decision matrix را قبل از Demo پر کنید

قابلیت را بسنجید، نه فهرست Logoها را

فهرست «بهترین Platform» بدون Use case و تاریخ، تصمیم‌یار نیست. یک Vendor ممکن است برای اپ داخلی Microsoft-centric عالی و برای محصول عمومی چندمستاجری نامناسب باشد. Platformها، Pricing و Region policy تغییر می‌کنند؛ امتیازدهی را با Requirement خودتان انجام دهید.

۱. Data model و Query

نوع داده، Relation، Unique constraint، Transaction، Index، Search، Aggregation، Pagination و Migration را بررسی کنید. UI ساده ممکن است پشت صحنه Query پرهزینه یا N+۱ بسازد. محدودیت Record، Attachment، API call و History را در Plan واقعی بخوانید.

برای هر Entity، Source of truth و Owner مشخص باشد. Sync دوطرفه بدون Conflict policy داده را متناقض می‌کند. آیا Bulk export با ID، Timestamp، Relation و فایل‌ها ممکن است یا فقط CSV صفحه جاری می‌دهد؟

۲. Workflow و Exception

Happy path را همه Demoها نشان می‌دهند. Duplicate، Timeout، Approval منقضی، لغو، Partial failure، Retry و Compensation را بسازید. Workflow باید Status قابل مشاهده، Idempotency key، Dead-letter/Failure queue و اقدام دستی امن داشته باشد.

اگر Platform Transaction سراسری وعده می‌دهد، Scope را بخوانید. ارسال Email و ثبت Payment در یک Atomic transaction معمولاً ممکن نیست؛ Reconciliation لازم است.

۳. هویت و مجوز

Authentication را با Authorization یکی نگیرید. SSO/MFA ورود را کنترل می‌کند؛ باید بررسی کنید چه کاربری به کدام Record، Field، Action و Tenant دسترسی دارد. Rule فقط در UI کافی نیست؛ API/Connector/Export نیز باید enforce شود.

• Role/Group و Least privilege؛
• Record/row-level و field-level access؛
• Tenant isolation و تست IDOR/BOLA؛
• Service account غیرشخصی و Rotation؛
• Break-glass با ثبت Audit؛
• Joiner/Mover/Leaver automation؛
• Export/Share/Embed permission.

۴. Integration؛ Connector مساوی Contract نیست

Connector آماده زمان شروع را کم می‌کند، اما Version، Scope، Pagination، Rate limit، Retry، Error mapping و Owner آن را بررسی کنید. آیا Vendor Connector را نگه می‌دارد یا Marketplace ناشناس؟ آیا Raw API escape hatch دارید؟

Webhook باید Signature، Timestamp/replay protection و Idempotency داشته باشد. Secret در Formula، Client bundle یا Shared credential نگذارید. برای Inventory و کنترل Endpoint از راهنمای امنیت API استفاده کنید.

۵. Extensibility و Escape hatch

Custom code فقط مزیت نیست؛ Runtime، SDK version، Sandbox، Dependency و Deployment خودش را دارد. مشخص کنید Code کجا اجرا می‌شود، چه Permission و Resource limit دارد، چگونه Test/Scan می‌شود و پس از Upgrade Platform چه کسی آن را نگه می‌دارد.

اگر برای نصف قابلیت‌ها Escape hatch می‌نویسید، شاید Platform Fit ضعیف است. نسبت Custom component و Workaround را در Pilot ثبت کنید.

۶. UI، دسترس‌پذیری و فارسی

Drag-and-drop خروجی قابل دسترس را تضمین نمی‌کند. Keyboard، Focus، Label/Error، Contrast، Screen reader، Zoom و Reduced motion را روی Component واقعی تست کنید. RTL، فونت فارسی، اعداد، تاریخ شمسی/میلادی، Sorting و جست‌وجوی حروف فارسی/عربی را بررسی کنید.

Custom CSS ممکن است Upgrade را شکننده کند. White-label، Domain، Email template، SEO metadata و Performance را در Plan موردنظر Vendor بسنجید، نه در Demo Enterprise.

۷. Performance، Scale و Quota

«Cloud scale» معیار نیست. Scenario عدددار بنویسید: Concurrent user، Record، File، Workflow run/min، API call، Peak و Latency P95. محدودیت Hard/soft، Throttling، Queue، Region و Overages را از Contract و تست بگیرید.

۸. Observability و Audit

Dashboard مصرف با Audit امنیتی فرق دارد. Log باید Actor، Action، Resource، Result، Time و Correlation ID داشته باشد. Export Log/API، Retention، Alert و دسترسی SIEM را بررسی کنید. آیا می‌توان از یک شکایت کاربر تا Workflow run و API call را دنبال کرد؟

برای Business metric، Queue age، Failure rate، Workflow duration و Manual retry داشبورد بسازید. Uptime عمومی Vendor، Availability اپ خاص شما را ثابت نمی‌کند.

۹. Backup، Restore و Disaster recovery

«Vendor Backup دارد» پاسخ کامل نیست. چه چیزهایی Backup می‌شود: Data، File، Schema، Workflow، Secret/Config، User/Permission و Audit؟ Retention، Frequency، Region و Restore granularity چیست؟ مشتری می‌تواند Restore را درخواست و زمانش را آزمایش کند؟

Export CSV جای Backup قابل بازیابی نیست. RPO/RTO و Runbook را با راهنمای بازیابی فاجعه طراحی و Restore drill اجرا کنید.

۱۰. Support، SLA و تغییر Vendor

SLA Credit لزوماً زیان کسب‌وکار را جبران نمی‌کند. Severity، Response/restore target، کانال Support، زبان/Timezone، Status history و Incident report را بخوانید. Deprecation policy، Notice، Version pin و Migration tool برای Connector/API/Runtime مهم‌اند.

TCO واقعی؛ اشتراک ماهانه فقط یک سطر است

فرمول ساده:

TCO سه‌ساله = License/Usage + Build + Operate + Change + Expected risk + Exit

سه سناریوی Base، Growth و Peak بسازید. تخفیف سال اول، حداقل تعهد و قیمت Enterprise را جدا کنید. هزینه «تا ۹۰٪ کمتر» بدون Scope، Quality و Horizon قابل دفاع نیست.

مدل‌های قیمت‌گذاری و تله‌ها

• Per-user برای اپ عمومی با کاربر زیاد می‌تواند نامناسب باشد؛
• Per-run اتوماسیون در Loop/Retry جهش می‌کند؛
• External/guest user ممکن است License جدا بخواهد؛
• SSO، Audit، Environment، Backup یا Custom domain گاهی Plan بالاتر است؛
• AI feature می‌تواند مصرف/Token و Retention متفاوت داشته باشد؛
• Overage، Tax، ارز و پرداخت واسط در ایران TCO را تغییر می‌دهد؛
• خروج Data یا نگهداری Redirect/Archive ممکن است هزینه داشته باشد.

Vendor Lock‑in یک طیف چندبعدی است

قفل‌شدن همیشه بد نیست؛ ممکن است ارزش سرعت از هزینه خروج بیشتر باشد. باید آن را آگاهانه قیمت‌گذاری و Trigger خروج را تعریف کنید.

Exit test را قبل از قرارداد اجرا کنید

1. Data و File را با ID/Relation/Timestamp کامل Export کنید.
2. Schema، Formula، Workflow و Permission را به Specification قابل خواندن تبدیل کنید.
3. یک نمونه را در Storage/DB مستقل Import و Count/Checksum مقایسه کنید.
4. Webhook/API consumer را به Adapter جایگزین وصل کنید.
5. Domain، DNS، Email و Identity owner را بررسی کنید.
6. زمان، هزینه، Downtime و Missing artifact را ثبت کنید.
7. Contract termination، data deletion و Backup retention را با Vendor تطبیق دهید.

اگر خروج نیازمند Rewrite کامل است، اشکالی ندارد به شرط آنکه Scope، داده قابل انتقال، زمان Dual-run و هزینه در Business case آمده باشد.

Security مسئولیت مشترک است

امنیت Infrastructure Vendor، Rule و Data sharing اشتباه Maker را خنثی نمی‌کند. OWASP Citizen Development Top 10 در نسخه جاری ریسک‌هایی مانند Blind trust، Account impersonation، Authorization misuse، Sensitive data leakage، Component، Misconfiguration، Injection، Asset management و Logging failure را پوشش می‌دهد.

Threat model برای Low‑Code/No‑Code

Data flow رسم کنید: User، Platform، Connector، API، Storage، Admin و AI model. برای هر Trust boundary، Spoofing، Tampering، Disclosure، Availability و Privilege escalation را بررسی کنید. Test را از UI فراتر ببرید: Export، Mobile client، API، Shared link و Automation credential.

Blind trust به Template/AI/Connector را فرض عملیاتی بدانید. Component آماده را از نظر Publisher، Permission، Update، Vulnerability و Data destination بررسی کنید.

Secure SDLC هنوز لازم است

NIST SSDF 1.1 نسخه نهایی جاری است؛ نسخه ۱٫۲ در Snapshot فعلی Draft باقی مانده است. اصول Prepare، Protect، Produce و Respond را می‌توان با Platform capability تطبیق داد: Requirement امنیت، محیط امن، حفاظت Artifact، Review، Test، Vulnerability response و Provenance.

No‑Code فایل کد کمتری در اختیار شما می‌گذارد، اما Configuration و Solution artifact همچنان Supply chain و Change history دارد. کنترل را بر Outcome پیاده کنید، نه فقط ابزار Static code scan.

Data classification و Privacy

• Public/Internal/Confidential/Restricted و داده شخصی را مشخص کنید؛
• Field-level ضرورت، Purpose و Retention بنویسید؛
• Region، Subprocessor، Backup و cross-border transfer را بررسی کنید؛
• Test environment را با داده Synthetic یا Maskشده بسازید؛
• Export/Analytics/AI training و Opt-out را از Contract بخوانید؛
• Deletion request باید در Platform و Connector downstream اجرا شود؛
• Log و Prompt نباید Secret/PII غیرضروری بگیرد.

Governance برای Enable کردن است، نه ممنوعیت کور

اگر Business نیاز فوری دارد و IT فقط منع می‌کند، Shadow app به Account شخصی می‌رود. Governance خوب مسیر سریع کم‌ریسک، Review متناسب و Escalation برای Workload حساس می‌سازد.

Inventory باید App/Flow، Owner، User، Data، Connector، Last use، Criticality و Expiry را نگه دارد. Orphan app پس از خروج Maker یک ریسک تداوم است.

Center of Excellence کوچک و عملی

CoE لازم نیست کمیته بزرگ باشد. یک تیم Enablement می‌تواند Template، Component approved، Environment، Training، Office hour، Review و Dashboard بسازد. Product owner همچنان مسئول Outcome است؛ Platform team Guardrail و Paved road می‌دهد؛ Security/Privacy برای Tier پرخطر Gate دارد.

راهنمای رسمی Microsoft برای ALM صریحاً هشدار می‌دهد Low‑Code workload را Low complexity فرض نکنید و سطح Formalization را با Complexity/Criticality تنظیم کنید. این اصل Vendor-neutral است، هرچند ابزار هر Platform فرق دارد.

محیط پیش‌فرض را Production نکنید

Development، Test/UAT و Production باید جدا باشند؛ Maker با دسترسی Admin شخصی در Production نسازد. Data، Secret، Connector credential و Config برای هر Environment جدا و Deployable باشند. Copy کردن دستی Screen/Flow میان حساب‌ها Traceability را می‌شکند.

ALM حداقلی

مستند ALM در Power Platform Governance، Change tracking، Audit، Deployment control و Rollback را جزو Lifecycle می‌داند و Source control و CI/CD را توصیه می‌کند. نام ابزار Vendor-specific است؛ اصل Delivery تکرارپذیر عمومی است.

Testing برای اپ بصری

• Rule/Formula test برای Boundary و Exception؛
• Permission matrix با نقش و Tenantهای مختلف؛
• Contract test برای API/Connector/Webhook؛
• Failure test برای Timeout، Duplicate، partial success و Retry؛
• Migration test برای Schema/Data/Plan upgrade؛
• Load/Quota test برای Peak؛
• Keyboard/Screen reader/RTL/Localization؛
• Backup/Restore و Exit rehearsal.

Test automation capability Vendor را در Pilot اثبات کنید. اگر UI test شکننده است، Logic را در Component/API قابل تست جدا کنید. Gate و Rollback عمومی را با راهنمای CI/CD امن هماهنگ کنید.

AI app builder؛ سرعت بیشتر، Blind trust بیشتر

Prompt می‌تواند Schema، UI و Code/Workflow بسازد، اما Requirement مبهم را حل نمی‌کند. Generated artifact را از نظر AuthZ، Secret، Dependency، Injection، Error handling، License و Data flow بررسی کنید. اگر Vendor فقط Preview بصری می‌دهد، مالکیت Runtime/Code و امکان Maintenance را بخوانید.

Prompt و Sample data ممکن است به Model/Vendor ارسال شود. Data policy، Training opt-out، Retention و Region را بررسی کنید. AI را Author امنیتی یا Reviewer نهایی فرض نکنید.

ملاحظات ایران

• ثبت‌نام، احراز، پرداخت ارزی و احتمال محدودیت حساب را قبل از Build آزمایش کنید؛
• Contract/Export/Domain باید در مالکیت سازمان و قابل بازیابی باشد؛
• Latency و Availability Runtime/CDN/API را از داخل ایران بسنجید؛
• Connector درگاه، پیامک، تقویم شمسی، RTL و جست‌وجوی فارسی را PoC کنید؛
• داده حساس و الزام میزبانی/انتقال را با متخصص حقوقی بررسی کنید؛
• قیمت ارز، واسطه پرداخت، Plan upgrade و Exit را در TCO وارد کنید؛
• Fallback عملیاتی و Export دوره‌ای خارج از Platform داشته باشید.

Self-host label را دقیق بخوانید: آیا Runtime، Builder، Database، update و license همگی قابل میزبانی‌اند یا فقط Agent/Connector؟ On-prem هزینه Patch، Backup و Operations را به شما منتقل می‌کند.

Vendor due diligence

Badge بدون Scope و تاریخ Evidence نیست. Controlهای Vendor را با Responsibility شما Map کنید و Gapها را در Risk register بگذارید.

PoC چهارهفته‌ای

1. هفته اول: Requirement، Risk tier، Exit criteria و دو Platform shortlist.
2. هفته دوم: Vertical slice با AuthZ، Data و یک Integration واقعی.
3. هفته سوم: Dev→Test→Prod، Load/failure، Log، Backup و Restore.
4. هفته چهارم: Change scenario، Export/Exit، TCO و Feedback Maker/User/Admin.

Demo Vendor را PoC ننامید. داده Synthetic ولی Shape واقعی، Plan خریدنی و Region مورد استفاده را تست کنید. Success metric شامل Time-to-change، Error، Permission correctness، P95، Operability و Cost باشد.

Scorecard انتخاب Platform

هر معیار را ۰ تا ۵ و وزن را ۱ تا ۵ بدهید. Security/Data/Exit برای Workload پرخطر Gate هستند؛ مجموع بالا نباید نمره صفر حیاتی را جبران کند.

برنامه ۳۰/۶۰/۹۰ روزه پذیرش سازمانی

Backlog بدهی Platform، Workaround و Custom component را ثبت کنید. برای امتیازدهی و جلوگیری از انباشت، راهنمای بدهی فنی را به Governance وصل کنید.

اشتباه‌های رایج

• انتخاب Platform از روی Demo، Logo یا فهرست «بهترین‌ها»؛
• تضمین کاهش ۸۰–۹۰٪ هزینه یا ساخت هر محصول در چند روز؛
• فرض اینکه No‑Code دانش فنی، امنیت و Testing نمی‌خواهد؛
• ساخت Business-critical app در Account/Environment شخصی؛
• کنترل Permission فقط در UI و Shared credential؛
• یکی‌دانستن Connector آماده با Integration قابل اعتماد؛
• ذخیره Secret/PII در Formula، Prompt، Log یا Client؛
• رفتن مستقیم از Development به Production بدون ALM؛
• محاسبه فقط Subscription فعلی و نادیده‌گرفتن Usage/Exit؛
• بررسی Export پس از Vendor lock-in؛
• فرض اینکه Self-host یا Enterprise Plan همه ریسک را حل می‌کند؛
• ممنوعیت کامل و سوق‌دادن Makerها به Shadow IT.

چک‌لیست نهایی خرید و اجرا

• Use case، Risk tier، User/Volume و Quality attribute عدددار است.
• No‑Code/Low‑Code/Custom/Hybrid با یک Matrix مقایسه شده‌اند.
• Vertical slice شامل Exception، Permission و Integration واقعی است.
• Data owner، Source of truth، Export، Retention و Region روشن است.
• Threat model، AuthZ، Secret، Component و Logging آزموده شده‌اند.
• Dev/Test/Prod، Source control، Pipeline، Approval و Rollback دارید.
• Performance، Quota، Failure، Backup/Restore و SLO تست شده‌اند.
• RTL، فارسی، Accessibility و Deviceهای هدف تأیید شده‌اند.
• TCO سه‌ساله در Base/Growth/Peak و اثر ارز محاسبه شده است.
• Exit test و Artifact/زمان/هزینه Migration قبل از قرارداد ثبت شده است.
• Owner دوم، Support، Incident و Decommission plan وجود دارد.
• قابلیت‌های Region/Plan خریدنی، نه Demo، را تأیید کرده‌اید.

جمع‌بندی؛ سرعت ساخت را با قابلیت تغییر و خروج بسنجید

No‑Code و Low‑Code می‌توانند فاصله مسئله تا نرم‌افزار را کوتاه کنند، اما کیفیت خودکار تولید نمی‌کنند. بهترین Use case جایی است که Component و Workflow آماده با نیاز هم‌راستاست، Risk قابل کنترل است و تیم از Speed برای یادگیری یا بهبود عملیات استفاده می‌کند.

قبل از Commitment، Permission، Failure، Deployment، Restore و Exit را در همان Plan و Region واقعی آزمایش کنید. معماری‌ای که فقط Demo را سریع می‌کند ولی تغییر و خروج را گران، صرفه‌جویی نکرده؛ هزینه را به آینده منتقل کرده است. برای Shortlist، PoC، TCO یا Governance می‌توانید درخواست مشاوره فنی Mindio را ثبت کنید.

سؤالات متداول No‑Code و Low‑Code

تفاوت اصلی No‑Code و Low‑Code چیست؟

No‑Code ساخت را عمدتاً با Component، Data و Workflow بصری انجام می‌دهد؛ Low‑Code مسیرهای بیشتری برای Code و Extension دارد. مرز Vendorها یکسان نیست. قابلیت‌های واقعی API، Runtime، ALM، Security و Export را بسنجید، نه فقط برچسب محصول.

آیا برای No‑Code هیچ دانش فنی لازم نیست؟

برای Prototype ساده ممکن است Syntax کدنویسی لازم نباشد، اما Data model، Logic، Permission، API، Error handling، Test و Privacy همچنان دانش می‌خواهند. هرچه اثر و پیچیدگی بیشتر باشد، Review مهندسی/امنیتی مهم‌تر می‌شود.

آیا No‑Code همیشه ارزان‌تر از توسعه اختصاصی است؟

خیر. زمان شروع می‌تواند کمتر باشد، اما License/Usage، محدودیت، Admin، Custom workaround، Scale و Exit روی TCO اثر دارند. سناریوی Base/Growth/Peak سه‌ساله را با کیفیت و ریسک یکسان مقایسه کنید؛ درصد صرفه‌جویی عمومی معتبر نیست.

آیا می‌توان اپ No‑Code را به سرور خود منتقل کرد؟

بسته به Platform متفاوت است. بعضی فقط Data export، بعضی Package/Code محدود و بعضی Runtime self-host/managed ارائه می‌کنند. حتی Export code ممکن است بدون Runtime/Dependency قابل نگهداری نباشد. یک Exit test واقعی قبل از قرارداد انجام دهید.

بهترین پروژه برای شروع No‑Code در سازمان چیست؟

Workflow داخلی کم‌ریسک با Owner مشخص، داده غیرحساس، User محدود و Outcome قابل سنجش معمولاً شروع خوبی است؛ مانند Approval یا داشبورد Read-only. همان پروژه را با Inventory، Dev/Test/Prod، Backup و Expiry اجرا کنید تا Governance نیز آزمایش شود.