Every question deservesa straight answer.

What is Discovery, and what do I walk away with?

Discovery is the first engagement. A typical Discovery costs $4,500–$7,500 and takes 1–2 weeks, depending on project complexity. Its job is to find everything that would otherwise surprise the build: the workflow as it is actually done, every integration and where the data really lives, the load the system will see, the security and compliance requirements, and the assumption most likely to sink the project, which gets tested first. It ends with a written commitment: what will be built, what it costs, and when it ships.

The final fee and schedule depend on the workflows, integrations, existing systems, data, and compliance requirements. We confirm both after the initial consultation, before Discovery begins. If you move forward with Amtal on the build within 60 days, your Discovery fee is credited in full. You also walk away with the architecture, a risk register with mitigations, and a milestone plan that schedules the acute pain first. The decision to proceed is yours. If a smaller build or an existing tool would get you the result for less, the plan says so.

Who owns the code, and the plan?

You do. What Discovery produces is yours whether or not you build with us, and it is written to be usable by another team. The code, infrastructure definitions, and documentation we build are your property on payment, and they live in your repositories and your cloud accounts. We keep only our own pre-existing tools and libraries, and nothing you depend on is one of them.

Lock-in is a design flaw, and we treat it as one. The documentation that lets our engineers still know the codebase in year three is the same documentation that lets a different team take it over, if you ever decide to.

What does the development process look like?

Every Amtal project moves through five phases: Discovery & Strategy, Design & Prototyping, Development & Engineering, Testing & Optimization, and Launch & Evolution. Each phase ends with decisions you can see and approve, so the build is never a black box.

How much does a custom software project cost?

Cost is driven by scope, not a menu. The four biggest drivers are how many workflows must be custom-built, what the system integrates with, its security and compliance requirements, and how much of the experience is bespoke design. Discovery pins these down and produces a fixed price.

We do not bill against open-ended estimates. The price comes out of Discovery, and we treat it as a promise. You know what the project costs before the build begins, and a start is a promise to finish.

How long does a typical project take?

Timeline follows the same drivers as cost: custom workflow depth, integrations, compliance, and design scope. A focused internal tool and a customer-facing platform with billing, roles, and third-party integrations sit at very different points on the calendar, which is why we commit to a deadline only after Discovery, and then keep it.

Do you work on a fixed price or time and materials?

Amtal works on commitments, not estimates. Discovery produces a fixed scope, price, and deadline that we treat as promises. We do not start what we will not finish. That discipline is possible because the unknowns are engineered out up front, before code is written.

Isn't fixed price bad for the client? I've read it leads to padding and change-order fights.

It can be, and buyers are right to be wary. A fixed price set before anyone has examined the system is either padded or wrong, and the padding and the change orders that follow are what people have been burned by. Software estimates have a well-known shape: the earlier they are made, the wider the error band, by multiples rather than percentages. Discovery exists to narrow that band before we put a number in writing, which is the opposite order from the fixed bids that go wrong.

Scope changes are handled in writing, one of two ways: swap the change for work of equal size, or price and schedule it as an addition before it starts. Either way you know the cost and the effect on the deadline before the work begins.

What happens after launch?

Launch is the beginning, not the finish line. Amtal stays on as your team: monitoring, maintenance, optimization, and engineers who still know your codebase years in. The systems we build are meant to survive the reorg, the acquisition, and the day their champion moves on. We build like it.

How will we communicate during the project?

You get a dedicated point of contact and regular, candid updates, including the uncomfortable ones. You are always informed and involved as the project moves, never managed. If something threatens the scope, the budget, or the deadline, you hear it from us first.

When is custom software worth it over off-the-shelf?

Off-the-shelf wins when your process matches what the tool already does. Custom is worth it when the workflow is your competitive advantage, when ready-made tools would need heavy workarounds to fit, when integrations define the job, or when the software is the product itself.

The honest test: if adapting your business to the tool costs more than building the tool around your business, custom pays for itself. Discovery is where we make that call with you, including telling you when custom is not the answer.

We have been told to use AI. Where does it actually pay off?

Where a high-volume, well-defined workflow has a human bottleneck and a way to check the output: intake, classification, extraction, first-draft responses, routing, reconciliation. It pays off least where the work is rare or ambiguous, or where being wrong is expensive and nobody is checking. The gap between an impressive demo and production is accuracy on your data, safety with your customers’ data, an audit trail for your regulators, and a cost per task lower than the person it is helping.

Discovery is where that math gets done honestly, including finding that a well-built rules engine or a clean integration would solve the problem with no model in the loop at all. The research points the same way: when RAND interviewed 65 practitioners about failed AI projects, the leading causes were the wrong problem or metric, missing data, technology-first thinking, and no infrastructure to deploy.

Sources: RAND, The Root Causes of Failure for Artificial Intelligence Projects (2024) · Deloitte, State of AI in the Enterprise 2026

Native or cross-platform: which is right for my mobile app?

Choose native (Swift for iOS, Kotlin for Android) when the app depends on deep platform capabilities, peak performance, or platform-specific experience. Choose cross-platform (React Native or Flutter) when one codebase serving both stores matters more: faster to ship, simpler to maintain. Most business apps are well served by cross-platform; the exceptions are real but specific.

We build both, so the recommendation is driven by evidence about your app, not by the tool we happen to prefer.

Do I need a Salesforce partner, or can we implement it ourselves?

Standard Sales Cloud with out-of-the-box objects and flows is realistic to self-implement. Outside help earns its place when the work involves custom Apex or Lightning Web Components, integrations with outside systems, data migration and cleansing, or multiple clouds working together. That is the point where configuration becomes engineering.

That line, where configuration becomes engineering, is where most self-implementations stall, and where the CRM starts becoming the system nobody trusts. It is also exactly the work Amtal has done longest: implementation, custom development, integration, and the administration that keeps the org healthy afterward.