How to pick the right service page
Most engagements land on one specific platform from day one, so the service pages are organized by platform rather than by phase. If the project is about Salesforce Marketing Cloud, Sales Cloud, Service Cloud, Revenue Cloud, B2C Commerce, Financial Services Cloud, or Apex Development, start at the Salesforce page. If it is Microsoft Power Platform (Power Apps, Power Automate, Dataverse, Power BI embedded, Copilot Studio), the Power Platform page covers what we ship there. For internal tooling that does not warrant a full custom build, the Retool page covers operations dashboards, admin panels, and workflow apps on Retool plus the line where it stops being the right answer.
For commerce, the Shopify page covers Liquid themes, custom Shopify Apps, Hydrogen storefronts, Shopify Functions, and Shopify Plus migrations. Salesforce B2C Commerce (SFCC, formerly Demandware) work is referenced on the Salesforce page since most teams already know which stack their merchant is on. For AI projects, the AI and machine learning page covers agentic systems, RAG architectures, and the production-readiness work between a demo and a deployed system. The Dynamics 365 page is referenced from the Microsoft cluster; we ship F&O and Business Central implementations as part of the broader Microsoft stack practice.
When platforms alone are not enough, the custom software page covers full-stack builds where the team picks the stack based on the project (Node, Python, Go, .NET, Java are all on the bench). The web app development and mobile app development pages cover Next.js, React, and the mobile stack decisions (React Native, Flutter, FlutterFlow, native iOS and Android) most teams agonize over before kickoff.
If you are unsure which service page matches your project, the contact page is the right starting point. We reply within one business day and will point you at the right page (or to another vendor if the project is not in our wheelhouse). Either way, every engagement starts with the two-week no-commitment trial, direct pricing, and named senior engineers from day one. No agency markup, no minimum commitment, no bait-and-switch between proposal and kickoff.
How services map to engagement size
Small engagements (one to three months, one or two engineers, scope under $30k) work well as targeted feature builds, platform-specific patterns we have shipped many times, or short rescue missions on existing systems. The two-week trial is usually the full evaluation period here; if the project is a fit on the trial deliverable, the remaining one to three months is straightforward execution. Most Retool, Shopify theme, and SFMC tactical projects fit this size.
Medium engagements (three to nine months, two to four engineers, $50k to $300k scope) cover the bulk of Sapota's typical work: a Salesforce implementation, a D365 F&O rollout, a custom web application from scratch, an AI agent deployment from prototype to production. The trial here is the first phase of work; the rest of the engagement runs as monthly direct billing with rolling scope adjustments as priorities shift. The engineer composition stays stable across the engagement.
Large engagements (nine months to multi-year, four to ten engineers, $300k plus annual) are the embedded partnership model: Sapota's engineers are part of your ongoing engineering team, not a vendor delivering a project. The team grows and shrinks with your roadmap. Reporting goes through your engineering leadership. Code review and architecture decisions are shared. We run this model with several long-term clients across Salesforce, Microsoft, and AI work.
Project-shape questions to answer before reaching out: what is the platform, what is the target deliverable, what is the timeline, and is there an existing team to embed with or is this a clean greenfield. With those four data points the team can usually propose a fitting engagement model on the first call. If the answer is "we are not sure yet," that is fine too; the first conversation is often the scoping conversation itself.