Discovery / בדיקה טכנית
שלב קצר להבנת התהליך, הארכיטקטורה, האינטגרציות ו-scope סביר לגרסה ראשונה.
הערכה שקופה
SCOPE BEFORE PRICEשני פרויקטים שנקראים 'אתר' יכולים להיות שונים מאוד בהיקף. קודם מגדירים את הבעיה, הנתונים, האינטגרציות וגבולות הגרסה הראשונה, ורק אחר כך נותנים מחיר.
אנחנו לא מפרסמים מספר 'החל מ-' מלאכותי. אחרי בדיקה קצרה תקבלו הערכה עם הנחות ברורות והיקף עבודה מוגדר.
ASH STUDIO ≠ ASH PLATFORM
עמוד זה מתייחס לפרויקטים מותאמים של ASH Studio. ASH Platform היא מוצר מנוי נפרד. תמחור מסחרי של Platform יפורסם בנפרד לאחר אישור.
מודלים לעבודה
שלב קצר להבנת התהליך, הארכיטקטורה, האינטגרציות ו-scope סביר לגרסה ראשונה.
מגדירים תוצאה ברורה, גבולות, שלבים ומחיר לפני תחילת הפיתוח.
מתקדמים בשלבים עובדים ומעדכנים סדרי עדיפויות אחרי כל תוצאה שניתן לבדוק.
מה משפיע על העלות
התחברות, הרשאות, אזורים אישיים, מצבים, אישורים וכללים עסקיים מיוחדים.
מודל נתונים, migrations, חיפוש, היסטוריה, קבצים ודרישות שלמות.
CRM, Telegram, תשלומים, APIs חיצוניים, webhooks, retries ומגבלות ספקים.
מספר workflows, מודלים, אימות תוצאה, בדיקה אנושית ושליטה בשימוש.
האם צריך שפה ויזואלית חדשה, ממשקים מורכבים, איורים, כתיבה או לוקליזציה.
Observability, audit, אבטחה, התאוששות ודרישות לפעולות קריטיות.
איך בנויה עלות AI
אנחנו לא מפרסמים מחיר קבוע מומצא ל-AI Receptionist או Custom Agent. קודם מגדירים workflow, integrations ושימוש צפוי.
Discovery, תכנון התנהגות, knowledge, integrations, permissions, validation, QA והשקה של ה-workflow.
שינויי workflow, monitoring, עדכוני knowledge, החלפת providers ושיפור לאחר ההשקה.
עלויות model/API, messaging ושירותי צד שלישי תלויות ב-providers ובשימוש בפועל.
לפני תחילת הפיתוח
מה כלול בגרסה הראשונה ומה נשאר במכוון מחוץ לה.
על אילו הנחות מבוססת ההערכה ומה יכול לשנות את המחיר.
אילו שלבים ניתן לבדוק בנפרד ומה נחשב לתוצאה גמורה.
אילו שירותים חיצוניים ועלויות קבועות יישארו לאחר ההשקה.
למי שייכים הקוד והנתונים ואיך ניתן להמשיך לפתח את המוצר.
כי אנחנו לא רוצים למכור מספר מלאכותי. דף נחיתה, אתר חברה רב-לשוני ומוצר עם CRM יכולים כולם להיקרא 'אתר', אבל אלה פרויקטים שונים. קודם scope, אחר כך מחיר.
כן. בדרך כלל זה עדיף: מגדירים את החתך השימושי הקטן ביותר, משיקים אותו ומרחיבים רק אחרי שרואים שימוש אמיתי.
תקציב הוא מגבלה ארכיטקטונית. אם כל הבעיה לא נכנסת למסגרת, נציע לצמצם scope, לפצל לשלבים או להשתמש בשירות קיים במקום שבו פיתוח מותאם לא מוצדק.
רוצים להבין טווח מציאותי?
בטופס אפשר לציין טווח תקציב, לוח זמנים וסוג פרויקט. זה מספיק כדי להתחיל שיחה מעשית על ה-scope.
קבלת הערכת scope